From: Douglas Gilbert <dougg@torque.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH as494] Add a scsi_device flag for RETRY_HWERROR
Date: Fri, 25 Mar 2005 09:13:17 +1000 [thread overview]
Message-ID: <4243498D.6070409@torque.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0503241134300.1345-100000@ida.rowland.org>
Alan Stern wrote:
> James:
>
> It turns out that a bunch of USB-IDE converters make the mistake of
> returning SK = 04 (Hardware Error) whenever the IDE device signals any
> sort of error, without bothering to distinguish recoverable from
> non-recoverable errors.
Alan,
The sense key of HARDWARE ERROR is a superset of MEDIUM ERROR.
SBC-2 treats them as synonymous. If it is a "real" medium
error then the LBA of the first (i.e. lowest address) bad
block should be placed in the "info" field and the "valid"
bit should be set. If this is done the block layer does
its job well.
Also for both hardware and medium errors the "sense key
specific" field (if SKSV=1) reports the actual retry
count. The read/write retry count is set in the "read
write error recovery" mode page. Anyways if the disk
has already retried reading the bad block 64 times (say)
what is the point of the mid level retrying??
<aside>
Another interesting quirk I noticed recently was a disk
yielding "recovered error, failure prediction threshold
exceeded" even though the PER bit was clear (which is the
normal case). I had expected recovered errors to be
bad block specific but this error was from SMART saying
"your disk hasn't got long to live". BTW That recovered
error was repeated every 10 minutes or so. Probably a
useful alerte to put in the log and on the console.
Doug Gilbert
next prev parent reply other threads:[~2005-03-24 23:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-24 16:45 [PATCH as494] Add a scsi_device flag for RETRY_HWERROR Alan Stern
2005-03-24 23:13 ` Douglas Gilbert [this message]
2005-03-25 15:37 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4243498D.6070409@torque.net \
--to=dougg@torque.net \
--cc=James.Bottomley@SteelEye.com \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox