On Fri, 28 Nov 2003, Andrew Heaton wrote: > I am trying to get a Freecom USB stick (0c76:0005) working with > an embedded linux build based on 2.4.22. > > I'm having problems getting it working, so I put in some > diagnostic code in my drivers submit_urb function to show the > urb->setup_packet data being sent. > > When I insert the stick for the first time, I see a strange > setup_packet going out (or attempting to go out - my USB chip > sees it as an error and refuses to send it). > > The data is below. flags=urb->transfer_flags, > length=urb->transfer_buffer_length, length2=urb->actual_length, > packets=urb->number_of_packets, interval=urb->interval > > Incidentally, if I unplug the stick and plug it back in I don't > get this odd setup_packet. I can do exactly the same with a USB > CDROM, with the same behaviour. If I plug in the stick, unplug > it, then plug in the CDROM I get another of these packets - so > it appears it is only sent on the first plugging in of a > particular device. > > Any ideas about what this is and why it's being sent? I don't > think it's doing any harm, but it's a bit confusing. > > Andrew > > > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 01 10 00 01 00 00 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 03 04 00 01 00 00 00 > hci_submit_urb: flags 0 length 4 length2 0 packets 0 interval 0 > data A3 00 00 00 01 00 04 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 23 01 14 00 01 00 00 00
I don't recognize these peculiar commands. They are vendor- or class-specific. They aren't generated by the standard USB stack; you must have some customized driver loaded. Even more strange, they appear _before_ the device address has been set. Is it possible that they were meant for a different device, not the Freecom unit? > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 00 05 02 00 00 00 00 00 > hci_submit_urb: flags 0 length 8 length2 0 packets 0 interval 0 > data 80 06 00 01 00 00 08 00 > hci_submit_urb: flags 0 length 18 length2 0 packets 0 interval 0 > data 80 06 00 01 00 00 12 00 > hci_submit_urb: flags 0 length 8 length2 0 packets 0 interval 0 > data 80 06 00 02 00 00 08 00 > hci_submit_urb: flags 0 length 39 length2 0 packets 0 interval 0 > data 80 06 00 02 00 00 27 00 > hci_submit_urb: flags 0 length 0 length2 0 packets 0 interval 0 > data 00 09 01 00 00 00 00 00 These commands are standard set-address, get-device-descriptor, get-configuration-descriptor, and set-configuration commands. They do come from the USB stack. Normally they would be the first commands sent to a newly-connected device. > hci_submit_urb: flags 0 length 1 length2 0 packets 0 interval 0 > data A1 FE 00 00 00 00 01 00 Another peculiar non-standard command. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
