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 20Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
USBLog1.usblog
Description: Binary data
Description: S/MIME Cryptographic Signature
