On Sat, 29 Jan 2005, Chris Clayton wrote:

> Hi again,
> 
> I didn't attract much attention with my first post :(, so I've been working 
> through the 2.6.10 USB code, following the error messages that get produced 
> when I attach a device (an unpowered hub), to my Armada 7400. I get as far as 
> core/message.c::usb_start_wait_urb(). It seems that after 
> wait_for_completion(), urb->status is set to -ECONNRESET, which is what one 
> would expec after a timeout, given the notes that precede 
> core/urb.c::usb_unlink_urb().
> 
> Hoping that my problems stem from my laptop being old and slow, I 
> (experimentally) amended the value assigned to timer.expires to jiffies + 
> timeout * 5, but still got a timeout failure ("khubd timed out on ep0in"), 
> followed by the message "unable to read config index 0 descriptor/start" from 
> core/config.c::usb_get_configuration().

A timeout like that is more likely to result from the _device_ being old 
and slow than from the _host_ being old and slow.

> Could anyone offer advice as to where I should now start looking. I've built 
> and booted with 2.4.29  and my hub (and other devices) just plain and simple 
> work, so I know it must be possible. Unless of course, there is a hardware 
> bug here that the 2.6 ohci design just can't work around. As I said before, I 
> can attach devices via a cardbus USB2 adapter, but I just hate it when things 
> that should work don't.

You can try using the patch in this message:

http://marc.theaimsgroup.com/?l=linux-usb-users&m=110624648813563&w=2

You can also try using the "old_scheme_first=y" module parameter for
usbcore.  However both of these only affect setting the device address and
reading the device descriptor, things which happen (and apparently
succeeded) before the error you got in reading a configuration descriptor.  
So I doubt they will help, but it's still worth a try.

> I'm willing to do the hard yards, experimenting with various settings, but I 
> really need some advice on where to start.

Your description and logs seem to indicate there's really something going 
wrong with the OHCI hardware/driver combination.  Other people may be able 
to help you there; I don't know much about it.

> By the way, I'm building all the usb stuff as modules, with the intention 
> that 
> after a rebuild I could just unload and reload the modules. But, usbcore is 
> reported as being in use and will not unload. Is there any way to force the 
> loading of a new version of usbcore without rebooting?

Don't try to force anything!  Just eliminate all the users of usbcore
before you try to unload it.  Typical users include other USB modules (all
the other USB drivers have to be unloaded before you can remove usbcore)  
and usbfs (you have to unmount /proc/bus/usb before unloading usbcore).

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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