Bug 90682

I think that some things are being confused here... you mention multi-stream, presumably in reference to DP-MST, but that doesn't work on nouveau, only intel and radeon. Are you actually using nouveau for anything? Can you attach an xorg log and xrandr output, that should make things a bit clearer.

runpm is a very crude form of power management -- it'll turn the GPU off when the driver decides it hasn't been used for ~5s or so (maybe 10? I forget). It can do this using ACPI calls. It will then wake the GPU back up when it wants to use something.

Now you have a Lenovo + GK106 combo, which is well known to have lots of trouble bringing up acceleration. In fact, your logs show

[    4.472623] nouveau E[     PGR][0000:01:00.0] grctx template channel unload timeout

which means that PGRAPH doesn't come up. You could save nouveau some trouble and just use nouveau.noaccel=1. You should still be able to use reverse-prime in this case.

Now, none of that has to do with you seeing the crash, just trying to help you achieve a working system. We shouldn't be crashing even when PGRAPH fails to come up.

[   52.772499] nouveau E[     DRM] failed to idle channel 0xcccc0000 [DRM]
[   52.788584] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xf0 [nouveau] returns -16

OK, so it tries to suspend but it can't shut down the main DRM channel. Because PGRAPH is dead to begin with. Although it begs the question of why it even tries to idle the channel, that means there's an active fence on it. I'm guessing that the remaining messages are due to improper cleanup of a failed runtime suspend.

If the above is in the vicinity of correct, nouveau.noaccel=1 should "fix" it, I think.

I do mention DP-MST! I have a ThinkPad Ultra Dock 40A2:
http://shop.lenovo.com/us/en/itemdetails/40A20090US/460/6D501EE899104FF9A362D739642CFC27
http://support.lenovo.com/us/en/documents/pd029622

It's got a variety of connectors: VGA, DVI, 2xDP, HDMI. It has a standard and advanced mode that is selectable from the BIOS. I have read that in standard mode only one port is usable but in advanced any ports are. I have mine set to standard.

I drive a pair of 2880x1620 displays with a DVI and a DP from the dock. I think the laptop and the dock use MST in order to use more than one display. Before using Linux 4.0 I had to drive one monitor with the dock and one with the VGA connector on the laptop itself.

I don't know if nouveau is used for anything, 2880x1620 is mentioned next to intel and nouveau lines in the Xorg.0.log. In the past I did blacklist nouveau.ko once to diagnose the crashing and found that the crashing stopped but I could only get outout on the laptop display. So it seems to be involved somewhere. How does one find out which screen is driven by which card, etc?

Thanks for the info regarding runpm, I have removed that option and am running with "nouveau.noaccel=1" now. It seems to be stable as it's up about 40 min so far. I have not used any reverse-prime stuff.

$ xrandr 
Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
eDP2 connected (normal left inverted right x axis y axis)
   2880x1620     59.96 +  50.00  
   2048x1536     60.00  
   1920x1440     60.00  
   1856x1392     60.01  
   1792x1344     60.01  
   1920x1200     59.95  
   1920x1080     59.93  
   1600x1200     60.00  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP2-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1920x1080     59.99    60.00    50.00    50.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    72.05    60.02  
   1440x900      74.98    59.89  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    70.07    60.00  
   800x600       72.19    75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.03    60.00    59.94  
   720x400       70.08  
DP2-2 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1920x1080     59.99  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    72.05    60.02  
   1440x900      74.98    59.90  
   1024x768      75.08    70.07    60.00  
   800x600       72.19    75.00    60.32  
   640x480       75.00    72.81    66.03    60.00  
   720x400       70.08  
DP2-3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
$

$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x73 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 10 associated providers: 0 name:Intel
Provider 1: id: 0x45 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 2 associated providers: 0 name:nouveau
$

Created attachment 116086 [details]
Xorg.0.log with nouveau.noaccel=1

Apologies, I copy and pasted the wrong resolutions. The external monitors are 1920x1200.

All of those screens are attached to intel. I can't think of a reason why you would have lost your DP screens.

However it seems like your eDP panel is actively attached to *both* the intel *and* the nvidia adapters. Yeah, *that*'ll work great. Ugh. There also appears to be a DVI-D output, which may or may not be real.

I wonder if that's the cause of the trouble. It seems like intel is allocating its outputs second, so the first eDP screen goes to nouveau. But presumably nouveau is card1 while intel is card0.

Double-check with

grep . /sys/class/drm/card*-*/status

I bet that there's a eDP-1 and eDP-2, and that eDP-2 is on the card that all the other useful ones are on. In that case, try booting with

video=eDP-1:d

Here is the status:
$ grep . /sys/class/drm/card*-*/status
/sys/class/drm/card0-DVI-D-1/status:disconnected
/sys/class/drm/card0-eDP-1/status:disconnected
/sys/class/drm/card1-DP-1/status:disconnected
/sys/class/drm/card1-DP-2/status:disconnected
/sys/class/drm/card1-DP-3/status:connected
/sys/class/drm/card1-DP-4/status:connected
/sys/class/drm/card1-DP-5/status:disconnected
/sys/class/drm/card1-eDP-2/status:connected
/sys/class/drm/card1-HDMI-A-1/status:disconnected
/sys/class/drm/card1-HDMI-A-2/status:disconnected
/sys/class/drm/card1-VGA-1/status:disconnected
$

I'm not sure about the DVI-D, I do have a thunderbolt socket on the laptop that I have never used. I'm not sure if the card order has always been the same, but it looks like card0 is nouveau and card1 is intel:

$ ls -l /sys/class/drm/card?/device/driver
lrwxrwxrwx 1 root root 0 May 27 17:36 /sys/class/drm/card0/device/driver -> ../../../../bus/pci/drivers/nouveau
lrwxrwxrwx 1 root root 0 May 27 17:35 /sys/class/drm/card1/device/driver -> ../../../bus/pci/drivers/i915
$

I rebooted without "nouveau.noaccel=1" and with "video=eDP-1:d" but it crashed again in nv50_display_init(). I then rebooted with "nouveau.noaccel=1 video=eDP-1:d" and it seems stable but I'm not sure that has actually done anything as dmesg and Xorg.0.log seem very similar.

Created attachment 116087 [details]
dmesg captured with kdump with video=eDP-1:d

Created attachment 116088 [details]
dmesg with nouveau.noaccel=1 video=eDP-1:d

Created attachment 116089 [details]
Xorg.0.log with nouveau.noaccel=1 video=eDP-1:d

-- 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/194.