Re: Help diagnosing an SATA vs. Sil3112 error on NF7-S 2.0 + FC5/2.6.17 ?

[Tejun Heo <htejun@gmail.com>]

Hello,

jon@alumni.caltech.edu wrote:
>     So far I've seen two sorts of errors. They both seem to be preceded
> by a sort of "chirp" from the drive. The first case resulted in journal
> failure and remounting of the partition that occurred on R/O, the second
> appeared to be more of a transient failure - after locking up the
> machine for a minute, things resumed. The syslogs looked like this:
> 
>     First error:
>> Sep  2 23:07:56 rocky kernel: ata1: command 0x25 timeout, stat 0x50
> host_stat 0x1
>> Sep  2 23:07:56 rocky kernel: ata1: status=0x50 { DriveReady SeekComplete }
>> Sep  2 23:07:56 rocky kernel: ata1: error=0x01 { AddrMarkNotFound }
>> Sep  2 23:07:56 rocky kernel: sda: Current: sense key: No Sense
>> Sep  2 23:07:56 rocky kernel:     Additional sense: No additional sense
> information
>> Sep  2 23:07:56 rocky kernel: EXT3-fs error (device sda4):
> ext3_free_blocks: Freeing blocks not in datazone - block = 1977993469,
> count = 1
>> Sep  2 23:07:56 rocky kernel: Aborting journal on device sda4.
>> Sep  2 23:07:56 rocky kernel: ext3_abort called.
>> Sep  2 23:07:56 rocky kernel: EXT3-fs error (device sda4):
> ext3_journal_start_sb: Detected aborted journal
>> Sep  2 23:07:56 rocky kernel: Remounting filesystem read-only
>> Sep  2 23:07:56 rocky kernel: EXT3-fs error (device sda4):
> ext3_free_blocks: Freeing blocks not in datazone - block = 1499238360,
> count = 1
>> Sep  2 23:07:56 rocky kernel: EXT3-fs error (device sda4):
> ext3_free_blocks: Freeing blocks not in datazone - block = 1092876199,
> count = 1
>   [... and many, many more of the last line - there were hundreds of
>    blocks recovered into lost+found after fsck, although their contents
>    may all have been from previously deleted files]
> 
>     Second error:
>> Sep  3 00:02:18 rocky kernel: ata1: command 0xca timeout, stat 0x50
> host_stat 0x1
>> Sep  3 00:02:18 rocky kernel: ata1: status=0x50 { DriveReady SeekComplete }
>> Sep  3 00:02:18 rocky kernel: ata1: error=0x01 { AddrMarkNotFound }
>> Sep  3 00:02:18 rocky kernel: sda: Current: sense key: No Sense
>> Sep  3 00:02:18 rocky kernel:     Additional sense: No additional sense
> information
>> Sep  3 00:02:18 rocky kernel: Info fld=0x1
> 
>     Is either of these related to the "m15w" error? Or would you have
> any other suggestions as to a known cause of the problem? I looked in
> sata_sil.c, and the ST3400633AS is not on the blacklist in this kernel.

No, none is related to m15w.  It seems that your drive is failing some 
commands w/ ID not found error, which might be a media problem. 
Anyways, libata is having problem recovering from the error condition 
and retrying the command, thus the catastrophe.

>     So far I've upgraded the BIOS to the latest from Abit, which
> includes a more recent SATA BIOS from Silicon Image, and fiddled with
> some of the BIOS settings - particularly changing Ext-P2P Discard from
> 30us to 1ms, as suggested in a much older NVIDIA/Abit bug dialogue. I
> don't know if any of this is actually helping yet, though.

I'm skeptical.

Can you try 2.6.18-rc5?  Latest libata has much improved error handling. 
  If the error your drive is reporting are transient, new libata EH 
should be able to recover from most of them and, even if not, it will 
help diagnosing the problem.

Thanks.

-- 
tejun

-- 
VGER BF report: H 3.80529e-06