From owner-freebsd-current  Wed Apr 24 20:00:27 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id UAA06781
          for current-outgoing; Wed, 24 Apr 1996 20:00:27 -0700 (PDT)
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 UAA06768
          Wed, 24 Apr 1996 20:00:13 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA01585; Thu, 25 Apr 1996 12:39:50 +1000
Date: Thu, 25 Apr 1996 12:39:50 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604250239.MAA01585@godzilla.zeta.org.au>
To: gpalmer@freebsd.org, smpatel@umiacs.umd.edu
Subject: Re: request for a new "feature" as regards DDB
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> > While we're talking about DDB, can't we have it timeout in 30s if you
>> > don't hit a key (and then generate a core dump).
>>
>> Not really ... that would assume that the IRQ handlers were still
>> operational, which may not be the case. DDB should only be running if
>> all interrupts are disabled if I remember right (and if I don't, I
>> won't mind being corrected :-) )

Here are some corrections :-).

1. ddb should run with all interrupts enabled.  It should also normally
   keep interrupts disabled while tracing.  Otherwise the system state
   may change while you're looking at it.
2. ddb actually doesn't disable interrupts.  It even enables them if
   they were only disabled in the cpu.  Thus breakpoints sections
   protected by `enable_intr(); ... disable_intr();' or early in
   Xintr*(), or in fastintr handlers don't work right.  spl masking
   works better.  Normally ddb spends most of it's time sitting in the
   console input routine at spltty() or higher.  Other interrupts are
   masked iff they are masked when ddb is entered.  tty interrupts
   aren't masked throughout unless they are masked when ddb is entered.
   Clock interrupts usually aren't masked when ddb is entered, so the
   clocks usually keep ticking away.
3. timeout() is unsuitable for use ddb.  First, clk0 interrupts might be
   masked when ddb is entered.  Then ddb can't unmask them, so the
   clk0 won't work.  Second, ddb shouldn't depend on the timeout() code
   to work.

>Can we sit in a loop, while polling the keyboard for input?

Yes, you can usefully poll the clock(s) while polling the keyboard,
provided:

a. polling is non-destructive.  This makes it difficult to use timer0,
   timer1 and the RTC. Perhaps they can be read without (destructively)
   latching the count.  Even that steals some state if a non-debugging
   part of the system has just latched the count.  timer2 is probably
   safe to use, because non-debugging parts of the system never access
   it.

b. the clock hasn't stopped.

Bruce