From owner-freebsd-bugs Mon Jun 15 10:00:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15229 for freebsd-bugs-outgoing; Mon, 15 Jun 1998 10:00:50 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15220 for ; Mon, 15 Jun 1998 10:00:46 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.8.8/8.6.5) id KAA19679; Mon, 15 Jun 1998 10:00:44 -0700 (PDT) Date: Mon, 15 Jun 1998 10:00:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199806151700.KAA19679@apollo.backplane.com> To: Jonathan Lemon Cc: 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 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> fix the problem and I'll test the AUTOEOI configs as well. :> :> As far as I can tell, the only two places where the bug can possibly be :> are in the interface driver (pci/if_de.c) or the UDP/IP stack. :> : :I recently observed something similar with doscmd/VM886. When running :a cpu-bound process (rc5, for example), the cpl is not being reset to 0 :when the doscmd process exits. Breaking to ddb and single-stepping :across the iret instruction in doreti will sometimes `reset' the cpl. : :I'm pretty sure that this isn't a problem with the VM86 code, as I've :seen this problem before (cf: doreti_stop in ipl.s), but this also happens :even when not attempting to run in vm86 mode. :-- :Jonathan Yah, and even though I can't reproduce the problem with my NFS/xterm test on BEST's 2.2.6 machine, I notice that the load on any of our shell machines will shoot up from 2 to 10 just due to the presence of a cpu-bound program. Even though it's priority is maxed out, it still has an adverse effect on the rest of the machine. Very odd. I'm going to shoehorn my 'fix' into the next BEST kernel to see if it makes a difference there. My best bet finding the problem is still with my home -current setup, though, since I can reproduce it there. -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message