Bug 19008 - 3D rendering causes complete system hang
Summary: 3D rendering causes complete system hang
Status: RESOLVED DUPLICATE of bug 18097
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
Depends on:
Reported: 2008-12-10 15:00 UTC by Alec Habig
Modified: 2008-12-13 01:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

The xrandr output (15.31 KB, text/plain)
2008-12-10 15:00 UTC, Alec Habig
no flags Details
the xorg log, verbosity 7 (495.43 KB, text/plain)
2008-12-10 15:01 UTC, Alec Habig
no flags Details

Description Alec Habig 2008-12-10 15:00:28 UTC
Created attachment 21024 [details]
The xrandr output

Using a T60p laptop (M56 chip, FireGL 5200) and the latest git (commit 48def66ce9592926ed9b23530fb21a55ac253392), running glxgears works for 5-15 seconds then locks the system hard.  So hard that no debris is left in any logfiles to provide a clue, and the system requires a hard power cycle.  Once it even locked the speaker beep on, haven't had a crash that spectacular since my TRS-80 days of writing little BASIC loops to POKE into random memory addresses till something died.  The randomness of it does smell like Pointers gone Wild.  The 2D exa acceleration works fine and hasn't crashed yet.  Glxgears gets great (~1500 fps) framerates till the system dies.

This started happening a month or so ago, when the laptop was running Fedora 9.  It's now on F10, still the same symptoms.  I cleverly didn't record the last good version, hoping that this was a common enough hardware setup that someone else would notice it too, and put off debugging till now - sorry!  Can try the mythical git bisect if someone can point me to instructions (I'm a cvs dinosaur in code management land). 

Xorg log attached with logverbose 7, xrandr output as well.  The system blows up before flushing disk caches, so I don't have a core or anything else, but am willing to apply whatever tricks you experienced folks know of to extract more information.
Comment 1 Alec Habig 2008-12-10 15:01:02 UTC
Created attachment 21025 [details]
the xorg log, verbosity 7
Comment 2 Yang Zhao 2008-12-10 15:10:02 UTC
This is possibly a duplicate of bug #18097
Comment 3 Alec Habig 2008-12-10 15:20:14 UTC
Could be related to bug #18097, but there are differences.  My lockup is hard and complete - no cursor, no way to measure loadavg, no networking - the machine simply bricks.

Also, I'm not using a compositing window manager, just plain old Windowmaker.

Could be related to moving the glxgears window, will experiment with that.
Comment 4 Alec Habig 2008-12-10 15:37:41 UTC
Can confirm that the lockup happens even if the glxgears window is not moving.

Interestingly - gnome + metacity, no problems!  glxgears runs for the minutes I care to let it before getting bored, can drag the window all around.

gnome + compiz gets me the same as bug #18097 : glxgears runs till moving the window around a while, when it hangs up (after leaving snapshots of itself in the places where I stop window moving and let things redraw), at which point X locks, but the mouse and networking do not.  So I can reproduce that bug, but it is different.

So: Windowmaker is tickling some nasty X bug, a window manager (no matter how archaic) shouldn't be able to completely brick a machine.  The window manager is running as a normal user, not root, so shouldn't be able to touch sensitive memory, right?

Comment 5 Egbert Eich 2008-12-13 01:32:36 UTC
For now let's assume that this is a duplicate of #18097.
At least it points into the same direction.

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

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.