On Thu, Sep 08, 2005 at 02:28:09PM -0600, Jim Ramsay wrote: > On 9/8/05, Jim Ramsay <jim.ramsay@xxxxxxxxx> wrote: > > On 9/8/05, Matthew Dharm <mdharm-kernel@xxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > > > > I think I have found a possible bug: > > > > [...] > > > > I suppose the scsi code could be changed to guarantee that > > > > srb->request_buffer is page-aligned or cache-aligned, but that seems > > > > like the wrong solution for this bug. > > > > > > Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer is > > > supposed to guarantee us that those buffers are suitable for DMA'ing, and > > > apparently it's violating that promise. > > > > Thanks, I'll check on what buffer I'm actually getting, where it's > > allocated, and post back what I find, or how I fixed it. > > More information: > > The error only occurrs during device sensing when the > srb->request_buffer is assigned as follows, by usb/storage/transport.c > in the routine usb_stor_invoke_transport: > > old_request_buffer = srb->request_buffer; > srb->request_buffer = srb->sense_buffer; > > Now, this is a problem because srb->sense_buffer is defined as follows > in the struct scsi_cmnd: > > #define SCSI_SENSE_BUFFERSIZE 96 > unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE]; > > Since it is not allocated at runtime there is NO WAY the SCSI layer > can possibly guarantee it is page- or cache-aligned and ready for DMA. > > Any suggestions on best fix for this? Is it still a SCSI-layer issue? > Or should USB step up in this case and ensure this buffer is dma-safe > itself? Ah, that buffer doesn't come from SCSI (tho I've long thought they should provide us with a sense data buffer). So this is a real usb-storage bug. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999
Attachment:
pgplBisygt0x5.pgp
Description: PGP signature
