Date: Thu, 24 Mar 2016 09:46:50 -0600 From: Ian Lepore <ian@freebsd.org> To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= <trasz@FreeBSD.org>, Alexander Motin <mavbsd@gmail.com> Cc: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= <jean-sebastien.pedron@dumbbell.fr>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r297190 - head/sys/kern Message-ID: <1458834410.1091.54.camel@freebsd.org> In-Reply-To: <20160324150151.GA1277@brick.home> References: <201603221346.u2MDk1XH029623@repo.freebsd.org> <1458662141.1091.16.camel@freebsd.org> <56F29654.8030806@dumbbell.fr> <20160323174537.GA1826@brick.home> <56F3B441.6030602@dumbbell.fr> <20160324134222.GA1442@brick.home> <56F3F52F.9040705@gmail.com> <20160324150151.GA1277@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1458834410.1091.54.camel>