Bug 99968 - [NV4C] System crashes reliably with glxinfo
Summary: [NV4C] System crashes reliably with glxinfo
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 12.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on: 91992
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-26 01:16 UTC by Dave Odell
Modified: 2019-09-18 20:45 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Example display corruption (3.49 MB, image/jpeg)
2017-02-26 01:16 UTC, Dave Odell
Details
dmesg (76.18 KB, text/plain)
2017-02-26 01:17 UTC, Dave Odell
Details
Xorg.0.log (25.41 KB, text/plain)
2017-02-26 01:18 UTC, Dave Odell
Details
VBIOS (60.00 KB, application/octet-stream)
2017-02-26 01:24 UTC, Dave Odell
Details

Description Dave Odell 2017-02-26 01:16:06 UTC
Created attachment 129920 [details]
Example display corruption

+++ This bug was initially created as a clone of Bug #91992 +++

Hardware is NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) on an old Dell Inspiron 531. Integrated graphics.

The system boots OK (with high-resolution console) into X11. I can log in to a Lubuntu desktop (2D, no OpenGL, AFAIK). Then, from a terminal window I run:

$ while true; do nice -n19 glxinfo > /dev/null; done

Then I drag the window around for a few seconds. Then the entire system crashes: total system lockup, followed by display corruption a second or two later. (I've attached a photograph, because I can't take a normal screen shot.) No Ctrl-Alt-F1, no magic SysRq, no ping response.

Other OpenGL apps (i.e. glxgears) can run...sometimes. Other times, they crash the same way. It seems to happen on GL init.

Ubuntu 16.10 (with Lubuntu Desktop)
Linux kernel        4.10.0          (freshly compiled)
libdrm              2.4.70-1        (from distro)
Mesa                12.0.3-1ubuntu2 (from distro)
xf86-video-nouveau  1:1.0.12-2      (from distro)

This seems a lot like bug 91992, but I've got my video memory cranked up to 256 MB in the BIOS settings, and it still happens.
Comment 1 Dave Odell 2017-02-26 01:17:23 UTC
Created attachment 129921 [details]
dmesg

Kernel messages, partially from dmesg, and partially from netconsole.
Comment 2 Dave Odell 2017-02-26 01:18:21 UTC
Created attachment 129922 [details]
Xorg.0.log
Comment 3 Dave Odell 2017-02-26 01:24:47 UTC
Created attachment 129923 [details]
VBIOS

Obtained via /sys/bus/pci/devices/0000:00:04.0/rom, as described in <https://nouveau.freedesktop.org/wiki/DumpingVideoBios/>.
Comment 4 Stewart Martin 2019-02-22 11:04:09 UTC
Same, or similar, problem on Linux Mint 19.1 Cinnamon, with the same graphics chipset.  The method I was using to reliably recreate the crash was to run glxdemo and then resize the window.

However, the symptoms did occur at other times.  I turned off hardware acceleration in chrome in an attempt to prevent it.  

Using "nouveau.config=NvMSI=0" as suggested here https://bugs.freedesktop.org/show_bug.cgi?id=61321 made no difference.
Comment 5 Dave Odell 2019-03-04 04:03:00 UTC
Tried again on the same hardware with Linux 5.0-rc8, and it's not any better. But now on top of that I've got intermittent system pauses, probably associated with "rcu_sched detected stalls on CPUs/tasks" that I see in dmesg. That's probably unrelated to the problem at hand.

Resizing the glxdemo window repeatedly does it for me, too.

nouveau.config=NvMSI=0 didn't help me, either.

A twist: I normally run this machine with modprobe.blacklist=nouveau, but it still happened (while running Linux 4.15.0-20 from Ubuntu)...except this time the system hadn't crashed, and CTRL-ALT-F1 (to get to tty1) followed by CTRL-ALT-F7 (to get back to X11) restored video.
Comment 6 GitLab Migration User 2019-09-18 20:45:03 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/mesa/mesa/issues/1128.


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.