Martin Diehl wrote: > > On Thu, 11 Oct 2001, Jean Tourrilhes wrote: > > > The good news is that your code works beautifully on my box > > for usb-ohci and usb-uhci. So, it will go out in the next rev os the > > driver (I also want to try with an XNTD dongle). > > Fine, thanks. Chances are this might be interesting for Greg too, IMHO it > is exactly this part of code which was duplicated for USB ir-serial ;-) > > > The bad news is that it didn't change anything with respect to > > uhci. Same problem, same crash at the same place. > > Ok - lets look for another reason. Rereading your logs makes me thinking, > the real problem is one step earlier: while usb_set_configuration() > succeeds in irda_usb_probe() the following usb_set_interface() apparently > returns EPIPE already. > > Did a short test using the ACT-IR2000U with 2.4.12-vanilla. Testbox is UP > with SMP kernel and has Intel 82371AB rev 01 USB-UHCI controller. > Works for me with _both_ usb-uhci and uhci - no Oops. However, > usb_set_interface() returns -EPIPE for both! But the dongle seems to work > nevertheless. Additionally, usb-uhci logs a status=3 error message from > uhci_interrupt(). >
If there is just one interface and no alternative interface then the USB spec says that a device can stall (-EPIPE) on the usb_set_interface() request. So there seems nothing wrong here. The error code sharing of stall and babble errors (both -EPIPE) is a design error of the URB interface and should be resolved immediately. STALLs are part of the protocol and BABBLE is a real error. > Well, what follows is just speculation, but let's see: > > - uhci-status=3 in interrupt means there was a TD processing error. > - from our former success with finding the USB-IrDA class descriptor > interleaved with the standard descriptors we know, the device appends > it when some standard descriptor was requested. > - if a TD was scheduled to get a single well-known standard descriptor > with known length, the requested transfer length was probably shorter > than what was returned by the device with the class descriptor appended. > - This would be detected as a BABBLE error by UHCI controller and the EP > gets stalled. (Same with DATAOVERRUN condition for OHCI, btw.) Do you really get a BABBLE error or just a STALL. I would guess it is a STALL first. - Roman > - IIRC there was an issue with VIA handling of BABBLE. Probably usb-uhci > has some fix to work around this. > - The rest of what you see is just a consequence of this, probably with > some racy help from SMP... > > What remains unclear to me is why this would happen at > usb_set_interface() - I don't see any descriptor reading at this point. > Seems to deserve some harder debugging. > > Comments? > > Martin > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
