Re: Scary Intel SATA problem: "frozen"

[Tejun Heo <htejun@gmail.com>]

Mark Lord wrote:
> Linus Torvalds wrote:
>> [ You may or may not have gotten my previous email. The kernel stayed 
>>   working, but due to the IO errors the filesystem got re-mounted   
>> read-only, and I'm not sure that the email I sent out in that state   
>> actually ever made it out. I suspect it didn't. ]
>>
>> Jeff,
>>  I just had a scary thing on my nice new Intel i965 box (all Intel 
>> chipsets apart from some strange Marvell IDE interface that I'm not 
>> using and that no driver even detected, and a TI firewire thing that 
>> I'm similarly not using).
>>
>> The machine basically froze for about a minute or so (well, things 
>> worked surprisingly well, considering that apparently no disk IO 
>> happened - I initially thought it was just firefox that had frozen up, 
>> since my mail session seemed to be fine), and after it came back the 
>> filesystem was mounted read-only and nothing really worked any more..
>>
>> I have no idea what status 0xD0 means: it looks like ATA_BUSY + 
>> ATA_DRDY + "bit#4", but what is bit#4?
> 
> Bit #4, when actually implemented, is a rotational seek indicator,
> which can be used for timing purposes.
> 
> But when BUSY (bit #7) is set, the rest are generally nonsense.
> 
>> And clearly, the soft-reset isn't doing squat.

I dunno.  My first suspect is transient transmission error and yeah they 
do occur from time to time even on otherwise stable setup.  For example, 
my machine is nvidia ck804 which has pretty weak error handling (at 
least used to) and stays up 24/7 and I've seen such unrecovered 
transmission error just once during last 6+ months.

My experience is that if something is weird (say, power fluctuation or 
electro-magnetic interference), SATA is the first thing to give out and 
that's why we need good EH w/ SATA much more than we do with PATA.

Drives (controllers too) sometimes fall into weird state after such 
errors and softreset is often not enough, so we need hardreset.  ICH8 
can do hardreset even in ata_piix mode.  I'll work on it.

Linus, I'll follow up with Jonas as his problem seems reproducible but 
I'm a bit skeptical about it being a driver issue.  Even w/ all its 
kinks, ata_piix is just a sff IDE controller and libata has been doing 
it for a long time.  I would be really surprised if the driver or 
controller has any such issue in the usual r/w path.  AHCI should be 
able to recover from most error conditions unless drive firmware is 
completely stuck requiring physical power off.

-- 
tejun