From owner-freebsd-current  Tue Apr  2 07:06:01 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA00212
          for current-outgoing; Tue, 2 Apr 1996 07:06:01 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA00184
          for <freebsd-current@freefall.freebsd.org>; Tue, 2 Apr 1996 07:05:57 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA28807; Wed, 3 Apr 1996 01:05:31 +1000
Date: Wed, 3 Apr 1996 01:05:31 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604021505.BAA28807@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@critter.tfs.com
Subject: Re: calcru: negative time:
Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> >Alternatively, could we make a check in spl*() so that if splhigh has been
>> >active >long< time we will print a warning ?
>> ...  The problem should
>> be reported by stopping at a breakpoint in spl0 or in doreti before the
>> cpl has been reduced.  Then there will be a chance of seeing what set
>> cpl high for too long.

>Couldn't you just record the %eip in splhigh() ?

Yes, unless the problem was more to do with the flow of control from
where splhigh was set to where it was cleared.  This would be hard to
see, but it might help to look at the stack frame.

You would also have to be careful about nested splhigh()s and nonlinear
flows of control (context switches).

I like breakpoints.  They're faster to write than printfs.

Bryce