lkml.org 
[lkml]   [2008]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Scatter-gather list constraints
On Thu, 26 Jun 2008, Jens Axboe wrote:

> On Thu, Jun 26 2008, Alan Stern wrote:
> > On Thu, 26 Jun 2008, Jens Axboe wrote:
> >
> > > Alan, in what specific cases have you observed IO requests that violate
> > > the rules you gave? The example of:
> > >
> > > "For example, suppose an I/O request starts out with two S-G elements of
> > > 1536 bytes and 2048 bytes respectively, and the DMA requirement is"
> > >
> > > really sounds concocted, have you ever seen something like that?
> >
> > It really was observed, though not by me. Here's the email message in
> > which it was reported (for some reason this doesn't seem to have made
> > it into the list archives):
> >
> > > From antonio.lin@alcormicro.com Thu Jun 26 11:05:30 2008
> > > Date: Wed, 11 Jun 2008 20:51:52 +0800
> > > From: AntonioLin <antonio.lin@alcormicro.com>
> > > To: Alan Stern <stern@rowland.harvard.edu>
> > > Cc: David Vrabel <david.vrabel@csr.com>, linux-usb@vger.kernel.org
> > > Subject: Re: [S] Re: [linux-uwb] packet size problem
> > >
> > > Hi All,
> > >
> > > I checked srb->device->request_queue->dma_alignment in usb_stor_bulk_Bulk_transport() routine. , the value is 1023.
> > >
> > > But in usb_stor_bulk_transfer_sglist, the length of first element in sg array is 3584 which is not divisible by 1024.
> > >
> > >
> > > Can you post your /proc/bus/usb/devices ?
> > >
> > > I don't know how to do this, could you descript moe about it ?
> > > (Sorry,I have few experience about Linux.)
> > >
> > > Thanks.
> > >
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320234] usb-storage: *** thread sleeping.
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320271] usb-storage: queuecommand called
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320288] usb-storage: *** thread awakened.
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320294] usb-storage: Command READ_10 (10 bytes)
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320297] usb-storage: 28 00 00 00 a8 91 00 00 1f 00
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320316] usb_stor_Bulk_transport:dma_alignment:1023
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320322] usb-storage: Bulk Command S 0x43425355 T 0x2f L 15872 F 128 Trg 0 LUN 0 CL 10
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320327] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320333] hwahc_op_urb_enqueue
> > > Jun 11 16:43:14 localhost kernel: [ 1959.320340] xfer d3202dc0 urb d30e6780 pipe 0xc0008200 [31 bytes] dma outbound inline
> > > Jun 11 16:43:14 localhost kernel: [ 1956.597834] giveback d3202dc0 0
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323583] usb-storage: Status code 0; transferred 31/31
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323588] usb-storage: -- transfer complete
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323593] usb-storage: Bulk command transfer result=0
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323598] usb-storage: usb_stor_bulk_transfer_sglist: xfer 15872 bytes, 4 entries
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323611] hwahc_op_urb_enqueue
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323618] xfer d3202000 urb d30e6c00 pipe 0xc0008280 [3584 bytes] dma inbound deferred
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323633] hwahc_op_urb_enqueue
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323640] xfer d32020c0 urb d30e6180 pipe 0xc0008280 [4096 bytes] dma inbound deferred
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323647] hwahc_op_urb_enqueue
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323652] xfer d3202780 urb d30e6900 pipe 0xc0008280 [4096 bytes] dma inbound deferred
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323659] hwahc_op_urb_enqueue
> > > Jun 11 16:43:14 localhost kernel: [ 1959.323665] xfer d3202800 urb d30e6100 pipe 0xc0008280 [4096 bytes] dma inbound deferred
> > > Jun 11 16:43:14 localhost kernel: [ 1956.607877] hwa-hc 1-4:1.1: DTI: xfer d3202000#0 failed (0x87)
> > > Jun 11 16:43:14 localhost kernel: [ 1956.607877] giveback d3202000 -84
> >
> > As you can see, the S-G element lengths for this I/O request were 3584,
> > 4096, 4096, 4096, totalling 15872 bytes. I don't know what workload
> > caused this request to be generated; maybe Antonio can tell us.
>
> OK, I can see that happening for fs IO if the block alignment odd. The
> 1kb block size would definitely fix that, but cause SCSI to treat you as
> such and cause problems as well. Alright, I'll write something up for
> you to bounce such a request.

Any progress?

Alan Stern



\
 
 \ /
  Last update: 2008-08-27 23:35    [W:0.100 / U:3.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site