>> Hello, >> >> First I found that this message was missing in user space. Then I did the following: >> >> - first I traced the packets within the user space and I found that a packet is missing from my drivers read mthod, >> - then I put debug messages into my kernel driver and I found that an input packet is missing from usb_bulk_msg(), >> - then I put debug messages into usb_api_blocking_completion() and I found that a input packet is missing, >> - then I started to use usbmon and I found that usbmon misses a packet exactly where I am missing it too, >> - then I plugged a PCI USB host controller card into this PC and this did not happen any more when I used it´s ports to plug in my device. >> >> Therefore I believe to know that this packet is dropped somwhere below my device driver code. > >Okay, that sounds right. In fact, since everything worked correctly >with a new PCI USB host controller card, it seems likely that the >packet gets dropped by your motherboard's host controller hardware. > >Have you tried testing the device on other computers? Can you find any >reason to think the host controller driver is at fault rather than the >host controller hardware? > >Alan Stern I tested the device driver at two other PCs (a single and a quad CPU Intel processor) with three different kernels (i.e. distributions SuSE SLES 9, openSuSE 11.0, openSuSE 11.1) and it worked just fine. At the System which shows the problem we first used libusb 0.1.12 to communicate with the device, and the problem did not show up there. Then we began to develop our own device driver for some reason. Maybe the problem was not triggered with libusb, because with the kernel device driver the data throughput is now three times faster. I don't know if it gets lost by hardware or software. Guenter Gebhardt -- 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
