The source of the problem is obviously buggy code inside the device itself, i.e. it subtracts the residual using a 16 bit counter only. This explains nicely why it works with Windows (that just doesn't do
=64k SCSI reads ;-).
Thanks for debugging.
This bad hack "fixes" my problem, but it's not a real solution. It is
Given the typo I'm surprised it still works at all. However I would suspect a better fix would be to limit the device to smaller transfer sizes. You can do that by lowering max_sectors in sysfs or adding an entry in drivers/usb/storage/scsiglue.c:slave_configure() There is already a similar workaround for another device there. That would probably be the right workaround. Given that thre is an easy workaround I don't think we'll take such a patch for 9.2, but if it gets into mainline the next release will likely have it.
--- linux-2.6.8-24.10/drivers/usb/storage/transport.c.orig 2005-01-06 00:52:32.283149967 +0100 +++ linux-2.6.8-24.10/drivers/usb/storage/transport.c 2005-01-06 00:52:58.935858513 +0100 @@ -1055,6 +1055,8 @@
/* try to compute the actual residue, based on how much data * was really transferred and what the device tells us */ + if(residue = 0x10000)
Surely you mean if (residue == 0x10000) ?
+ residue = 0; // fake residue to 0 residue = min(residue, transfer_length); srb->resid = max(srb->resid, (int) residue);
-Andi