On Monday 09 October 2006 4:44 am, Daniel Stenberg wrote: > The problem I have is that when I insert my USB cable from my usb-storage > device into my Linux board, I get a few USB IRQs fine and the USB layer > detects the presence of a new device and all and sets it up like: > > usb 1-1: new high speed USB device using ehci_hcd and address 2 > > After a short while it fails and I get this back: > > usb 1-1: device descriptor read/64, error -145 > > The timeout (-145) is the one in > drivers/usb/core/message.c:usb_start_wait_urb().
I'm pretty well convinced there's a bug somewhere in the USB stack, and likely in usbcore, which is causing those device descriptor read errors. We didn't get them in early 2.6 releases (e.g. 2.6.5 ISTR was OK), now there are systems which report them pretty commonly. There might also be HCD bugs ... but, from my foggy memories of those long-ago days, the system changes that could have welcomed in such usb stack bugs didn't include HCD changes. > If I follow that function > (usb_submit_urb) it goes on to hcd_submit_urb() and here's my question coming > up: > > In hcd_submit_urb() it sets up urb->setup_dma and urb->transfer_dma, and it > calls ehci_urb_enqueue() and then submit_async() ... > > But usb_start_wait_urb() in usb/core/message.c times out after 1000 ms, so > that timeout_kill() is called and usb_unlink_urb() etc. Yep. > Does anyone have any interesting clue to offer to what functionality that is > missing here? I can see it it using usb_internal_control_msg() a couple of > times just fine before it reaches this point where it fails, but the failing > point is the first usage of the urb->*_dma stuff. For the PCI based HCDs (like EHCI), every URB uses DMA. So I'm not clear how you could say this is the "first usage" ... do you mean it's the first URB with an IN-DATA stage? > When the timeout occurs, are "we" waiting for an USB IRQ at that point? > Anyone > feel familiar with the problem and might have an idea what the problem is? Clues would be useful. This is with EHCI, so you could presumably turn on debugging and call dbg_qh() for the QH being canceled, and dbg_qtd() for each of its QTDs. On the theory that the issue is timing-related, some msleep() calls between control transfers might be informative too. > Since this is my own Linux port still, there might be HW-init etc related > problems and everything, but I feel that I don't quite understand what error > this is indicating so I'm a bit in the dark right now. > > I'll be grateful for whatever hint, advice, pointer or similar I get. If you > think these are things I should already know about, please enlighten me where > a good place to pick this knowledge up would be! We've seen this class of error with ISTR at least EHCI and UHCI. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
