Date: Thu, 24 Mar 2016 10:15:54 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= <trasz@freebsd.org>, Alexander Motin <mavbsd@gmail.com>, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <jean-sebastien.pedron@dumbbell.fr>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r297190 - head/sys/kern Message-ID: <CANCZdfr9b=2DnVxgpJN=3q634tgMDX3mO8B127or682-5Z35bw@mail.gmail.com> In-Reply-To: <1458834410.1091.54.camel@freebsd.org> 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> <1458834410.1091.54.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore <ian@freebsd.org> wrote:
> On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napiera=C5=82a wrote:
> > On 0324T1609, Alexander Motin wrote:
> > > On 24.03.16 15:42, Edward Tomasz Napiera=C5=82a wrote:
> > > > On 0324T1032, Jean-S=C3=A9bastien P=C3=A9dron 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
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > =3D=3D=3D=3D=3D=3D
> > > > > > --- 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 =3D cp;
> > > > > > end =3D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr9b=2DnVxgpJN=3q634tgMDX3mO8B127or682-5Z35bw>