It would be good to try it with the fiq_split branch of the kernel, that has much better scheduling to stop split transactions from going wrong? In this situation what happens is a split transaction fails (the device you are using is full speed and therefore uses split transactions) and the transaction will get lost in the hub. Gordon On 23/06/2013 19:43, "Greg KH" <greg@xxxxxxxxx> wrote: >On Sun, Jun 23, 2013 at 01:13:34PM -0500, Daniel Santos wrote: >> So I'm working on this MCP2210 driver which talks in 64-byte >> request/response pairs using interrupt URBs (it can be used with >> hid-generic, but I don't want to do that). I'm testing on a >> Raspberry Pi Model B using the Raspbian 3.9.7 kernel. > >My deepest sympathies, the USB host controller driver on the Raspberry >Pi is a huge shop of horrors, it's amazing that it works at all, and >when it does, it eats huge amounts of CPU for no known good reason. > >Good luck with it, and be happy that it's working for you in the first >place :) > >Anyway... > >> My usual order >> of things is: >> >> I submit an out URB (to rx my response) >> I submit an in URB (with my request) >> My in URB completion handler is called >> My out URB completion handler is called. >> >> But occasionally (more so when my system is heavily loaded, spamming >> printks & such), the out URB completion handler is called first. I >> initially thought this was due to the device chattering or some >> electrical noise as I have all of this open with wires in >> bread-boards & such, but then I dumped the contents of the out URB >> and discovered that it was a valid response for the given request. >> So the transaction must have completed normally & correctly, but my >> completion handlers weren't called in the same order as the actual >> communications occurred. >> >> I'm (obviously) new to device drivers, but I wasn't able to find any >> information saying that this is normal. Is it? > >Yes it is, there is no guarantee in which order an urb callback happens, >as the hardware itself can answer them in different order (the hardware >in the client device, not the host.) > >> Also, again usually when I have debug enabled, it is common for me >> to have a stalled out URB (that I detect with a manager thread >> running in a delayed work queue) that I have to kill and re-submit. >> This almost always stalls as well, so I have to re-submit the in URB >> (request) as well. I'm not sure of the cause of that either, but it >> causes me to think that some of my responses are being dropped on >> the floor, which wont allow me to build a reliable device since >> double-sending some requests will cause undesired results. > >That's probably due to the crappy USB host driver on the rpi. Try it on >a "normal" machine and see what happens there. > >thanks, > >greg k-h -- 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
