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. vt is broken as designed in
many aspects (I even mention not all of them), 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.
> The escape sequences in dmesg are very interesting. You should debug
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).
> 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. 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
> - 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).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"