Bug 27153 - [NV18] Frequent lockups during graphical activities
Summary: [NV18] Frequent lockups during graphical activities
Status: RESOLVED DUPLICATE of bug 25366
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-17 20:26 UTC by Christopher James Halse Rogers
Modified: 2010-09-07 17:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
nv18_pgraph_lockup.patch (603 bytes, patch)
2010-03-22 04:22 UTC, Francisco Jerez
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher James Halse Rogers 2010-03-17 20:26:18 UTC
Forwarded from Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/537741

Whenever something graphically intensive happens (except, apparently, video) like compositing, a gpu lockup occurs, freezing X and even terminal switching but allowing use of SysRq commands. Can sometimes switch terminals by first pressing Alt-SysRq-K. Only occurs with an NV18 card; NV17 works fine, for example.

I have enabled compositing in Metacity. One test was selecting the Applications menu and rapidly switching through that and Places and System, which eventually froze X. After doing Alt-SysRq-K, it allowed me to log back in, and I tried again with no problem; I opened some semi-transparent terminals, enlarged them, and moved them around over eachother. Trying to enlarge the ~eighth terminal froze X. Eventually I had a kernel panic. Occasionally I can't even boot fully. Sometimes X will freeze and allow cursor movement, other times won't. Has occured a couple times in a (Ctrl-Alt-F1...) virtual terminal.

Often I see colorful flashing as textures load, particularly at boot. Once I rebooted and seen the screen as it was when X froze, for a few seconds, and it cleared and finished loading GNOME.

I suppose there is a chance the card is defective...but it has no problem with the NVIDIA binary drivers. (As an aside, I even had Compiz running in Nouveau for some durations before freezing.)

Xorg log: http://launchpadlibrarian.net/40822534/XorgLogOld.txt
Boot dmesg: http://launchpadlibrarian.net/40822504/BootDmesg.txt
dmesg around the freeze & SAK recovery: http://launchpadlibrarian.net/40822506/CurrentDmesg.txt
lspci: http://launchpadlibrarian.net/40822515/Lspci.txt
Comment 1 Francisco Jerez 2010-03-18 06:51:26 UTC
Can you reproduce without the 3d driver? E.g. after hiding "/usr/lib/dri/nouveau_vieux_dri.so" somewhere the loader wouldn't look in.

Comment 2 Christopher James Halse Rogers 2010-03-21 18:47:55 UTC
The report on launchpad indicates that this is reproducible without the 3D component installed.
Comment 3 Francisco Jerez 2010-03-22 04:22:44 UTC
Created attachment 34310 [details] [review]
nv18_pgraph_lockup.patch

The attached patch might help, in any case we don't have an mmiotrace for this card yet and it would be useful if we want to fix it properly.

In short, you'd need to:
- Start tracing
- Load nvidia.ko and start X up with the nvidia proprietary driver
- Run some 3d for a few seconds (e.g. fire up glxgears)
- Stop tracing and send the generated output to mmio.dumps at gmail.com

It's explained in more depth here:
http://nouveau.freedesktop.org/wiki/MmioTrace
http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/trace/mmiotrace.txt
Comment 4 Francisco Jerez 2010-09-07 17:54:08 UTC

*** This bug has been marked as a duplicate of bug 25366 ***


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.