Steps to reproduce: 1. Open several instances of 'gears' and 'gloss' (for me, seven or eight does it pretty quickly) 2. Let them all run for a few seconds 3. The Xserver hangs. The cursor still moves, but the keyboard is dead and open applications stop responding to mouse events. The system is still running, and the following is in /var/log/messages: Mar 13 20:08:50 eem12 kernel: [drm:mga_fire_primary] *ERROR* num_dwords == 0 when dispatched Pertinent hardware specs: Matrox G200, AMD K6/2-400. I suspect this is a race of some sort, because it happens basically at random (I got it to happen once with one instance of gears running while previewing GLPlanet in the Control Center.) Possibly related is the fact that running a GL app locks up the Xserver if it's occluded completely behind another window. That could explain all of the above.
Mismatched XFree/Mesa RPMs. Upgrade to the latest packages: XFree86-4.0.2a-1 & Mesa-3.4-12 from: ftp://people.redhat.com/mharris
Hm. This one still locks up, with the added bonus of not being able to sync my monitor in any mode besides 640x480 (and a rather funky 640x480 at that :-/ Some oddness -- when the Xserver is killed, it says something about an unresolved function being called, and "this shouldn't happen." I've never seen that one before!
I completely agree with you. We are testing a new experimental driver from Matrox, and it is possible that it breaks things. I am reverting the new driver right now, and will be releasing a 4.0.2a release in a few hours that uses the old driver, and should fix the problem you're having. Sorry for the inconvenience.
Ok, I had released 4.0.2a-2 that reverted the driver, and now I have 4.0.3-1 out, and Mesa-3.4-13. Please try them and let me know if it works for you. I can run many of these GL apps simultaneously and it works ok. I've left them running overnight, and they're running while I type too. This is on a G400 singlehead configuration. I have a G200 here I'll test out as well, but I might not get to it right away, so if you could try out 4.0.3 that would be cool. Take care, and hope it works for ya. If not, reopen.
I still get hangs running multiple instances of gloss from Mesa-demos: $ for i in 1 2 3 4 5 6 7 8 9 10 11 12 ; do sh -c "gloss &" ; done ...and the Xserver hangs after a bit, though the mouse cursor still moves. I haven't tried this with gears in awhile, but I don't think the particular application makes a difference. (I've also seen this with just two instances, which is why I think it's a race of some sort.) Covering a window that contains a GL app still hangs the Xserver after not too long (uncovering the window is usually triggers it.)
BTW, this was tested on XFree86 4.0.3-1 and Mesa-3.4-13 (running on a G200, as mentioned before.)
There is a new Matrox patch in 4.0.3-5. It might solve the problem for you. If not, attach your X server log from after a crash, config.
No difference. Xserver log and config attached, as well as tail of dmesg.
Go here instead: http://nebulascape.dyndns.org/bugzilla-31917
After updating from 04/07 rawhide, it seems things are more unstable than ever. Previewing GL screensavers in the Control Center is now enough to crash the machine reproducibly. :-/
I assume that you have 8Mb card. Your top resolution 1152x864x16bpp may be too large for 3d-acceleration which indeed requires 3-4 times more memory than 2d rendering. See if you can reproduce your behavior with a little smaller resolution 1024x768x16bpp or even smaller. That fixed my 3d-accelerated freezes caused by insufficient memory. Report your findings here.
The Xserver also crashes at 640x480x16bpp, in both cases (run a GL app and switch desktops, or open too many gears windows.) gdb shows the Xserver stuck in an __ioctl call, if that's at all relevant. Quake3 et. al. don't render to a hidden window, or to more than one window at a time, and it's my cynical feeling that it'll be some time before the target audience for Linux OpenGL consists of more than FPS players. For now, I don't think the bleeding edge is for me. DRI does show promise, though, and I'll be sure to keep an eye on things from time to time. Thanks, all.
Created attachment 22027 [details] XFree86.0.log
I am having the same problem, but with a G400. I noticed this problem when running 'gears', and moving a window over the gears window. X locked up, but I could ssh into the box. Killing X didn't do much, and the screen stayed "frozen" on the console. I had to use Alt-SysRq-S,U to sync the disks, and do a clean unmount. Here is the output from /var/log/messages when the lockup occured: kernel: [drm:mga_fire_primary] *ERROR* num_dwords == 0 when dispatched I am attaching my XFree86.0.log
This particular bug is apparently fixed in XFree86 4.1.0. You'll need to build your own kernel to use drm w/ that release, but I haven't had the time or inclination to do so. I'll likely try again once kernel-* gets updated in rawhide.
What in the kernel config do I need to change to build with drm? I'm thinking about grabbing the XFree86 from Rawhide, and giving it a try.
It's not a question of kernel options, but matching the correct kernel drm version with the right XFree86 version. In my experience, XFree86 tends to do really bad things if run with the wrong kernel version.
Ok, so how do you make sure the versions are correct? Compile the whole deal (XFree, Mesa, kernel) from source?
The packager usually has this responsibility. Rawhide packages for XFree86 have been good about not installing without all the correct versions, at least recently. I haven't tried with 2.4.5-0.4 for other reasons (USB issues), but I expect it'll be fixed soon. The mailing lists (xfree-xpert, etc.) are a good resource if you're going to do this by hand (not that I recommend it. :-) I'm still waiting for 2.4.5-1 to show up in rawhide, as another bug report I've filed depends on it ...
Fixed in 4.1.0