Date: Thu, 25 Apr 1996 12:39:50 +1000 From: Bruce Evans <bde@zeta.org.au> To: gpalmer@freebsd.org, smpatel@umiacs.umd.edu Cc: current@freebsd.org Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604250239.MAA01585@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604250239.MAA01585>