Date: Mon, 30 Jan 2006 21:57:36 +0000 From: Ian Dowse <iedowse@iedowse.com> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-usb@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h Message-ID: <200601302157.aa30543@nowhere.iedowse.com> In-Reply-To: Your message of "Mon, 30 Jan 2006 20:52:58 %2B0100." <20060130195258.GA7172@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060130195258.GA7172@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 >happens `sometimes'...) 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 condition. 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 Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601302157.aa30543>