On Mon, 9 Oct 2006, Daniel Stenberg wrote:

> Hi USB hackers!
> 
> I'm a newbie in EHCI hacking land (and not very good at USB internals in 
> general), but I'm working with a Linux port for a MIPS-based microcontroller 
> with a good old NEC uPD720101 USB 2.0 Host Controller connected to a PCI bus 
> on the board. I'm currently running kernel 2.6.17.8, but I would assume that 
> this is somewhat stable things that haven't moved too much lately.
> 
> Anyway, I have a little problem with the USB/EHCI parts so I was hoping that 
> perhaps someone here could offer a little clue or a pointer to where I can 
> get 
> more clues myself.
> 
> 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(). 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.
> 
> 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.
> 
> 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?

The code is waiting for the URB to complete.  This should take much less 
than one second.

> 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.

It indicates that no reply was received from the device.  Most likely 
because of bugs in your controller driver.

> 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!

Read the kerneldoc in include/linux/usb.h and in drivers/usb/core/urb.c
and drivers/usb/core/message.c.  It also wouldn't hurt to look through 
some of the files in Documentation/usb, although a number of them are out 
of date.

Alan Stern


-------------------------------------------------------------------------
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

Reply via email to