:The patch seems to have completely broken fast interrupts.
:GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see.
:The necessary and sufficient locking is done by COM_LOCK() in individual
:drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock),
:which does nothing very well, to `sti(); get_mplock(); cli();', which
:essentially de-prioritizes "fast" interrupts from "higher than the highest"
:(higher than clock interrupts which are nominally highest) to "lower than
:the lowest" (lower than all normal interrupts, all software interrupts,
:and all MP-unsafe syscalls).
It isn't quite that bad. Remember that interrupts are vectored to
the cpu already running in supervisor mode, and the MP lock is recursive.
So GET_FAST_INTR_LOCK will generally not block against MP-unsafe
syscalls or anything else. It will still operate as a high-priority
interrupt.
I understand the point about COM_LOCK, and agree - but I also never
trusted the MP-safeness of the fast-interrupt code hack so lets not
commit this until we have a chance to audit the entire fast-interrupt
path. Frankly, I would much rather see MP-safe NIC interrupt code
then MP-safe serial interrupt code.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
