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 18:13, Bruce Evans wrote:
>> On Thu, 30 Mar 2017, Andrey Chernov wrote:
>>> ...
>>> Finally I have good news and bad news with today's -current:
>>>
>>> 1) It seems your latest commit r316136 fix premature reboot issue.
>>
>> Now I need to know how that helped.  Do you used a non-default mode?
>
> Perhaps it isn't really helped, but just hide the problem, changing some
> another race time parameters.
> I use 80x30 text mode on all screens.

I think it was the sizing.  The non-updated mode is 80x25, so the row
address can be out of bounds in the teken layer.

>>> 2) I still can't enter KDB using Ctrl-Alt-ESC, while booting, after
>>> booting, after login and while shutdown - nothing happens.
>>> boot -d enters KDB normally, but the keyboard sequence handler is
>>> broken, not boot -d.
>>
>> Try "<newline>~b".
>
> What? It just prints \n, new csh prompt and ~b

This takes ALT_BREAK_TO_DEBUGGER.

>> It is an old bug that Ctrl-Alt-ESC (and Ctrl-PrtScr)

GENERIC is even more broken than I remembered.  It doesn't even have
ALT_BREAK_TO_DEBUGGER.  In old versions, this didn't affect the syscons
key.  The key was controlled by the SC_DISABLE_DDBKEY option so defaulted
to enabled.  There was no tunable or sysctl to change the default.  Serial
consoles had a BREAK_TO_DEBUGGER option to control entering the debugger
on a serial line break.  This was not per-device or even per-driver.
Things were broken by conflating serial line BREAKs with entering the
debugger using a breakpoint instruction.

Now there are many sysctls and tunable,s but the basic enable is the
conflated BREAK_TO_DEBUGGER.  This now gives the default setting for
entering kdb using a breakpoint instruction.  Syscons calls the function
kdb_break() which calls kdb_enter() which does the breakpoint instruction.
Arches that don't have such an instruction must have a virtual one.

The default setting can be modified using a tunable or sysctl.  So to
have a chance of the syscons debugger keys working, you first have to
configure this setting, using either:
- BREAK_TO_DEBUGGER in static config file.  This is documented in ddb(4),
   but only for its unbroken meaning for serial consoles
- tunable debug.kdb.break_to_debugger.  This seems to be undocumented
- sysctl debug.kdb.break_to_debugger.  This is documented in ddb(4), but
   only as equivalent to the unbroken BREAK_TO_DEBUGGER.
You have to set the variable using 1 or more of these knobs if you want
the syscons and vt debugger keys to work, but this also enables debugger
entry for serial line breaks and thus breaks the reason for existence of
the unbroken BREAK_TO_DEBUGGER option.  Normally you don't want to enter
the debugger for serial line breaks, since then unplugging the cable or
noise on the cable may enter the debugger, and the option exists to enable
the entry for the rare cases where it is safe.

Next there are the sysctl and vt knobs to set, but these have correct
defaults so are enabled automatically.  SC_DISABLE_DDBKEY is now named
SC_DISABLE_KDBKEY.  It always disabled not only the key, but the code
to enable it.  It actually controls 2 keys and 1 sequence of keys.
When it is not configured, the Ctrl-PtrScr and Ctrl-Alt-ESC keys are
enabled by default.  This can be changed by a sysctl but not by a
tunable.  The sysctl is confusingly named with "kbd" (keyboard) in its
name, while the configu option has KDB (kerel debugger) in its name.
The variable for this also controls the sequences of keys which are
more than ddb keys and are controlled by the ALT_BREAK_TO_DEBUGGER
option and its knobs.

vt doesn't have a static config knob to enable the enables.  It has
a tunable as well as a sysctl.  This sysctl only controls the keys,
not key sequences.  (There may be more than 2 debugger keys.  keymap
allows any key to be a debugger key.)

syscons and/or vt also have knobs to control halt, poweroff, reboot
and panic, bug not suspend.  Many of these are defeated by the
sequences enabled by ALT_BREAK_TO_DEBUGGER.  This is a larger bug
in vt.  In vt, ALT_BREAK_TO_DEBUGGER is limited by the sysctl for
the kdb keys.  If kdb entry is allowed, then there is no point in
disallowing anything since anything can be done using kdb if it has
a backend.

This complexity is not enough to give enough control.  The control
should be per-device.  You might have 1 secure console and 1 insecure
console.  Then enable kdb on at most the secure console.  Or 1 remote
serial console with a good cable and serial console with a bad cable.
Then enable kdb entry for serial line breaks on at most the one with
the good cable.  With per-device control, the 6 knobs for controlling
entry at the kdb level would be sillier, but at least 1 knowb is
needed there to prevent all ddb use.

> Ctrl-PrtScr does nothing too.
>
>> But I think the misconfiguration is the
>> same for vt.
>
> No, Ctrl-Alt-ESC works for vt at every phase of the system lifecycle.

My point it that it is easy to misconfigure the maze of knobs.  However,
since sc used to work and vt still works, you must have something
like BREAK_TO_DEBUGGER configured, so they should both work.

> I use Russian keymap for syscons, but Ctrl, Alt, ESC of course are not
> remapped. I surely remember it works for syscons long time ago.

I didn't change this, except for th usb keyboard some keys near or equal
to Ctrl-PrtScr were broken and I fixed them.  I normally use that instead
of Ctrl-Alt-Esc.

I also rarely enable BREAK_TO_DEBUGGER even for systems that don't have
a serial console, but enable the sysctl dynamically on systems where this
is safe.  This gives the annoying behaviour that the syscons keys don't
work until late in the boot, so I have to type <newline>~b.

Bruce