Bug 98582

Summary: nouveau on a GM108 fails to resume properly from suspension
Product: xorg Reporter: hoboprimate
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: jan.public, ondrej.homolka, peter
Version: unspecified   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Description Flags
lshw -c display
'journalctl -b' output when running kernel 4.7
acpidump output
*full* log of failed resuming on 4.8.4 none

Description hoboprimate 2016-11-03 22:24:22 UTC
Created attachment 127737 [details]

I have a dual-graphics laptop, intel+nvidia. With the 'nouveau' module loaded, the laptop doesn't resume fully, with the screen staying blank.
'rmmod'-ing the nouveau driver, resuming works fine.

This used to work in the past few years, the problem appeared with Fedora 25.
Comment 1 hoboprimate 2016-11-03 22:24:42 UTC
Created attachment 127738 [details]
Comment 2 hoboprimate 2016-11-03 22:25:00 UTC
Created attachment 127739 [details]
Comment 3 hoboprimate 2016-11-03 22:25:18 UTC
Created attachment 127740 [details]
lshw -c display
Comment 4 Pierre Moreau 2016-11-04 07:48:05 UTC
Support for GM108 chipsets was merged in Linux 4.7, which was released end of July 2016, so I assume that it worked before as Nouveau failed to recognise the chipset, and therefore did nothing.

Trying Linux 4.7 and making sure that the chipset is recognised would be nice, to rule out a possible regression. Could you also please add the output of acpidump to the bug report?
Comment 5 hoboprimate 2016-11-04 23:38:47 UTC
Created attachment 127777 [details]
'journalctl -b' output when running kernel 4.7
Comment 6 hoboprimate 2016-11-04 23:39:17 UTC
Created attachment 127778 [details]
acpidump output
Comment 7 hoboprimate 2016-11-04 23:49:04 UTC
Took a while to compile the 4.7 kernel :) (from fedora sources), and the chipset was recognized with it (see attached log). Resuming from suspend also failed there.

Also attached acpidump output.

Also just realized, I have not been attaching *full* boot logs, i.e., up to the point it fails to wake from suspension. I will do that (right after this comment) on the current 4.8.4 kernel.
Comment 8 hoboprimate 2016-11-04 23:55:09 UTC
Created attachment 127779 [details]
*full* log of failed resuming on 4.8.4
Comment 9 Peter Wu 2016-11-24 09:59:24 UTC
Possibly a duplicate of bug 98398, can you try the ACPICA patches at https://bugs.acpica.org/show_bug.cgi?id=1333#c45
Comment 10 hoboprimate 2016-12-10 23:17:53 UTC
(In reply to Peter Wu from comment #9)
> Possibly a duplicate of bug 98398, can you try the ACPICA patches at
> https://bugs.acpica.org/show_bug.cgi?id=1333#c45

Sorry for late replying, but applying the 3 patches in compiled kernel version 4.9 fixes the problem.
Comment 11 hoboprimate 2016-12-10 23:19:00 UTC
I mean, I had to compile 4.9 with the patches, of course.
Comment 12 hoboprimate 2017-06-10 00:31:22 UTC
Using the latest Fedora 26 (alpha), suspension is working fine with nouveau loaded :) . Linux version is 4.11.3-302 .

Closing this report.
Comment 13 hoboprimate 2017-09-22 18:59:25 UTC
Just re-opening because I'm still having some occasional failed resumes, where the display becomes visible showing gnome's lock screen, but otherwise the laptop remains unresponsive.
Comment 14 hoboprimate 2017-10-05 12:57:00 UTC
Might be usefull to put here a snippet of the boot for the last months kernel versions:

nouveau 0000:03:00.0: bus: MMIO read of 00000000 FAULT at 612004 [ IBUS ]
nouveau 0000:03:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]
usb 2-5: New USB device found, idVendor=04ca, idProduct=300b
usb 2-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
fbcon: inteldrmfb (fb0) is primary device
clocksource: Switched to clocksource tsc
vga_switcheroo: enabled
[TTM] Zone  kernel: Available graphics memory: 3014696 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
nouveau 0000:03:00.0: DRM: VRAM: 2048 MiB
nouveau 0000:03:00.0: DRM: GART: 1048576 MiB
nouveau 0000:03:00.0: DRM: Pointer to TMDS table invalid
nouveau 0000:03:00.0: DRM: DCB version 4.0
nouveau 0000:03:00.0: DRM: Pointer to flat panel table invalid
nouveau 0000:03:00.0: DRM: MM: using COPY for buffer copies
[drm] Initialized nouveau 1.3.1 20120801 for 0000:03:00.0 on minor 1
Console: switching to colour frame buffer device 170x48
i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Comment 15 Martin Peres 2019-12-04 09:19:09 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/297.

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.