From owner-freebsd-hackers Tue Mar 26 01:26:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA22665 for hackers-outgoing; Tue, 26 Mar 1996 01:26:58 -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 BAA22658 for ; Tue, 26 Mar 1996 01:26:52 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA00773; Tue, 26 Mar 1996 20:22:56 +1100 Date: Tue, 26 Mar 1996 20:22:56 +1100 From: Bruce Evans Message-Id: <199603260922.UAA00773@godzilla.zeta.org.au> To: bde@zeta.org.au, lehey.pad@sni.de Subject: Re: kgdb / remote gdb of the kernel? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> interrupts disabled... Restoring the clocks is quite complicated. >> See apm for how to do it wrong. >The obvious way to restore the time-of-day clock would be from CMOS. >Would this break anything else? That's how apm gets it wrong :-). The way it is done in apm breaks: - accuracy. The mc141618A clock doesn't can't be read more accurately than to the nearest second. For apm it's probably OK to wait until the seconds counter changes, but 1 second pauses aren't OK for single stepping in the debugger. - associated clocks. The i586 cycle counter isn't affected by interrupts being enabled, so it may get way ahead of the (slow) current time. This may caused division overflow in microtime(), or addition of more usec than microtime() is prepared to deal with (> 1 million). The statistics clock is usually stopped iff the main clock is stopped. It should be advanced by the same amount as the main clock (assign interrupt ticks to idle so that the statistics are consistent with reality). Bruce