From owner-freebsd-current  Fri Dec 25 03:18:07 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA28749
          for freebsd-current-outgoing; Fri, 25 Dec 1998 03:18:07 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA28732
          for <current@FreeBSD.ORG>; Fri, 25 Dec 1998 03:18:04 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id WAA31256;
	Fri, 25 Dec 1998 22:17:50 +1100
Date: Fri, 25 Dec 1998 22:17:50 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199812251117.WAA31256@godzilla.zeta.org.au>
To: jdp@polstra.com, mike@smith.net.au
Subject: Re: trap 12 with interrupts disabled
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> > If my page fault fails because I've blocked the interrupt, I'd expect
>> > some serious damage to happen to the process environment.n
>> 
>> Usually you're lucky and something else turns them on unconditionally.  
>> This test simply makes damn sure that if you take a fault interrupts 
>> get turned back on.
>
>I'm still not entirely clear about the implications of this change.
>If I understand it right, the message is caused by a bug in Xaccel.

Right.

>..
>Do the interrupts get turned back off again when control returns to
>Xaccel, or do they remain on?  If Xaccel is assuming they're off, it
>seems bad to turn them on underfoot.

They get turned back off, but this might not help because control might
not be returned to for Xaccel a long time.  E.g., the kernel might decide
to run 10 other processes for 100 msec each before returning to Xaccel.
This might break whatever timing requirements Xaccel is attempting to
meet by turning off interrupts.

Before the change, the following could happen:

1) Benign case: the pagefault handler finds the page in the cache and
   completes fairly fast (< about 100 usec).
2) The pagefault handler runs for a long time without blocking.  This
   causes slow response to interrupts.   "A long time" can apparently
   be several 10's of msec so that clock interrupts are lost.  I don't
   know how it can be so long (perhaps it is all in the application).
3) The pagefault handler blocks.  Then interrupts are turned on underfoot
   when another process or idle() is run.  Interrupts are "known" to
   be on already, and their state is "restored" to on when the blocked
   process is restarted in the kernel.  They get turned back off when
   the process leaves the kernel.
4) The pagefault handler happens to calls something that "knows" that
   interrupts are on and "restores" their state to on after turning them
   off.  This is essentially the same as the current behaviour.  I'm
   not sure if it actually occurred.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message