On Mon, 8 Oct 2007, David Miller wrote:
> As coicidence would have it I finally found a recipe for triggering
> the issue, and it ties into what you're talking about here.
>
> It happens only if I make sure OHCI gets loaded first and then EHCI
> right afterwards.
>
> It seems that indeed it is important for EHCI to get loaded first,
> and in-kernel this is ensured by the link ordering.
>
> However, when both OHCI and EHCI are built as modules (or, similarly
> I guess, OHCI is built-in and EHCI is modular) there appears to be
> nothing in userspace which makes sure EHCI gets loaded first.
>
> When this triggers, in OHCI's root_port_reset(), the port status
> register reads 0x111 in that inner-loop and the value never changes.
> It stays like this forever.
I agree with Ben; the best way to solve this is in the kernel. Even if
you did manage to make sure that modules were loaded in the right order
initially, that wouldn't help if somebody starts unloading and loading
modules by hand.
The underlying cause of the problem appears to be related to the fact
that it is impossible in principle to detect a disconnect while a
full/low-speed reset is in progress. However the hardware shouldn't
rely on this, and it should fail gracefully when an unexpected
disconnect does occur.
For example, what would the controller do if the user unplugged the USB
cable right in the middle of a reset?
Anyway, it certainly would be easy enough to make port resets mutually
exclusive with EHCI initialization. That would work on any platform,
PCI or not.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
