| Summary: | 3D applications with larger textures cause X to freeze | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Vlado Plaga <rechner> | ||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | 7.5 (2009.10) | ||||||||
| Hardware: | PowerPC | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 46670 [details]
dmesg output
(In reply to comment #2) > [...] I did not manage to reduce AGP speed. When I give "radeon.agpmode=1" to > the "Kernel command line" there are still lines like the following in dmesg: radeon.agpmode only has an effect with KMS. With UMS, you need to use Option "AGPMode" in xorg.conf. Found the correct xorg version (with "aptitude show xorg")... Here are a few lines from glxinfo: OpenGL renderer string: Mesa DRI R200 (RV280 5962) 20090101 AGP 4x PowerPC/Altivec TCL OpenGL version string: 1.3 Mesa 7.7.1 (In reply to comment #2) > radeon.agpmode only has an effect with KMS. With UMS, you need to use Option > "AGPMode" in xorg.conf. Thanks for the quick reply! I tried that as well (although I think I had tried it before, for the option was in my xorg.conf, but commented out). The effect was the same: a blue-ish full screen picture, and a dead X server. The backtrace in Xorg.0.log seems to be identical to the one I already attached to this report. Now I also created a new report for the KMS situation in Ubuntu: #37169 You might try using the internal gart rather than AGP. For UMS: Option "BusType" "PCI" in the device section of your xorg.conf (In reply to comment #5) 'Option "BusType" "PCI"' maybe led to a slight improvement, but not to a solution. I noticed the preview window shows the GLSlideshow xscreensaver without crashing X, so I thought a lower resolution might help. And indeed: switching to 720x400 I could even preview that screensaver in full screen mode. But already the modest resolution of 1024x768 caused a crash like before (as in the attached Xorg.0.log). Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases. |
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.
Created attachment 46669 [details] Xorg.0.log with EQ overflow error and backtrace Although I know that the UMS driver is no longer top priority (and probably even less so on PowerPC) I'd appreciate help in solving this issue. I already invested to many hours in trying to make "3D" work on this old Mac mini for just giving up. ;-) I never had stable 3D under Linux on this computer. With KMS I don't get it to run at all and with UMS only some applications work well: glxgears and /usr/lib/xscreensaver/queens for example. What I'd be more interested in, a GL desktop or GL slideshow, always crashes X immediately. From what I found on the net it might be ralated to an AGP problem, but I did not manage to reduce AGP speed. When I give "radeon.agpmode=1" to the "Kernel command line" there are still lines like the following in dmesg: [ 27.784430] agpgart-uninorth 0000:00:0b.0: putting AGP V2 device into 4x mode [ 27.784444] pci 0000:00:10.0: putting AGP V2 device into 4x mode Accordingly I get "(==) RADEON(0): Using AGP 4x" in "Xorg.0.log". I'm attaching my Xorg.0.log ending with "[mi] EQ overflowing. The server is probably stuck in an infinite loop." and a short backtrace. This is from Debian 6.0 (and I'm not sure it really is version 6.8.0 of the Radeon driver).