Bug 90423 - [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled
Summary: [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
Depends on:
Reported: 2015-05-12 16:04 UTC by Alexander Stein
Modified: 2019-12-04 08:59 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

ascidump output (209.85 KB, text/plain)
2015-05-13 15:57 UTC, Alexander Stein
no flags Details
serial console output (42.11 KB, text/plain)
2015-05-13 15:59 UTC, Alexander Stein
no flags Details

Description Alexander Stein 2015-05-12 16:04:45 UTC
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[1]: 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

That's all.

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.
Comment 1 Ilia Mirkin 2015-05-13 00:42:06 UTC
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?
Comment 2 Alexander Stein 2015-05-13 15:57:51 UTC
Created attachment 115743 [details]
ascidump output
Comment 3 Alexander Stein 2015-05-13 15:59:18 UTC
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
Comment 4 Peter Wu 2016-07-16 10:21:25 UTC
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?
Comment 5 Martin Peres 2019-12-04 08:59:08 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.