Nouveau - May 2015 - [Bug 90423] New: [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled

https://bugs.freedesktop.org/show_bug.cgi?id=90423

            Bug ID: 90423
           Summary: [NVAA]: Shutdown (poweroff) get stuck when runtime PM
                    is enabled
           Product: xorg
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: alexanders83 at web.de
        QA Contact: xorg-team at lists.x.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150512/bdbd0536/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90423

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150513/70e72125/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90423

--- Comment #2 from Alexander Stein <alexanders83 at web.de> ---
Created attachment 115743
  --> https://bugs.freedesktop.org/attachment.cgi?id=115743&action=edit
ascidump output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150513/7e940c26/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90423

--- Comment #3 from Alexander Stein <alexanders83 at web.de> ---
Created attachment 115744
  --> https://bugs.freedesktop.org/attachment.cgi?id=115744&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150513/fef34fa3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90423

Peter Wu <peter at lekensteyn.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter at lekensteyn.nl

--- Comment #4 from Peter Wu <peter at lekensteyn.nl> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160716/55e3d317/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90423

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #5 from Martin Peres <martin.peres at free.fr> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/3583d3b5/attachment.html>