From owner-freebsd-bugs  Sun Jun 14 14:50:45 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA07150
          for freebsd-bugs-outgoing; Sun, 14 Jun 1998 14:50:45 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA07143
          for <freebsd-bugs@FreeBSD.org>; Sun, 14 Jun 1998 14:50:44 -0700 (PDT)
          (envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id OAA12657;
	Sun, 14 Jun 1998 14:50:02 -0700 (PDT)
Date: Sun, 14 Jun 1998 14:50:02 -0700 (PDT)
Message-Id: <199806142150.OAA12657@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.ORG
From: Matthew Dillon <dillon@backplane.com>
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
Reply-To: Matthew Dillon <dillon@backplane.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

The following reply was made to PR i386/6944; it has been noted by GNATS.

From: Matthew Dillon <dillon@backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: bde@zeta.org.au, 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: Sun, 14 Jun 1998 14:41:35 -0700 (PDT)

 :>    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).
 
     Yah, I checked that out... but the problem was still there after turning
     off VM86, and I've got SMP turned off.  I also have APIC_IO turned off.
 
 :>    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.
 
     Damn.  I was hoping it would be easily reproduceable.  I see the same
     effect on our 2.2.x production machines.
 
     The diskless workstation is a -current kernel talking to a -current 
     server.  nfsd -n 4 on the server, nfsiod -n 2 on the client.  In one
     of my iterations I was dumping debugging printf()'s in the kernel,
     which showed that while the forever process ./x was running, the nfs 
     socket wakeup WAS setting the AST in ipending along with want_resched,
     but that nfsd wasn't getting woken up until the next timer tick.  If
     the machine was idle (no forever process), nfsd would get the cpu 
     immediately.
 
     Also, another point of reference:  If the forever process is running but
     with system call in a tight loop, like this:
 
 	for (;;)
 	    write(1, buf, 0);
 
     Then the nfsd would get woken up instantly for each request.  But if the
     forever process was running like this:
 
 	for (;;)
 	    ;
 
     The nfsd would not get woken up until the next timer tick.
 
 						-Matt
 
 :
 :Bruce
 
     Matthew Dillon   Engineering, BEST Internet Communications, Inc.
 		     <dillon@backplane.com>
     [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