: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

    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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to