On Sun, 2 Dec 2001, Georg Acher wrote: > On Sun, Dec 02, 2001 at 07:08:45PM +0100, Mark Burazin wrote: > > > I have a custom driver for a custom USB board wich talks using the interrupt > > transfer. > > The usb-uhci driver doesn't work at all for ages (he sends only one interrupt > > urb, and every next fails). > > In what way does it fail?
Hi Georg, don't know if it's the same, but I'm just investigating an issue with interrupt transfer on usb-uhci too. It's not yet pretty clear to me what's really going on, but the first impression is as follows: - single-shot int-out transfer, submitted in fops->ioctl path of the driver. transfer_size is 64 bytes. - the ioctl blocks (no, not sleep_on) on the completion (i.e. until urb->status becomes != EINPROGRESS). - after it got awoken it issues an usb_unlink_urb call (ASYNC not set) for safety (usb programming guide says so) - ioctl returns - userland application calls this ioctl in tight loop it basically works without error messages - but: I'm printk'ing the content of the transfer-buffer *directly* before submitting the urb and it is always fine (i.e. what was send from userland). On the USB device however (Ez USB-FX) the arriving data is always the same, i.e. the content of the very first urb. This happens only with usb-uhci (2.4.13 - will try 2.4.16 tomorrow). With both uhci(JE) and usb-ohci everything works as expected. Furthermore, if I simply change the transfer type to bulk (directed to the same ep still reported as int-out in the interface descriptor) the otherwise identical code works for usb-uhci as well. Hence I'm really sure it's not a hardware issue or the firmware on the device side. And, FWIW, I'm also doing int-in transfers (8ms interval) which are working without any problem for all 3 hcd's. What I've seen is the urb->status ends up as ECONNABORTED which is not considered a state in which an urb should end - right? At least it is not in the list of error codes. I think it is some kind of temporary status during the 1ms frame period before it gets finally removed from the schedule. However, if I change the code to block while status == (EINPORGRESS || ECONNABORTED) it goes sleeping forever. That's the current state of observation. But before making any assumptions I'd really like to know how this could cause the guy sending old data. In fact there is only this one urb recycled for every transfer so even some staled references would still point to the right buffer by accident. And I don't assume the transfer buffer gets copied so there is no chance ending up sending always the same copy? Well - I just want to give you some early indication as this came up here. I'm gonna try to get more information. Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
