On Mon, 11 May 2009, Dwayne Fontenot <dwayne.fontenot@xxxxxxx> wrote: > > > I appreciate any input on how to proceed with debugging this issue. > > > > Is it always the same 24? That is, if you run your test twice in a > > row, do you receive messages back from the same 24 devices each time? > > I ran the test five times and the same 24 devices came back each time. > > > Is there any relation between the missing responses and the order in > > which your program submits its interrupt URBs? > > The 24 devices which come back are the first 24 interrupt URBs which are submitted. Have you tested this by changing the order in which the URBs are submitted? > > Does it make any difference if you never have more than a single > > interrupt URB pending at any time (i.e., testing the devices one by > > one)? > > I'm not sure about this one; we wrote a USB driver to talk to the RUs and it submits > an interrupt URB for each device in the probe() function. > The driver re-submits the interrupt URB for each device in the interrupt message callback > function. So take the resubmission out of the completion routine and see what happens. > So far none of the interrupt USB submissions (including those after the first 24 on probe) > are returning errors. All of this suggests that there's something wrong with the way the NEC host controller iterates through the periodic list. In other words, a hardware problem. Alan Stern -- 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
