From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libata error handling fixes (ATAPI)
Date: Tue, 15 Nov 2005 04:28:59 -0500 [thread overview]
Message-ID: <4379AA5B.1060900@pobox.com> (raw)
In-Reply-To: <20051115074148.GA17459@htj.dyndns.org>
Tejun Heo wrote:
> I've been trying to do about the same thing and here's my version
> which only fixes error/sense handling. This patch makes ahci's
> eng_timeout act correctly w.r.t ATAPI sense requesting. libata ATAPI
> request sensing mechanism was not broken. What's broken was AHCI's
> eng_timeout handler. And, yes, this problem disappears with request
> sensing via active qc turn-around in your patch.
Yes, that's intentional. I fixed the problem in AHCI by copying code
from libata-core's ata_qc_timeout(), similar to what you did. Didn't
like that solution at all, so I started over from scratch.
> As I've written several times, I'm not a big fan of sense requesting
> by turning around active qc. For libata's EH to work any better,
> handing-over failed commands to EH is necessary with or without
> request sensing. Hmm... It's true that the current implementation
> used for ATAPI request sensing needs improvements. Remember those
> patches which implement generic failed command handover and perform
> request sensing from EH with proper timeout and synchronization?
We'll see how things shake out in the future.
One of the reasons I haven't responded to your ATA exceptions doc RFC is
that I don't like to plan. Linux isn't about roadmaps, it's about
what's the next-best-step. I think my current EH fixes are the next
best step, as it cleans up the error handler a lot, and gets things
working. Next step after that? No idea. I just go on gut feeling I
have based on direction.
The current feeling is that we should move away from complex
dependencies on the SCSI EH layer, and do all our own error handling
(perhaps in ata_wq). This will allow use of libata as a block driver.
> Ah.. also, I'm working on sil24 ATAPI support. However, it seems that
> I need to do a little bit more; unfortunately, I'm not sure which....
> INQUIRY succeeds and then my drive fails the first TUR with SK 6h
> (UNIT ATTENTION) which is probably due to previous phy reset. Then,
> my drive fails to repsond to following REQUEST SENSE.
>
> With my patched AHCI, REQUEST SENSE works and after SK 06h and several
> SK 02h's (NOT READY), it comes online and works okay.
>
> As INQUIRY works okay, my hunch is that I'm not performing TUR
> properly (that is ATAPI command with no data) and the drive locks up
> after it. I'll fool around with this more and report.
TUR fails for me, too. It triggers the EH code, which is why I wound up
needing to fix it :)
Have you dumped the D2H FIS returned by the drive, when the TUR fails?
What does it look like? What does the D2H FIS look like after REQUEST
SENSE?
I bet there is some "clear error" actions we need to take on sil24,
before it work there.
Jeff
next prev parent reply other threads:[~2005-11-15 9:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-14 19:57 [PATCH] libata error handling fixes (ATAPI) Jeff Garzik
2005-11-15 7:41 ` Tejun Heo
2005-11-15 9:28 ` Jeff Garzik [this message]
2005-11-15 10:03 ` Tejun Heo
2005-11-15 11:02 ` Jeff Garzik
2005-11-15 12:00 ` Jens Axboe
2005-11-15 18:25 ` Mike Christie
2005-11-15 18:41 ` Jens Axboe
2005-11-16 12:40 ` Jens Axboe
2005-11-16 12:56 ` Jeff Garzik
2005-11-16 13:13 ` Jens Axboe
2005-11-16 13:23 ` Jeff Garzik
2005-11-16 13:31 ` Jeff Garzik
2005-11-16 13:47 ` Jens Axboe
2005-11-16 15:04 ` Bartlomiej Zolnierkiewicz
2005-11-16 15:31 ` Jens Axboe
2005-11-16 16:06 ` Bartlomiej Zolnierkiewicz
2005-11-16 17:10 ` Jens Axboe
2005-11-16 19:11 ` Bartlomiej Zolnierkiewicz
2005-11-16 19:22 ` Jens Axboe
2005-11-16 19:45 ` Jens Axboe
2005-11-16 19:46 ` Bartlomiej Zolnierkiewicz
2005-11-16 19:55 ` Bartlomiej Zolnierkiewicz
2005-11-16 20:02 ` Jens Axboe
2005-11-16 20:23 ` Bartlomiej Zolnierkiewicz
2005-11-16 20:40 ` Jens Axboe
2005-11-19 10:55 ` Christoph Hellwig
2005-11-19 13:27 ` Jens Axboe
2005-11-15 13:43 ` Tejun Heo
2005-11-15 14:11 ` Jeff Garzik
2005-11-16 3:04 ` Tejun Heo
2005-11-16 3:18 ` Jeff Garzik
2005-11-16 3:48 ` Mark Lord
2005-11-16 3:58 ` Jeff Garzik
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=4379AA5B.1060900@pobox.com \
--to=jgarzik@pobox.com \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).