Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756718AbXJIQCI (ORCPT ); Tue, 9 Oct 2007 12:02:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753602AbXJIQB4 (ORCPT ); Tue, 9 Oct 2007 12:01:56 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:35964 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754212AbXJIQBz (ORCPT ); Tue, 9 Oct 2007 12:01:55 -0400 Date: Tue, 9 Oct 2007 12:01:54 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: David Miller cc: Greg KH , David Brownell , Kernel development list , USB users list Subject: Re: [Linux-usb-users] OHCI root_port_reset() deadly loop... In-Reply-To: <20071008.201653.43030513.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1821 Lines: 44 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/