On onsdagen den 16 juli 2003 01.27, David Brownell wrote: > Roger Larsson wrote: > > Removed from linux-kernel... > > > > On tisdagen den 15 juli 2003 20.34, David Brownell wrote: > >>Roger Larsson wrote: > >>>I am not alone then... > >>> > >>>>hub.c: new USB device 00:02.1-3, assigned address 2 > >>>>usb_control/bulk_msg: timeout > >>>>usb-ohci.c: unlink URB timeout > >>>>usb.c: USB device not accepting new address=2 (error=-110) > >>> > >>>This is exactly what I get (2.4.20). But I use quite different hardware. > >>>STPC Atlas (100MHz, for an embedded project) > >> > >>Q: Why doesn't USB work at all? I get "device not accepting address". > >> > >> http://www.linux-usb.org/FAQ.html#ts6 > >> > >>Basically, if your PCI IRQ routing is broken, USB won't work. Likely > >>that FAQ entry could stand updating (ACPI vs APCI etc). There are > >>still significant issues there in 2.6 kernels; and I've hardly ever > >>seen ACPI do anything except break USB. > > > > I do get the interrupts! (If I remember correctly we get two) > > We use TinyBIOS, full control of it - compiled by us. > > And you're sure that it handles its OHCI initialization right?
Guess so. But how can I be sure :-/ > I hadn't thought all the BIOS-level hooks for that were fully > standardized. (Not that I'd have reason to know!) The STPC Atlas has usb-ohci built in, so either you use it or you don't... > > > Could you please explain the sequence for getting an accepted address? > > I guess it is something like this: > > * Send new address to device > > Read the USB 2.0 specification and the Linux kernel code. > All the answers are right in front of you! :) And if they differ with each other or reality? :-) > > Chapter 9 says how it works. The HC sends a reset to the > device, that reset completes. Now the device is running > with address zero. Linux could read descriptors then, but > it doesn't. (Windows does.) Instead, the first thing Linux > does is send a SET_ADDRESS request: > > SETUP packet to the host (one TD, 8 bytes SET_ADDRESS data) > IN packet from the device (one TD, zero bytes, status ack) > > > * Interrupt when data sent. > > Each of those TDs could cause an IRQ when they complete. > Linux 2.6 normally just gets one for the second one; I > seem to recall the 2.4 OHCI code gets an IRQ for both. This could be a possible scenario then: * Code backported from 2.6 expects only one interrupt - on the reply. * But on 2.4 you get both... * Trying to decode the answer after the interrupt will fail - since there is none yet. Possible? Has any ohci code been backported? > > The HCD is supposed to report the completion when both TDs > complete ... and usb_set_address() times out if that doesn't > happen within about 5 seconds. > So I guess I have to read the manuals and code - but right now I am on vacation, back to work in september - something for rainy days... /RogerL -- Roger Larsson Skellefte� Sweden ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
