[RV280] glyph corruption and occasional X lockup on radeon 9200 se
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-
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-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
affects: | ubuntu → xserver-xorg-video-radeonhd (Ubuntu) |
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 |
tags: | added: freeze |
tags: | added: corruption |
tags: | added: jaunty |
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.