[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080316185602.79064f7c@core>
Date: Sun, 16 Mar 2008 18:56:02 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Anders Eriksson <aeriksson@...tmail.fm>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Jens Axboe <jens.axboe@...cle.com>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.25-rc4
On Sun, 16 Mar 2008 11:13:42 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>
> On Sun, 16 Mar 2008, Bartlomiej Zolnierkiewicz wrote:
> >
> > We don't do error handling for special commands (REQ_TYPE_ATA_*) at all,
> > ide_error() just dumps device's status/error register(s) and finishes early:
>
> Well that sounds bogus too, for all the same reasons already outlined. The
> DRQ flag needs to be cleared up on error!
No it doesn't. DRQ simply means "drive has more data for the controller
if you want it". Interrupts are controlled via IEN and the interrupt line.
If the drive wants to give us data and we end the transaction that is
fine. In practice a tiny few devices crap themselves if we don't.
A few controllers require specific magic, either to ensure we never touch
data after an error, or that we drain enough bits to empty the internal
fifo the controller is using to improve ata performance and latches the
IRQ arrival against.
The PIIX/ICH is as it happens one of the most forgiving controllers
anyway. The later ICH (the ones that are also AHCI) are a bit fussier
about handling them to the spec because they seem to be some kind of
magic ICH emulation layer on an AHCI chip.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists