Neil Schemenauer's Web Log

I've got a Radeon X800 GTO card in my desktop machine. It's an older card but it still has pretty good 3D gaming performance (it came out of the box with all pipelines enabled). I bought it a few years ago based on an ArsTechnica system building guide. I've been irritated for a while by it's poor performance in X but never bothered to look into the cause.

Yesterday I was tinkering driver problems for a Radeon 9600 HD (or some similar recent, cheap card). When using Ubuntu's fast user switching (i.e. multiple instances of X), performance goes to pot. It turns out that the driver can only use DRI and therefore acceleration on the first X instance. It's likely that the limitation will be fixed in an upcoming "radeon" or "radeonhd" driver version.

Anyhow, that tinkering session gave me a hint to my poor X800 performance. I suspected it was related to the XAA/EXA options. Sure enough, a peak at the Xorg.0.log revealed:

(==) RADEON(0): Using XAA acceleration architecture
...
(II) RADEON(0): XAA Render acceleration unsupported on Radeon
 9500/9700 and newer. Please use EXA instead.
(II) RADEON(0): Render acceleration disabled

Adding Option "AccelMethod" "EXA" to the Device section of the xorg.conf configuration file produced a huge speedup. The performance before was not awful but the improvement was dramatic. The configuration of X has gotten vastly easier over the years due to sensible defaults but it looks like they missed this one.

I recently had a Seagate 500GB drive die on me. The Linux kernel produced the following messages:

ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: failed to read native max address (err_mask=0x1)
ata4.00: HPA support seems broken, skipping HPA handling
ata4.00: ATA-8: ST3500320AS, AD14, max UDMA/133
ata4.00: 0 sectors, multi 0: LBA NCQ (depth 0/32)
ata4.00: configured for UDMA/133 (device error ignored)
scsi 3:0:0:0: Direct-Access     ATA      ST3500320AS      AD14 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
sd 3:0:0:0: [sdb] 0 512-byte hardware sectors: (0 B/0 B)

The computer BIOS reported the drive as having 0 size. After much searching I finally figured out that I was facing what is known as the "Seagate 7200.11 0 LBA" problem. Essentially, a firmware bug causes the drive to get into a hung state. The only way to repair it is to use the 3.3V CMOS level pins connected to the serial interface of the drive controller and issue some (potentially dangerous) low level commands.

A good description of the fix procedure as been compiled by some owners of the drives. Seagate have not handled the bug well considering that apparently many drives are affected. The fix is not recommended for those unfamiliar with electronics as you can easily brick your drive.

If you want to attempt it, the trickiest part is finding a RS232 level converter that can work with 3.3 volts. You need a chip like the MAX232. I have a MAX232N on a AVR board but according to the datasheet it only handles 5 volts. I made a level converter for the MAX232 TX (out) pin using a N-channel MOSFET I had kicking around. You only need to convert the MAX232 output since the input will sense 0-3.3V logic okay. The MOSFET level converter circuit I used is very elegant. If you are going to attempt this, double and triple check that you have the RX and TX pins connected correctly (there is much confusion on the labeling of these pins). You want the T?OUT pin of the MAX232 (via the level converter) going to the RX pin of the drive (the rightmost pin).

After you have successfully run the commands, you need to upgrade the drive firmware to prevent the bug from happening again. My drive went from firmware version AD14 to SD1A. The good news about this procedure is that the data on the drive is intact.

My setup is shown below (MacGyver would be proud).