Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

On Thu, 30 Mar 2017, Andrey Chernov wrote:

> On 30.03.2017 8:53, Bruce Evans wrote:
>>> Maybe two will be enough too, I don't check. I just don't need _any_ of
>>> vt lines. What is matter it is that syscons only mode (without any vt)
>>> was recently broken, causing shutdown problems and file system damage
>>> each time. Syscons only mode works for years until you break it recently.
>>
>> Actually, I fixed it not so recently (over the last few months), partly
>> with much older local fixes.
>
> Please commit your fix as soon as possible.

Committing it is what broke things for you.

> vt is broken as designed in
> many aspects (I even mention not all of them),

It is not that bad.  It is much cleaner, but 10-20 times slower and too
simple to have as many features or preserve old features, and I don't
like rewrites than remove or move features.  vt does well to be as
compatible as it is, so only annoys people who use the more arcane
syscons features (I don't use most of them, but find them in regression
tests).  Syscons looks ugly, but much better when you look at the details.

> but from other hand I
> can't allow dirty filesystem (or hang) on each reboot using sc only mode
> as always. It is dangerous, and fsck takes big time. Moreover, using sc
> while keeping vt bloat compiled in the kernel just as the bug workaround
> is the best demotivator for perfectionist.

We don't understand the bug yet.  It might not even be in sc.  Do you only
see problems for shutdown?  The shutdown environment is special for locking.
A hang in sc means that deadlock occurred and sc's new deadlock detection
didn't work.  sc is supposed to either drop the output or do it specially
when it detects deadlock.  Deadlocks can also occur in upper layers of
the console driver, but even more rarely.  I haven't committed fixes for
this yet.  cnputs() detects some deadlocks and handles them by dropping
the output.  This loses WITNESS output when you need it for debugging the
deadlock.

>> The escape sequences in dmesg are very interesting.  You should debug
>> those.
>
> I'll send you them a bit later. Since I don't want vt at all, I don't
> want to debug or fix it, let it die.

:-)

>>> I'll try. thanx. But most dangerous new syscons bug is the first one,
>>> damaging file system on each reboot. I try to go to KDB to debug it, but
>>> seeing that I can't even enter KDB I understand that all that bugs,
>>> including nasty one, are introduced by your syscons changes, it was a
>>> hint to add completely unneeded and unused vt to my kernel config file.
>>
>> It's normal to have a slightly damaged file system after a panic.
>
> In sc only mode I have no kernel panic, i.e panic with trace on console
> or entering KDB. I have silent reboot in the middle or end of shutdown
> sequence or rare dead hang on reboot (which absolutely not acceptable
> for remote machine).

There's not much that sc does which can cause that.  Maybe a wrong
pointer for the frame buffer access in emergency ouput.  I saw reboots
when I broke this during booting.

Check that ddb works before shutdown, or just put a lot of printfs in
the shutdown sequence to see where it stops working.  I usually sprinkle
ddb breakpoints instead of printf()s.  This requires more console code
to work.  Both should work until the final shutdown message from a working
version.

ddb breakpoints don't work properly under SMP.  If all CPUs hit the
same one, then the first one corrupts the state for the others.  Shutdown
should be mostly on a single CPU or with not all CPUs running the shutdown
code, so most won't hit breakpoints in shutdown code, so it is fairly
safe to put them there.

>> You might have entered ddb in a context which used to race or deadlock.
>
> No. I try about 20 times on machine which does nothing and can't enter
> KDB in sc only mode, but got one dead hang instead, when start to repeat
> it too fast.

Even earlier than shutdown, and when booting?

booting with -d gives a simpler environment until sc is completely attached.
Try testing that first.  Also, do tests before mounting file systems so
that nothing needs fsck'ing.

> In vt mode I can enter each time, but there are exit
> problems I already mention.
> I use text mode in sc.
>
>> Strings for function keys:
>> - these are just broken in both sc and vt
>
> I have all function keys working in sc only mode with TERM=cons25 and
> similar ones.
>
>> Pseudographics:
>> - I don't use it enough to see problems in it.  Even finding the unicode
>>   glyph for the block character took me some time.
>
> Even cp437 have it and dialog library use it for all windows frames,
> f.e. all ports config windows use pseudographics if it is available and
> working (replaced by +-| etc poor looking ASCII otherwise).

I call this line-drawing characters for cp437, and use them occasionally,
but I don't know the termcap method for using them very well.

Bruce