Created attachment 41003 [details] [review] Xorg log First, I'm running Kubuntu Maverick on a Thinkpad T60. I couldn't figure out how their version numbering of the driver corresponds to yours, but I've included package information at the bottom of this message. If I start the laptop allowing KMS and using just the laptop's own display (1400x1050), then things are by-and-large well. However, if I attach an external monitor, configure the display, and hit "accept" (at which point it activates the external monitor), severe graphical glitches start. The most regular of these is a set of horizontal lines that continually dance across the screen. I was unable to take a screenshot of them; the files look entirely normal, even though the display does not. Let me know if a photograph would help. Against a blue background, many of the lines change from black to white at somewhere around 2/3 the way horizontally across the screen. Moreover, when I type a character there is a quick "blip" on the screen that looks as if graphical elements (either sections of windows or whole windows) are temporarily being placed in the wrong position. After a fraction of a second, it goes back to the usual dance of the lines. Switching between windows causes a more persistent form of this whacky whole-screen shuffling, lasting perhaps half a second. Using UMS avoids these glitches. The odd thing is that I don't remember these glitches being present on the Maverick beta CD, which I tried out some time ago. (I only just this week upgraded to Maverick on the hard drive.) This is the version of the radeon driver apparently installed: $ dpkg -l *radeon* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-===========================-===========================-====================================================================== ii libdrm-radeon1 2.4.21-1ubuntu2.1 Userspace interface to radeon-specific kernel DRM services -- runtime ii radeontool 1.6.1-1 utility to control ATI Radeon backlight functions on laptops ii xserver-xorg-video-radeon 1:6.13.1-1ubuntu5 X.Org X server -- AMD/ATI Radeon display driver un xserver-xorg-video-radeonhd <none> (no description available)
Created attachment 41005 [details] Original dmesg (pre BIOS upgrade) In the process of attaching dmesg output, I looked at it and noticed a comment about needing a BIOS update. This is the dmesg prior to the BIOS upgrade.
Created attachment 41006 [details] dmesg output (post BIOS upgrade) The glitches are actually worse after the BIOS upgrade; rather than being a set of horizontal lines that dance across the screen through which I could still read what I was typing, now the screen is far more messed up (in hard-to-define ways), making it impossible to use. KMS still works in the laptop's native resolution, however. This dmesg was acquired after activating the external monitor.
Created attachment 41007 [details] xrandr output Here's the output of xrandr --verbose. Note I should point out that I'm not certain that the last dmesg output was really after activating the external monitor; I couldn't see the command line to make sure I was running the right command. After uploading this attachment, I'm going to switch the external monitor on again and get you a new dmesg, just to be sure.
Created attachment 41008 [details] More certain dmesg post BIOS upgrade OK, this one I'm sure about.
This is just to say that I've verified that forcing UMS with a file: /etc/modprobe.d$ cat radeon.conf # Turn off KMS # Put this in /etc/modprobe.d options radeon modeset=0 still allows me to work with the large external monitor even after the BIOS upgrade.
booting with radeon.new_pll=0 on your kernel command line in grub or updating to 2.6.37 should fix the issue.
(In reply to comment #6) > booting with radeon.new_pll=0 on your kernel command line in grub or updating > to 2.6.37 should fix the issue. Supplying the kernel parameter did not fix the issue. I have not tried updating my kernel.
Can you try booting with radeon.disp_priority=2 on your kernel command line? Also try adding: Option "ColorTiling" False" to the device section of your xorg.conf
(In reply to comment #8) > Can you try booting with radeon.disp_priority=2 on your kernel command line? By itself, this did not help. > Also try adding: > Option "ColorTiling" False" > to the device section of your xorg.conf I tried this on its own, in combination with the disp_priority=2, and even tossed in new_pll=0 as well for good measure. None of these fixed the problem. There is one point that I should perhaps amplify: when I boot with the external monitor attached, X comes up in 1024x768 mode. Even in KMS, it works fine at this resolution. The glitches only start when I try to change to a higher resolution (LVDS 1400x1050, VGA 1920x1080). I have not tried many different higher-resolution settings, just these.
(In reply to comment #9) > There is one point that I should perhaps amplify: when I boot with the external > monitor attached, X comes up in 1024x768 mode. Even in KMS, it works fine at > this resolution. The glitches only start when I try to change to a higher > resolution (LVDS 1400x1050, VGA 1920x1080). I have not tried many different > higher-resolution settings, just these. Right, the glitches are bandwidth related, the memory controller is having trouble keeping up with all the requests so you end up with underflow to the VGA port. Either there's a problem with the display watermarks (which shouldn't be a factor with disp_priority set to 2), or the bandwidth requests are too much for the asic to keep up with. You might try a lower color depth. You might also try: Option "EXAPixmaps" "off" in the device section of your xorg.conf
> Right, the glitches are bandwidth related, the memory controller is having > trouble keeping up with all the requests so you end up with underflow to the > VGA port. Either there's a problem with the display watermarks (which > shouldn't be a factor with disp_priority set to 2), or the bandwidth requests > are too much for the asic to keep up with. Just to make sure I'm being clear: I also don't have a problem with high resolution if I'm using UMS. It's only with KMS that it's a problem. I don't know enough to judge whether the bandwidth demands would be expected to be higher under KMS than UMS. > You might try a lower color depth. > You might also try: > Option "EXAPixmaps" "off" > in the device section of your xorg.conf I will try these tomorrow morning. Thanks for your suggestions.
(In reply to comment #11) > Just to make sure I'm being clear: I also don't have a problem with high > resolution if I'm using UMS. It's only with KMS that it's a problem. I don't > know enough to judge whether the bandwidth demands would be expected to be > higher under KMS than UMS. The memory usage patterns are different and likely higher under KMS. Do you still have the problems with KMS if you disable accel? Option "NoAccel" "True" in the device section of your xorg.conf
(In reply to comment #12) > The memory usage patterns are different and likely higher under KMS. Do you > still have the problems with KMS if you disable accel? > Option "NoAccel" "True" > in the device section of your xorg.conf Setting "NoAccel" to "True" fixed the problem. (I should note that I also had "ColorTiling" still set to "False" left over from a previous test.) Many thanks! Obviously it would be nice to have acceleration, but this is certainly a major improvement. So does this establish that it's really a hardware limitation? Or is it possible that there is some bug in acceleration with my hardware configuration? Independently, I tried the "EXAPixmaps" but this caused X to fail to start. I noticed that the template xorg.conf file created by X -configure did not even list this as an option.
(In reply to comment #13) > Setting "NoAccel" to "True" fixed the problem. (I should note that I also had > "ColorTiling" still set to "False" left over from a previous test.) Many > thanks! Obviously it would be nice to have acceleration, but this is certainly > a major improvement. > > So does this establish that it's really a hardware limitation? Or is it > possible that there is some bug in acceleration with my hardware configuration? > The combination of the large screens and the acceleration activity patterns seem to indicate it's more than the MC can handle at one time. > Independently, I tried the "EXAPixmaps" but this caused X to fail to start. I > noticed that the template xorg.conf file created by X -configure did not even > list this as an option. Can you attach your xorg log with that option set?
(In reply to comment #14) > > Independently, I tried the "EXAPixmaps" but this caused X to fail to start. I > > noticed that the template xorg.conf file created by X -configure did not even > > list this as an option. > > Can you attach your xorg log with that option set? Sorry, but can you provide a bit of instruction about how I should do that? When I add that option, upon boot-up the whole screen starts turning a bluish/greenish color, a bit like a slowly-burning piece of paper. I can't interact with the machine at all in that circumstance---it's unresponsive to anything I do. I'm sure there's a trick, I just don't know it.
(In reply to comment #15) > > Can you attach your xorg log with that option set? > > Sorry, but can you provide a bit of instruction about how I should do that? > When I add that option, upon boot-up the whole screen starts turning a > bluish/greenish color, a bit like a slowly-burning piece of paper. I can't > interact with the machine at all in that circumstance---it's unresponsive to > anything I do. I'm sure there's a trick, I just don't know it. Just copy the log on your next boot (it will often be saved as Xorg.0.log.old) or, boot into single user (append single to the end of your kernel command line in grub) or a non-X runlevel and retrieve the log.
Hi Alex, (In reply to comment #16) > > > Can you attach your xorg log with that option set? > > > > Sorry, but can you provide a bit of instruction about how I should do that? > > When I add that option, upon boot-up the whole screen starts turning a > > bluish/greenish color, a bit like a slowly-burning piece of paper. I can't > > interact with the machine at all in that circumstance---it's unresponsive to > > anything I do. I'm sure there's a trick, I just don't know it. > > Just copy the log on your next boot (it will often be saved as Xorg.0.log.old) > or, boot into single user (append single to the end of your kernel command line > in grub) or a non-X runlevel and retrieve the log. My apologies for being so slow; I was testing other things, but I should have given this to you first. The "EXAPixmaps" issue turned out to be my fault; I had typed Options "EXAPixmaps" "off" rather than Option "EXAPixmaps" "off" I'm now beginning to recognize that "burnt paper" screen as indicative of an xorg.conf error.
Hi again Alex, (In reply to comment #14) > (In reply to comment #13) > > Setting "NoAccel" to "True" fixed the problem. (I should note that I also had > > "ColorTiling" still set to "False" left over from a previous test.) Many > > thanks! Obviously it would be nice to have acceleration, but this is certainly > > a major improvement. > > > > So does this establish that it's really a hardware limitation? Or is it > > possible that there is some bug in acceleration with my hardware configuration? > > The combination of the large screens and the acceleration activity patterns > seem to indicate it's more than the MC can handle at one time. I also have some good news: after updating my system (which included xserver-xorg-core 1.9.0-0ubuntu7.3), KMS works even without an xorg.conf file (i.e., without setting NoAccel to "true"). So I am marking this bug as "fixed." Thanks for your help!
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.