Date: Tue, 23 May 2000 20:32:48 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Boris Popov <bp@butya.kz> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, current@FreeBSD.ORG Subject: Re: Anyone else seeing jumpy mice? Message-ID: <Pine.BSF.4.21.0005231859060.485-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.10.10005231120190.64867-100000@lion.butya.kz>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Untested fix: 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 **** #include "i386/isa/intr_machdep.h" - /* - * 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). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005231859060.485-100000>