Hi Owen,
Owen Martin wrote:
> This looks like a timeout during a read command:
>
> ata3.00: cmd c8/00:08:90:3c:59
>
> Read dma of 8 blocks from 0x903c59
>
> Next time it happens, see if it is the same LBA. Since the drive came
> back after the bus reset makes me think it was probably in error
> recovery for an extended amount of time.
Sounds like a good idea. However, I had the drive swapped yesterday and
have now reinstalled on a (seemingly) identical one which so far seems
to be free from these messages. Hence, I keep my fingers crossed that
this was indeed a hw error.
As it was on warranty I was not allowed to keep the bad drive for
further experiments.
> Sorry, but I am new to using smartmontools for decoding SMART
> attributes. Your previous email showed:
>
> Device is: Not in smartctl database [for details use: -P showall]
>
> Does that imply the tool will not know the exact meaning of all the
> attributes? I am not familiar with Fujitsu's implementation.
I believe you are correct.
>>From the data you sent about the attributes before, it looks like the
> pending and reallocated sector counts are zero, so the block must have
> not failed recovery. Can you try to dump the sector using hdparm-8.9 to
> see if it reproduces?
>
> hdparm --read-sector 9452633 /dev/sda
Would if I could... The messages I sent were indeed only from cases
where the driver succeeded write to the disk in the end (extracts from
/var/log/messages). In the failure cases I did not make a hard copy.
> What is the timeout set to?
>
> cat /sys/block/sda/device/timeout
30
> Maybe try to increase that. You want to be sure that it is not a drive
> issue by verifying the block is readable and the raw values from the
> pending, uncorrectable or reallocated sector attributes don't change.
Will do if I ever see it again.
Best / Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
