Re: svn commit: r297190 - head/sys/kern

[Bruce Evans]

On Fri, 25 Mar 2016, Edward Tomasz [utf-8] Napiera?~Ba wrote:


On 0325T0809, Bruce Evans wrote:

On Thu, 24 Mar 2016, Edward Tomasz [utf-8] Napiera?~Ba wrote:


On 0324T1015, Warner Losh wrote:

On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore  wrote:


On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napiera??a wrote:

[...]
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.


Serial consoles should work already due to their use of grab/ungrab, and
this use being easier to get right for serial consoles.

I still see problems with sio.  It doesn't use grab/ungrab yet, although
grab/ungrab were designed by me in ~1988 for my serial drivers older than
sio.

Note that cngetc() was broken by multiple console support in ~2000.
Before that, cngetc() waited with device interrupts disabled.  This
prevented the interrupt handler eating the interrupts.  Now it polls
and is still broken since its polling loop is not wrapped by
grab/ungrab.  cngets() was broken before multiple consoles, but was
fairly usable.  You just had to type reasonably slowly so that the
characters arrive in the low-level polling loop while device interrupts
are disabled.


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


Console drivers can't block or depend on timeouts.  Perhaps cngets() can,
because it is only called in simple contexts, but the simple contexts
make it especially easy for it to work using the same synchronous i/o that
is needed in more complicated contexts.


Note that this particular problem doesn't seem to be caused by the console
driver as such.  One of the things I've tried was to add a callout that
prints out something each second, and then enter an infinite loop.  The
assumption is, the loop in proc0 should get preempted by the callout.
For some reason this doesn't happen.


But it is a bug for (low level) console drivers to ever wait.  They should
assert that they don't.


I think we should first try to figure out why this doesn't work in the first
place.

Basically, even though the interrupts are running, scheduler seems to be ok,
and the thread that's calling this has a lower priority than the callouts
thread, it can't be preempted.  This doesn't seem to be caused by vt(4);
with syscons the callouts don't get called either (it just doesn't break
the echo in this case).  To demonstrate the problem you can add add
a callout that calls printf each second and then does an infinite loop.


cngets() is even correctly wrapped by cngrab()/cnungrab().  This is supposed
to put the console driver in a special synchronous mode for the duration of
the grabbing.  (Console drivers still need to be reentrant, so that they
can do i/o when the grabbed section is reentered for ddb or another
non-maskable trap.)  syscons and vt have similar too-simple grab handlers
which start with a screen switch in the !cold case.  This should refresh
the screen and/or switch it to special low-level console screen(s).


So basically, what you're suggesting is to make cngrab() set a flag that
switches vt, and its video drivers, into a mode that doesn't use any kind
of callouts, right?  That seems like a proper solution, but still doesn't
explain the root of the problem here.


Yes.  They already increment an xx_grabbed counter, but only use it to
do nothing for nested grabs.  (Doing nothing is too simple.)


Screen switching in ddb is noticeably more broken for vt than for syscons.
Indeed, it just doesn't work in vt (except for the initial switch to vty0).
This might be related.


Yeah; I remember some strange problems with keyboard state when
entering/leaving ddb.


Both syscons and vt hang fairly quickly in -current for the ddb command
's/p,1000'.  vt just hangs sooner.  I think I fixed this in an old version
of syscons, but I only tested the fix on systems with not as many CPUs as
the one that shows the most problems.  Printing after every 

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierała]

On 0325T0809, Bruce Evans wrote:
> On Thu, 24 Mar 2016, Edward Tomasz [utf-8] Napiera�~Ba wrote:
> 
> > On 0324T1015, Warner Losh wrote:
> >> On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore  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
> 
> Console drivers can't block or depend on timeouts.  Perhaps cngets() can,
> because it is only called in simple contexts, but the simple contexts
> make it especially easy for it to work using the same synchronous i/o that
> is needed in more complicated contexts.

Note that this particular problem doesn't seem to be caused by the console
driver as such.  One of the things I've tried was to add a callout that
prints out something each second, and then enter an infinite loop.  The
assumption is, the loop in proc0 should get preempted by the callout.
For some reason this doesn't happen.

> > I think we should first try to figure out why this doesn't work in the first
> > place.
> >
> > Basically, even though the interrupts are running, scheduler seems to be ok,
> > and the thread that's calling this has a lower priority than the callouts
> > thread, it can't be preempted.  This doesn't seem to be caused by vt(4);
> > with syscons the callouts don't get called either (it just doesn't break
> > the echo in this case).  To demonstrate the problem you can add add
> > a callout that calls printf each second and then does an infinite loop.
> 
> cngets() is even correctly wrapped by cngrab()/cnungrab().  This 

Re: svn commit: r297190 - head/sys/kern

[Bruce Evans]

On Thu, 24 Mar 2016, Edward Tomasz [utf-8] Napiera?~Ba wrote:


On 0324T1015, Warner Losh wrote:

On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore  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


Console drivers can't block or depend on timeouts.  Perhaps cngets() can,
because it is only called in simple contexts, but the simple contexts
make it especially easy for it to work using the same synchronous i/o that
is needed in more complicated contexts.


I think we should first try to figure out why this doesn't work in the first
place.

Basically, even though the interrupts are running, scheduler seems to be ok,
and the thread that's calling this has a lower priority than the callouts
thread, it can't be preempted.  This doesn't seem to be caused by vt(4);
with syscons the callouts don't get called either (it just doesn't break
the echo in this case).  To demonstrate the problem you can add add
a callout that calls printf each second and then does an infinite loop.


cngets() is even correctly wrapped by cngrab()/cnungrab().  This is supposed
to put the console driver in a special synchronous mode for the duration of
the grabbing.  (Console drivers still need to be reentrant, so that they
can do i/o when the grabbed section is reentered for ddb or another
non-maskable trap.)  syscons and vt have similar too-simple grab handlers
which start with a screen switch in the !cold case.  This should refresh
the screen and/or switch it to special low-level console screen(s).

Screen switching in ddb is noticeably more broken for vt than for syscons.
Indeed, it just doesn't work in vt (except for the initial switch to vty0).
This might be related.

Bruce___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierała]

On 0324T1015, Warner Losh wrote:
> On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore  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

I think we should first try to figure out why this doesn't work in the first
place.

Basically, even though the interrupts are running, scheduler seems to be ok,
and the thread that's calling this has a lower priority than the callouts
thread, it can't be preempted.  This doesn't seem to be caused by vt(4);
with syscons the callouts don't get called either (it just doesn't break
the echo in this case).  To demonstrate the problem you can add add
a callout that calls printf each second and then does an infinite loop.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Warner Losh]

On Thu, Mar 24, 2016 at 9:46 AM, Ian Lepore  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
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: 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

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierała]

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.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Alexander Motin]

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().

-- 
Alexander Motin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierała]

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).

And, for the record, https://reviews.freebsd.org/D5724 doesn't fix
the problem.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Jean-Sébastien Pédron]

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?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierala]

On 0323T1412, Jean-Sébastien Pédron wrote:
> On 22/03/2016 16:55, Ian Lepore wrote:
> > On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> >> Author: trasz
> >> Date: Tue Mar 22 13:46:01 2016
> >> New Revision: 297190
> >> URL: https://svnweb.freebsd.org/changeset/base/297190
> >>
> >> Log:
> >>   Wait for root mount tokens before showing the root mount prompt.
> >>   This restores the pre-r290196 behaviour, eliminating the need to manually
> >>   press '.' a couple of times to get USB to finish probing.
> >>   
> >>   Note that there's still something wrong with the console (character
> >>   echoing doesn't quite work), and there's also a reported problem with
> >>   BHyVe, but those two don't seem related to the problem above.
> > 
> > Just a datapoint on the echoing... it works fine on a serial console,
> > it's been years since I've seen glitches at the mountroot prompt.  So
> > the problem may be in vt or kbdmux.
> 
> I confirm this is a known issue with vt(4): it uses a callout to refresh
> the screen, but for reasons unknown to me, the callout is not called
> anymore on mountroot prompt. I tried to debug this but failed. Since
> then, I didn't have time to work on this again.
> 
> 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);
c = cngetc() & 0177;
switch (c) {
case '\n':

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Jean-Sébastien Pédron]

On 22/03/2016 16:55, Ian Lepore wrote:
> On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
>> Author: trasz
>> Date: Tue Mar 22 13:46:01 2016
>> New Revision: 297190
>> URL: https://svnweb.freebsd.org/changeset/base/297190
>>
>> Log:
>>   Wait for root mount tokens before showing the root mount prompt.
>>   This restores the pre-r290196 behaviour, eliminating the need to manually
>>   press '.' a couple of times to get USB to finish probing.
>>   
>>   Note that there's still something wrong with the console (character
>>   echoing doesn't quite work), and there's also a reported problem with
>>   BHyVe, but those two don't seem related to the problem above.
> 
> Just a datapoint on the echoing... it works fine on a serial console,
> it's been years since I've seen glitches at the mountroot prompt.  So
> the problem may be in vt or kbdmux.

I confirm this is a known issue with vt(4): it uses a callout to refresh
the screen, but for reasons unknown to me, the callout is not called
anymore on mountroot prompt. I tried to debug this but failed. Since
then, I didn't have time to work on this again.

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.

I will repeat this in the bug report.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierala]

On 0322T2113, Rick Macklem wrote:
> Ian Lepore wrote:
> > On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> > > Author: trasz
> > > Date: Tue Mar 22 13:46:01 2016
> > > New Revision: 297190
> > > URL: https://svnweb.freebsd.org/changeset/base/297190
> > > 
> > > Log:
> > >   Wait for root mount tokens before showing the root mount prompt.
> > >   This restores the pre-r290196 behaviour, eliminating the need to 
> > > manually
> > >   press '.' a couple of times to get USB to finish probing.
> > >   
> > >   Note that there's still something wrong with the console (character
> > >   echoing doesn't quite work), and there's also a reported problem with
> > >   BHyVe, but those two don't seem related to the problem above.
> > 
> > Just a datapoint on the echoing... it works fine on a serial console,
> > it's been years since I've seen glitches at the mountroot prompt.  So
> > the problem may be in vt or kbdmux.
> > 
> When I had a console character echo problem (not serial), changing the
> clock source to RTC fixed it.

Just for the record, doing "set kern.eventtimer.timer=RTC" in loader(8)
prompt didn't change anything wrt character echo.

I've submitted a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208239

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Warner Losh]

On Tue, Mar 22, 2016 at 7:50 PM, Ian Lepore  wrote:

> On Tue, 2016-03-22 at 19:28 -0600, Warner Losh wrote:
> > On Tue, Mar 22, 2016 at 7:13 PM, Rick Macklem 
> > wrote:
> >
> > > Ian Lepore wrote:
> > > > On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> > > > > Author: trasz
> > > > > Date: Tue Mar 22 13:46:01 2016
> > > > > New Revision: 297190
> > > > > URL: https://svnweb.freebsd.org/changeset/base/297190
> > > > >
> > > > > Log:
> > > > >   Wait for root mount tokens before showing the root mount
> > > > > prompt.
> > > > >   This restores the pre-r290196 behaviour, eliminating the need
> > > > > to
> > > manually
> > > > >   press '.' a couple of times to get USB to finish probing.
> > > > >
> > > > >   Note that there's still something wrong with the console
> > > > > (character
> > > > >   echoing doesn't quite work), and there's also a reported
> > > > > problem with
> > > > >   BHyVe, but those two don't seem related to the problem above.
> > > >
> > > > Just a datapoint on the echoing... it works fine on a serial
> > > > console,
> > > > it's been years since I've seen glitches at the mountroot prompt.
> > > >   So
> > > > the problem may be in vt or kbdmux.
> > > >
> > > When I had a console character echo problem (not serial), changing
> > > the
> > > clock source to RTC fixed it.
> > >
> >
> > I fixed this for the UART code a while ago in r260890. Maybe a
> > similar fix
> > is needed here? Basically, is the data being consumed by the
> > interrupt
> > handler before we can poll-read it...
> >
> > Warner
>
> Your cngrab fixes were only for uart?  Or was it some other fix?
>

Yes, I only fixed uart. But the cngrab interface is generic. I didn't have
issues with the console code at the time, but there's been two
elephants of change in that code since then, including a rewrite.
Perhaps some of that change broke what was working at the time
and needs to be fixed. Perhaps it was working only by accident, like
the UARTs were for years before I made the fix (well, working on and
off... something broke them a bit before I made the change). mountroot>
is so little used that things can break there and be broken for years
before people notice.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Ian Lepore]

On Tue, 2016-03-22 at 19:28 -0600, Warner Losh wrote:
> On Tue, Mar 22, 2016 at 7:13 PM, Rick Macklem 
> wrote:
> 
> > Ian Lepore wrote:
> > > On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> > > > Author: trasz
> > > > Date: Tue Mar 22 13:46:01 2016
> > > > New Revision: 297190
> > > > URL: https://svnweb.freebsd.org/changeset/base/297190
> > > > 
> > > > Log:
> > > >   Wait for root mount tokens before showing the root mount
> > > > prompt.
> > > >   This restores the pre-r290196 behaviour, eliminating the need
> > > > to
> > manually
> > > >   press '.' a couple of times to get USB to finish probing.
> > > > 
> > > >   Note that there's still something wrong with the console
> > > > (character
> > > >   echoing doesn't quite work), and there's also a reported
> > > > problem with
> > > >   BHyVe, but those two don't seem related to the problem above.
> > > 
> > > Just a datapoint on the echoing... it works fine on a serial
> > > console,
> > > it's been years since I've seen glitches at the mountroot prompt.
> > >   So
> > > the problem may be in vt or kbdmux.
> > > 
> > When I had a console character echo problem (not serial), changing
> > the
> > clock source to RTC fixed it.
> > 
> 
> I fixed this for the UART code a while ago in r260890. Maybe a
> similar fix
> is needed here? Basically, is the data being consumed by the
> interrupt
> handler before we can poll-read it...
> 
> Warner

Your cngrab fixes were only for uart?  Or was it some other fix?

-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Warner Losh]

On Tue, Mar 22, 2016 at 7:13 PM, Rick Macklem  wrote:

> Ian Lepore wrote:
> > On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> > > Author: trasz
> > > Date: Tue Mar 22 13:46:01 2016
> > > New Revision: 297190
> > > URL: https://svnweb.freebsd.org/changeset/base/297190
> > >
> > > Log:
> > >   Wait for root mount tokens before showing the root mount prompt.
> > >   This restores the pre-r290196 behaviour, eliminating the need to
> manually
> > >   press '.' a couple of times to get USB to finish probing.
> > >
> > >   Note that there's still something wrong with the console (character
> > >   echoing doesn't quite work), and there's also a reported problem with
> > >   BHyVe, but those two don't seem related to the problem above.
> >
> > Just a datapoint on the echoing... it works fine on a serial console,
> > it's been years since I've seen glitches at the mountroot prompt.  So
> > the problem may be in vt or kbdmux.
> >
> When I had a console character echo problem (not serial), changing the
> clock source to RTC fixed it.
>

I fixed this for the UART code a while ago in r260890. Maybe a similar fix
is needed here? Basically, is the data being consumed by the interrupt
handler before we can poll-read it...

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Rick Macklem]

Ian Lepore wrote:
> On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> > Author: trasz
> > Date: Tue Mar 22 13:46:01 2016
> > New Revision: 297190
> > URL: https://svnweb.freebsd.org/changeset/base/297190
> > 
> > Log:
> >   Wait for root mount tokens before showing the root mount prompt.
> >   This restores the pre-r290196 behaviour, eliminating the need to manually
> >   press '.' a couple of times to get USB to finish probing.
> >   
> >   Note that there's still something wrong with the console (character
> >   echoing doesn't quite work), and there's also a reported problem with
> >   BHyVe, but those two don't seem related to the problem above.
> 
> Just a datapoint on the echoing... it works fine on a serial console,
> it's been years since I've seen glitches at the mountroot prompt.  So
> the problem may be in vt or kbdmux.
> 
When I had a console character echo problem (not serial), changing the
clock source to RTC fixed it.

rick

> -- Ian
> 
> 
> 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r297190 - head/sys/kern

[Ian Lepore]

On Tue, 2016-03-22 at 13:46 +, Edward Tomasz Napierala wrote:
> Author: trasz
> Date: Tue Mar 22 13:46:01 2016
> New Revision: 297190
> URL: https://svnweb.freebsd.org/changeset/base/297190
> 
> Log:
>   Wait for root mount tokens before showing the root mount prompt.
>   This restores the pre-r290196 behaviour, eliminating the need to manually
>   press '.' a couple of times to get USB to finish probing.
>   
>   Note that there's still something wrong with the console (character
>   echoing doesn't quite work), and there's also a reported problem with
>   BHyVe, but those two don't seem related to the problem above.

Just a datapoint on the echoing... it works fine on a serial console,
it's been years since I've seen glitches at the mountroot prompt.  So
the problem may be in vt or kbdmux.

-- Ian

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r297190 - head/sys/kern

[Edward Tomasz Napierala]

Author: trasz
Date: Tue Mar 22 13:46:01 2016
New Revision: 297190
URL: https://svnweb.freebsd.org/changeset/base/297190

Log:
  Wait for root mount tokens before showing the root mount prompt.
  This restores the pre-r290196 behaviour, eliminating the need to manually
  press '.' a couple of times to get USB to finish probing.
  
  Note that there's still something wrong with the console (character
  echoing doesn't quite work), and there's also a reported problem with
  BHyVe, but those two don't seem related to the problem above.
  
  MFC after:1 month
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/vfs_mountroot.c

Modified: head/sys/kern/vfs_mountroot.c
==
--- head/sys/kern/vfs_mountroot.c   Tue Mar 22 13:32:34 2016
(r297189)
+++ head/sys/kern/vfs_mountroot.c   Tue Mar 22 13:46:01 2016
(r297190)
@@ -89,6 +89,7 @@ __FBSDID("$FreeBSD$");
 static int parse_mount(char **);
 static struct mntarg *parse_mountroot_options(struct mntarg *, const char *);
 static int sysctl_vfs_root_mount_hold(SYSCTL_HANDLER_ARGS);
+static void vfs_mountroot_wait(void);
 static int vfs_mountroot_wait_if_neccessary(const char *fs, const char *dev);
 
 /*
@@ -488,6 +489,8 @@ parse_dir_ask(char **conf)
char *mnt;
int error;
 
+   vfs_mountroot_wait();
+
printf("\nLoader variables:\n");
parse_dir_ask_printenv("vfs.root.mountfrom");
parse_dir_ask_printenv("vfs.root.mountfrom.options");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"