Bernd, Bernd Walter wrote: >>>What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? it says this: usbd_setup_pipe: dev=0xc3f9d980 iface=0xc3efbaa0 ep=0xc3f192c8 pipe=0xdb936974 ugenwrite: transfer 5 bytes usbd_intr_transfer: start transfer 5 bytes usbd_intr_transfer: transferred 0 usbd_intr_transfer: error=13 (This is with ehci disabled.) > Mmm - looks you are right, but your init data seems to be different. > 0x8001 vs 0x8003 and 0x8007. I think the only difference is that I prepended the 0x80 directly, which the Linux driver fudges in front in send_packet. > Interesting is the calculation of transfer_buffer_length in > send_packet(), which would result in 4 for init1 and 8 for init2. > I interpret this that the last byte from init1 doesn't get written > and your packets don't fit into that sheme. I think they do, see the Windows dump. > The source looks very confusing to me, but maybe that because of my > current localtime()... No, it's not :-) After I reading that driver, I know why I like the BSD sources. > The Windows log could help as it's at least readable and familar. It's attached, in whatever format snoopy (http://sourceforge.net/projects/usbsnoop/) saves it. It shows two writes with this data: TransferBuffer: 0x00000005 (5) length 0000: 80 01 00 20 14 TransferBuffer: 0x00000008 (8) length 0000: 80 01 00 20 14 20 20 20 Lars -- Lars Eggert <larse_at_isi.edu> USC Information Sciences Institute
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC