Date: Sun, 14 Jun 1998 12:10:01 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/6944: bug in i386/isa/icu_ipl.s - AST gets lost, causes extreme network slowdown when cpu-bound processes present, possibly other problems Message-ID: <199806141910.MAA12005@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/6944; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dillon@backplane.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: i386/6944: bug in i386/isa/icu_ipl.s - AST gets lost, causes extreme network slowdown when cpu-bound processes present, possibly other problems Date: Mon, 15 Jun 1998 05:01:45 +1000 > Well, I spent 6 hours from 9p.m. to 3a.m. just find this :-) I'm going > to leave the finding of the broken spl to someone else, but there ARE > several places where $0 is loaded into the cpl in the assembly, and Mainly SMP places in swtch.s and VM86 places in ipl.s. I can't see any relevant problems there (except it's hard to see anything because of the ifdefs). > other places where the interrupt nesting count is manually reset to 1. That should just be an optimization. incl/decl should work, but takes one more memory access. Unfortunately, this optimization tends to hide bugs. > The problem is extremely reproducable... just NFS mount / and /usr from > a server to a workstation, run a for (;;); process on the server, and > try to run xterm on the workstation and, poof. Not reproducible here. I'll try using VM86. > I also noticed that the fast interrupt code doesn't save/restore the cpl > around the call to the interrupt handler, but the 'normal' interrupt > code does. I believe the code thinks this is ok because it's leaving cpl has no effect on fast interrupt handlers. > the cpu CLI'd through the call, but I actually think the slow interrupt > handler results in faster operation because the interrupt context doesn't > get popped & repushed through a ring change if a nested interrupt occurs. No, slow interrupt handlers do a few more integer operations, and at least 2 more i/o operations which may each take as long as several hundred integer instructions. The slow pop-repush case only occurs when a fast interrupt handler wants to switch to a SWI handler. Nested interrupts can't occur while the fast interrupt handler is running. The nest level is only checked to avoid going too deep. > I also submit that the fast interrupt code doesn't make the system any > more responsive... the two critical time-sensitive interrupts are the They are no supposed to. They are supposed to make dumb hardware work at all. E.g., without fast interrupts, a 16450 at 115200 bps would lose about 30 fifos full of input whenever someone presses CapsLock, because the console driver disables tty interrupts while setting the LEDs, and setting the LEDS takes about 3 msec. A 16550 would lost only about 2 fifos full :-). > ethernet rx and the serial rx and neither is able to keep up as it > stands... our 100BaseTX boards almost universally get knocked back into > store and forward mode due to rx overruns after the machine's been up Fast interrupt handlers are not used by any network drivers. Network interrupts for CapsLock if SLIP is configured or PPP is active :-(. > for a while, and anyone with a digital camera can tell you that the > serial interrupt sucks rocks in terms of being able to process exceptions > at a high rate in unhandshaked mode without overrunning. Running a > 'fast' interrupt with interrupts disabled isn't a hot idea when the 'fast' > interrupt isn't the serial or network receive interrupt! That's one reason why fast interrupts are only used by serial drivers. When getting to the interrupt handler takes 5 usec (longer on old systems) it doesn't hurt at all to keep interrupts disabled another 5-10 usec to do all the i/o that a 16450 can do, and it doesn't hurt much to keep them disabled another 50 usec to do all the i/o that a 16550 can do. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806141910.MAA12005>