On 2012.08.28 13:11, Xiaofan Chen wrote: >> Not really. The mass storage test of xusb should work. It's there to >> demonstrate the libusbx capabilities against USB devices that are mass >> storage, and there's no real reason it should fare worse than Windows in >> that respect. > > I mean 'xusb -k" will not work for certain USB flash drive > no matter which driver you use since there are many > non-compliant USB Mass Storage device.
I'm fine with xusb -k consistently failing for all drivers if it's due to non compliance with the USB protocol (though if the Windows mass storage driver can overlook it, I don't see why we shouldn't try to have libusbx do so too). But I'm not OK with xusb -k failing with one driver when the others work, which is the case of interest to us here. But I understand this is also what you state below. > The libusbk.sys case is different. > >> Right now, and just like your tests, I'm pretty much seeing a read >> failure against any mass storage device I try, when using the libusbK >> driver. > > Please refer to previous reply to that one. It seems to me libusbK > is less forgiving about the bulk transfer size. > > Just wondering if you set some non-default pipe policy for > libusbK in the libusbx codes, that might cause the issue > as well. > http://libusbk.sourceforge.net/UsbK3/group__usbk.html#ga10f9e367e4241c431edc2cecd1bb827e https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2629 I think the issue is the interpretation of ALLOW_PARTIAL_READS from WinUSB and libusbK. If you can tolerate the atrocious new SF code browser interface (and for even more fun, try to copy a line!), [2] and the "if (!mRequestContext->Policies.AllowPartialReads)" section seems to indicate that K will reject a read buffer that is smaller than MaximumPacketSize, unless the ALLOW_PARTIAL_READS policy is set. But we disable this policy by default in X, as per [2], hence the issue. I have of course now been able to confirm this, by commenting out the disabling of ALLOW_PARTIAL_READS in libusbx, and verifying that it lets K complete the mass storage test where it previously failed. Now, with regards to where in libusbx or libusbK lies the problem, in xusb, we do call libusb_bulk_transfer() and tell it we expect 36 bytes, which is what K also indicates we receive. And according to what the MSDN has to say on ALLOW_PARTIAL_READS [3], "Disabling ALLOW_PARTIAL_READS causes the read requests to fail whenever the device returns more data (on bulk and interrupt IN endpoints) than the caller requested". Thus, considering that 36 bytes is what K reports, and we're therefore not getting more data than we expect, even with ALLOW_PARTIAL_READS disabled, I think K should let the transfer go through. Especially I don't think the comparison between stageLength and MaximumPacketSize, that K does to decide what it should do with the ALLOW_PARTIAL_READS flag, is what ALLOW_PARTIAL_READS is really about. Still, if needed, I don't see a major problem enabling ALLOW_PARTIAL_READS in 1.0.13 (thought we want to check why we decided to disable it in the first place, as some people may rely on it), but if Travis agrees that the current implementation of ALLOW_PARTIAL_READS might be off in K, I'd prefer a fix in there. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff540304%28v=vs.85%29.aspx [2] https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2661 [3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff540304%28v=vs.85%29.aspx ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
