From: Eric Mudama <edmudama@gmail.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Brad Campbell <brad@wasp.net.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: Crashed Drive, libata wedges when trying to recover data
Date: Fri, 3 Sep 2004 18:10:46 -0600 [thread overview]
Message-ID: <311601c904090317107136bd43@mail.gmail.com> (raw)
In-Reply-To: <87k6vbs0a9.fsf@stark.xeocode.com>
On 03 Sep 2004 13:57:34 -0400, Greg Stark <gsstark@mit.edu> wrote:
>
> Eric Mudama <edmudama@gmail.com> writes:
>
> > Boom, you're deadlocked. This means that in SATA, the only way to overcome
> > this deadlock in the driver is to have the host/board generate a COMRESET
> > OOB burst to hard-reset the drive.
>
> So now I'm wondering if there's a way to coerce the libata drivers to generate
> this?
>
> > Today's (and tomorrow's) generation of SATA drives will never ever
> > generate a 0x59 status... the error and DRQ bits become mutually
> > exclusive. However, unfortunately, there are quite a few drives in
> > the field which have this behavior...
>
> I read somewhere that the current generation of SATA drives from everyone
> except Seagate were really PATA with a "bridge". It sounded like BS to me, but
> is that why they're behaving like PATA drives as far as these error codes? Or
> is it simply a question of the shared firmware codebase?
Our (Maxtor's) first generation of SATA drives were all bridged
products. Our new drive (slowly appearing today) is a native sata
product that support NCQ.
next prev parent reply other threads:[~2004-09-04 0:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 8:32 Crashed Drive, libata wedges when trying to recover data Greg Stark
2004-09-02 9:05 ` Brad Campbell
2004-09-03 4:52 ` Greg Stark
2004-09-03 5:13 ` Greg Stark
2004-09-03 11:08 ` Alan Cox
2004-09-03 14:27 ` Greg Stark
2004-09-03 13:53 ` Alan Cox
2004-09-03 15:58 ` Greg Stark
2004-09-03 15:09 ` Alan Cox
2004-09-03 16:47 ` Greg Stark
2004-09-03 17:08 ` Eric Mudama
2004-09-03 17:35 ` Greg Stark
2004-09-03 17:57 ` Greg Stark
2004-09-03 19:45 ` Brad Campbell
2004-09-04 0:10 ` Eric Mudama [this message]
2004-09-03 12:51 ` Brad Campbell
2004-09-03 14:09 ` Alan Cox
2004-09-04 21:58 ` Greg Stark
2004-09-05 4:02 ` Brad Campbell
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=311601c904090317107136bd43@mail.gmail.com \
--to=edmudama@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=brad@wasp.net.au \
--cc=gsstark@mit.edu \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.