Re: [RFT][PATCH v7] sata_mv: convert to new EH

[Jeff Garzik <jeff@garzik.org>]

dean gaudet wrote:
> On Fri, 13 Jul 2007, greg wrote:
> 
>> dean gaudet <dean <at> arctic.org> writes:
>>> if you've got any other workload you'd like me to throw at it, 
>>> let me know.  
>> I've had a few problems with the driver in 2.6.20 (fc6xen x86_64). The machine 
>> tended to lock up after a random period of time (from a few minutes upwards), 
>> without any messages. Performing a smartctl on all the disks, or leaving smartd 
>> running, seemed to speed up the rate at which the crash occurred. What I found 
>> was that by moving the sata_mv device onto it's own bus (or a bus with two 
>> sata_mv devices), the crashes went away. Are you doing tests with the 
>> controller sharing a bus with other devices?
>>
>> Is there an merit to my observation that it might be an issue with devices 
>> sharing a PCI-X bus?
>>
>> Cards: Supermicro 5081 (SAT-MV8), Supermicro 6081 (SAT2-MV8), Highpoint 5081 
>> (RocketRaid 1820A v1.1). Motherboards: Tyan S2882, AMD 8131 chipset; IBM x206, 
>> Intel 6300ESB.
> 
> hmm!  i don't seem to have replied to this.
> 
> you know, i've seen this problem.  the first time it happened was with a 
> promise ultra tx/100 or tx/133 (on a dual k7 box, two controllers on the 
> same bus certainly)... a 5 minute cronjob logging HD temperatures via 
> smart would occasionally cause one of the disks to just disappear, return 
> errors on every request, and required a reboot to rediscover it.  
> eliminating the cronjob stopped the problem.

Promise cards, in particular, snoop the ATA commands and occasionally 
update registers and do other internal magic based upon those commands.

It is possible that SMART commands have the same requirements as SET 
FEATURES - XFER MODE: namely, all ports must be idle when the command is 
issued, not just the port in question.

	Jeff