Can you configure your email client to wrap lines after 70 columns or so? Dealing with very long lines is annoying. On Sun, 12 Jul 2009, Sivaram Gowkanapalli wrote: > Hello, > > I am struggling with getting an usb gadget to enumerate and a couple of days ago, I received Greg's advice (by irc) of checking with the USBCV tests before trying out the enumeration on linux. > > Since then: > > 1. I have tried and found that the USBCV tests cannot be used on non-enumerating usb devices. > 2. USBTrace, USBlyzer and Snoopypro do not seem to be working on non-enumerating devices, even though they claim the contrary. Or, maybe they work after the device does something correctly, I guess. > > So, using the windows software tests/sniffers has been a dead-end for me till now. > > Of all the above, the linux hosts' usbmon has been the most promising. > > The usbmon 0u tells me that the device is receiving the get_descriptor_from_device setup control packet and is also receiving some data back from the device, which it considers as corrupt (as evidenced by the below entry in the log, prefixed with '='): > > dc4c7e20 211038484 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > dc4c7e20 211038523 C Ci:1:001:0 0 4 = 03030000 > dc4c7e20 211094486 S Co:1:001:0 s 23 01 0014 0001 0000 0 > dc4c7e20 211094508 C Co:1:001:0 0 0 > =============dc4c7e20 211094564 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < > =============dc4c7e20 211099733 C Ci:1:000:0 -84 8 = 12010002 00000008 > dc4c7e20 211099791 S Co:1:001:0 s 23 03 0004 0001 0000 0 > dc4c7e20 211099803 C Co:1:001:0 0 0 > dc4c7e20 211154482 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > dc4c7e20 211154523 C Ci:1:001:0 0 4 = 03030000 > > The kernel ( CONFIG_USB_DEBUG) enabled identifies the data packet as corrupt due to "babble", as evidenced in the /var/log/debug. (I added the output line prefixed by>>, by updating the uhci 'c' file, to understand what the status code 50000 meant): No, the "babble" occurred later. Your log contains two bad packets; the one shown above is the first and the one shown below is the second. > >>>>>>>>>>>>>>>>>Jul 12 12:38:52 backup-test kernel: [ 983.400706] usb 1-1: uhci_map_status_custom: failed with status 500000 -- TD_CTRL_BABBLE <<<<<<<<<<<<<<<<<< > Jul 12 12:38:52 backup-test kernel: [ 983.400729] usb 1-1: uhci_result_common: failed with status 500000 > Jul 12 12:38:52 backup-test kernel: [ 983.400769] [dfc4d420] CTL QH link (00000001) element (1fe5b090) > > I am attaching both files to this email. > > I built my own logic analyzer to see the data passing on the USB D+ and D- lines and it tells me that my device is sending the correct data through. I believe that it has to be something very simple as sending an extra/defective bit after eop as the "12010002 00000008" is exactly what I wanted to send as the first 8 bytes of the device descriptor. > > Do you have any thoughts/ideas on this, please? > > I have tried everything and I believe that my redemption lies at poking/debugging further on the linux host to figure out why it considers the device as a babbling device.... It seems clear that your device is sending an invalid CRC or packet termination. There's no way to tell exactly what's wrong without seeing the information from the logic analyzer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
