Date: Sat, 02 Apr 2005 19:02:18 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: ticso@cicely.de Cc: freebsd-usb@freebsd.org Subject: Re: panic: uhci_abort_xfer: not in process context Message-ID: <200504021902.aa86365@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sat, 02 Apr 2005 19:19:39 %2B0200." <20050402171938.GU2072@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050402171938.GU2072@cicely12.cicely.de>, Bernd Walter writes: >I fully agree with you - in general. >You see the inetrrupt routine as non-blocking context. >Fine - abort_xfer is bad as it blocks for a long time - agreed. >But we need any kind of syncronisation with top half. >Although taking a mutex may block I don't consider it bad as it should >not be hold for long time and therefor waiting a long time is unlikely. >Allowing to wait for a Mutex in the bottom half is the whole reason we >have interrupt threads. >But that is the current problem - we are not even allowed to take >a Mutex, just because intr_context isn't safe. >The panic was triggered by a userland call that was claimed to be in >interrupt context. >OK - I was wrong in that it was not close, but that doesn't change >anything with the basic problem: >The panic triggered when it shouldn't. Maybe I'm misunderstanding the cause of some of these panics, so correct me if this sounds wrong. There seem to be two ways for the "not in process context" panic to occur. One is where usbd_abort_pipe() is called directly from an interrupt thread. The other way is for a callback to be called from interrupt thread and that callback sleeps. This allows other threads to enter the USB code with intr_context > 0, so the panic can be incorrectly triggered. In both cases, the bug is that a callback function is sleeping and allowing other threads to run. I'm not sure I understand your comments about locking mutexes though. It is fine for a callback function to acquire a mutex, because acquiring a mutex is not really sleeping, because currently held locks are not dropped even if the mutex cannot be acquired immediately. For example, the USB system will hold Giant at the time that the interrupt thread is calling completion callbacks. Even if one of those callbacks needs to acquire another mutex that is currently locked, Giant will not be dropped while that mutex is acquired, so no other threads can enter the USB code. The problem is limited to tsleep/msleep where all mutexes are dropped. A more specific statement of the original comments would be that callbacks in asynchronous event systems should not call tsleep or msleep, no matter what the calling context is. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504021902.aa86365>