Re: kern/55286: Kernel messages cause loss of serial console input

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR kern/55286; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/55286: Kernel messages cause loss of serial console input
Date: Sun, 24 May 2020 16:51:52 +0300

 Manuel Bouyer wrote:
 > no, it works fine even if nothing is being printed. I know, I'm using '+++++'
 > as a key to enter ddb.
 
 If it's working when nothing is being printed, you are not using
 the code path in case, but a different one that will continue to work.
 During normal system operation when serial port interrupts are
 enabled, the cnmagic check happens in comintr(), and that's the one
 you are relying on.
 
 The code I'd like to delete is in com_common_putc() and is intended
 for situations such as early startup where interrupts are not yet
 enabled, or late shutdown when they have already been disabled.  If
 you type '+++++' during one of those phases, it is only detected in
 com_common_putc(), and that only works if the kernel happens to print
 a character to the console after each '+'.  It will not work if the
 kernel is deadlocked or in an infinite loop where nothing is printed
 to the console.
 
 > It definitively has some value. There are setups where BREAK can't be
 > sent (e.g. qemu, Dell idrac, ...). 
 
 I'm also using both qemu and idrac.  The qemu bug is supposedly fixed
 (https://bugs.launchpad.net/qemu/+bug/1654137), and the Dell server
 I'm using has a nice NMI button.  But that really only matters for the
 interrupts-disabled case; normally, '+++++' will continue to work.
 
 > I need it.
 
 Sure, but do you need it specifically in the case when serial
 interrupts are disabled and the kernel is not polling for console
 input but is printing something to the console?  That is the only
 case that deleting this code will break.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost