On Sun, 5 Feb 2006 [EMAIL PROTECTED] wrote: > >You have two options. One is just always to set the max_sectors value > >whenever the drive is attached (could be automated by writing a hotplug > >script). > > Well, this works as a workaround for me. But unusual_devs.h implies that > we do like to support even broken devices 'out of the box'... > For example, we could have an extra unusual_devs flag (US_FL_SMALL_XFERS?) > (which would allow you to move the Genesys special casing into > unusual_devs as well). Would imply picking a value of 'small' small enough > to satisfy all devices broken like this, though.
We certainly could do that. Right now it looks like 32 KB is sufficiently small to work with all devices that need it. I doubt we'll find a device that needs anything smaller, and while some devices might be able to get away with 64 KB, the overhead is using a smaller limit isn't all that worrisome. > > The other is to create an unusual_devs.h entry with the > >IGNORE_RESIDUE flag. This has the minor disadvantage that the residue > >will be ignored even for transfers less than 32 KB, when it might > >conceivably be of some value. > > This was what I tried first. It works for reading, but not for writing > (because IGNORE_RESIDUE doesn't ignore residues on writing). If you do > hack the source to make it ignore residues on writes then it seems to > work OK but the resulting mp3s skip occasionally, presumably because > we weren't detecting genuinely failed writes any more. In the current driver, IGNORE_RESIDUE affects writes too. I forget when we changed it... some device needed it. Not detecting genuinely failed writes is very bad; I would go a long way to try to avoid it. Do you think you can track down the exact cause of those skips? If allowing transfers larger than 32 KB is going to cause write errors, then automatically setting max_sectors is the thing to do. (BTW, as far as I know, Windows always ignores the residue value completely. That's why so many devices get it wrong -- they never were tested properly and they seemed to work.) Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
