Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline
On Sun, Sep 2, 2012 at 9:49 AM, Pete Batard wrote: > On 2012.08.31 11:13, Xiaofan Chen wrote: >> I have seen some potential issues with USB composite >> device (FT2232H based JTAG debugger) with libusbK or >> libusb0.sys (filter or device driver) when I tested OpenOCD >> 0.6.0-rc2 with libusbx git. I will try to use xusb to replicate >> the issues and post the details. > > Was it with K/0 used in lieu of the composite parent? Or were the > drivers installed against the children devices? Here are the results with the simple "xusb -g". BTW, "xusb -j" does not seem to do much more than "xusb -g". The tests are with Amontec JTAGKey2 under a Windows 7 x64 machine (not using VM). Summary: a) Filter driver + Vendor driver: failed b) Using libusb0.sys or libusbk.sys or winusb.sys to replace the Windows composite parent driver: passed c) Keeping the Windows composite parent driver but using libusb0.sys or libusbk.sys or winusb.sys to replace the vendor driver for both interfaces, failed Detailed results: 1) Using filter driver + FTDI driver, failed, I tried to install the filter driver on top of both interface or on top of the composite parent or both D:\work\libusbx\libusbx\x64\Release\examples>xusb.exe -g 0403:cff8 Using libusbx v1.0.12.10557 Opening device... libusbx: info [cache_config_descriptors] could not access configuration descript or (dummy) for '\\.\USB#VID_0B05&PID_1788#1C4BD6065A96': [31] A device attached to the system is not functioning. libusbx: info [cache_config_descriptors] could not access configuration descript or (dummy) for '\\.\USB#VID_0B05&PID_1788#1C4BD6065A96': [31] A device attached to the system is not functioning. bus: 2, port path from HCD: 4 speed: 480 Mbit/s (USB HighSpeed) Reading device descriptor: length: 18 device class: 0 S/N: 3 VID:PID: 0403:CFF8 bcdDevice: 0700 iMan:iProd:iSer: 1:2:3 nb confs: 1 Reading configuration descriptors: nb interfaces: 2 interface[0]: id = 0 interface[0].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: FF.FF.FF endpoint[0].address: 81 max packet size: 0200 polling interval: 00 endpoint[1].address: 02 max packet size: 0200 polling interval: 00 interface[1]: id = 1 interface[1].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: FF.FF.FF endpoint[0].address: 83 max packet size: 0200 polling interval: 00 endpoint[1].address: 04 max packet size: 0200 polling interval: 00 Claiming interface 0... Failed. Claiming interface 1... Failed. Reading string descriptors: libusbx: error [composite_submit_control_transfer] no libusbx supported interfac es to complete request libusbx: error [composite_submit_control_transfer] no libusbx supported interfac es to complete request libusbx: error [composite_submit_control_transfer] no libusbx supported interfac es to complete request libusbx: error [composite_submit_control_transfer] no libusbx supported interfac es to complete request Releasing interface 0... Releasing interface 1... Closing device... 2) To use WinUSB driver to replace the composite parent, okay D:\work\libusbx\libusbx\x64\Release\examples>xusb.exe -g 0403:cff8 Using libusbx v1.0.12.10557 Opening device... bus: 2, port path from HCD: 4 speed: 480 Mbit/s (USB HighSpeed) Reading device descriptor: length: 18 device class: 0 S/N: 3 VID:PID: 0403:CFF8 bcdDevice: 0700 iMan:iProd:iSer: 1:2:3 nb confs: 1 Reading configuration descriptors: nb interfaces: 2 interface[0]: id = 0 interface[0].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: FF.FF.FF endpoint[0].address: 81 max packet size: 0200 polling interval: 00 endpoint[1].address: 02 max packet size: 0200 polling interval: 00 interface[1]: id = 1 interface[1].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: FF.FF.FF endpoint[0].address: 83 max packet size: 0200 polling interval: 00 endpoint[1].address: 04 max packet size: 0200 polling interval: 00 Claiming interface 0... Claiming interface 1... Reading string descriptors: String (0x01): "Amontec" String (0x02): "Amontec JTAGkey-2" String (0x03): "53T9XDR4" Releasing interface 0... Releasing interface 1... Closing device... 3) To use WinUSB driver for interface 0 (A) only, it will fail as expected since WinUSB needs to claim both interface. But then when I use WInUSB driver for both interface 0 and 1, it still fails, this is a bit strange. D:\work\libusbx\libusbx\x64\Release\examples>xusb.exe -g 0403:cff8 Using libusbx v1.0.12.10557 Opening device... bus: 2, port path from HCD: 4 speed: 480 Mbit/s (USB HighSpeed) Reading device descriptor:
Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline
Many thanks for the tests. It looks like composite is broken alright, and has been since 10540 [1]. There's some breakage in set_composite_interface(), where the change introduced in 10540 means we're only getting one interface populated, and I'm also seeing file handles not being initialized on open, resulting in autoclaim later failing to access the interfaces. I'll be fixing that. Regards, /Pete -- 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
Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline
[1] https://github.com/libusbx/libusbx/commit/e82c677b5f10a966c89f6b58caa1ae4341260527 -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
Hi, On 09/02/2012 03:47 AM, Pete Batard wrote: >> On 2012.08.31 20:40, Hans de Goede wrote: >>> This assumes that the winusb flag causes the ep to halt when the short >>> read is encountered > > Couldn't see much in NetMon, but it looks like even after WinUSB returns > a short read error, and if I let xusb sleep for a while, I can still > query more data. Thus I don't see much stalling of the ep. > > The msdn doc, which simply states that "Disabling ALLOW_PARTIAL_READS > causes the read requests to fail whenever the device returns more data", > would also seem to indicate that all !ALLOW_PARTIAL_READS does is get > WinUSB to return a non fatal errorcode. Then as said that is a pretty useless feature, since apps can already find out as much by comparing the amount actually read versus the amount they requested... Regards, Hans -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
On Sun, Sep 2, 2012 at 7:15 AM, Hans de Goede wrote: > Hi, > > On 09/02/2012 03:47 AM, Pete Batard wrote: > >> On 2012.08.31 20:40, Hans de Goede wrote: > >>> This assumes that the winusb flag causes the ep to halt when the short > >>> read is encountered > > > > Couldn't see much in NetMon, but it looks like even after WinUSB returns > > a short read error, and if I let xusb sleep for a while, I can still > > query more data. Thus I don't see much stalling of the ep. > > > > The msdn doc, which simply states that "Disabling ALLOW_PARTIAL_READS > > causes the read requests to fail whenever the device returns more data", > > would also seem to indicate that all !ALLOW_PARTIAL_READS does is get > > WinUSB to return a non fatal errorcode. > > Then as said that is a pretty useless feature, since apps can already > find out as much by comparing the amount actually read versus the amount > they requested... > Not quite. Without allow partial reads, if your buffer length isn't a multiple of the maximum packet size for the endpoint and the device returns more than your buffer length, you can lose data. With allow partial reads, if less than your buffer length is returned by the device, the excess data is buffered by WinUSB or discarded, depending on the AUTO_FLUSH setting. See: http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx Orin. -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
On Sun, 2 Sep 2012, Orin Eman wrote: > > Then as said that is a pretty useless feature, since apps can already > > find out as much by comparing the amount actually read versus the amount > > they requested... > > > > > Not quite. Without allow partial reads, if your buffer length isn't a > multiple of the maximum packet size for the endpoint and the device returns > more than your buffer length, you can lose data. With allow partial reads, > if less than your buffer length is returned by the device, the excess data > is buffered by WinUSB or discarded, depending on the AUTO_FLUSH setting. > > See: > http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx The description implies that ALLOW_PARTIAL_READS and AUTO_FLUSH are higher-level options meant to make life easier for driver authors. RAW_IO is closer to what libusb wants, but it's not an exact match: It requires the transfer size to be a multiple of the maxpacket value and it has a limitation on transfer size. Do you know what a typical value for MAXIMUM_TRANSFER_SIZE is? Interestingly, ALLOW_PARTIAL_READS has nothing to do with short packets, as Hans assumed. Instead, it means the WinUSB will allow the driver to read less data than the device sends, without generating a Babble error. Alan Stern -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
On Sun, Sep 2, 2012 at 2:15 PM, Alan Stern wrote: > On Sun, 2 Sep 2012, Orin Eman wrote: > > > > Then as said that is a pretty useless feature, since apps can already > > > find out as much by comparing the amount actually read versus the > amount > > > they requested... > > > > > > > > > Not quite. Without allow partial reads, if your buffer length isn't a > > multiple of the maximum packet size for the endpoint and the device > returns > > more than your buffer length, you can lose data. With allow partial > reads, > > if less than your buffer length is returned by the device, the excess > data > > is buffered by WinUSB or discarded, depending on the AUTO_FLUSH setting. > > > > See: > > > http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx > > The description implies that ALLOW_PARTIAL_READS and AUTO_FLUSH are > higher-level options meant to make life easier for driver authors. > RAW_IO is closer to what libusb wants, but it's not an exact match: It > requires the transfer size to be a multiple of the maxpacket value and > it has a limitation on transfer size. Do you know what a typical value > for MAXIMUM_TRANSFER_SIZE is? > I don't, but comments on the OSR ntdev forum indicate in the order of MB for high speed devices, hundreds of KB for low and full speed devices and 4KB for control endpoints (any speed). Next time I'm working with our USB device, I'll put the relevant call in and find out. I use 32KB buffers, so the point is moot for me. Orin. -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
On Mon, Sep 3, 2012 at 5:15 AM, Alan Stern wrote: > On Sun, 2 Sep 2012, Orin Eman wrote: > >> Not quite. Without allow partial reads, if your buffer length isn't a >> multiple of the maximum packet size for the endpoint and the device returns >> more than your buffer length, you can lose data. With allow partial reads, >> if less than your buffer length is returned by the device, the excess data >> is buffered by WinUSB or discarded, depending on the AUTO_FLUSH setting. That seems to be in line with what Travis does in libusbK with regard to the understanding of the ALLOW_PARTIAL_READS flag. But the wording of the following MSDN article seems to be different. Rather it seems to have nothing to do with max packet size as pointed out by Pete and Alan. >> See: >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx > > The description implies that ALLOW_PARTIAL_READS and AUTO_FLUSH are > higher-level options meant to make life easier for driver authors. > RAW_IO is closer to what libusb wants, but it's not an exact match: It > requires the transfer size to be a multiple of the maxpacket value and > it has a limitation on transfer size. Do you know what a typical value > for MAXIMUM_TRANSFER_SIZE is? Not specific to WinUSB, but different Windows version have different value for different types of transfer. Ref: http://msdn.microsoft.com/en-us/library/windows/hardware/ff538112(v=vs.85).aspx Other drivers may have different limit. Eg: http://support.microsoft.com/kb/2581464 > Interestingly, ALLOW_PARTIAL_READS has nothing to do with short > packets, as Hans assumed. Instead, it means the WinUSB will allow the > driver to read less data than the device sends, without generating a > Babble error. -- Xiaofan -- 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
Re: [Libusbx-devel] RFC: libusbx OS specific API calls
On Sun, 2 Sep 2012, Orin Eman wrote: > > it has a limitation on transfer size. Do you know what a typical value > > for MAXIMUM_TRANSFER_SIZE is? > > > > > I don't, but comments on the OSR ntdev forum indicate in the order of MB > for high speed devices, hundreds of KB for low and full speed devices and > 4KB for control endpoints (any speed). > > Next time I'm working with our USB device, I'll put the relevant call in > and find out. I use 32KB buffers, so the point is moot for me. Then it would be feasible for WinUSB backend to break a transfer down to maximum-sized pieces and submit them one at a time. The overhead of waiting for each piece to complete before submitting the next one wouldn't be so bad. (A bounce buffer would be necessary for the last packet if the transfer length wasn't a multiple of the maxpacket value; that also wouldn't be so bad.) Then the RAW_IO flag could always be used and the other options would be irrelevant. It's kind of a shame that Windows goes to such lengths to provide the illusion of a continuous data stream instead of the packetized stream that USB actually uses -- this just causes more complications in the end. Alan Stern -- 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
