From owner-freebsd-current Tue Apr 25 22:13:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id D668D37B728 for ; Tue, 25 Apr 2000 22:13:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 3418 invoked from network); 26 Apr 2000 05:13:15 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 26 Apr 2000 05:13:15 -0000 Date: Wed, 26 Apr 2000 15:13:10 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Greg Lehey Cc: Doug Rabson , FreeBSD Committers , FreeBSD current users Subject: Re: Remote serial gdb is broken in -CURRENT. In-Reply-To: <20000426105344.B38665@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Greg Lehey wrote: > Even that didn't work for me. BTW, the fix had the side effect of > making the clock stand still. I've changed the code (spltty instead The gdb code apparently assumes that the kernel debugger runs entirely with interrupts disabled (as is required for the kernel debugger to actually be useful for debugging interrupt handlers), or that the i/o routines are buffered. My version of ddb/gdb has always run with interrupts disabled, but I never committed the changes because they break the clock :-). I wrote fixes to restore the clock from the RTC a couple of years ago but have never been completely happy with them. Restoring the clock properly from the RTC should be part of a larger fix that restores it properly after resuming from suspend mode, intertwined with ntp-related code for slewing the clock instead of stepping it in some cases. > of splhigh), and it seems to work OK now, so it probably was the tty > interrupt stealing characters. I'll commit when I'm sure all is still > OK. Neither spltty() nor splhigh() prevents sio interrupts, since sio interrupts are fast. spltty() primarily prevents mainly keyboard interrupts and software interrupts. The former could be a problem becuase the console driver still uses polled mode for setting the keyboard LEDs (it busy-waits for typically 2-5 msec). The latter could be a problem if someone has added slow timeout routines or slow netisrs or slow camisrs. The tty software interrupt routines haven't changed lately. spltty() secondarily prevents network hardware interrupts if slip is configured or ppp is attached. Use "s = splvm(); (void)spltty();" to mask everything except clock interrupts. Try using splnet() to see if masking only timeouts and netisrs fixes the problem. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message