cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
iedowse at iedowse.com
Mon Jan 30 13:57:44 PST 2006
In message <20060130195258.GA7172 at saturn.kn-bremen.de>, Juergen Lock writes:
> Well ehci_intrlist_timeout belongs to the ehci patch in the Subject
>so its pretty new... (I don't know the code enough to know if it
>matters, but shouldnt the timer only be scheduled if the interrupt
>did appear too early, i.e. the transfer indeed wasnt complete yet?
>Not all transfers hung before i applied the patch, so it only
Calling the driver's interrupt service routine should be safe at
any time (assuming sufficient locking, which should be OK), since
this can happen with shared interrupts, so if anything it's more
likely to be an existing problem that just gets triggered more often
by having the ISR called via the new timer.
Try applying the patch I posted yesterday and see if that helps.
It includes a change to usb_transfer_complete() that might be
relevant - the EHCI driver touches the transfer structure in its
done() method, and the usb_transfer_complete() change makes it safe
to do this when a callback function reuses the transfer structure.
The umass driver shouldn't normally reuse its transfer structures
during callbacks, but maybe it can during some error recovery
Could you also do the following from gdb on the crash dump you have?
It might possibly provide further hints as to what went wrong.
p *(struct ehci_xfer *)0xc1aaf300
p *(struct ehci_softc *)0xc1a3f800
More information about the freebsd-usb