----- Original Message ----- *From:* Hans de Goede <j.w.r.degoede@xxxxxx> *To:* USB Storage list <usb-storage@xxxxxxxxxxxxxxxxxxxxxxxx> *CC:* fedora-kernel-list@xxxxxxxxxx, USB development list <linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx>, David Brown <usb-storage2@xxxxxxxxxx>, Guillaume Bedot <littletux@xxxxxxxx>, linux-scsi@xxxxxxxxxxxxxxx, linux-usb@xxxxxxxxxxxxxxx *Sent:* Wed, Jan 09 2008 at 23:44 +0200 *Subject:* Linux scsi / usb-mass-storage and HP printer cardreader bug + fix > Hi All, > > First of all sorry for the somewhat massive cross-posting, I've spend a > significant amount of time hunting down this bug, and so far the response has > been less the overwhelming. > > The problem is with the HP PSC 1350 (my printer and confirmed by 2 others) and > atleast also the HP PSC 1610 (confirmed by Guillaume Bedot, in the CC). > > The cardreader of the multi function printers will "crash" and from that moment > on no longer communicate in any sane way, if you try to read the last sector of > an sdcard* in a read that is more then 1 sector, so trying to read 8 sectors > starting at sector capicity-8 will crash it, as will reading 2 sectors starting > at sector capicity-2, however reading the last sector in a one 1 sector read > will succeed! (* xdcards seem to be fine). > > I haven't tried if it will crash on larger then 1 sector writes which include > the last sector too, I immediately added code to not do that in both the read > and write paths. I have tested reading and writing the end of the disk with > this kludge in and it works. > > I currently have a somewhat ugly proof of concept patch for this, which adds > another type of usb-massstorage quirk. When this quirk flag is set, the > usb-massstorage driver modifies READ_10 and WRITE_10 commands of more then 1 > sector which includes the last sector to become one sector less. I've been told > by scsi subsystem developers that doing a shorter read / write then requested > is not a problem, the scsi subsystem is designed to handle getting less then it > asked for and will send a seperate request for the last sector. > > I and 3 others (2 on a PSC 1350 too, one on a PSC1610) have tested this patch > with success. I'm not asking for this patch to be included to the kernel as is, > I'm asking for the now known workaround for this to be added to the kernel in > someway! > > Perhaps its an idea to add the posibility to have a scsi command filter > function / callback to the scsi or usb-massstorage subsystem, and then add a > mechanism to set this filter depending on usb id's and if added to the scsi > layer, a mechanism to set it based on scsi device and manufacturer > identification strings. Such a mechanism might be usefull in the future to work > around other broken hardware too, and has the added advantage of not having > todo much changes to the normal code path, keep that readable. > > I'm willing to come up with a patch for such a filter mechanism, provided I get > some pointers where this is best added. > > Thanks & Regards, > > Hans > > > p.s. > > I've also included the fedora-kernel list in the addressee's because I was > hoping that maybe someone can take one of these printers to the kernel hackfest > in the weekend's fudcon and take a look at this. > > + if ((offset + num) == sdkp->capacity && num > 1) { > + if (srb->cmnd[8] == 0) > + srb->cmnd[7]--; > + srb->cmnd[8]--; > + srb->request_bufflen -= 512; > + srb->underflow -= 512; > + } > This will no longer compile on top of latest scsi-misc, and LLDs are not suppose to modify request_bufflen anymore. I'm not sure what the proper solution should be? Boaz _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list