David Brownell ([EMAIL PROTECTED]) said:
> Looks like a cleanup path needs to handle early failure a bit better;
> likely just having ehci_stop test for ehci->async non-null (before
> calling scan-async to clean up any pending work) would suffice.
This patch solves the oops for me - thanks!
Bill
David Brownell ([EMAIL PROTECTED]) said:
> Bill Nottingham wrote:
> >With a 2.6.6-rc1 based kernel. Happened when loading ehci_hcd some
> >10 hours after booting, couldn't reproduce in initial attempts. I
> >suppose the question is also why it failed to init, but it certainly
> >didn't like the fa
Bill Nottingham wrote:
With a 2.6.6-rc1 based kernel. Happened when loading ehci_hcd some
10 hours after booting, couldn't reproduce in initial attempts. I
suppose the question is also why it failed to init, but it certainly
didn't like the failure...
Hmm, no it didn't. The "illegal capability" is
With a 2.6.6-rc1 based kernel. Happened when loading ehci_hcd some
10 hours after booting, couldn't reproduce in initial attempts. I
suppose the question is also why it failed to init, but it certainly
didn't like the failure...
Bill
PCI: Enabling device :00:1d.7 ( -> 0002)
ehci_hcd :
