svn commit: r297190 - head/sys/kern

[Warner Losh]

On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore <ian at freebsd.org> wrote:

> 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?
>

PVM isn't an ideal priority to wait at. PWAIT would be better. However,
if the only reason to call pause is run the scheduler after each character,
perhaps a better solution would be to call kern_yield() instead? We could
do that instead of cpu_waitspin() inside of cngetc, but that would break
the debugger's use of it....

Warner