On Wed, 17 Oct 2007, David Miller wrote:
> From: Alan Stern <[EMAIL PROTECTED]>
> Date: Wed, 17 Oct 2007 11:51:57 -0400 (EDT)
>
> > > + break;
> > > + }
> > > + if (limit_1 < 0) {
> > > + ohci_warn(ohci, "Root port outer-loop reset timeout, "
> > > + "now
From: Alan Stern <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 11:51:57 -0400 (EDT)
> > + break;
> > + }
> > + if (limit_1 < 0) {
> > + ohci_warn(ohci, "Root port outer-loop reset timeout, "
> > + "now[%04x] reset_done[%04x]\n",
> > +
On Tue, 16 Oct 2007, Greg KH wrote:
> But perhaps we can order the hardware init stuff from all three together
> like this into a separate module they all depend on. In a way, that's
> what the lock tried to do, right? Are we just not catching all places
> we could have hardware being talked to
On Tue, 16 Oct 2007, David Miller wrote:
> From: Alan Stern <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 11:23:58 -0400 (EDT)
>
> > Do you have any idea _where_ in ohci_hub_control the hang still occurs?
> > Is it the same unbounded reset loop?
>
> Yes, with post status stuck at 0x111
>
> > D
On Tue, Oct 16, 2007 at 03:06:31PM -0700, David Miller wrote:
> From: Alan Stern <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 11:23:58 -0400 (EDT)
>
> > Unfortunately that simply isn't possible. No matter what you do, the
> > user can always unload ehci-hcd and then load it back in again.
>
> Y
From: Alan Stern <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 11:23:58 -0400 (EDT)
> Do you have any idea _where_ in ohci_hub_control the hang still occurs?
> Is it the same unbounded reset loop?
Yes, with post status stuck at 0x111
> Does the patch below satisfy both Davids?
No, there are no w
From: Alan Stern <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 11:23:58 -0400 (EDT)
> Unfortunately that simply isn't possible. No matter what you do, the
> user can always unload ehci-hcd and then load it back in again.
Yes we can, by making OHCI and EHCI one module with a top-level
dispatch. If
> > > Bad news, even with the rwsem after a lot more testing I can still
> > > trigger the hang in ohci_hub_control() :-(
> > >
> > > I think we need to go back to considering the total serialization
> > > approach to this problem.
> >
> > We shouldn't need that. What happens if you add an msleep
On Mon, 15 Oct 2007, David Miller wrote:
> I want to help with this, but if I even breath on the kernel the bug
> goes away. The race just gets harder to trigger, and if we just keep
> adding things it'll make the problem go away but for the absolutely
> wrong reasons.
>
> The only way we will p
From: David Brownell <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 16:39:10 -0700
> > Bad news, even with the rwsem after a lot more testing I can still
> > trigger the hang in ohci_hub_control() :-(
> >
> > I think we need to go back to considering the total serialization
> > approach to this proble
> Bad news, even with the rwsem after a lot more testing I can still
> trigger the hang in ohci_hub_control() :-(
>
> I think we need to go back to considering the total serialization
> approach to this problem.
We shouldn't need that. What happens if you add an msleep(5)
before ehci-hcd::ehci_ru
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 09 Oct 2007 21:35:07 -0700 (PDT)
> From: David Miller <[EMAIL PROTECTED]>
> Date: Tue, 09 Oct 2007 15:00:40 -0700 (PDT)
>
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Tue, 9 Oct 2007 14:43:54 -0700
> >
> > > Does it resolve the problem
On Tue, 9 Oct 2007, David Brownell wrote:
> > From: Greg KH <[EMAIL PROTECTED]>
> >
> > Here's some information from Intel about where they have seen this
> > happen for UHCI controllers, so it's not just an OHCI issue :(
> >
> > ...
> >
The Intel error reports here are kind of unclear.
> >
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 09 Oct 2007 15:00:40 -0700 (PDT)
> From: David Brownell <[EMAIL PROTECTED]>
> Date: Tue, 9 Oct 2007 14:43:54 -0700
>
> > Does it resolve the problem you observed?
>
> I will definitely give the patch a try and report back.
My tests look really g
From: David Brownell <[EMAIL PROTECTED]>
Date: Tue, 9 Oct 2007 14:43:54 -0700
> Does it resolve the problem you observed?
I will definitely give the patch a try and report back.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tuesday 09 October 2007, David Miller wrote:
> Are we sure that this is the only event that causes the conflicts between
> the EHCI and it's companion virtual OHCI/UHCI host(s)?
It's the event which can cause trouble when EHCI starts up
after OHCI/UHCI (rather than before it).
The other event
From: Alan Stern <[EMAIL PROTECTED]>
Date: Tue, 9 Oct 2007 14:42:34 -0400 (EDT)
> On Tue, 9 Oct 2007, Greg KH wrote:
>
> > > 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.
> >
>
> Even though I'm severly overloaded, you asked me for a patch, I gave
> you one.
And I got some questions as I reviewed it. That's far
from un-heard-of. One particular question related to
one potential simplification ... which unfortunately
couldn't check out. Also not un-heard-of.
> A
> > > > > What values do you see for "portstat"?
> > > >
> > > > 0x111
> > >
> > > That's unfortunately useless ... PPS, PRS, CCS (meaning powered,
> > > resetting, connected). In short, there is *no* indication from
> > > the OHCI hardware that a disconnect happened.
> >
> > But it's an excelle
On Tue, Oct 09, 2007 at 01:41:16PM -0700, David Miller wrote:
> From: David Brownell <[EMAIL PROTECTED]>
> Date: Tue, 09 Oct 2007 09:38:27 -0700
>
> > > > What values do you see for "portstat"?
> > >
> > > 0x111
> >
> > That's unfortunately useless ... PPS, PRS, CCS (meaning powered,
> > resettin
From: David Brownell <[EMAIL PROTECTED]>
Date: Tue, 09 Oct 2007 09:38:27 -0700
> > > What values do you see for "portstat"?
> >
> > 0x111
>
> That's unfortunately useless ... PPS, PRS, CCS (meaning powered,
> resetting, connected). In short, there is *no* indication from
> the OHCI hardware that
> From: Greg KH <[EMAIL PROTECTED]>
>
> Here's some information from Intel about where they have seen this
> happen for UHCI controllers, so it's not just an OHCI issue :(
>
> ...
>
> 1) We see that the ports with low speed devices are still in EHCI mode
> (port owner bit not written to in EH
> Here is a proposed patch. I haven't tried running it, but it compiles
> okay.
Looks about right, too; thanks. Minor comments:
> --- usb-2.6.orig/drivers/usb/core/hcd.h
> +++ usb-2.6/drivers/usb/core/hcd.h
> @@ -470,5 +472,9 @@ static inline void usbmon_urb_complete(s
> : (in_in
> > Assuming PCI is present, /sys/bus/pci/devices/*/class can tell
> > if EHCI is present (0x0c0320) ... if so, load that driver.
> > Then repeat for OHCI (0x0c0310) and UHCI (0x0c0300).
>
> That will not work for all of the non-PCI implementations though.
Oddly enough, that's why I said "assuming
On Tue, 9 Oct 2007, Greg KH wrote:
> > 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.
>
> That's a good idea, any thoughts as to how to do this? I think I can
> find some Intel and D
On Tue, Oct 09, 2007 at 12:01:54PM -0400, Alan Stern wrote:
> 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 f
> > What values do you see for "portstat"?
>
> 0x111
That's unfortunately useless ... PPS, PRS, CCS (meaning powered,
resetting, connected). In short, there is *no* indication from
the OHCI hardware that a disconnect happened.
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
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 i
On Mon, 2007-10-08 at 22:00 -0700, David Brownell wrote:
> > > > The old /etc/hotplug/usb.rc script made sure to load those modules
> > > > in the correct order: EHCI first.
> > >
> > > I expected to find something cute attempting to handle this under
> > > /etc/udev, I have failed so far :-)
>
On Mon, 2007-10-08 at 22:26 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 09 Oct 2007 15:13:36 +1000
>
> > I'm not even sure module load order is 100% fault proof here since
> > khubd spawns as a thread...
>
> I'm concerned about that as well, thanks
On Mon, Oct 08, 2007 at 09:47:27PM -0700, David Miller wrote:
> From: Greg KH <[EMAIL PROTECTED]>
> Date: Mon, 8 Oct 2007 21:39:09 -0700
>
> > No, nothing cute in udev itself, but it seems that all distros that I
> > know of have a "load these modules now" type setting in their init
> > scripts th
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 09 Oct 2007 15:13:36 +1000
> I'm not even sure module load order is 100% fault proof here since
> khubd spawns as a thread...
I'm concerned about that as well, thanks for bringing it up.
My understanding, however, is that the critical t
From: David Brownell <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 22:00:19 -0700
> Assuming PCI is present, /sys/bus/pci/devices/*/class can tell
> if EHCI is present (0x0c0320) ... if so, load that driver.
> Then repeat for OHCI (0x0c0310) and UHCI (0x0c0300).
These are facts all of us know very w
> Yes, that's why I asked about EHCI. My speculation would be that
> OHCI starts the reset, and EHCI claims the port before it completes;
> or contrariwise OHCI starts the reset right after EHCI claims it.
>
> And there's some point in that process where a hardware race makes
> the trouble you've
On Mon, 2007-10-08 at 21:47 -0700, David Miller wrote:
> From: Greg KH <[EMAIL PROTECTED]>
> Date: Mon, 8 Oct 2007 21:39:09 -0700
>
> > No, nothing cute in udev itself, but it seems that all distros that I
> > know of have a "load these modules now" type setting in their init
> > scripts that can
> > > The old /etc/hotplug/usb.rc script made sure to load those modules
> > > in the correct order: EHCI first.
> >
> > I expected to find something cute attempting to handle this under
> > /etc/udev, I have failed so far :-)
>
> No, nothing cute in udev itself, but it seems that all distros tha
From: Greg KH <[EMAIL PROTECTED]>
Date: Mon, 8 Oct 2007 21:39:09 -0700
> No, nothing cute in udev itself, but it seems that all distros that I
> know of have a "load these modules now" type setting in their init
> scripts that can be used here.
>
> I can't think of a way to enforce this load orde
From: David Brownell <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 21:36:43 -0700
> Don't need this "limit_1" timeout; "reset_done" handles all
> the timeout needed there. The regs->fmnumber is essentially
> a millisecond counter.
If the hardware hangs and the register stops incrementing,
the entir
> Regardless, here is a patch that hardens the OHCI reset handling
> loops so that they break out instead of hanging the entire system
> should this condition occur. It's at least better than what the
> code does to a user right now which is hang the box completely:
>
> [USB] ohci: Do not hang the
On Mon, Oct 08, 2007 at 08:42:36PM -0700, David Miller wrote:
> From: David Brownell <[EMAIL PROTECTED]>
> Date: Mon, 08 Oct 2007 20:34:12 -0700
>
> > > 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
> >
> To add some more information here, I think the EHCI idea might
> hold some water.
>
> What I have here are two NEC OHCI USB interfaces and one NEC EHCI
> USB interface on PCI. Aparently they all go through a shared
> USB hub, mapped like this:
>
> HUB Port 1: OHCI #1, EHCI
> HUB Port 2: OHCI #2,
From: David Brownell <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 20:34:12 -0700
> > 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.
>
> The
> 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.
The old /etc/hotplug/usb.rc script made sure to load those modules
in the correct order: EHCI
From: Greg KH <[EMAIL PROTECTED]>
Date: Mon, 8 Oct 2007 20:10:49 -0700
> Yes it does, I'm seeing reports from some hardware companies of the very
> same thing. If you serialize and load the ehci driver first, and then
> the ohci driver, that should fix the problem.
>
> Does that also work for yo
On Mon, Oct 08, 2007 at 04:54:20PM -0700, David Miller wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Sun, 07 Oct 2007 00:51:56 -0700 (PDT)
>
> > From: David Brownell <[EMAIL PROTECTED]>
> > Date: Sun, 07 Oct 2007 00:31:41 -0700
> >
> > > Are the other ports still behaving? Is EHCI mayb
From: David Miller <[EMAIL PROTECTED]>
Date: Sun, 07 Oct 2007 00:51:56 -0700 (PDT)
> From: David Brownell <[EMAIL PROTECTED]>
> Date: Sun, 07 Oct 2007 00:31:41 -0700
>
> > Are the other ports still behaving? Is EHCI maybe trying to switch
> > ownership of that port? Is maybe the (newish) autosu
From: David Brownell <[EMAIL PROTECTED]>
Date: Sun, 07 Oct 2007 00:31:41 -0700
> Is this SPARC, or is ACPI potentially in play? PCI, or non-PCI?
It's sparc64 on PCI.
> Are the other ports still behaving? Is EHCI maybe trying to switch
> ownership of that port? Is maybe the (newish) autosuspen
> From [EMAIL PROTECTED] Sat Oct 6 23:56:49 2007
>
> When root_port_reset() in ohci-hub.c polls for the end of the reset,
> it puts no limit on the loop and will only exit the loop when either
> the RH_PS_PRS bit clears or the register returns all 1's (the latter
> condition is a recent addition)
When root_port_reset() in ohci-hub.c polls for the end of the reset,
it puts no limit on the loop and will only exit the loop when either
the RH_PS_PRS bit clears or the register returns all 1's (the latter
condition is a recent addition).
If for some reason the bit never clears, we sit here fore
49 matches
Mail list logo
