svn commit: r297190 - head/sys/kern

[Ian Lepore]

On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napierała wrote:
> On 0324T1609, Alexander Motin wrote:
> > On 24.03.16 15:42, Edward Tomasz Napierała wrote:
> > > On 0324T1032, Jean-Sébastien Pédron wrote:
> > > > On 23/03/2016 18:45, Edward Tomasz Napierala wrote:
> > > > > > So maybe callouts are disabled in this situation. If there
> > > > > > is a way to
> > > > > > detect that, then vt(4) can go back to a "synchronous mode"
> > > > > > where it
> > > > > > refreshes the screen after each typed character, like it
> > > > > > does when ddb
> > > > > > is active.
> > > > > 
> > > > > Looks like that's the case: for some reason the callouts
> > > > > don't work.
> > > > > This trivial hack is a (mostly) working workaround:
> > > > > 
> > > > > Index: svn/head/sys/kern/kern_cons.c
> > > > > =============================================================
> > > > > ======
> > > > > --- svn/head/sys/kern/kern_cons.c	(revision 297210)
> > > > > +++ svn/head/sys/kern/kern_cons.c	(working copy)
> > > > > @@ -430,6 +430,7 @@ cngets(char *cp, size_t size, int
> > > > > visible)
> > > > >  	lp = cp;
> > > > >  	end = cp + size - 1;
> > > > >  	for (;;) {
> > > > > +		pause("meh", 1);
> > > > 
> > > > Could you please explain how this works to me? Does calling
> > > > pause() here
> > > > give a chance to interrupt handlers or other threads of
> > > > running?
> > > 
> > > It looks like it allows the callout to run.  I've did an
> > > experiment
> > > and added a simple callout that printed something each second;
> > > during
> > > the root mount prompt it doesn't get run unless you type '.',
> > > which
> > > calls pause(9).
> > 
> > Kernel threads run with absolute priorities, so if somehow this
> > threads
> > happen to have higher or equal priority then callout thread, or the
> > kernel is built without PREEMPTION, then the last may never be
> > executed
> > until this thread get to sleep or at least call sched_yield().
> 
> The callout's td_priority seems to be 40; the thread running the
> prompt
> is 84, so it's lower.
> 
> I've just noticed another curious thing, though: when you press
> ScrLk,
> the screen gets immediately refreshed; also, pressing arrows works
> just
> the way it should.  In other words, the refresh is broken except for
> the ScrlLk mode, where it works as it should.

Since cngets() is used only by the mountroot prompt and the geli pw
entry, pausing/yielding within the input loop seems like a good idea. 
 It would allow for things like plugging in a usb device and having it
actually appear without having to enter a '.' several times.

It would be nice if the pause were done with pause_sbt() and a shorter
timeout, maybe a millisecond or even 100uS.  Otherwise things like
pasting text at that prompt in a serial console is likely to drop
chars.

Hmmm... speaking of the geli pw prompt... what's the locking situation
there?  Will there be any problems calling pause() from that context?

-- Ian