Bug 37166

Summary: 3D applications with larger textures cause X to freeze
Product: xorg Reporter: Vlado Plaga <rechner>
Component: Driver/RadeonAssignee: 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:
Description Flags
Xorg.0.log with EQ overflow error and backtrace
none
dmesg output none

Description Vlado Plaga 2011-05-13 02:21:14 UTC
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).
Comment 1 Vlado Plaga 2011-05-13 02:21:59 UTC
Created attachment 46670 [details]
dmesg output
Comment 2 Michel Dänzer 2011-05-13 02:27:42 UTC
(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.
Comment 3 Vlado Plaga 2011-05-13 02:52:49 UTC
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
Comment 4 Vlado Plaga 2011-05-13 03:57:09 UTC
(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
Comment 5 Alex Deucher 2011-05-13 08:56:43 UTC
You might try using the internal gart rather than AGP.  For UMS:
Option "BusType" "PCI"
in the device section of your xorg.conf
Comment 6 Vlado Plaga 2011-05-16 12:10:20 UTC
(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).
Comment 7 Adam Jackson 2018-06-12 19:10:49 UTC
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.