kern/42992: KGDB does not work once interrupts are enabled

[paul_koning%dell.com@localhost]

>Number:         42992
>Category:       kern
>Synopsis:       KGDB does not work once interrupts are enabled
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 17 19:20:00 +0000 2010
>Originator:     Paul Koning
>Release:        5.0
>Organization:
Dell
>Environment:
NetBSD pkvm50 5.0 NetBSD 5.0 (GENERIC) #9: Wed Mar 17 12:11:58 EDT 2010  
root@pkvm50:/usr/obj/sys/arch/i386/compile/GENERIC i386

>Description:
kgdb uses polled I/O for talking to the remote gdb.  Early on that works fine, 
but once interrupts are enabled, incoming characters trigger an interrupt to 
the com port driver so it becomes a race between that driver and the polled 
driver to see who gets to grab the character.  The polled driver loses most of 
the time, and even a single lost byte is enough to mess up the remote protocol. 
 The result is that KGDB is simply non-functional once the kernel switches to 
interrupt driven I/O.

>How-To-Repeat:
Build a kernel with KGDB.  Start it with -d, attach kgdb, set a breakpoint at 
some spot that will be hit once the OS is up.  Continue.  The breakpoint will 
be hit, but then gdb will not communicate successfully (in particular, fetching 
registers after the break signal fails) so it appears hung.  Running gdb with 
"set debug remote 1" shows the failure to communicate fairly well, and turning 
on DEBUG_KGDB in kgdb_stub.c shows it even more clearly (you see partial gdb 
packets instead of complete ones -- the missing bytes were sucked up by 
comintr().)

>Fix:
The solution is to put  a splserial() early in kgdb_trap with the matching 
splx() at the two exits.  This cures the problem and makes KGDB work reliably.