[RV280] glyph corruption and occasional X lockup on radeon 9200 se

Bug #373968 reported by fuzzyBSc
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have been getting glyph corruption since upgrading to Jaunty (examples attached). Mostly it is a few characters here and there, but in some cases the corruption is substantial. The corruption seems to be the random flipping or changing of pixels across the glyph, sometimes in the form of lines or blocks of pixels. The corruption is identical when a particular character appears multiple times on the screen, and is evident in screenshots.

The corruption -seems- to be more frequent when extra hardware acceleration is being used. I set my desktop to use compiz and maximum desktop effects, and saw quite a lot of this. After changing back to metacity I believe I have been seeing it less frequently.

Another issue I am having is, I think, related. Since the upgrade I occasionally get an X lockup of some description. Keyboard keys become unresponsive (eg num lock does not change the associated light). The machine itself is still operating, but very slowly as if under high load. I am able to ssh in from a nearby machine, and top will indicate that X is very busy. Firefox also tends to be quite busy, along with chipcard4 for some reason. I am able to reboot from this point, although it takes a long time. I am able to kill X, but again I have to wait. I suspect it is doing some sort of long system call at the time, but was not able to attach strace to see what it might be. To add more confusion, I seem sometimes to be able to kill firefox, then press Ctrl+Alt+F1 to return to normal operations.

My card details as per lspci:

04:01.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
 Subsystem: PC Partner Limited Device 7c25
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 64 (2000ns min), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 17
 Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
 Region 1: I/O ports at e000 [size=256]
 Region 2: Memory at fea00000 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at fea20000 [disabled] [size=128K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel modules: radeonfb

04:01.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)
 Subsystem: PC Partner Limited Device 7c24
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 64 (2000ns min), Cache Line Size: 32 bytes
 Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
affects: ubuntu → xserver-xorg-video-radeonhd (Ubuntu)
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :

I have just experienced another lockup, so rather than raise another bug report about it I thought I would continue attaching information to this one. My assumption at this stage is that they have the same root cause.
The lockup behaviour I experienced today was as follows:
* Applications locked up, but I was still able to move the mouse (previous lockups have actually caused my monitor to report out of range, so this is a first for this behaviour)
* I was able to ssh in (as usual) and login and keyboard performance were very slow (as usual)
* chipcardd4 and Xorg were the busy processes again. I did not put a strace onto chipchardd4, but captured output from Xorg this time before killing it (-9 was needed)
* A reboot was still required to get the system functional again
* Ctrl+Alt+Backspace doesn't seem to work for me in these conditions :(

dmesg doesn't contain any obviously-useful messages, but output is attached.
Xorg.1.log contained a number of enable/disable primary dac messages (attached)
strace on the Xorg process indicated periodic SIGALRMs interweaved with rt_sigreturn and ioctl calls on file descriptor 10. The rt_sigreturn and ioctl were both reporting -1 return code with errno of EBUSY.

Top is actually reporting more than 100% cpu usage for Xorg during this lockup on my dual-core machine.

Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :
affects: xserver-xorg-video-radeonhd (Ubuntu) → xserver-xorg-video-ati (Ubuntu)
summary: - glyph corruption and occasional X lockup in Jaunty with ati rv280
- (radeon 9200 se)
+ [RV280] glyph corruption and occasional X lockup on radeon 9200 se
Changed in xserver-xorg-video-ati (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce)
tags: added: freeze
tags: added: corruption
Revision history for this message
David Harmon (dmh-phoenix) wrote :

Aha! https://bugs.launchpad.net/bugs/367051 would seem to be another instance of this. My Graphics card is Radeon 1300X. I've been getting the occasional X lockups too.

Revision history for this message
Bryce Harrington (bryce) wrote :

Do you have an AGP system? If so, does it help if you try some different AGPMode values? (1,2,4,8)
Please check https://wiki.ubuntu.com/X/Quirks#ATI%20AGP%20Mode%20Quirk and report back if it helps.

Also, if you can, please check if you can reproduce this on Ubuntu Karmic. LiveCD's of the alpha-3 release are available from http://cdimages.ubuntu.com/

Changed in xserver-xorg-video-ati (Ubuntu):
status: Confirmed → Incomplete
Bryce Harrington (bryce)
tags: added: jaunty
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

A new version of the -ati driver is now available in Karmic.

This is a significant update to -ati which brings in kernel mode-setting
(currently disabled) and scores of fixes for DRI2, EXA, etc.

I've posted the new version of this driver to the following PPA,
would you mind testing it and seeing if it resolves the bug you
reported?

  https://edge.launchpad.net/~bryceharrington/+archive/ppa/+sourcepub/709908/+listing-archive-extra

If you're not running this release of Ubuntu, you can try booting the Karmic
LiveCD and loading the PPA onto it, and then log out/in to restart X.
ISOs are available at http://cdimages.ubuntu.com/releases/

After testing Karmic, report back here whether it's still an issue or not,
and if it is please post a fresh Xorg.0.log and 'dmesg' output.

Note there could be new bugs... please file these as new reports using
the command 'ubuntu-bug xorg'.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → New
status: New → Incomplete
Revision history for this message
fuzzyBSc (benjamincarlyle-soundadvice) wrote :

Just a quick update.

I am still running Jaunty at the present time. I'm pretty busy at the current moment and haven't had time to upgrade to Karmic. I have been working through the AGP modes in xorg.conf. I am up to 4 (tried 1 & 2, but not 8). This has been more stable for me, which is to say that it has been failing just as often but not as badly. At settings of 1 and 2 the whole machine would be unusable until a restart. I could ssh in (very slowly) and issue the reboot command, but nothing else helped. With a setting of four I get the same kind of lockups, but occasionally can Ctrl+Alt+F1 my way out and restart gdm. If that doesn't work (often the keyboard is completely unresponsive in this case, ie no numlock response) I have been pretty reliably been able to ssh in. A restart of gdm has been all that I have required to get back up and running at AGP mode 4.

This suggests to me that 4 may be the right mode, but that an underlying problem still exists with the driver. I'll have a go at Karmic when I get a chance. Sorry about the delays.

Revision history for this message
Pauli (paniemin) wrote : Re: [Bug 373968] Re: [RV280] glyph corruption and occasional X lockup on radeon 9200 se

On Fri, Sep 18, 2009 at 11:02 AM, fuzzyBSc <
<email address hidden>> wrote:

> Just a quick update.
>
> I am still running Jaunty at the present time. I'm pretty busy at the
> current moment and haven't had time to upgrade to Karmic. I have been
> working through the AGP modes in xorg.conf. I am up to 4 (tried 1 & 2,
> but not 8). This has been more stable for me, which is to say that it
> has been failing just as often but not as badly. At settings of 1 and 2
> the whole machine would be unusable until a restart. I could ssh in
> (very slowly) and issue the reboot command, but nothing else helped.
> With a setting of four I get the same kind of lockups, but occasionally
> can Ctrl+Alt+F1 my way out and restart gdm. If that doesn't work (often
> the keyboard is completely unresponsive in this case, ie no numlock
> response) I have been pretty reliably been able to ssh in. A restart of
> gdm has been all that I have required to get back up and running at AGP
> mode 4.
>
> This suggests to me that 4 may be the right mode, but that an underlying
> problem still exists with the driver. I'll have a go at Karmic when I
> get a chance. Sorry about the delays.
>
>
> You problem is that you have enabled DFS (DownloadFromScreen) which is not
stable in AGP mode. You can try to disable UTS/DFS in xorg.conf device
section. Details can be found from exa man page.

Revision history for this message
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from fuzzyBSc. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.