Bug 90423 - [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled
Summary: [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled
Status: NEW
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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-12 16:04 UTC by Alexander Stein
Modified: 2016-07-16 10:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
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

Note You need to log in before you can comment on or make changes to this bug.
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?


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.