Bug 657607

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.