Created attachment 20770 [details] xorg.conf Forwarding this bug from a Ubuntu reporter: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/272991 [Problem] Monitor goes black (no signal) after 30 seconds, unless the glx module is disabled. With glx disabled, display works with proper resolution but has a bad flicker every 10 sec. Fiddling with AGPMode, EXA, DRI, and other parameters didn't have an effect. [lspci] 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Unknown device [1002:053a] Monitor: Samsung SyncMaster 170MP (VGA) Motherboard: Asus K8V-X SE Processor: Athlon 64 2800+ [Original Report] On this test version of Kubuntu Intrepid, my monitor goes black after about 30 seconds. Normally I would expect the usual keyboard selection etc. to appear, but the last video I get is the boot menu itself. The monitor indicates no signal. This happens whether I use the "install" or "live CD" options, and regardless of whether I choose the "Safe video" mode with F4 (this is usually necessary for me due to my weird monitor). So it's possible that safe video mode is broken - I'm not sure. The attached monitor is a Samsung SyncMaster 170MP, connected via VGA, at 1280x1024/58Hz and the vesa driver. Historically autodetection by the installer fails so I boot in "safe video mode" and supply my own xorg.conf later. This has worked for me through Hardy. I changed my xorg.conf some time ago because I found that my particular monitor doesn't work well with DDC and certain acceleration options make my graphics card unhappy. It may have been as far back as Dapper but definitely in Feisty it was like this. My installation procedure for new releases through Hardy has been to install in "safe video mode", then reboot in safe video mode (or text mode), copy over my old xorg.conf, and reboot in normal mode. Based on other bug reports I went ahead and did some experiments. I can tell you that: 1) disabling dri and glx allows me to see video, although the quality is poor 2) AGPMode appears to have no effect 3) "ignore LVDS" doesn't help either I have the radeon driver *almost* working - by removing the Modes information and disabling only "glx", I get a good image at the proper resolution, but with a bad flicker event about every 10 seconds. xorg.conf attached if you have any suggestions - successful vesa config is exactly that with driver changed to "vesa" and no "AccelMode EXA". I am up and running with Intrepid Beta now via the alternate install CD (text mode).
Created attachment 20771 [details] [review] Xorg.0.log
I was able to test on a different monitor and the flicker-when-glx-disabled disappeared, but the black screen with glx enabled persists. In addition, I found another user with the same problem: http://ubuntuforums.org/showthread.php?t=939603 He also reports black screen and "Idle timed out, resetting engine..." messages. I emailed him privately and he confirmed that disabling glx cured his problem. So I think there is a general issue with glx and Radeon 7000/RV100 cards and this driver. Thanks, Jeff (I am the original Ubuntu reporter)
I assume what really makes the difference is disabling the DRI, not GLX? Did you try Option "DRI" "off" to disable the DRI? (The "dri" module will be autoloaded by current X servers) If that's the case, does the DRI work with Option "BusType" "PCI"?
Disabling either "glx" or "dri" in the Modules section allows me to use the driver successfully. Leaving both enabled and using BusType PCI per your suggestion also appears to work (and gives me those nice effects I've heard so much about, for the first time). Do these symptoms suggest anything? Do I have a setting wrong somewhere? Thanks.
(In reply to comment #4) > Disabling either "glx" or "dri" in the Modules section allows me to use the > driver successfully. Leaving both enabled and using BusType PCI per your > suggestion also appears to work (and gives me those nice effects I've heard so > much about, for the first time). Do these symptoms suggest anything? Do I > have a setting wrong somewhere? Thanks. > It means AGP isn't working on your system. Generally this means a bad AGP mode. Can you try the AGPMode option again? e.g., Option "AGPMode" "1" Please also try: Option "AGPMode" "2"
OK, I've retried, and it's still the case that none of the "AGPMode" variants work. I also tried restoring the BIOS defaults, and then varying the AGP multipliers in both BIOS and xorg.conf, to no avail. I added changing "AccelMethod" "EXA" into the mix but that made no difference. Finally I noticed a comment somewhere on the web regarding aperture size. Although my BIOS aperture size setting was 64M, a kernel message (from agpgart-amd64) indicated it was 32M. Unfortunately changing the BIOS aperture size to 32M, and then subsequently to 128M, made no difference either.
Created attachment 22862 [details] register settings from "radeontool" for the passing (no glx enabled) case At Bryce's suggestion I built "radeontool" and am supplying the register settings found when glx is disabled (and the screen looks OK) and when it is enabled (blank screen, next attachment).
Created attachment 22863 [details] radeontool register dump for glx enabled (black screen)
It looks like AGP is just plain busted with your combination of card and motherboard. setting the bustype to pci is the right fix.
> It looks like AGP is just plain busted with your combination of card and > motherboard. setting the bustype to pci is the right fix. Is this something that could be detected and fixed/quirked in the driver itself? I'd like to avoid having to require users to set this in their xorg.conf since we're trying to move away from that in general, but if it's not possible I can just document it I guess.
(In reply to comment #10) > > It looks like AGP is just plain busted with your combination of card and > > motherboard. setting the bustype to pci is the right fix. > > Is this something that could be detected and fixed/quirked in the driver > itself? I'd like to avoid having to require users to set this in their > xorg.conf since we're trying to move away from that in general, but if it's not > possible I can just document it I guess. > You could add a pci mode quirk list just like you did for agp. maybe add it to RADEONPreInitChipType() in radeon_driver.c where we detect the bus type.
Created attachment 22871 [details] log from X running with AMD64 kernel I have some good news - this may be a kernel bug. I found this: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/29813 And followed its advice to install an AMD64 kernel. Aperture references in the kernel log changed from this (i686): [ 18.447151] agpgart-amd64 0000:00:00.0: AGP aperture is 32M @ 0xe8000000 to this (x86_64): [ 0.004000] Checking aperture... [ 0.004000] Aperture from AGP @ e8000000 old size 32 MB [ 0.004000] Aperture from AGP @ e8000000 size 128 MB (APSIZE f20) [ 0.004000] Node 0: aperture @ 8e8000000 size 32 MB [ 0.004000] Aperture beyond 4GB. Ignoring. [ 0.575494] agpgart-amd64 0000:00:00.0: AGP aperture is 128M @ 0xe8000000 and I got video with glx! working Xorg.log attached.
Well, switching to 64 bits seems like more of a workaround than a solution, so perhaps the pci quirk stuff is still necessary. I'll put that on my todo list, but I'm fairly swamped (as I'm sure everyone is) so can't say when I'll be able to get to it; if anyone else wants to give it a shot, please don't wait on me.
I think I found the kernel bug - aperture size is calculated by different code if in 64b mode (arch/x86/kernel/aperture_64.c) versus 32b mode (drivers/char/agp/amd64-agp.c). There's a section of very similar (possibly cut+paste then modified) code in the two files but in the 32b version an early exit is taken. I removed this early exit so the aperture size would be recalculated and got the correct value. Now running glx in 32b mode with my hacked kernel: OpenGL renderer string: Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow!+/SSE2 NO-TCL I'm off to make a kernel bug report. Thanks for your help.
Great, good sleuthing tracking that down. Since it sounds like there is not an X problem here, I guess we can close these bugs. But feel free to reopen if there is additional X work to be done.
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.