Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Aug 1996 10:37:50 +0100 (BST)
From:      Doug Rabson <dfr@render.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        james@miller.cs.uwm.edu, freebsd-current@FreeBSD.ORG, wangel@wgrobez1.remote.louisville.edu
Subject:   Re: locking up
Message-ID:  <Pine.BSI.3.95.960813103029.8304A-100000@minnow.render.com>
In-Reply-To: <199608130910.TAA01996@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960813103029.8304A-100000>