On Tue, 1 Aug 2006, David Brownell wrote:
> > Yes, the URB remained in ep->urb_list and hcd_endpoint_disable() did see
> > it when it went through the loop again. But urb->status had been changed
> > to -ESHUTDOWN, so hcd_endpoint_disable() simply skipped over it and did
> > not keep retrying to
On Thursday 27 July 2006 8:41 am, Alan Stern wrote:
> > > The problem came up when there was a control URB running while the HCD
> > > module was unloaded. hcd_endpoint_disable() didn't wait for the URB to
> > > complete, the driver was unloaded from memory, and boom!
> >
> > Hmm, the if(1) sho
On Thu, 27 Jul 2006, Alan Stern wrote:
> The real problem was this: hcd_endpoint_disable() relies on
> hcd->driver->endpoint_disable() to wait until all URBs for an endpoint
> have completed. Normally that's fine, but it doesn't work with URBs for
> endpoints on the root hub -- because these U
On Tuesday 25 July 2006 11:47 am, Matthias Urlichs wrote:
> >
> > Why do you say "perennial" as if this is a problem that's been reported
> > often? If it had been, surely I'd have heard of it ... yet these lock
> > debug tools are new, and ISTR aren't free of reporting false positives.
> > Such
On Tue, 25 Jul 2006, David Brownell wrote:
> > Or are you referring to the second sentence in the comment? It doesn't
> > mention asynchronous unlinks in particular; it just says that interrupts
> > have to be enabled.
>
> Yes. One of the basic reasons to be async is so you can run with
> irq
On Wednesday 26 July 2006 8:29 am, Alan Stern wrote:
> On Wed, 26 Jul 2006, David Brownell wrote:
>
> > > The patch uses spin_lock_irqsave() and spin_unlock_irqrestore() along with
> > > a call to wait_event(). What happens if you end up calling wait_event()
> > > with interrupts disabled? Woul
On Wed, 26 Jul 2006, David Brownell wrote:
> On Wednesday 26 July 2006 8:29 am, Alan Stern wrote:
> > On Wed, 26 Jul 2006, David Brownell wrote:
> >
> > > > The patch uses spin_lock_irqsave() and spin_unlock_irqrestore() along
> > > > with
> > > > a call to wait_event(). What happens if you end
On Tuesday 25 July 2006 2:41 pm, Alan Stern wrote:
> On Tue, 25 Jul 2006, David Brownell wrote:
>
> > > /* Asynchronous unlinks of root-hub control URBs are legal, but they
> > > * don't do anything. Status URB unlinks must be made in process context
> > > * with interrupts enabled.
> > > */
>
Hi,
David Brownell:
> On Tuesday 25 July 2006 7:54 am, Alan Stern wrote:
> > On Tue, 25 Jul 2006, Matthias Urlichs wrote:
> >
> > > This is the perennial "we have an OHCI interface on a PCMCIA card. We
> > > pull the card. The kernel crashes / hangs / whatever" problem.
> > >
> > > [ INFO: incon
On Wednesday 26 July 2006 7:16 am, Alan Stern wrote:
> On Tue, 25 Jul 2006, David Brownell wrote:
>
> > > Or are you referring to the second sentence in the comment? It doesn't
> > > mention asynchronous unlinks in particular; it just says that interrupts
> > > have to be enabled.
> >
> > Yes.
On Wed, 26 Jul 2006, David Brownell wrote:
> > The patch uses spin_lock_irqsave() and spin_unlock_irqrestore() along with
> > a call to wait_event(). What happens if you end up calling wait_event()
> > with interrupts disabled? Would it be better simply to spin?
>
> You're ignoring that ugly
>
On Tue, 25 Jul 2006, David Brownell wrote:
> ... except that as you noted later, that invariant was blown away by a
> routine lower down in usbcore, which violates one of the cardinal locking
> rules of not enabling IRQs on exit if they weren't enabled on entry:
At least the violation is document
On Tuesday 25 July 2006 10:44 am, Alan Stern wrote:
> On Tue, 25 Jul 2006, David Brownell wrote:
>
> > Plus, this trace clearly shows the issue is with UHCI, not OHCI!
>
> No, not really. The trace says that the OHCI operations caused
> hcd_data_lock to be acquired in hcd_endpoint_disabled() wit
On Tue, 25 Jul 2006, David Brownell wrote:
> Plus, this trace clearly shows the issue is with UHCI, not OHCI!
No, not really. The trace says that the OHCI operations caused
hcd_data_lock to be acquired in hcd_endpoint_disabled() with interrupts
enabled, which is inconsistent with the earlier beh
On Tuesday 25 July 2006 7:54 am, Alan Stern wrote:
> On Tue, 25 Jul 2006, Matthias Urlichs wrote:
>
> > This is the perennial "we have an OHCI interface on a PCMCIA card. We
> > pull the card. The kernel crashes / hangs / whatever" problem.
> >
> > [ INFO: inconsistent lock state ] -- details bel
On Tue, 25 Jul 2006, Matthias Urlichs wrote:
> This is the perennial "we have an OHCI interface on a PCMCIA card. We
> pull the card. The kernel crashes / hangs / whatever" problem.
>
> [ INFO: inconsistent lock state ] -- details below.
This is interesting because the "inconsistent lock state"
This is the perennial "we have an OHCI interface on a PCMCIA card. We
pull the card. The kernel crashes / hangs / whatever" problem.
[ INFO: inconsistent lock state ] -- details below.
Kernel log:
pccard: card ejected from slot 0
ohci_hcd :02:00.0: remove, state 1
ohci_hcd :02:00.0: root
17 matches
Mail list logo
