From owner-cvs-sys  Mon Feb 20 12:50:35 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA07533 for cvs-sys-outgoing; Mon, 20 Feb 1995 12:50:35 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA07522; Mon, 20 Feb 1995 12:50:31 -0800
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id MAA05527; Mon, 20 Feb 1995 12:50:12 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id MAA00171; Mon, 20 Feb 1995 12:50:11 -0800
Message-Id: <199502202050.MAA00171@corbin.Root.COM>
X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol
To: Bruce Evans <bde@freefall.cdrom.com>
cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/isa icu.s 
In-reply-to: Your message of "Mon, 20 Feb 95 12:35:26 PST."
             <199502202035.MAA06487@freefall.cdrom.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Mon, 20 Feb 1995 12:50:10 -0800
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

>bde         95/02/20 12:35:25
>
>  Modified:    sys/i386/isa icu.s
>  Log:
>  Fix restoring cpl in the swi_ast_phantom case.  The system sometimes
>  returned to user mode without enabling ASTs.  The problem fixed itself
>  at the next syscall or non-FPU trap, if any.  It hung the system for
>  a test process that masked SIGFPE's and divided by zero.  The faulting
>  division was returned to endlessly and this gave plently of opportunities
>  for the swi_ast_phantom case to be reached; after it was reached the
>  system hung because the ASTs for preemption and SIGINT handling were
>  disabled.

   Hmmm...this sounds like the same bug that is (was?) causing Larry McVoy's
bw_tcp benchmark to 1) hang, and 2) after interrupting it the process would
hang in the kernel bouncing between the low level AST processing and the upper
layer TCP processing code. This didn't use to happen a few months ago - was
something changed to cause this?

-DG