On Tue, 23 May 2000, Boris Popov wrote:
> On Mon, 22 May 2000, Matthew Dillon wrote:
> > :> No, I don't mean rodents who've nibbled on chocolate-covered expresso
> > :> beans, I mean PS/2 mice which fall victim to this new problem:
> > :
> > :> May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != 0000).
> > :
> > I got an email from Boris Popov in regards to getting more silo
> > overflows after the SMP cleanup patch then before.
> > One thing the patch removed was the hack that allowed certain interrupts
> > (tty interrupts) to run in parallel with the supervisor.
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).
> What is interesting in this case, is that this is the only active
> serial port on this machine. And it is behind my understanding why PII-350
> can not process interrupts when the come at 11Khz rate max (and machine
> idles most of the time).
Some syscalls take more than 1 / 11000 seconds without blocking, and the
interrupt handler is locked out while most syscalls are running. The
necessary processing rate is actually only 5.5 KHz for 16550 UARTs with
the default input fifo threshold of 2 below the fifo size.
diff -c2 apic_vector.s~ apic_vector.s
*** apic_vector.s~ Thu May 11 04:46:57 2000
--- apic_vector.s Tue May 23 16:37:52 2000
*** 10,24 ****
- * Interrupts must be enabled while waiting for the MP lock.
- #define GET_FAST_INTR_LOCK \
- sti; call _get_mplock; cli
- #define REL_FAST_INTR_LOCK \
- movl $_mp_lock, %edx ; /* GIANT_LOCK */ \
- call _MPrellock_edx
/* convert an absolute IRQ# into a bitmask */
#define IRQ_BIT(irq_num) (1 << (irq_num))
--- 10,13 ----
*** 49,55 ****
FAKE_MCOUNT((5+ACTUALLY_PUSHED)*4(%esp)) ; \
pushl _intr_unit + (irq_num) * 4 ; \
- GET_FAST_INTR_LOCK ; \
call *_intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \
- REL_FAST_INTR_LOCK ; \
addl $4, %esp ; \
movl $0, lapic_eoi ; \
--- 38,42 ----
If this causes crashes, then try removing the INTR_FAST flag in sio.c
so that normal interrupts are used. Normal interrupts are only blocked
by certain other normal interrupts, and only a few devices and/or
drivers are are broken enough to block interrupts for more than 1 / 5500
seconds. The main ones are IDE drives in PIO mode (or anything with
large buffers in slow PIO mode), and keyboard LEDs (or anything that
uses polled mode).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message