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.
Created attachment 21025 [details] the xorg log, verbosity 7
This is possibly a duplicate of bug #18097
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.
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?
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.