Re: [usb-storage] BUG: SCSI: usb storage SDHC card doesn't work in 2.6.27-rc1

Matthew Frost
2008-08-01T22:22:23Z

--- Matthew Frost <artusemrys@sbcglobal.net> wrote:

> Alan Stern wrote:
> > > The patches to fix this that I have tried do not apply
> > > cleanly to lk 2.6.26 (and break during compile if forced:
> > > "us->fflags" is not defined).
> > >
> > > Is there a lk 2.6.26 patch available?
> >
> > Sorry about that; my patches are against the USB development tree and
> > I tend to forget to redo them against the vanilla kernel. Below is a
> > patch against 2.6.26. Or you can just edit the original patch and
> > change the occurrences of "fflags" to "flags".
> >
> > Alan Stern
> >
> >
> > Index: 2.6.26/drivers/usb/storage/transport.c
> > ===================================================================
> > --- 2.6.26.orig/drivers/usb/storage/transport.c
> > +++ 2.6.26/drivers/usb/storage/transport.c
> > @@ -1034,8 +1034,21 @@ int usb_stor_Bulk_transport(struct scsi_
> >
> > /* try to compute the actual residue, based on how much data
> > * was really transferred and what the device tells us */
> > - if (residue) {
> > - if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
> > + if (residue && !(us->flags & US_FL_IGNORE_RESIDUE)) {
> > +
> > + /* Heuristically detect devices that generate bogus residues
> > + * by seeing what happens with INQUIRY and READ CAPACITY
> > + * commands.
> > + */
> > + if (bcs->Status == US_BULK_STAT_OK &&
> > + scsi_get_resid(srb) == 0 &&
> > + ((srb->cmnd[0] == INQUIRY &&
> > + transfer_length == 36) ||
> > + (srb->cmnd[0] == READ_CAPACITY &&
> > + transfer_length == 8))) {
> > + us->flags |= US_FL_IGNORE_RESIDUE;
> > +
> > + } else {
> > residue = min(residue, transfer_length);
> > scsi_set_resid(srb, max(scsi_get_resid(srb),
> > (int) residue));
> >
> >
>
> Thanks! I've been trying to fix it manually, and it wouldn't work. Trying
> this version now. Let's see if this fixes my problem.
>
> Matt Frost
>

Tested under two distributions, this patch restores correct functionality to
my hardware. Thank you very much!

Matt