I'm having a problem with Xorg from cvs and mesa built from cvs. When I'm running beryl on it for some time my X hard locks. I can access the machine with ssh but can't terminate X. The logs say nothing special after it locked up. The problem must be introduced with a change in "recent" mesa/xorg code, because when I downgrade mesa to 6.5.2 my system seems to be stable. (But its r300 is not as fast as with latest code so I'd like to use more recent version) First I thought it could be an option in xorg.conf but I tried a lot of different combinations with no luck.
Created attachment 8212 [details] dmesg of my system
Created attachment 8213 [details] The xorg.conf with fastest options.
Created attachment 8214 [details] the Xorg.conf log file
Could you enable debugging output of drm an attach log generated once a lockup happened. Could you also gitbisec mesa try finding if there is a particuliar commit responsible for this (but i don't think so as there haven't been so much change since 6.5.2).
I was wrong: Even with mesa 6.5.2 my system locks up.
Hmm where exactly do I need to enable debug? When compiling what or can I set en env variable?
Ok now I downgraded to xorg 7.1 and mesa 6.5.1. (stable stuff on gentoo) But still my system locked up. I found a good way to lock it up: Starting beryl + a 3d app like googlearth. The only thing the log said was: (II) XAA: Evicting pixmaps
Same problem here, with mesa 6.5.2 and xorg-server 1.1.99.903
You enable debug by echo 1 > /sys/module/drm/parameters/debug or while loading drm module modprobe drm debug=1
(In reply to comment #9) > You enable debug by echo 1 > /sys/module/drm/parameters/debug > or while loading drm module modprobe drm debug=1 Ok I will now upgrade again and then try to get some more information from the log file right?
drm log will be in your message logfile likely /var/log/message
Created attachment 8215 [details] debug output I crashes especially (or even only) under "heavy" load...
I just had a similar crash with googleearth (on metacity, without compiz/beryl), so it seems that the problem is driver-related.
This problem still exists (xorg 7.2). Is there anything I can do to help solving this problem? Do you need some additional information?
I opened another bug report, because I'm not sure that the problem with googleearth is the same reported here (https://bugs.freedesktop.org/show_bug.cgi?id=9861). Could you check if you have that problem too? You could also try with the instructions of http://wiki.x.org/wiki/DebuggingTheXserver. To obtain the backtrace I had to attach gdb to the X process AFTER the lockup.
As far as I can judge this a lot of people are having this freeze problem. It even happens without running compiz. The problem still exists in the latest versions of xorg-server. Is any dev taking this serious? Do you need more information or anything we can do to get this solved soon?
Problem disappeared here with the upgrade to xorg-server 1.4, mesa 7.0.1 and xf86-video-ati 6.7.1xx (using compiz/compiz-fusion 0.5.2 and then 0.6.2/0.6.0).
I have the same problem with the open source drivers and with Xorg server 1.3 (Ubuntu 7.10), like many other people on this bug report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/108527 GoogleEarth usually makes it happen faster.
(In reply to comment #18) > I have the same problem [...] That's quite a bold statement unfortunately - there are countless possible causes for lockups, all resulting in similar if not the same symptoms. As for this particular report, the first thing to do is always to rule out a configuration issue. In particular, Option "GARTSize" "64" is a candidate, try reducing that to 32 (see bug 12612). Option "DynamicClocks" is another candidate. If disabling these and other options doesn't help, the best thing to do is to try and isolate the version of Mesa, xf86-video-ati, drm or xserver that introduced it or to try and isolate a way to reproduce the problem that is as specific as possible.
Back in March of this year I started having a problem with lockups on my PCIe box when running most/many 3D applications (including GoogleEarth) if I didn't disable SilkenMouse. From my testing, this seemed to be introduced with the merged from the vbo-0.2 branch. Please try disabling that option and see if it makes a difference.
(In reply to comment #20) > Back in March of this year I started having a problem with lockups on my PCIe > box when running most/many 3D applications (including GoogleEarth) if I didn't > disable SilkenMouse. Is that still necessary with current xf86-video-ati Git?
(In reply to comment #20) > Back in March of this year I started having a problem with lockups on my PCIe > box when running most/many 3D applications (including GoogleEarth) if I didn't > disable SilkenMouse. From my testing, this seemed to be introduced with the > merged from the vbo-0.2 branch. Please try disabling that option and see if it > makes a difference. > SilkenMouse is a config option in xorg.conf, how exactly? Btw: Where can I get a list of all options?
Michel, actually this does not appear to be necessary any more. Not sure when it was fixed :-) Cyrill, in the Device section, you'd add the line: Option "SilkenMouse" "0" That will disable SilkenMouse
Closing
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.