Date: Tue, 13 Aug 1996 19:10:32 +1000 From: Bruce Evans <bde@zeta.org.au> To: dfr@render.com, james@miller.cs.uwm.edu Cc: freebsd-current@FreeBSD.ORG, wangel@wgrobez1.remote.louisville.edu Subject: Re: locking up Message-ID: <199608130910.TAA01996@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608130910.TAA01996>