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: Valery Ushakov <uwe%stderr.spb.ru@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/55286: Kernel messages cause loss of serial console input
Date: Mon, 25 May 2020 16:47:02 +0300

 Valery Ushakov wrote:
 >  > >  How does your original test end up in a state like that to trigger
 >  > >  this bug?  Kernel message being printed with polled code and steals
 >  > >  the input?
 >  > 
 >  > Yes.
 >  
 >  That would be early autoconfig, before the interrupts are enabled, if
 >  I understand correctly.  That's an important time window, isn't it?
 
 Early autoconfig is one of the cases the read-ahead mechanism appears
 to be intended for, and yes, that's an important time window, but I
 have a hard time imagining a situation where the read-ahead would
 actually be useful.  For example, if the system hangs during early
 autoconfig, read-ahead won't help you break into ddb because a hung
 system will not be printing anything to the console.
 
 And to be clear, the kernel messages that are causing data loss for me
 are not the ones printed during early autoconfig, but ones printed
 after the system has fully booted.
 
 When the read-ahead mechanism was first added in com.c 1.174, it was
 not enabled by default (it was conditional on "options DDB_BREAK_CHAR"),
 but apparently it got enabled by default with the conversion to use
 cnmagic in com.c 1.186.  There is no corresponding mechanism in the
 other serial drivers.
 
 >  > > In that case isn't the right fix to only do readahead when
 >  > > interrupts are disabled?
 >  > 
 >  > That is the right fix if you think the read-ahead code is worth
 >  > keeping, but I don't.  I'm volunteering to remove it; are you
 >  > volunteering to fix it?
 >  
 >  That sounds pretty rude.  I'm asking a question and you are telling me
 >  to shut up unless I'm up to imeediately fixing it.
 
 Sorry, I didn't mean to be rude, it was an honest question and I'm
 certainly not asking you to shut up.  I'm just trying to figure out if
 anyone cares about this code, and if you do care about it, I don't
 think it's unreasonable to ask if you care about it enough to want to
 fix the bugs in it.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost