> I'm using kernel 2.5.8.  When my Adaptec USB2connect for
> Notebooks USB 2.0 Cardbus Adapter is plugged in to my
> Dell Inspiron 4100 notebook and I press the power switch
> on, I get an Oops message during bootup.

Did you try 2.5.15?  I suspect you won't see much change
there, but it'd be good to know for sure.  (The driver has had
a lot of changes, though few that should affect the async unlink
codepath that seems to be complaining here.  Other parts of
the kernel changed more.)

Also:  is there high speed device plugged in when this
happens?  And does this only happen at powerup, or does
it also happen when you plug the card in later?


> static void end_unlink_async (struct ehci_hcd *ehci)
> {
>     1acb: 8b 7c 24 10          mov    0x10(%esp,1),%edi
> struct ehci_qh *qh = ehci->reclaim;
>     1acf: 8b 77 08             mov    0x8(%edi),%esi
> 
> qh->qh_state = QH_STATE_IDLE;                          
>     1ad2: 66 c7 46 5a 03 00    movw   $0x3,0x5a(%esi)   <=====
> ...

Hey, I like that -- a ksymoops that's tracked down to
the actual lines of code!!  Would that all Oops reports
were tracked down that completely!


> I think I'm getting the Oops because struct ehci_qh *reclaim in
> struct ehci_hcd is not initialized.  I'm not sure what instance of
> struct ehci_qh to declare and if I should put it in struct ehci_hcd
> so I can initialize *reclaim.  

I'd suspect ehci->reclaim_ready was somehow clobbered,
since a null ehci->reclaim (which you seemed to have) is
the normal state except when something is being taken off
of the async ring.  Then when the ehci->reclaim_ready flag
is set, end_unlink_async() is called to handle the hardware
having given up that QH.

If there was no device hooked up, this code should never be
executed.  (Strongly suggesting that some other kernel code
overwrote a chunk of EHCI data...)

If there was a device hooked up, then this code path would
be executed some request was unlinked ... maybe some
enumeration request timed out.  You can look at the EHCI
spec to see what it's supposed to be doing, the "IAA"
mechanism (4.15.2.3) kicking in _or_ one of two other
unlink cases found in start_unlink_async().

- Dave




_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to