severe HID problem
in [Device Drivers]
|
Prev: NDIS6 NBL indication
Next: DTM and Vista x64 (v.6000)
From: Robert Marquardt on 5 Jan 2007 00:07 Ray Trent wrote: > Sounds like a host controller bug/limitation. Wouldn't be the first one > by any means. How fast are you sending those blobs of 8 packets? It is a low-speed HID device with clean and simple descriptor. It tells the normal 10 ms polling time. The data also goes over the bus. > Does it make a difference whether the machine has an OHCI or UHCI USB > controller? Definitely not. We verified under Win98 with an UHCI chipset controller and an OHCI PCI card. The bug also shows up under Linux. We will test with Macs next week.
From: Doron Holan [MS] on 5 Jan 2007 00:22 that is posting one async read on the handle at any given time. what if you posted 10 async reads simultaneously and the reposted them in the apc completion routine ? or better yet, have you try a completion port and tried to repost the reads from it? d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. "Robert Marquardt" <marquardt(a)codemercs.com> wrote in message news:eFE3Cq9LHHA.3588(a)TK2MSFTNGP06.phx.gbl... > Doron Holan [MS] wrote: >> it is definitely not HID dll. are you posting multiple reads using >> overlapped i/o on the same handle or just one transfter at a time? > > I have two implementations in C and Delphi. > > This is the Delphi read loop in the thread: > > if Device.ReadFileEx(Report[0], Device.Caps.InputReportByteLength, > @DummyReadCompletion) then > begin > // wait for read to complete > repeat > SleepRet := SleepEx(Device.ThreadSleepTime, True); > until Terminated or (SleepRet = WAIT_IO_COMPLETION); > > The C implementation is similar. > Running the C and Delphi programs in parallel on the same device shows the > same loss of reports so the data is lost in the HID.DLL or the HID drivers > (it is a generic HID device). > I also tested with a file handle not opened for overlapped IO and using > simple ReadFile calls in a loop. There is no difference. > All implementations lose reports. The loss is random. On some computers > between 1 in 50 and 1 in 100 on others much less. Unfortunately the test > computer for the device was the one losing almost no reports. > > On our current test setup the reports are sent in sequences of either 8 or > 64 reports on a button press on the device. The device is low speed. There > seems to be no difference in probability of loss if sending reports by > pressing the button for 8 reports repeatedly or 64 reports at once. > > It cannot be a device bug, because the correct amount of reports are sent > over the bus (verified with a hardware tracker).
From: Robert Marquardt on 5 Jan 2007 03:15 Doron Holan [MS] wrote: > that is posting one async read on the handle at any given time. what if you > posted 10 async reads simultaneously and the reposted them in the apc > completion routine ? or better yet, have you try a completion port and > tried to repost the reads from it? I very much doubt that it helps. After all the HID drivers buffer reports on their own. 128 for NumInputReports does not help at all.
From: Ray Trent on 8 Jan 2007 17:04 > Definitely not. We verified under Win98 with an UHCI chipset controller > and an OHCI PCI card. The bug also shows up under Linux. We will test Right... you said that... sorry. Anyway, with Linux, of course, you're lucky enough to have the source for the USB/HID driver stacks available in compilable form... it might be interesting to stick in some debug logic at various levels to see where the packet is getting lost. In spite of your testing with multiple HCs, I'm still suspicious that it's not even getting past the host controller based on your tests. Now why that might be is another question... though I've seen some pretty egregious behaviors (some of them really subtle to notice) on the part of cheap USB serial engines. Is the USB interface on your device an off-the-shelf one and if so, from whom? -- Ray
From: Robert Marquardt on 8 Jan 2007 23:57
Ray Trent wrote: > Anyway, with Linux, of course, you're lucky enough to have the source > for the USB/HID driver stacks available in compilable form... it might > be interesting to stick in some debug logic at various levels to see > where the packet is getting lost. We will first test on Macintosh and on newest SuSE Linux. > In spite of your testing with multiple HCs, I'm still suspicious that > it's not even getting past the host controller based on your tests. Now > why that might be is another question... though I've seen some pretty > egregious behaviors (some of them really subtle to notice) on the part > of cheap USB serial engines. Is the USB interface on your device an > off-the-shelf one and if so, from whom? It is a Cypress chip and we use it for other devices without problems. The firmware has been firmly debugged. |