Nouveau - May 2015 - [Bug 90682] New: failed to idle channel 0xcccc0001 then crash

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

            Bug ID: 90682
           Summary: failed to idle channel 0xcccc0001 then crash
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: thomas at stewarts.org.uk
        QA Contact: xorg-team at lists.x.org

Created attachment 116084
  --> https://bugs.freedesktop.org/attachment.cgi?id=116084&action=edit
dmesg captured with kdump

Hi,

My Lenovo W540 started crashing when I upgraded from Linux 3.14 to 3.16 in Sept
2014. I continued to use 3.14 and I did nothing till last week when I tried
Linux 4.0 (from sid) which kept crashing soon after logging in to GNOME 3. I
EFI boot to grub and use GRUB_GFXPAYLOAD_LINUX=keep. Then use KMS and Plymouth
till GDM, X.Org and GNOME3. When it crashed the mouse and keyboard no longer
did anything (ie Ctrl-Alt-F1 did not work) and the laptop appeared to drop off
the network. 

When I boot with Linux 4.0 and login to GNOME 3, it would crash within minutes,
but sometimes an hour. I manually compiled 3.15, 3.16, 3.17, 3.18, 3.19 and 4.0
which all had various issues: the external monitor resolution was broken on
3.15, 3.16 seemed ok, but 3.17, 3.18, 3.19 and 4.0 all seemed to crash soon
after boot.

I used kdump to capture a dump and dmesg and there was a message about nouveau:
[   76.792370] nouveau E[     DRM] failed to idle channel 0xcccc0001 [DRM]

Then 60 microseconds later a BUG:
[   76.792430] BUG: unable to handle kernel paging request at ffff8805660b7ffc
[   76.792455] IP: [<ffffffffa0406bf3>] evo_wait+0x53/0x120 [nouveau]

After a little googling I found out about the "nouveau.runpm=0"
parameter. Once
I added this parameter and rebooted my laptop has worked fine with Linux 4.0.
However I have not tried that parameter in any previous kernels so am unsure
which release this workaround started working.

I'm now happy that I have a working system with working lcd screen
brightness
controls and multi-stream transport monitors that work. However I don't want
to
kill the laptops battery by permanently disabling the power management. I could
try bisecting, but with so many revisions I'm not sure what to mark good and
bad or if I should use runpm at all.

Anyway here are some Debian package versions and info:
linux-image-4.0.0-1-amd64       4.0.2-1
libdrm-nouveau2                 2.4.60-3
libgl1-mesa-glx                 10.5.5-1
xserver-xorg-video-nouveau      1:1.0.11-1+b1

$ lspci | grep -i VGA
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK106GLM [Quadro K2100M]
(rev a1)
$

Kind Regards
--
Tom

-- 
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/20150527/fb8ae05d/attachment.html>

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

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

-- 
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/20150527/b8fef06f/attachment.html>

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

Tobias Klausmann <tobias.klausmann at mni.thm.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|failed to idle channel      |[NVE6] failed to idle
                   |0xcccc0001 then crash       |channel 0xcccc0001 + crash

-- 
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/20150527/b63b8ade/attachment.html>

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

--- Comment #2 from Thomas Stewart <thomas at stewarts.org.uk> ---
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
$

-- 
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/20150527/a7221bef/attachment.html>

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

--- Comment #3 from Thomas Stewart <thomas at stewarts.org.uk> ---
Created attachment 116086
  --> https://bugs.freedesktop.org/attachment.cgi?id=116086&action=edit
Xorg.0.log with nouveau.noaccel=1

-- 
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/20150527/6a336402/attachment.html>

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

--- Comment #4 from Thomas Stewart <thomas at stewarts.org.uk> ---
Apologies, I copy and pasted the wrong resolutions. The external monitors are
1920x1200.

-- 
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/20150527/afb29c5b/attachment.html>

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

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

-- 
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/20150527/39fd9528/attachment.html>

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

--- Comment #6 from Thomas Stewart <thomas at stewarts.org.uk> ---
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.

-- 
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/20150527/cbb00a0e/attachment.html>

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

--- Comment #7 from Thomas Stewart <thomas at stewarts.org.uk> ---
Created attachment 116087
  --> https://bugs.freedesktop.org/attachment.cgi?id=116087&action=edit
dmesg captured with kdump with video=eDP-1:d

-- 
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/20150527/fc91726f/attachment.html>

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

--- Comment #8 from Thomas Stewart <thomas at stewarts.org.uk> ---
Created attachment 116088
  --> https://bugs.freedesktop.org/attachment.cgi?id=116088&action=edit
dmesg with nouveau.noaccel=1 video=eDP-1:d

-- 
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/20150527/54381b07/attachment.html>

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

--- Comment #9 from Thomas Stewart <thomas at stewarts.org.uk> ---
Created attachment 116089
  --> https://bugs.freedesktop.org/attachment.cgi?id=116089&action=edit
Xorg.0.log with nouveau.noaccel=1 video=eDP-1:d

-- 
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/20150527/9de621cc/attachment.html>

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

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

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

--- Comment #10 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/194.

-- 
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/3cee31c4/attachment.html>