I was told on irc to file a bug here. unsure what details are needed so feel free to ask for them. basically, I have a T42p with it's FireGL R300 card. I have always had lockup issues with it and use fglrx in the past to avoid it, but not an issue right now with 1.6 what I mean by lockup is that the machine still works (can ssh into it), and mouse moves, but display is locked up hard. removed the radeon.ko module to see if it cant be reproduced without it loaded. unsure what else to debug or what other info is needed
please attach your xorg log and config. Do any of the following options help (please try them individually, not all together)? Option "DRI" "False" Option "AGPMode" "x" where x is 1 or 2 or 4 or 8. Option "BusType" "PCI"
Created attachment 23834 [details] Xorg.log
Created attachment 23835 [details] xorg.conf file (very simple)
so it crashed again b4 I changed any options. I logged in via ssh and Xorg process was pegging CPU acc to top. running with dri disabled right now.
been running for a while now with Option "DRI" "False" and haven't had the display hang on me yet.
(In reply to comment #5) > been running for a while now with Option "DRI" "False" and haven't had the > display hang on me yet. > Please try the AGPMode options as disabling the DRI disables 3D support.
running with AGPMode set to 1 right now and hasn't hung on me yet, even doing things that normally hang it. anyways, running in cpmpiz again, if it doesn't hang after a day or so, I'll try 2. As 4 is the default and what was having issues b4, don't see much of a point in iterating through that.
(In reply to comment #7) > running with AGPMode set to 1 right now and hasn't hung on me yet, even doing > things that normally hang it. > > anyways, running in cpmpiz again, if it doesn't hang after a day or so, I'll > try 2. As 4 is the default and what was having issues b4, don't see much of a > point in iterating through that. > Excellent. I'll add a quirk to the driver for your chip once you've tested mode 2.
can reproduce the hang even with 1x with dosbox if I tell it to use opengl at a resolution of 1600x1200 in fullscreen. first causes dosbox to chew up all cpu. then if dosbox is killed Xorg chews up all cpu (and is unkillable, just stuck in R state, never getting the kill -9)
(In reply to comment #9) > can reproduce the hang even with 1x with dosbox if I tell it to use opengl at a > resolution of 1600x1200 in fullscreen. > > first causes dosbox to chew up all cpu. then if dosbox is killed Xorg chews up > all cpu (and is unkillable, just stuck in R state, never getting the kill -9) > That may be an app specific issue and not necessarily related to this bug. Can you try agpmode 2?
I've been using 2 without a problem. However, should a buggy app be able to make the Xserver go nuts like that? i.e. consume 100% cpu even when the program is forcably killed and the Xserver not be able to be forcably killed?
(In reply to comment #11) > I've been using 2 without a problem. > ok. > However, should a buggy app be able to make the Xserver go nuts like that? > i.e. consume 100% cpu even when the program is forcably killed and the Xserver > not be able to be forcably killed? > If the app uses GL, the 3D driver converts GL to hardware commands which are fed to the chip. Something about that command stream (perhaps in combination with the 2D command stream from the 2D driver loaded by the xserver) is causing the GPU to hang. Once that happens generally, you're done. The 2D driver is generally stuck looping in an ioctl waiting for idle, etc. which is what causes the CPU to spike.
I've added an AGP quirk for your system: a6855c370194b6df307ea33724fe17a85d67607e
I stumbled upon this "resolved bug" report searching a solution for my issue "not resolved", seeing symptoms so close to mines. I've got an ATI Radeon X800 XT PE on a machine running Slackware64 13.0 (xorg 1.6) using the open-source radeon driver. I enabled EXA acceleration and everything works quite well (even desktop compositing effects in KDE 4), except a few things: - Whenever I run OpenOffice, it hangs the entire X server at the welcome screen as soon as I push the 'Next' button in order to fill in my personal information. This happens with compositing effects enabled or disabled, and even in TWM (so it's not a KDE issue). Tried a few options in xorg.conf and turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). Seems quite strange that OpenOffice makes X hang because of DRI... - Some 3D games run through wine (32 bit, with mesa 32 libs installed correctly) cause the same issue, but not all. Every game I run in SDLMame (3D or 2D) doesn't hang X. I can ssh into the the machine through my laptop, in order to see what's happening. 'top' displays X as a CPU devourer beast. Obviously, no relevant information can be found in Xorg.0.log as soon as the hang occurs. Any suggestions?
(In reply to comment #14) > Tried a few options in xorg.conf and turning off DRI did the trick. Changing > AGPMode to 2 didn't (didn't try 1). So it's definitely not the same problem, please file a separate report.
(In reply to comment #14) > I stumbled upon this "resolved bug" report searching a solution for my issue > "not resolved", seeing symptoms so close to mines. > I've got an ATI Radeon X800 XT PE on a machine running Slackware64 13.0 (xorg > 1.6) using the open-source radeon driver. > I enabled EXA acceleration and everything works quite well (even desktop > compositing effects in KDE 4), except a few things: > - Whenever I run OpenOffice, it hangs the entire X server at the welcome screen > as soon as I push the 'Next' button in order to fill in my personal > information. This happens with compositing effects enabled or disabled, and > even in TWM (so it's not a KDE issue). Tried a few options in xorg.conf and > turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). > Seems quite strange that OpenOffice makes X hang because of DRI... Sounds like bug 13176. Please try the patch there in comment 18.
> Sounds like bug 13176. Please try the patch there in comment 18. Don't know why I didn't see this before. After the hang up occurs, the X log gets filled with these messages: [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. So, I don't think it's anything like bug #13176. I'm gonna open a new bug report.
(In reply to comment #17) > I'm gonna open a new bug report. Done. It's bug #23793
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.