sata_sil24 AMD64 crash/lockup

It finaly puked! Unfortulately, it did NOT survive and while it's less of a hard lock-up, the root file system is unhappy and I can't log in and copy the log files, so this is copied by hand.

(Which is a bit odd, because I have the root file system on a RAID-10 such that no controller is critical. I.e. the mirror pairs are sdb/sdc, sdd/sde, and sdf/sda. If the drive just returned -EIO, then the md layer could drop the drive and use the other mirror.)

I have an entire scrollback buffer full of a mixture of ata3 and ata4 error messages.

The two errors are almost identical except for the "Info fld" value, whose value is a consistent function of the controller number.

ata3: command timeout
ata3: status=0x50 { DriveReady SeekComplete }
sdc: Current: sense key: No Sense
Additional sense: No additional sense information
Info fld=0x78af38
sata_sil24 ata3: resetting controller

ata4: command timeout
ata4: status=0x50 { DriveReady SeekComplete }
sdd: Current: sense key: No Sense
Additional sense: No additional sense information
Info fld=0xeb9712
sata_sil24 ata4: resetting controller

If it matters, the order of the errors I can see in the scrollback buffer (but there are clearly more off the top) is 343434343444444433343434344444443.

I will hold the machine in the current state for a couple of hours in case there's any more debug information that can be retrieved from the console.

Anyway, thanks a lot for any clues. I'd really like to push this machine into production, but it's a bit difficult right now.

Interestingly, the machine was not running any stress tests at the time of the problem, but pcbackup may have been doing its thing, and it was recently power-cycled (taken down as non-essential for Monday's hurricane).

An additional data point: it doesn't appear to have failed "fast", given that it left the XFS file system in a confused state.
See http://marc.theaimsgroup.com/?l=linux-xfs&m=113081816804458

So while it did lock up and refuse to proceed further, at least one write got reordered, misdirected, or miswritten as part of the locking-up procedure.

(Actually, theoretically it could have been a read which returned bad metadata and led to an incorrect following write, but I would expect a 150G file system on a 2G machine to have all such core journaling metadata cached, so there should be on such read.)

As before, thanks for any suggestions or patches.

I'm now attempting to repair the XFS file system and move to a post-2.6.14 libata kernel.