Nouveau - Jun 2014 - [Bug 79518] New: nouveau causes lockup and reboot on GT215

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

          Priority: medium
            Bug ID: 79518
          Assignee: nouveau at lists.freedesktop.org
           Summary: nouveau causes lockup and reboot on GT215
        QA Contact: xorg-team at lists.x.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: kilobyte at angband.pl
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: 7.7 (2011)
         Component: Driver/nouveau
           Product: xorg

Created attachment 100258
  --> https://bugs.freedesktop.org/attachment.cgi?id=100258&action=edit
kernel log via a serial console

On my system, with nvidia GT215/240, nouveau causes random crashes on the order
of 1 hour.  Typically, there's a lockup followed by a reboot a few seconds
later.  With the proprietary driver, the system is stable.  The crash happens
on both old and new kernels, up to 3.15-rc.

-- 
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/20140602/9fe4b35e/attachment.html>

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

--- Comment #1 from Adam Borowski <kilobyte at angband.pl> ---
Created attachment 100259
  --> https://bugs.freedesktop.org/attachment.cgi?id=100259&action=edit
another log, with DRM=debug

TJK on IRC suggested to boot with: nouveau.debug=DRM=debug drm.debug=0xe
Here's a log with these settings.  This time, there was no delay between the
lockup and reboot.  The log contains some stack traces, but they apparently
come from the serial console being unable to cope with big bursts of debug
info, and thus are unrelated to the problem at hand.

-- 
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/20140602/8a4f0f57/attachment.html>

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

--- Comment #2 from Adam Borowski <kilobyte at angband.pl> ---
Created attachment 122750
  --> https://bugs.freedesktop.org/attachment.cgi?id=122750&action=edit
syslog with kernel 4.6-rc2

With kernel 4.6-rc2, there's some new output, including a stack trace.
The frequency of crashes seems to be lower, before it crashed reliably after no
longer than an hour, here's the first and so far only crash after ~2 days of
trying nouveau instead of proprietary.

-- 
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/20160406/16c46137/attachment.html>

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

--- Comment #3 from Adam Borowski <kilobyte at angband.pl> ---
Created attachment 122773
  --> https://bugs.freedesktop.org/attachment.cgi?id=122773&action=edit
a non-tainted dump (serial console)

Found a way to trigger it: while on 4.6-rc2 nothing during normal work or GL
stuff causes the crash anymore, something Chromium does always causes a crash
nearly instantly.  So here's a non-tainted serial console dump.

-- 
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/20160406/c3b52c83/attachment.html>

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

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Was there anything before the tlb flush timeout error? Unfortunately I have no
clue why those timeouts happen... basically it's an indication that the GPU
is
"done". You could disable GL stuff for chromium, either launching it
with
LIBGL_ALWAYS_SOFTWARE=1 or by disabling stuff in about:flags.

Perhaps the memory comes up in a (slightly) funny state? You could try
reclocking it and see if that improves matters, have a look in
/sys/kernel/debug/dri/0/pstate for the available perf levels, you can echo
those values in to change states.

-- 
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/20160406/11740892/attachment.html>

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

--- Comment #5 from Adam Borowski <kilobyte at angband.pl> ---
Created attachment 122779
  --> https://bugs.freedesktop.org/attachment.cgi?id=122779&action=edit
including boot with nouveau.debug=DRM=debug drm.debug=0xe
> Was there anything before the tlb flush timeout error?
Nothing since boot.  I don't know what messages are interesting to you, so
here's a dump since boot, this time with nouveau.debug=DRM=debug
drm.debug=0xe
> Unfortunately I have no clue why those timeouts happen... basically
it's an indication that the GPU is "done".
I believe my hardware itself is ok, at least as in "never had any issue
with
the proprietary driver".  Those bastards dropped support for GT215
though...
> You could disable GL stuff for chromium, either launching it with
LIBGL_ALWAYS_SOFTWARE=1 or by disabling stuff in about:flags.
I don't care about chromium, I got a better browser :p  But whatever GL
calls
it does can be invoked by some other program later...
> Perhaps the memory comes up in a (slightly) funny state? You could try
reclocking it and see if that improves matters, have a look in
/sys/kernel/debug/dri/0/pstate for the available perf levels, you can echo those
values in to change states.
What values would you suggest?  I'm afraid I did not find documentation
that's
idiot-proof -- and I sadly got exactly 0 clue about this kind of stuff so I
require some handholding to give you useful debug info.

-- 
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/20160406/c879dc1d/attachment-0001.html>

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

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Adam Borowski from comment #5)
> > Unfortunately I have no clue why those timeouts happen... basically
it's an indication that the GPU is "done".
> 
> I believe my hardware itself is ok, at least as in "never had any
issue with
> the proprietary driver".  Those bastards dropped support for GT215
though...
Yeah, I'm sure your HW is fine. But it just stops responding (reasonably) to
nouveau when this happens, and we don't know what to do about it. Perhaps
this
is "normal" and the blob drivers know how to kick it in that case. Or
perhaps
we're doing something wrong to push the hw over the brink of sanity.
> > Perhaps the memory comes up in a (slightly) funny state? You could try
reclocking it and see if that improves matters, have a look in
/sys/kernel/debug/dri/0/pstate for the available perf levels, you can echo those
values in to change states.
> 
> What values would you suggest?  I'm afraid I did not find documentation
> that's idiot-proof -- and I sadly got exactly 0 clue about this kind of
> stuff so I require some handholding to give you useful debug info.
cat /sys/kernel/debug/dri/0/pstate

I can provide more instructions when you give me the output of that.

-- 
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/20160406/a667264c/attachment.html>

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

--- Comment #7 from Adam Borowski <kilobyte at angband.pl> ---
03: core 135 MHz shader 270 MHz memory 135 MHz
07: core 405 MHz shader 810 MHz memory 324 MHz
0f: core 600 MHz shader 1460 MHz memory 800 MHz
AC: core 405 MHz shader 810 MHz memory 324 MHz

-- 
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/20160406/f564ae1e/attachment.html>

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

--- Comment #8 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Adam Borowski from comment #7)
> 03: core 135 MHz shader 270 MHz memory 135 MHz
> 07: core 405 MHz shader 810 MHz memory 324 MHz
> 0f: core 600 MHz shader 1460 MHz memory 800 MHz
> AC: core 405 MHz shader 810 MHz memory 324 MHz
try

echo 07 > /sys/kernel/debug/dri/0/pstate

This should try to normalize the parameters while keeping the same perf level.
You can also try 03 and 0f (for low and high pstates).

-- 
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/20160406/5ca35b66/attachment.html>

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

--- Comment #9 from Adam Borowski <kilobyte at angband.pl> ---
Created attachment 122781
  --> https://bugs.freedesktop.org/attachment.cgi?id=122781&action=edit
log with 07 pstate

With the 07 pstate, the lockup was different: chromium worked for a longish
time (instead of causing a crash almost immediately).  When finally the lockup
happened, the machine remained operative (sans display) -- but this might be
randomness inherent in such failures.

I'll try 03.

-- 
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/20160406/5125f2b1/attachment.html>

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

--- Comment #10 from Adam Borowski <kilobyte at angband.pl> ---
Nah, it looks like it was random luck: with 03 pstate it crashed immediately,
without even a single message on the serial console.

-- 
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/20160406/7852738c/attachment.html>

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

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

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

--- Comment #11 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/110.

-- 
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/4c1c21c8/attachment.html>