The radeon driver mostly works for me, but I get distracting light snow and occasional horizontal lines flickering across the screen. I've tried to capture some close-up images with my camera which I'll attach to this bug. The worst corruption is at the far right of the screen. I don't see the problem with the radeonhd driver. I've tried to switch to the radeon driver a few times but always run into this snag. I'm running Ubuntu Jaunty with ati_drv.so from xf86-video-ati-6.12.2-76-g2c8e130 My hardware is an HP t5735 thin client with onboard x1200: $ lspci | grep VGA 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] I'll attach configs, logs and the photos
Created attachment 25431 [details] xorg.conf for radeon (snowy)
Created attachment 25433 [details] Xorg.0.log for radeon (snowy)
Created attachment 25436 [details] xorg.conf for radeonhd (clean)
Created attachment 25438 [details] Xorg.0.log for radeonhd (clean)
Created attachment 25439 [details] snapshot of "snow" on lcd monitor The corruption comes and goes so quickly, I captured this with a relatively long exposure since a fast shot would never catch it.
Created attachment 25440 [details] second snapshot of "snow" on lcd monitor The corruption comes and goes so quickly, I captured this with a relatively long exposure since a fast shot would never catch it.
Can you try with the driver from xf86-video-ati git master? Also, you might want to increase the amount of vram allocated to graphics in your bios if possible. your current setting (32 MB) is too small to enable the dri which results in slower 2D performance and no Xv acceleration as well.
Hi Alex, I enjoy watching your daily commits to the driver. Thanks for looking at my bug. I think I am already running the git master as mentioned in the description (xf86-video-ati-6.12.2-76-g2c8e130). Sorry that wasn't clear. I cloned and built like this: $ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati $ cd xf86-video-ati $ ./configure $ make $ cp -fb src/.libs/ati_drv.so /usr/lib/xorg/modules/drivers/ati_drv.so However I just realized I only copied ati_drv.so and not radeon_drv.so. I assume I can ignore the theatre*.so files. I'll retry with radeon_drv.so. Also I'll check if I can increase the RAM allocated to video. I wasn't aware that was possible. Thanks!
Okay, I retested with the correct radeon_drv.so. I also copied the theatre*.so files into place just in case, though I don't know what purpose they serve. Unfortunately I get the same snow as before. I'll update the attached Xorg.0.log to the new one. Regarding RAM allocated to gfx, unfortunately the BIOS doesn't provide any options for changing that. Do you have any suggestions for manipulating that value apart from the supplied BIOS? Regarding DRI, I'm able to use DRI with the radeonhd driver by setting Virtual 1920 1200. However I've noticed that doesn't work for the radeon driver. I guess the radeon driver needs more memory than radeonhd?
Created attachment 25462 [details] Xorg.0.log for radeon (snowy)
(In reply to comment #9) > Regarding RAM allocated to gfx, unfortunately the BIOS doesn't provide any > options for changing that. Do you have any suggestions for manipulating that > value apart from the supplied BIOS? > > Regarding DRI, I'm able to use DRI with the radeonhd driver by setting Virtual > 1920 1200. However I've noticed that doesn't work for the radeon driver. I > guess the radeon driver needs more memory than radeonhd? > It should work. The virtual stuff is handled by the xserver. what does the log say when you set the virtual option?
(In reply to comment #11) > It should work. The virtual stuff is handled by the xserver. what does the > log say when you set the virtual option? Sorry, I didn't mean that the Virtual line didn't work. What I meant was that using Virtual 1920 1200 would allow the radeonhd driver to enable DRI, but not the radeon driver. However I retested and it appears that using Virtual 1920 1200 allows either driver to enable DRI. That's good to know for the future, but it doesn't change anything regarding the "snow" screen corruption which is present with radeon but not radeonhd.
Does disabling colortiling help? Option "ColorTiling" "FALSE"
(In reply to comment #13) > Does disabling colortiling help? > Option "ColorTiling" "FALSE" Sorry for the delay, this is my primary workstation... I tried the suggestion, it unfortunately doesn't help. Back to radeonhd for now, but I'll update from git and test any further suggestions you want. Thanks.
Maybe you monitor doesn't like coherent mode. try: xrandr --output DVI-0 --set coherent_mode 0 I don't remember if it takes effect immediately or not, so you may have to force a mode change, e.g.: xrandr --output DVI-0 --mode 1280x1024 xrandr --output DVI-0 --mode 1920x1200
(In reply to comment #15) > Maybe you monitor doesn't like coherent mode. try: > xrandr --output DVI-0 --set coherent_mode 0 > I don't remember if it takes effect immediately or not, so you may have to > force a mode change, e.g.: > xrandr --output DVI-0 --mode 1280x1024 > xrandr --output DVI-0 --mode 1920x1200 I tried the sequence above. The snow is gone at 1280 but returns at 1920.
I have experienced a similar problem on my Dell 5100. For me it seems to have worsened considerably with new kernel versions. I started running Ubuntu Intrepid on a Dell 5100 laptop at the beginning of March (2009). I don't recall any display problems for the first few weeks. Then a few weeks ago I noticed occasional pixel artifacts and odd horizontal lines. It worsened, and a few days ago became intolerable. For me the severity seems to depend upon the Linux kernel version. When running 2.6.27-14-generic I get prolonged colorful snowstorms, green and blue blizzards, that last anywhere from seconds to minutes, recurring at intervals from one minute to maybe fifteen minutes. My display becomes pretty much incomprehensible and useless. Running 2.6.27-11-generic (the previous kernel automatically downloaded by my system update) is somewhat better, but still frustrating. The blizzards are less frequent, but I do see many artifacts and lines. I've gone back to 2.6.27-7-generic for now. With that kernel I get zero snowstorms (that I recall) and just a few pixel artifacts similar to the snapshots Aron posted. I can also still boot Windows XP. No displays problems occur then, so it doesn't appear to be failing hardware. Other technical details: Here's the panel ID from Xorg.0.log: (II) RADEON(0): Panel ID string: IBM J1838 ITSX95 Chipset: "ATI Radeon Mobility M7 LW (AGP)" (ChipID = 0x4c57) This is a Dell 5100, about six years old. Native panel resolution is 1400x1050. Radeon drivers loading: (II) Matched radeon from file name radeon.ids (==) Matched radeon for the autoconfigured driver (II) LoadModule: "radeon" (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" (II) AIGLX: Loaded and initialized /usr/lib/dri/radeon_dri.so My /etc/X11/xorg.conf is all defaults, apparently set by dexconf. I have attempted no tweaking of settings. I hope that's useful. Cheers
Oops, I forgot to paste the version info for radeon_drv.so: (II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.5.2, module version = 6.9.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1
(In reply to comment #18) > Oops, I forgot to paste the version info for radeon_drv.so: > compiled for 1.5.2, module version = 6.9.0 6.9.0 is ancient. You might have more luck with a more recent version. 6.12.2 is that latest release.
Thanks for the version tip. I've been hoping not to stray from Ubuntu stock downloads, but I'll give the newer radeon driver a try ASAP.
No joy. Or at least, less joy than I hoped for. radeon_drv.so 6.12.2 still exhibits display corruption for me. At first it seemed better. It ran without any issues the first day. But as I was about to file an update this morning, the problem returned. One thing I noticed today when I rebooted to a different kernel version: the display corruption persisted even after X apparently shut down. During shutdown, when the display switched to a text console, the plain text became garbled. Even the BIOS POST and boot screen were garbled. The console text cleared up when the GRUB menu ran. As I type this my display is quivering from side to side, with portions of my browser window shifting several pixels left and right. I'm trying to take some pictures of my screen. I'll upload a snapshot if I get one that shows the problem.
Just come across this bug - I think it may be related to the one I reported here. http://bugs.freedesktop.org/show_bug.cgi?id=22229 Would be interesting to know if the fix/hack I found works in your case.
I've incorporated Tom's patch into xf86-video-ati git master. Please test and let me know if it helps.
Alex, this solves the problem for me. I tested this morning with Tom's patch and now I'm running git revision 808c90a24c48da7fa97e15e2f12be5bb8fd8cc96 [Only enable frac fb divs on rs600/rs690/rs740 for now]. Thank you Tom!
I'll try this patch ASAP.
I compiled and installed the current git master. It hasn't run long enough to determine whether the noise and screen corruption have gone away for me. But it has run long enough to generate several megabytes of this message in Xorg.log: (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at radeon_commonfuncs.c:809 (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at radeon_commonfuncs.c:809 (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at radeon_commonfuncs.c:809 (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at radeon_commonfuncs.c:809
(In reply to comment #26) > I compiled and installed the current git master. It hasn't run long enough to > determine whether the noise and screen corruption have gone away for me. > > But it has run long enough to generate several megabytes of this message in > Xorg.log: > > (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at > radeon_commonfuncs.c:809 > (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at > radeon_commonfuncs.c:809 > (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at > radeon_commonfuncs.c:809 > (EE) RADEON(0): ADVANCE_RING count != expected (6 vs 10) at > radeon_commonfuncs.c:809 > Fixed now. However, the pll fix in this bug is only relevant to rs6xx chips and you are running an r1xx chip.
I noticed the chip family selection in the patch code, and I suspected it wouldn't apply to mine. I thought I'd try it anyway. Is the frequency selection a benign change that could applied safely to my chip version as well? The screen trash problem just returned while I've been typing. Just like last time it first reappeared while typing in this comment form. An odd coincidence, but probably just Murphy's Law, I think. The display problem happens with various apps running, not just Firefox. I piggybacked on this bug report because it seemed closely related. If the original reported case is now fixed, would you like me to file a new, separate bug report? By the way, the current git master does seem to fix another minor cosmetic quirk that I hadn't even reported. So that's an improvement. I just took a batch of photos while my display was snowed. I'll see if any of them turned out well enough to illustrate the problem. Cheers
(In reply to comment #28) > I noticed the chip family selection in the patch code, and I suspected it > wouldn't apply to mine. I thought I'd try it anyway. > > Is the frequency selection a benign change that could applied safely to my chip > version as well? It's not relevant as your chip does not have fractional fb dividers. > > The screen trash problem just returned while I've been typing. Just like last > time it first reappeared while typing in this comment form. An odd > coincidence, but probably just Murphy's Law, I think. The display problem > happens with various apps running, not just Firefox. > Does it happen with acceleration disabled (Option "NoAccel" "True") or DRI disabled (Option "DRI" "False")? It might also be AGP related. Try: Option "AGPMode" "X" where X = 1 or 2 or 4 or Option "BusType" "PCI" > I piggybacked on this bug report because it seemed closely related. If the > original reported case is now fixed, would you like me to file a new, separate > bug report? It may be the same issue, but the resolutions will probably be different since the chips are so different. Might as well file a new bug. > > By the way, the current git master does seem to fix another minor cosmetic > quirk that I hadn't even reported. So that's an improvement. > Good. What was it? > I just took a batch of photos while my display was snowed. I'll see if any of > them turned out well enough to illustrate the problem. That would be helpful. It would also be helpful to get a copy of your video bios and you xorg log and config.
New bug filed, 22256 https://bugs.freedesktop.org/show_bug.cgi?id=22256 The quirk that seems fixed for me involves some artifacts on window decorations after waking up from hibernation. After waking up, I used to see some horizontal lines a few pixels away from window top and bottom edges and some odd shapes at the corners of 3D buttons and such. My workaround was to restart the gtk-window-decorator process using the command "gtk-window-decorator --replace". That minor issue seems to have gone away in the current git master revision. Git is new to me, by the way. I don't yet know how to obtain the git version to be more specific. Thanks for plugging away at this! Cheers
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.