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?
--
Jim Ramsay
"Me fail English? That's unpossible!"
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
