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.
Created attachment 127738 [details]
Created attachment 127739 [details]
Created attachment 127740 [details]
lshw -c display
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?
Created attachment 127777 [details]
'journalctl -b' output when running kernel 4.7
Created attachment 127778 [details]
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.
Created attachment 127779 [details]
*full* log of failed resuming on 4.8.4
Possibly a duplicate of bug 98398, can you try the ACPICA patches at https://bugs.acpica.org/show_bug.cgi?id=1333#c45
(In reply to Peter Wu from comment #9)
> Possibly a duplicate of bug 98398, can you try the ACPICA patches at
Sorry for late replying, but applying the 3 patches in compiled kernel version 4.9 fixes the problem.
I mean, I had to compile 4.9 with the patches, of course.
Using the latest Fedora 26 (alpha), suspension is working fine with nouveau loaded :) . Linux version is 4.11.3-302 .
Closing this report.
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.
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
[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
-- 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.