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. BruceReceived on Thu Mar 30 2017 - 16:53:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC