From: Jeff Garzik <jeff@garzik.org>
To: Fajun Chen <fajunchen@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Mark Lord <liml@rtr.ca>, Tejun Heo <htejun@gmail.com>
Subject: Re: PATA Sil680 Disabling IRQ
Date: Thu, 28 Feb 2008 17:24:14 -0500 [thread overview]
Message-ID: <47C7348E.5070607@garzik.org> (raw)
In-Reply-To: <8202f4270802281411j747bf96dx34ff81c4d192d417@mail.gmail.com>
Fajun Chen wrote:
> On 2/28/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> PIO read/writes with wrong direction is not the only failure mode,
>> > PATA sil680 also failed with disabling IRQ with some unsupported
>> > commands such as Trusted Send (0x5E) even with perfect TF data. Given
>> > that some ATA commands are optional, we may have a chance to hit the
>> > trap even with well programmed code.
>>
>>
>> That sounds very strange - I regularly test PATA controlles with
>> unsupported commands and see the correct 0x04 abort patterns.
>>
>>
>> > What would take to harden the PATA ISR code such that it fails more gracefully?
>>
>>
>> First thing would be to work out why your system is behaving differently
>> to the others. What is the trigger here.
>>
> For most of unsupported commands, it will be aborted by drive.
> However, for some unsupported commands, it may not. I suspect these
> bad commands are the new ones in ATA8 issued to some drives with old
> firmware. For instance, can you try command 0x5E (Trusted Send PIO
> data out) with sector count set to 1 and see what happens?
>
> The blame is probably on drives which should have aborted these
> commands. But the reality is that libata will handle variety of drives
> including the ones with old firmware. So the question here is whether
> libata PATA code can be more fault tolerate. It seems the weakest link
> is on PATA PIO since I have not been able to reproduce the IRQ
> disabling problem on DMA operations.
With regards to many controllers -- and I think sil680 is one of those
-- they snoop commands send to the device, in order to set some internal
parameters (generally, guessing the taskfile protocol of the command).
As such, you cannot assume that all controllers will gracefully abort
unknown commands.
Again, we are in the realm of privileged administrators creating
scenarios which are not designed for general production use.
I support efforts to "harden" libata, but its a judgement call when it
comes to random, unpredictable scenarios that only root may create.
There are an infinite variety of such scenarios.
Jeff
next prev parent reply other threads:[~2008-02-28 22:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 0:47 PATA Sil680 Disabling IRQ Fajun Chen
2008-02-27 0:58 ` Jeff Garzik
2008-02-28 0:20 ` Fajun Chen
2008-02-28 20:22 ` Alan Cox
2008-02-28 22:11 ` Fajun Chen
2008-02-28 22:24 ` Jeff Garzik [this message]
2008-02-28 23:10 ` Alan Cox
2008-02-29 1:07 ` Fajun Chen
2008-02-29 11:21 ` Alan Cox
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=47C7348E.5070607@garzik.org \
--to=jeff@garzik.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=fajunchen@gmail.com \
--cc=htejun@gmail.com \
--cc=liml@rtr.ca \
--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 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).