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
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.
> >
>
> 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
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
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
20 matches
Mail list logo
