Tejun Heo wrote:
Some ATA controllers including SFF BMDMA and libata PIO HSM need the
number of bytes mapped in the sg table. Yeah, it can be calculated with
a simple macro but it also is a fundamentally confusing dual-sizing
which should be made as clear as possible. Plus, it can be
And, here's working version. I'll splite and post them tomorrow.
Thanks.
Index: work/block/blk-core.c
===
--- work.orig/block/blk-core.c
+++ work/block/blk-core.c
@@ -116,6 +116,7 @@ void rq_init(struct request_queue *q, st
On Mon, 2008-02-04 at 23:43 +0900, Tejun Heo wrote:
And, here's working version. I'll splite and post them tomorrow.
Thanks.
Index: work/block/blk-core.c
===
--- work.orig/block/blk-core.c
+++ work/block/blk-core.c
@@
On Mon, 2008-02-04 at 18:25 +0900, Tejun Heo wrote:
Tejun Heo wrote:
Some ATA controllers including SFF BMDMA and libata PIO HSM need the
number of bytes mapped in the sg table. Yeah, it can be calculated with
a simple macro but it also is a fundamentally confusing dual-sizing
which
On Tue, 2008-02-05 at 09:43 +0900, Tejun Heo wrote:
Hello,
James Bottomley wrote:
No, it doesn't. Drain needs to extend the sg table too
The patches do extend the sg table.
Hmm... Where?
It's the block component; it's already in git head with this patch:
commit
Hello,
James Bottomley wrote:
No, it doesn't. Drain needs to extend the sg table too
The patches do extend the sg table.
Hmm... Where?
and it makes controllers lax about buffer overruns for commands they
shouldn't be.
So adjust the qc-nbytes to show no drain element in libata ...
On Tue, 2008-02-05 at 09:06 +0900, Tejun Heo wrote:
James Bottomley wrote:
Plus, tape devices are also ATAPI and since the problem seems to be
handling of ATAPI pio commands, they need all of this too. It really
is, I think, better just to do the setup in the libata slave configure
if
James Bottomley wrote:
No, it doesn't. Drain needs to extend the sg table too
The patches do extend the sg table.
Hmm... Where?
It's the block component; it's already in git head with this patch:
commit fa0ccd837e3dddb44c7db2f128a8bb7e4eabc21a
Author: James Bottomley [EMAIL PROTECTED]
On Tue, 2008-02-05 at 10:07 +0900, Tejun Heo wrote:
James Bottomley wrote:
No, it doesn't. Drain needs to extend the sg table too
The patches do extend the sg table.
Hmm... Where?
It's the block component; it's already in git head with this patch:
commit
James Bottomley wrote:
Oops, I was talking about padding. Sorry about that.
Oh, OK ... the I thought the changelog was pretty explicit. However, it
works because the dma_aligment parameter of the block layer ensures that
all elements of the sg list begin and end on an address that conforms
On Sun, 2008-02-03 at 16:37 +0900, Tejun Heo wrote:
James Bottomley wrote:
I think the best solution is to update block layer draining such that it
can be included together before the merge window closes. I'll dig into it.
Like I said, the block layer pieces are already upstream. All
James Bottomley wrote:
I'm reluctant to add another parameter to the request, but this one you
can calculate: you just do it wherever you work out the size of the
request. If data_len is the true data length and total_data_len is the
data length plus the drain length, the calculation
On Mon, 2008-02-04 at 00:14 +0900, Tejun Heo wrote:
James Bottomley wrote:
I'm reluctant to add another parameter to the request, but this one you
can calculate: you just do it wherever you work out the size of the
request. If data_len is the true data length and total_data_len is the
James Bottomley wrote:
The aic94xx sequencer has a very finely honed sense of DMA transfers.
It's fully automated, and handles both ATA DMA and ATA PIO in the
sequencer engine (so all the driver sees is DMA).
ditto AHCI, and most other DMA engines
It reports both underrun and overrun
On Sun, 2008-02-03 at 11:38 -0500, Jeff Garzik wrote:
James Bottomley wrote:
The aic94xx sequencer has a very finely honed sense of DMA transfers.
It's fully automated, and handles both ATA DMA and ATA PIO in the
sequencer engine (so all the driver sees is DMA).
ditto AHCI, and most
James Bottomley wrote:
I'm only really going by what Tejun says about AHCI. The problem as I
understand it is data overrun on PIO mode commands. AHCI apparently
(like aic94xx) processes these internally and doesn't actually use the
libata pio handlers, so it just uses an internal buffer to
James Bottomley wrote:
On Mon, 2008-02-04 at 00:14 +0900, Tejun Heo wrote:
James Bottomley wrote:
I'm reluctant to add another parameter to the request, but this one you
can calculate: you just do it wherever you work out the size of the
request. If data_len is the true data length and
James Bottomley wrote:
On Fri, 2008-02-01 at 15:02 -0500, Jeff Garzik wrote:
James Bottomley wrote:
Could we please get this in ... I thought I mentioned several times that
it fixes a fatal oops in both aic94xx and ipr.
Tejun has a persistent objection... see other email.
Actually, see
On Sun, 2008-02-03 at 12:04 +0900, Tejun Heo wrote:
James Bottomley wrote:
On Fri, 2008-02-01 at 15:02 -0500, Jeff Garzik wrote:
James Bottomley wrote:
Could we please get this in ... I thought I mentioned several times that
it fixes a fatal oops in both aic94xx and ipr.
Tejun has a
James Bottomley wrote:
I think the best solution is to update block layer draining such that it
can be included together before the merge window closes. I'll dig into it.
Like I said, the block layer pieces are already upstream. All we need
is the ATA bits and I think it should all work
James Bottomley wrote:
Could we please get this in ... I thought I mentioned several times that
it fixes a fatal oops in both aic94xx and ipr.
Tejun has a persistent objection... see other email.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body
21 matches
Mail list logo
