[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <48BD6086.1030101@xms.se>
Date: Tue, 02 Sep 2008 17:49:26 +0200
From: "Jonas Petersson" <jonas.petersson@....se>
To: Owen Martin <omartin@...ezza.com>
CC: Justin Piszcz <jpiszcz@...idpixels.com>, linux-ide@...r.kernel.org,
smartmontools-support@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [smartmontools-support] exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists