Bug 1302847

Created attachment 1119233 [details]
output of journalctl -b

Created attachment 1119234 [details]
output of dmesg

Just a "me, too" post. I am seeing the same thing. 100% repeatable.

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.

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.

(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?

That worked for me, as well.

Instructions for making it persistent are at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool.html

just note that this will have a pretty severe impact on your battery life.

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?

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.

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 on attachment 1119339 [details]
sosreport after getting a lockup at 19:51 local time

Correction, created the lockup at 19:51

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

(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.

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

I also have this issue following a fresh net install of FF23 and disabling the power mgmt stops the hang issue.

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?

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.

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).

(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

*** Bug 1309668 has been marked as a duplicate of this bug. ***

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.

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,

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.

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

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.

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.

*** Bug 1305772 has been marked as a duplicate of this bug. ***

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

(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

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.

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.

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

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.

When I run Gnome 3 the issues go away.  I was still experiencing the pauses in Gnome Mate.

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).

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!

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.

*** Bug 1343800 has been marked as a duplicate of this bug. ***

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.

Does anyone know if the NVidia card is removable? This is pretty ridiculous. I'd rather just use the Intel video.

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.

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"

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"

(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?

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

*********** 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.

Still happens with f24

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!

(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!

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.

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.

This was an in-place upgrade. So what's the state of your system? Are you using Bumblebee?

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