Bug 1302847 - System freezes for ~10s for some actions on Thinkpad W541
System freezes for ~10s for some actions on Thinkpad W541
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 1305772 1309668 1343800 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-28 13:59 EST by Gerard Ryan
Modified: 2017-03-28 13:37 EDT (History)
37 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-05 20:02:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of journalctl -b (503.15 KB, text/plain)
2016-01-28 14:04 EST, Gerard Ryan
no flags Details
output of dmesg (75.25 KB, text/plain)
2016-01-28 14:05 EST, Gerard Ryan
no flags Details
sosreport after getting a lockup at 19:51 local time (5.31 MB, application/x-xz)
2016-01-28 22:59 EST, Thomas Cameron
no flags Details

  None (edit)
Description Gerard Ryan 2016-01-28 13:59:32 EST
Description of problem:
On a Lenovo Thinkpad W541 laptop, if one tries to launch gnome-control-center or switch display brightness (using either the hardware buttons or the slider in the drop-down status menu), the system will not respond to user input and the display will freeze for about 10 seconds.

This machine is one of those that has both intel integrated graphics and an nvidia graphics card also (optimus, is that what it's called?). GNOME reports that the graphics is "Intel Haswell Mobile". dmesg consistently has some output from nouveau (that's the nvidia driver, right?) whenever this occurs:

[110820.755428] nouveau 0000:01:00.0: DRM: resuming kernel object tree...
[110821.404017] nouveau 0000:01:00.0: devinit: 0x64da[0]: script needs connector type
[110825.488831] nouveau 0000:01:00.0: DRM: resuming client object trees...
[110829.493418] nouveau 0000:01:00.0: DRM: resuming display...
[110829.493454] nouveau 0000:01:00.0: DRM: resuming console...
[110835.247341] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[110835.247569] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[110835.247769] nouveau 0000:01:00.0: DRM: suspending console...
[110835.247772] nouveau 0000:01:00.0: DRM: suspending display...
[110835.247791] nouveau 0000:01:00.0: DRM: evicting buffers...
[110835.247793] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle...
[110835.247817] nouveau 0000:01:00.0: DRM: suspending client object trees...

Version-Release number of selected component (if applicable):
kernel-4.3.3-301.fc23.x86_64
xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64

This happens with earlier kernels also, I'm not sure how far back it goes.

How reproducible:
100% on Lenovo W541.

Steps to Reproduce:
1. Install F23 on a W541
2. Launch gnome-control-center

Actual results:
System doesn't respond to any input and display freezes for about 10 seconds.

Expected results:
There is no freeze.

Additional info:
I think there's also the same pause on initial login, but I'm not sure.
Comment 1 Gerard Ryan 2016-01-28 14:04 EST
Created attachment 1119233 [details]
output of journalctl -b
Comment 2 Gerard Ryan 2016-01-28 14:05 EST
Created attachment 1119234 [details]
output of dmesg
Comment 3 Thomas Cameron 2016-01-28 14:32:27 EST
Just a "me, too" post. I am seeing the same thing. 100% repeatable.
Comment 4 John Dennis 2016-01-28 15:29:21 EST
I also see this on a W541 when opening the Gnome settings applet. However I also see a similar hang when:

* starting a Bluejeans session

* when first logging in after a reboot

This might be an incorrect inference but it seems like all three of these scenarios might be when graphics/montior settings are interrogated and/or set.
Comment 5 Dave Airlie 2016-01-28 15:39:21 EST
Does nouveau.runpm=0 on the kernel command line work around this?

To save power we turn the nvidia GPU off when not in use, but some things must poke it and wake it up.
Comment 6 Gerard Ryan 2016-01-28 15:53:10 EST
(In reply to Dave Airlie from comment #5)
> Does nouveau.runpm=0 on the kernel command line work around this?
> 
> To save power we turn the nvidia GPU off when not in use, but some things
> must poke it and wake it up.

That does indeed seem to fix the issue for me. Thanks a lot Dave!

I guess there's some config file somewhere that I can put that so that it persists, is there? Or is this something that would get configured dynamically somehow by a future kernel package?
Comment 8 Dave Airlie 2016-01-28 16:43:38 EST
just note that this will have a pretty severe impact on your battery life.
Comment 9 Thomas Cameron 2016-01-28 18:13:00 EST
My laptop already runs really warm and goes through the battery faster than I'd like. Is there any way to go the opposite way? Instead of turning off power management for the NVidia card, maybe turn the whole NVidia card off completely? Not probe it at all?
Comment 10 Dave Airlie 2016-01-28 22:10:57 EST
could someone get dmesg from

log_buf_len=8M nouveau.debug=trace

remove nouveau.runpm=0 for this.

we'd like to try and work out what is taking 10s here.

This should log a lot of stuff, but hopefully it'll have at least one power on in it, if you trigger the 10s pause.
Comment 11 Thomas Cameron 2016-01-28 22:59 EST
Created attachment 1119339 [details]
sosreport after getting a lockup at 19:51 local time

I got a long hang after I entered my password to log in, and another when I opened up "settings" from within Gnome3. About 17:51 local time.

I added log_buf_len=8M nouveau.debug=trace to the kernel command line to get this.
Comment 12 Thomas Cameron 2016-01-28 23:04:47 EST
Comment on attachment 1119339 [details]
sosreport after getting a lockup at 19:51 local time

Correction, created the lockup at 19:51
Comment 13 David Martin 2016-02-01 06:23:39 EST
I'm unable to reproduce this with F23 on W541 Thinkpad.


lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)


rpm -q kernel xorg-x11-drv-nouveau control-center
kernel-4.2.3-300.fc23.x86_64
kernel-4.3.3-303.fc23.x86_64
xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64
control-center-3.18.2-1.fc23.x86_64


xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x93 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 10 associated providers: 2 name:Intel
Provider 1: id: 0x65 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 2 associated providers: 2 name:nouveau
Provider 2: id: 0x65 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 2 associated providers: 2 name:nouveau
Comment 14 Gerard Ryan 2016-02-01 06:28:29 EST
(In reply to David Martin from comment #13)
> rpm -q kernel xorg-x11-drv-nouveau control-center
> kernel-4.2.3-300.fc23.x86_64
> kernel-4.3.3-303.fc23.x86_64
> xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64
> control-center-3.18.2-1.fc23.x86_64

Of the two kernels that David has installed, the running one appears to be the older one. Since that appears to be the only difference between our setups, I'll reinstall that one later and see if I can reproduce with that.
Comment 15 Jeffrey Cutter 2016-02-03 13:08:08 EST
My W541 with Fedora 23 used to run very warm (it made my left hand uncomfortable, the GPU is right in that area) with very short battery life, presumably for the same reason based on my resolution.  From my notes, I did the following things mostly with the intent of disabling the discrete NVIDIA GPU.  My system runs nice and cool now even when working it hard.  I would not be comfortable recommending these steps (though they have worked for me), but they may prove informative at the least:

1.  Disable nouveau module:

# pwd
/etc/modprobe.d
# cat blacklist-nouveau.conf 
blacklist nouveau

2.  Add acpi_osi=Linux kernel option to /etc/grub2.conf for current kernel.

3.  Install bbswitch package from:

https://fedoraproject.org/wiki/Bumblebee

4.  Enable load of bbswitch module:

# pwd
/etc/modules-load.d
# cat bbswitch.conf 
bbswitch

5.  Set option for bbswitch module to disable the card.

# pwd
/etc/modprobe.d
# cat bbswitch.conf 
options bbswitch load_state=0

6. Reboot

7.  Verify:

# cat /proc/acpi/bbswitch 
0000:01:00.0 OFF

https://github.com/Bumblebee-Project/bbswitch
https://wenlong.wordpress.com/2012/05/01/disable-the-nvidia-discrete-graphic-card-in-a-nvidia-optimus-laptop/
http://pranavk.github.io/linux/disable-your-nvidia-card-in-linux/

Some possibly pertinent details on my W541:

# lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev ff)

# rpm -q kernel xorg-x11-drv-nouveau control-center
kernel-4.3.3-301.fc23.x86_64
kernel-4.3.3-303.fc23.x86_64
kernel-4.3.4-300.fc23.x86_64
xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64
control-center-3.18.2-1.fc23.x86_64

# xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x4a cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 7 associated providers: 1 name:Intel
Provider 1: id: 0x129 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

# uname -r
4.3.4-300.fc23.x86_64

Hope it helps and thanks,
-Jeff
Comment 16 Jason 2016-02-11 13:57:12 EST
I also have this issue following a fresh net install of FF23 and disabling the power mgmt stops the hang issue.
Comment 17 Dave Airlie 2016-02-16 00:49:38 EST
okay I have a better workaround that should keep your battery life as well

can you boot with acpi_osi="!Windows 2013" on the command line and see if it goes away?
Comment 18 Eric Blake 2016-02-16 17:08:40 EST
With kernel 4.3.4-300.fc23.x86_64, the acpi_osi="!Windows 2013" trick indeed makes the worst of the delays go away. I can adjust the brightness on my display with almost instant response, much nicer than the old way of pushing the button and then having no interaction for several seconds.

With kernel kernel-4.3.5-300.fc23.x86_64, I couldn't even get things to boot (not sure why it wouldn't let me unlock LUKS), but that was independent of whether I tried adding acpi_osi, so it appears to be unrelated.
Comment 19 Eric Blake 2016-02-16 17:19:49 EST
okay, kernel-4.3.5-300.fc23.x86_64 not booting was a red herring (for some reason, the older kernel lets me type in my LUKS passphrase from my wireless USB keyboard, but the newer kernel required me to use the laptop keyboard, until further along in the boot process).  I'm not sure if there's something I could do with dracut to make my kernels always recognize my wireless USB keyboard, but that's the topic for another day. For this bug, I can confirm that the acpi_osi setting even with the latest kernel makes a difference (no hangs on operations that affect graphics).
Comment 20 Gerard Ryan 2016-02-17 18:01:21 EST
(In reply to Dave Airlie from comment #17)
> okay I have a better workaround that should keep your battery life as well
> 
> can you boot with acpi_osi="!Windows 2013" on the command line and see if it
> goes away?

Hi Dave,

That's much better than without it, but there's still a brief pause (~2s) compared to setting nouveau.runpm=0. I'm happy to stick with that rather than one of the extremes though! :)

If it's of any use to you, here's what I see in dmesg if I follow it when I switch the brightness.

Straight after the pause:
[  522.879014] thinkpad_acpi: EC reports that Thermal Table has changed
[  522.879079] nouveau 0000:01:00.0: DRM: resuming kernel object tree...
[  523.567083] nouveau 0000:01:00.0: devinit: 0x64da[0]: script needs connector type
[  523.646778] nouveau 0000:01:00.0: DRM: resuming client object trees...
[  523.646857] nouveau 0000:01:00.0: DRM: resuming display...
[  523.646878] nouveau 0000:01:00.0: DRM: resuming console...

Then after a couple more seconds:
[  557.191855] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  557.192085] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[  557.192285] nouveau 0000:01:00.0: DRM: suspending console...
[  557.192289] nouveau 0000:01:00.0: DRM: suspending display...
[  557.192310] nouveau 0000:01:00.0: DRM: evicting buffers...
[  557.192311] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle...
[  557.192340] nouveau 0000:01:00.0: DRM: suspending client object trees...
[  557.197870] nouveau 0000:01:00.0: DRM: suspending kernel object tree...
[  558.427009] thinkpad_acpi: EC reports that Thermal Table has changed
Comment 21 Dave Airlie 2016-02-18 22:31:54 EST
*** Bug 1309668 has been marked as a duplicate of this bug. ***
Comment 22 Erwan Velu 2016-02-19 07:39:05 EST
I've been trying the acpi_osi thing on my system with vmlinuz-4.3.5-300.fc23.x86_64

Dmesg reported it to be disabled :
[    0.082764] ACPI: Deleted _OSI(Windows 2013)

My bios is Version: GNET78WW (2.26) and my video bios version is : 80.07.ac.00.20

I cannot notice any benefits from using the osi setup. I'm trying the pm one now.
Comment 23 Erwan Velu 2016-02-19 07:43:55 EST
The nouveau.pm setting works like a charm (I don't consider here the battery drain). It's so much more fluent.

If I could be helpful are running any test, please feel free to ping me.

Thanks for your support,
Comment 24 Thomas Cameron 2016-02-20 10:48:10 EST
Jeffrey Cutter - your instructions are great, thanks! I might add a few details:

In step 3, you need to use the "dnf install bumblebee-nouveau bbswitch-dkms kernel-devel" option from the Bumblebee page. Just installing bumblebee-nouveau doesn't give you the bbswitch module.

After step 5, you need to create a new initial ramdisk but running "dracut -f" as root before rebooting. 

Once I did those, I was able to see /proc/acpi/bbswitch and everything seems to work fine. 

I am able to use an external monitor with this setup, which was my only concern.
Comment 25 Jeffrey Cutter 2016-02-22 12:16:44 EST
Hi Thomas - Glad it helped.  I'm afraid I didn't take the best notes on step 3 so thanks for   Checking my system though, I have the following:

# rpm -qa | egrep "bumblebee|bbswitch|kernel-devel"
bbswitch-dkms-0.8.0-2.fc23.x86_64
bumblebee-release-1.2-1.noarch
kernel-devel-4.3.3-303.fc23.x86_64
kernel-devel-4.3.4-300.fc23.x86_64
kernel-devel-4.3.5-300.fc23.x86_64

So it would appear the bumblebee-nouveau isn't (or at least wasn't) necessary.

Also, it occured to me my step 2 should probably be add acpi_osi=Linux to the GRUB_CMDLINE_LINUX line in /etc/default/grub and remake the grub config (grub2-mkconfig).  Not sure this step is strictly needed either though.

One last though, I have had to reinstall the bbswitch-dkms and reboot once, perhaps due to failed dkms following kernel update.  My hot left hand tipped me off to the problem...

-Jeff
Comment 26 Dave Airlie 2016-02-22 15:22:18 EST
Unless you are using the nvidia binary driver, please don't go giving advice to use bumblebee.

The fix for this problem right now is acpi_osi="!Windows 2013", the GPU will poweroff under Linux fine then if nouveau is loaded, you don't need to explicitly do anything.

I'm trying to work out with upstream how to support the Windows 10 device model requirements.
Comment 27 Jeffrey Cutter 2016-02-22 15:42:54 EST
I guess I should reiterate my initial disclaimer with each post:

I would not be comfortable recommending these steps (though they have worked for me), but they may prove informative at the least.
Comment 28 Dave Airlie 2016-03-14 03:51:18 EDT
*** Bug 1305772 has been marked as a duplicate of this bug. ***
Comment 29 marc skinner 2016-03-23 15:51:27 EDT
So using the nouveau driver with acpi_osi="!Windows 2013" kernel boot option is what is recommended?  

I'm still seeing pauses.

when i su to root
when i first login to gnome-mate after putting in my credentials into gdm
when shutting down
when doing anything with display settings

each action starts a 10 second delay

Running F23.latest on W541 with latest bios 2.26
Comment 30 Marc 2016-03-24 10:58:51 EDT
(In reply to marc skinner from comment #29)
works for me. Are you positive your cmdline is OK? check dmesg for 
ACPI: Deleted _OSI(Windows 2013) 
as described above.

Took me some tries to add acpi_osi="!Windows 2013" to GRUB_CMDLINE_LINUX in /etc/default/grub, make sure you specify it as follows:
\"acpi_osi=!Windows 2013\" 

then run 
grub2-mkconfig --output=/boot/grub2/grub.cfg
Comment 31 marc skinner 2016-03-25 09:42:39 EDT
Currently I have this:

[root@w541 ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.4.5-300.fc23.x86_64 root=/dev/mapper/W541-root ro rd.lvm.lv=W541/root rd.luks.uuid=luks-0b415cb9-576a-4daf-944c-96931e41791c rd.lvm.lv=W541/swap rhgb quiet acpi_osi=!Windows2013 LANG=en_US.UTF-8


Will try as your called it out:  \"acpi_osi=!Windows 2013\" 

and repost.
Comment 32 marc skinner 2016-03-28 09:06:14 EDT
Still seeing the same.

I have the following in my /etc/default/grub

GRUB_CMDLINE_LINUX="rd.lvm.lv=W541/root rd.luks.uuid=luks-0b415cb9-576a-4daf-944c-96931e41791c rd.lvm.lv=W541/swap rhgb quiet \"acpi_osi=!Windows2013\""

and have rebuilt my grub2.cfg

grub2-mkconfig --output=/boot/grub2/grub.cfg

upon reboot I see this:

cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.4.6-300.fc23.x86_64 root=/dev/mapper/W541-root ro rd.lvm.lv=W541/root rd.luks.uuid=luks-0b415cb9-576a-4daf-944c-96931e41791c rd.lvm.lv=W541/swap rhgb quiet acpi_osi=!Windows2013 LANG=en_US.UTF-8

and am still experiencing the delays.

I'm not seeing 

ACPI: Deleted _OSI(Windows 2013) 

in my dmesg output which appears to confirm the kenel paramater is working correctly.
Comment 33 Marc 2016-03-28 10:15:36 EDT
there is no space between Windows and 2013?

my /proc/cmdline preserves the double quotes (because of the blank I guess):

cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.4.6-300.fc23.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet "acpi_osi=!Windows 2013" LANG=en_US.UTF-8
Comment 34 marc skinner 2016-03-28 15:58:38 EDT
Finally got the ACPI: Deleted _OSI(Windows 2013) to show up in dmesg.

You have to add the following to your grub CMDLINE exactly:

\"acpi_osi=!Windows 2013\"

It needs a space!

I'm still seeing the pause ...

When I su to root
When I configure display Settings
Running the lspci command below

I'm running F23.latest, with Gnome Mate as my environment.

Kernel: 4.4.6-300.fc23.x86_64
BIOS: 2.26

lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1) 

modinfo nouveau
filename:       /lib/modules/4.4.6-300.fc23.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko.xz
license:        GPL and additional rights
description:    nVidia Riva/TNT/GeForce/Quadro/Tesla
author:         Nouveau Project
alias:          pci:v000012D2d*sv*sd*bc03sc*i*
alias:          pci:v000010DEd*sv*sd*bc03sc*i*
depends:        drm,drm_kms_helper,ttm,mxm-wmi,wmi,video,i2c-algo-bit
intree:         Y
vermagic:       4.4.6-300.fc23.x86_64 SMP mod_unload 
parm:           tv_norm:Default TV norm.
		Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J,
			hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i.
		Default: PAL
		*NOTE* Ignored for cards with external TV encoders. (charp)
parm:           vram_pushbuf:Create DMA push buffers in VRAM (int)
parm:           nofbaccel:Disable fbcon acceleration (int)
parm:           tv_disable:Disable TV-out detection (int)
parm:           ignorelid:Ignore ACPI lid status (int)
parm:           duallink:Allow dual-link TMDS (default: enabled) (int)
parm:           pstate:enable sysfs pstate file, which will be moved in the future (int)
parm:           config:option string to pass to driver core (charp)
parm:           debug:debug string to pass to driver core (charp)
parm:           noaccel:disable kernel/abi16 acceleration (int)
parm:           modeset:enable driver (default: auto, 0 = disabled, 1 = enabled, 2 = headless) (int)
parm:           runpm:disable (0), force enable (1), optimus only default (-1) (int)

I'm also noticing that where my left palm rests gets hot.  Not too hot to touch, but almost uncomfortable. I'm assuming this is where the video card is?

Is there anything I need to configure in the BIOS?  I have only updated to BIOS 2.26 from what was shipped and not made any changes in the BIOS configuration.
Comment 35 marc skinner 2016-03-29 09:37:02 EDT
When I run Gnome 3 the issues go away.  I was still experiencing the pauses in Gnome Mate.
Comment 36 jamo luhrsen 2016-03-30 13:11:34 EDT
for me, this seems to make things better (taken from previous comments):

in my /etc/default/grub, appended \"acpi_osi=!Windows 2013\" to GRUB_CMDLINE_LINUX

rebuild grub2.cfg with "grub2-mkconfig --output=/boot/grub2/grub.cfg"

reboot


@mskinner, I tried your three cases where you still see the pause, but I
did not (su root, display settings, lscpi).
Comment 37 Beat Rubischon 2016-03-31 11:52:50 EDT
Significant improvement with \"acpi_osi=!Windows 2013\" in GRUB_CMDLINE_LINUX. F23, Gnome 3, W541. Freezes went down from ~10s to ~1s. Thanks for the hints!
Comment 38 Sean Flanigan 2016-04-10 23:13:38 EDT
Same results as brubisch here, on F22 with XFCE, W541: 10 second freeze down to 1 second when opening gnome-control-center or xfce4-display-settings. Thanks!

Some of my freezes were occasionally permanent freezes, so here's hoping that's gone too.
Comment 39 Luke Meyer 2016-07-01 16:44:56 EDT
*** Bug 1343800 has been marked as a duplicate of this bug. ***
Comment 40 John Dennis 2016-07-27 14:19:36 EDT
Just as a point of reference, I had been booting my F23 Lenovo W541 with acpi_osi=!Windows 2013 to solve the delay problem. I just updated to F24 and wondered if this was still necessary. Apparently it is, without it I still get the same delay problem.
Comment 41 Thomas Cameron 2016-07-28 17:04:09 EDT
Does anyone know if the NVidia card is removable? This is pretty ridiculous. I'd rather just use the Intel video.
Comment 42 Thomas Cameron 2016-07-28 17:12:57 EDT
FWIW, fresh install of F24, I added the entry described in comment 36, above, and I see that the kernel "sees" it:

[root@w541 ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.6.4-301.fc24.x86_64 root=UUID=21dabd5b-9755-44cd-a412-80fb54441578 ro rd.luks.uuid=luks-b2244ae4-cc13-4528-a35f-af50f0e7b3c7 rd.luks.uuid=luks-73ab5eaa-f5cd-456e-a34a-1002b5b79399 rhgb quiet "acpi_osi=!Windows 2013"

But I still get delays of around 10 seconds when I open the settings applet.
Comment 43 Josh Poimboeuf 2016-07-28 18:16:16 EDT
Hm, that's odd.  I also have F24 (but it has been upgraded several times, so it's definitely not fresh), and the "acpi_osi=!Windows 2013" still seems to be helping.

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.6.3-300.fc24.x86_64 root=UUID=d22efac2-ed62-498b-ad4d-0c376974c2b5 ro rd.luks.uuid=luks-7276a549-122b-45e9-97ea-dfbbfeb0bfc8 rd.luks.uuid=luks-6655629d-9cf5-4ef4-8ef8-64bd354631e8 "acpi_osi=!Windows 2013"
Comment 44 Gerard Ryan 2016-07-28 18:18:43 EDT
That's odd: with that fix, opening the settings takes less than 2 seconds for me on F24. I've got slightly different output from that command than you have, but I don't think any of the other options would have an impact on this, right?

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.6.4-301.fc24.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.luks.uuid=luks-a50235d6-47b6-4db4-9bc8-72363cc039c6 rd.lvm.lv=fedora/swap quiet LANG=en_GB.UTF-8 "acpi_osi=!Windows 2013"
Comment 45 Gerard Ryan 2016-07-28 18:20:00 EDT
(In reply to Josh Poimboeuf from comment #43)
> Hm, that's odd.  I also have F24 (but it has been upgraded several times, so
> it's definitely not fresh), and the "acpi_osi=!Windows 2013" still seems to
> be helping.

Mine was also an upgrade, so maybe reinstallation makes it different for Thomas?
Comment 46 Thomas Cameron 2016-07-28 18:31:22 EDT
OK, if you're having problems with F24, here is what worked for me. I am NOT saying it's the best way, but it does work. When I used the acpi_osi=!Windows 2013 entry, I got an error message saying the kernel crashed at boot when I logged in. Also, the area under my left hand got HOT. Finally, under F24, the 10-second delay was still there opening the administration apps or running lspci or su'ing to root.

With the steps below, I get no error at boot, there is zero delay opening the management application or running lspci, and the hand rest area is cool to the touch.

# enable the bumblebee repo
dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora24/noarch/bumblebee-release-1.2-1.noarch.rpm

# install the bumblebee software
dnf -y install bumblebee-nouveau bbswitch-dkms kernel-devel

# blacklist the nouveau module
echo blacklist nouveau > /etc/modprobe.d/blacklist-nouveau.conf

# enable the bbswitch module
echo bbswitch > /etc/modules-load.d/bbswitch.conf

# set the module to disable the NVidia card
echo options bbswitch load_state=0 > /etc/modprobe.d/bbswitch.conf

# create a new initial ramdisk
dracut -f

# set acpi_osi=Linux in the grub default file
perl -pi -e 's/rhgb quiet/rhgb quiet acpi_osi=Linux/' /etc/default/grub

# create a new grub.cfg
grub2-mkconfig --output=/boot/grub2/grub.cfg

# reboot
init 6
Comment 47 Laura Abbott 2016-09-23 15:55:56 EDT
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.
Comment 48 Bill Peck 2016-09-26 08:12:35 EDT
Still happens with f24
Comment 49 Bill Peck 2016-09-26 08:21:51 EDT
Sorry - I realized I hadn't update to the kernel version requested in the needinfo.  I only saw f24.

In any event.  It appears to be fixed on f24 with 4.7.4-200.fc24.x86_64 kernel.

Thanks!
Comment 50 Gerard Ryan 2016-11-05 20:02:33 EDT
(In reply to Bill Peck from comment #49)
> Sorry - I realized I hadn't update to the kernel version requested in the
> needinfo.  I only saw f24.
> 
> In any event.  It appears to be fixed on f24 with 4.7.4-200.fc24.x86_64
> kernel.
> 
> Thanks!

Given that Bill says it's fixed on f24, and I don't experience it on f25, I'm going to close the issue. If anyone is still seeing it, either re-open this or create a new issue.

Thanks to everyone who helped!
Comment 51 Nicolai Nielsen 2017-02-28 17:26:16 EST
I'm seeing this issue on FC25 (not 10s, but significant, about 2-5s delays). I have the acpi setting:

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.9.11-200.fc25.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-22295afa-5392-4cdc-a10d-bb9c3d81d2da rhgb quiet "acpi_osi=!Windows 2013" LANG=en_US.UTF-8

I also note that my GPU seems to be running quite hot and battery life is laughable, so I'm not too keen on turning ACPI off completely.
Comment 52 Thomas Cameron 2017-02-28 17:29:12 EST
Nicolai, I did a fresh install of F25, did NOT make any modifications to the kernel line, and the problem went away. 

Did you do a fresh install, or an in-place upgrade? Just curious.
Comment 53 Nicolai Nielsen 2017-03-01 11:51:21 EST
This was an in-place upgrade. So what's the state of your system? Are you using Bumblebee?
Comment 54 Alessandro Silva 2017-03-28 13:37:41 EDT
I'm seeing the same issue in my Thinkpad P50 + RHEL 7.3 and I solved:

1. Adding this parameter:

# vi /etc/default/grub

\"acpi_osi=!Windows 2013\" "

2. Re-configuring Grub:

# grub2-mkconfig > /boot/grub2/grub.cfg

3. Reboot

Note You need to log in before you can comment on or make changes to this bug.