I'm currently running a 3.19 kernel where I looked into the problem that one of my systems doesn't shutdown cleanly most of the time. THis behavior started from some older kernels, I _guess_ it's 5addcf0a5f0fadc ("nouveau: add runtime PM support (v0.9").
My board is a Asus M3N78-EM with a
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8300] (rev a2)
During shutdown dmesg shows the following:
[ 38.476675] systemd-shutdown: Powering off.
[ 38.536997] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[ 38.542522] sd 1:0:0:0: [sdb] Stopping disk
[ 41.069224] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 41.074745] sd 0:0:0:0: [sda] Stopping disk
I added some printk to my source tree and could trace the shutdown execution path down to __pm_runtime_barrier where dev->power.runtime_status == 3. The call to schedule() finally seems to be the deadlock.
Of course, if I compile my kernel with CONFIG_PM=n everything is fine. Reenabling it again the problem occurs again.
A workaround suggested on IRC is to set runpm=0. This seems to work as the system did clean shutdowns from this change on.
As I consider this really as a workaround I would like to fix this.
runpm really shouldn't have any effect on your machine since you shouldn't have the ACPI methods for it... can you include your dmesg and, if possible, acpidump?
Created attachment 115743 [details]
Created attachment 115744 [details]
serial console output
As the problem occurs at shutdown after disks has been stopped, I logged the serial console output.
This is from plain v4.0.3 kernel
The provided acpidump does contain the Nvidia DSM method (9d95a0a0-0060-4d48-b34d-7e5fea129fd4) with function 3 (used for switchable graphics).
What if you enable vga_switcheroo in your kernel .config?
If the Nvidia device goes into runtime sleep (after 5 seconds idle, not driving a console or anything) and is then runtime resumed, does it also hang?
Is suspend/resume working?
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/188.