The display will remain ungarbled until I do anything that's too taxing on the display. Mainly zooming in on images (like google maps zooming in firefox). It definitely is exacerbated by resizing images in firefox or chromium. I was running nomodeset to resolve this problem but as of the upgrade to fedora 14, X will no longer start with nomodeset in the kernel parameters. -- Version-Release number of selected component (if applicable): libdrm-2.4.22-1.fc14.x86_64 xorg-x11-drv-ati-6.13.1-0.3.20100705git37b348059.fc14.x86_64 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] 2.6.35.6-48.fc14.x86_64 This occurs on a gateway laptop model lt3103u. -- Steps to Reproduce: 1. Fire up firefox, zoom in and out with google maps 2. Observer display become unreadable 3. Profit!
Created attachment 463125 [details] xorg.conf
Created attachment 463127 [details] Xorg.0.log
Created attachment 463128 [details] Xorg.9.log
Created attachment 463129 [details] syslog
Created attachment 463130 [details] dmesg output
Created attachment 463152 [details] Screenshot of Fedora 14 after screen becoming garbled.
I filed the original bug for F12, and now I've updated to F14, and I still get this. Just running firefox for a few seconds causes this. I also was using nomodeset, which no longer works. thanks, Paul
Also see bz#533645 comment 17 (is this a duplicate?). As someone who also ran into the issue with F12, but not F13, only now to upgrade to F14 and see it again, I'm wondering if this isn't an upstream regression (?). In any case, given the widespread volume of the X1200 series, we will want to test this for F15. NOTE: I do _not_ speak for Red Hat product support, I am with consulting. I just ran into the issue myself after upgrading to F14 while I was on-the-road. The workaround I'm using (disabling DRM) makes 2D performance unbearable.
(In reply to comment #8) > As someone who also ran into the issue with F12, but not F13, only now to > upgrade to F14 and see it again, I'm wondering if this isn't an upstream > regression (?). I definitely encountered this bug in Fedora 13.
Reporter, what's the point of your /etc/X11/xorg.conf? What happens if you run without it (and without nomodeset)? Could you give us logs from that (even failed) attempt? Thank you
Matej -- The "point of my /etc/X11/xorg.conf.d/01-system-setup-video.conf in case others want a working X configuration with the RS690. But yes, I will send a log from a non-working configuration this evening. ;) Jason -- I'd be interested in exchanging information on and trying different kernels and X versions in Fedora 13. I upgraded mid-F13 release, with several errata. I know I ran with the last few kernels and X updates had no issues. I need to go back through the changelogs to see anything of note.
(In reply to comment #10) > what's the point of your /etc/X11/xorg.conf? Actually, I removed a bunch of commented out configuration settings when I posted my xorg.conf. The reason it is there is because of my various X experiments (setting DRI off, changing AccelMethod, setting RenderAccel off). I was also messing around with the radeonhd driver a couple of fedoras back. > What happens if you run without it (and without nomodeset)? If I run with no xorg.conf and modesetting enabled, the exact same behavior is exhibited (garbled display). Xorg no longer starts with nomodeset: See bug 604196. (In reply to comment #11) > I'd be interested in exchanging information on and trying different kernels and > X versions in Fedora 13. That's cool with me. I have F13 and F14 currently installed on separate partitions so that wouldn't be a problem. Although I won't be able to perform any experimenting until around 19:00 PDT when I have access to that laptop.
Created attachment 486948 [details] dmesg with no xorg.conf and drm debug enabled Fully updated fedora with libdrm 2.4.22 and xorg-x11-drv-ati 6.13.1
Created attachment 486949 [details] Xorg.0.log with no xorg.conf Fully updated fedora with libdrm 2.4.22 and xorg-x11-drv-ati 6.13.1
Created attachment 486950 [details] Xorg.9.log Fully updated fedora with libdrm 2.4.22 and xorg-x11-drv-ati 6.13.1
Created attachment 486951 [details] Syslog (no xorg.conf) Fully updated fedora with libdrm 2.4.22 and xorg-x11-drv-ati 6.13.1
As expected deleting my xorg.conf file has no effect on the garbled display issue. packages: xorg-x11-drv-ati-6.13.1-0.4.20100705git37b348059.fc14.x86_64 libdrm-2.4.22-1.fc14.x86_64 kernel-2.6.35.11-83.fc14.x86_64
Working! OK, so I finally decided to try a new kernel. I pulled 2.6.39-rc4 from kernel.org, the defconfig doesn't enable either DRM_RADEON or DRM_RADEON_KMS, and everything works great like this! (don't forget to add ext4 as this is the main thing most Fedora users would need that's not in the defconfig). If I enable either DRM_RADEON or DRM_RADEON+DRM_RADEON_KMS I get the same problem. I'm not sure if these settings would work with older kernels or not. Other than the kernel the laptop is fully updated F14 even with --enablerepo=updates-testing. thanks, Paul
This bug is still present in fedora 15. I'm able to reproduce by zooming in and out rapidly with google maps in firefox. libdrm-2.4.25-1.fc15.x86_64 xorg-x11-drv-ati-6.14.1-1.20110504gita6d2dba6.fc15.x86_64 kernel-2.6.38.6-27.fc15.x86_64
Created attachment 512470 [details] lspci for Gateway netbook LT3101u CPU - AMD ATHLON 64 ATI Radeon graphic card
Created attachment 512472 [details] Gateway Kernel 2.6.38.6-26.rc1.fc15.x86_64
(In reply to comment #20) > Created attachment 512470 [details] > lspci for Gateway netbook LT3101u CPU - AMD ATHLON 64 ATI Radeon graphic card Is this AMD driver the one currently being used: http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.aspx?type=2.7&product=2.7.2.3.2&lang=English
(In reply to comment #22) > (In reply to comment #20) > > Created attachment 512470 [details] > > lspci for Gateway netbook LT3101u CPU - AMD ATHLON 64 ATI Radeon graphic card > > Is this AMD driver the one currently being used: > > http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.aspx?type=2.7&product=2.7.2.3.2&lang=English No this link point to the closed source driver, we don't distribute closed source software in fedora.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #20) > > > Created attachment 512470 [details] > > > lspci for Gateway netbook LT3101u CPU - AMD ATHLON 64 ATI Radeon graphic card > > > > Is this AMD driver the one currently being used: > > > > http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.aspx?type=2.7&product=2.7.2.3.2&lang=English > > No this link point to the closed source driver, we don't distribute closed > source software in fedora. Proprietary drivers are used for some hardware components and considering this has been an issue for over 3 years and may distributions of Fedora this might qualify one of the hardware components. Considering most vendors are now supporting linux.
There is no proprietary software in fedora whatsoever This bug affects only a limited set of user with those gpu for instance i am unable to reproduce on my rs690 (but maybe i am just not waiting long enough). We are sorry but we don't have the resource (neither the hw neither the human one to fix all the bugs)
ceco: in the case where the driver authors can't reproduce the bug, often the only way it can really get fixed is if we can somehow transport the problematic hardware to a coder who can fix the problem...where in the world are you located? do you manage to get to any Linux conventions at all?
Thank you Adam and I do understand but I must be the odd one because I have a few laptops from different vendors. I'm going leave it alone I will hit the forums and see if I can get some resolution to this issue
ceco: the log you provided indicates you do have the same hardware as the initial reporter of this bug, so this is a good place to follow. but my question was significant: if you happen to live somewhere close to an X developer we might be able to make some arrangement for them to try and resolve the bug with physical access to your laptop.
I relocated to Maryland from St. Louis where I was member of the St. Louis LUGs maybe there is a LUGroup here.
RH has a pretty large engineering contingent in Boston, I'll have to try and find out if anyone there might be able to look at the issue.
...maryland, massachussets, what's the difference...excuse me while i fail!
Problem still exists in Fedora 16 xorg-x11-drv-ati-6.14.2-2.20110727git8c9266ed2.fc16.x86_64 libdrm-2.4.26-3.fc16.x86_64 kernel-3.1.0-7.fc16.x86_64
Based on the screen shot, this looks awfully suspiciously like the same issue as bug 738790 on different hardware... (Neither of the examples in the bug report quite match, but the example here looks exactly like what my Thunderbird looks like about half the time.) Anyone in the Albany, NY area want to have a look?
Problem still exists in Fedora 17
The problem still exists in Fedora 19 TC2. xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19.x86_64 libdrm-2.4.44-2.fc19.x86_64 kernel-3.9.0-0.rc8.git0.2.fc19.x86_64
same problem here: xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19.x86_64 libdrm-2.4.46-1.fc19.x86_64 kernel-devel-3.10.5-201.fc19.x86_64
Created attachment 786232 [details] xorg log
Comment on attachment 786232 [details] xorg log log with nomodeset in bootup
(In reply to g. artim from comment #36) > same problem here: > > xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19.x86_64 > libdrm-2.4.46-1.fc19.x86_64 > kernel-devel-3.10.5-201.fc19.x86_64 wrong queue this is a vesa problem, with modeset, screen garbled until i switch to nomodeset on some apps (firefox, libreoffice, etc)
I still see this RS690M problem after 2 years on F20. What can I do to help fix this?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.