> On Mon, 11 May 2009, Dwayne Fontenot 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 I will try your above suggestions tomorrow, however I wanted to update now with a bit of new information: If I self test a single RU which is *not* one of the first 24 to have an interrupt URB submitted, I never receive an interrupt message response from it. It's as if the interrupt URB submissions after the first 24 are "lost" yet no error is returned from the usb_submit_urb() call. I should also mention that for any specific kernel version / configuration / arch the number of returned interrupt messages remains constant, but with different kernel versions / configurations (I have tested back to 2.6.23 on the 32-bit PPC embedded platform which brought this problem to light) the number of returned interrupt messages can vary; I have seen 24, 25 and 26. Dwayne Fontenot -- 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
