From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Albert Lee <albertcc@tw.ibm.com>
Subject: Re: PATA drivers in libata?
Date: Thu, 17 Feb 2005 12:13:43 +1100 [thread overview]
Message-ID: <1108602823.5382.11.camel@gaston> (raw)
In-Reply-To: <1108405679.23533.20.camel@localhost.localdomain>
On Mon, 2005-02-14 at 20:42 +0000, Alan Cox wrote:
> On Llu, 2005-02-14 at 00:16, Jeff Garzik wrote:
> > Error handling is -very- stupid simple right now: if we get an error,
> > report that error in the struct request [based on your ATA -> SCSI sense
> > conversion] back to upper layer.
> >
> > It needs to be fleshed out into separate host bus / ATA bus / device
> > errors, and handled accordingly.
>
> Thats a barrier to real PATA IDE I guess then. We see a lot of cable
> errors and speed change downs and not all are caused by misdetecting
> 80wire cables.
>
> The current IDE layer does speed changes synchronously outside the state
> machine which makes a nasty mess when your error handling interrupt
> state wants to speed change.
It's not _too_ bad ... you can just put the current request "on
hold" (and block the queue) until the thread finishes with the speed
change, but I tend to think nowadays that the state machine approach
might be better in the long run (even if a bit more complex to implement
in the first place).
Ben.
next prev parent reply other threads:[~2005-02-17 1:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-13 18:51 PATA drivers in libata? Jeff Garzik
2005-02-13 21:12 ` Mark Hahn
2005-02-13 22:01 ` Jeff Garzik
2005-02-14 0:19 ` Doug Maxey
2005-02-14 0:25 ` Jeff Garzik
2005-02-13 22:38 ` Alan Cox
2005-02-14 0:16 ` Jeff Garzik
2005-02-14 20:42 ` Alan Cox
2005-02-17 1:13 ` Benjamin Herrenschmidt [this message]
2005-02-17 1:11 ` Benjamin Herrenschmidt
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=1108602823.5382.11.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertcc@tw.ibm.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@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.