From owner-freebsd-current Tue Aug 13 02:19:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA02589 for current-outgoing; Tue, 13 Aug 1996 02:19:14 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA02580 for ; Tue, 13 Aug 1996 02:18:55 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA01996; Tue, 13 Aug 1996 19:10:32 +1000 Date: Tue, 13 Aug 1996 19:10:32 +1000 From: Bruce Evans Message-Id: <199608130910.TAA01996@godzilla.zeta.org.au> To: dfr@render.com, james@miller.cs.uwm.edu Subject: Re: locking up Cc: freebsd-current@FreeBSD.ORG, wangel@wgrobez1.remote.louisville.edu Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> 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 :-). 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). Bruce