From owner-freebsd-current Tue Aug 13 02:41:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA03806 for current-outgoing; Tue, 13 Aug 1996 02:41:10 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA03801 for ; Tue, 13 Aug 1996 02:41:04 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id KAA11503; Tue, 13 Aug 1996 10:37:51 +0100 Date: Tue, 13 Aug 1996 10:37:50 +0100 (BST) From: Doug Rabson To: Bruce Evans cc: james@miller.cs.uwm.edu, freebsd-current@FreeBSD.ORG, wangel@wgrobez1.remote.louisville.edu Subject: Re: locking up In-Reply-To: <199608130910.TAA01996@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 Aug 1996, Bruce Evans wrote: > >> This happens to me whenever I break into DDB. The ipending thing fixes > >> it. I guess this motherboard manages to misplace the keyboard interrupt > >> while I am in the debugger :-(. > > >Potentially useless extra datapoint: This only happens under syscons; pcvt > >works fine. > > I guess it's not a motherboard problem :-). Actually, I think this motherboard is a bit flakey in the keyboard department. Windows95 sometimes loses the keyboard on this machine as well. When I break into ddb using pcvt, it always seems to insert 'df' into the keyboard buffer. Odd. > > pcrint() has the necessary loop in the default (PCB_KBD_FIFO configured) > case except in polled mode. It buffers scancodes in a huge fifo. Some > of the recent fixes to pcvt have been for the extra complications for > handling the buffering in polled mode. > > In polled mode, pcrint() reduces to sgetc(). sgetc() has too many cases > for me to understand. It seems to return too early in some cases, but not > when Debugger() is called. > > Note that no loop is necessary when sgetc() is called from pccngetc() > or pccncheckc(). For other reasons, keyboard interrupts must be blocked > when it is called, so returning early is harmless - if the keyboard IRQ > line is still active when the handler returns, then a keyboard interrupt > will occur later (actually, blocked keyboard interrupts occur early and > are turned into pending interrupts which occur later). I was just looking at syscons.c again and I noticed that scgetc() is called with interrupts blocked from sccngetc() but not blocked from sccncheckc(). Is that right? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426