From owner-freebsd-current Tue Aug 13 00:53:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA28381 for current-outgoing; Tue, 13 Aug 1996 00:53:28 -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 AAA28374 for ; Tue, 13 Aug 1996 00:53:10 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA31144; Tue, 13 Aug 1996 17:48:21 +1000 Date: Tue, 13 Aug 1996 17:48:21 +1000 From: Bruce Evans Message-Id: <199608130748.RAA31144@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 >> > Sometimes, at no predetermined time, without warning, when switching VC's, >> > I'll lock up. FreeBSD doesn't lockup just the keyboard, and I can only fix >> > it by rebooting. >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 :-(. I guess it is a timing bug in the console driver. If an ISA interrupt handler returns before completely servicing then interrupt, then it will never get anothr interrupt (because ISA interrupts are edge triggered and the old one hasn't gone away). Polling for keystrokes in the (ddb) console input routine apparently sometimes confuses the driver into thinking that an unserviced interrupt has been serviced. The bug is very obvious: scintr() doesn't loop like it needs to. scgetc() does loop, but it sometimes returns early. I used to think that the loop handled all cases, but this bug has been present since revision 1.1. Bruce