ctl-alt-esc not taking me to kernel debugger

On my FreeBSD 8 and 9 machines, I can't use ctl-alt-esc from the console to enter the kernel debugger. DDB is compiled into the kernel. It works fine on my 7 and earlier machines.

I looked at kbdcontrol to see if it had been unmapped, but it seems correct:

Code:
kbdcontrol -d | egrep 'debug|^#'
#                                                         alt
# scan                       cntrl          alt    alt   cntrl lock
# code  base   shift  cntrl  shift  alt    shift  cntrl  shift state
# ------------------------------------------------------------------
  001   esc    esc    esc    esc    esc    esc    debug  esc     O
  092   nscr   pscr   debug  debug  nop    nop    nop    nop     O

Searching the kernel configuration for debug like these things:
Code:
config -x /boot/kernel/kernel | egrep -i 'db|deb'
makeoptions     DEBUG=-g
options DDB_CTF
options GDB
options DDB_NUMSYM
options DDB
options KDB_UNATTENDED
options ALT_BREAK_TO_DEBUGGER
options USB_DEBUG
options IEEE80211_DEBUG
options KDB_TRACE
options KDB
device  cardbus

I can use sysctl to get in, but when my shell is locked, I won't be able to do that, of course.

Code:
sudo sysctl debug.kdb.enter=1
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter
[thread pid 68665 tid 100420 ]
Stopped at      0xc097aaea = kdb_enter+0x3a:    movl    $0,0xc1024574 = kdb_why
db> c

I must be missing something that would allow ctl-alt-esc to drop me into the kernel debugger, but what?
 
Check that hw.syscons.kbd_debug variable is set to 1. Read syscons(4)() for more details.
Code:
[CMD]% sysctl -d hw.syscons.kbd_debug[/CMD]
hw.syscons.kbd_debug: enable keyboard debug

Also try to force a panic on the fly, # sysctl debug.kdb.panic=1. Maybe your keyboard will work using this way to enter the kernel debugger.

Moreover, check if you have USB support enabled in the BIOS (is updated?)

See 10.4. On-Line Kernel Debugging Using DDB for more information.
 
I have not manually set that to 0, nor (as can be seen in the first post) built the kernel with the SC_DISABLE_KDBKEY option.

Code:
sysctl hw.syscons.kbd_debug
hw.syscons.kbd_debug: 1

Any other ideas?
 
cpu82 said:
Also try to force a panic on the fly, # sysctl debug.kdb.panic=1. Maybe your keyboard will work using this way to enter the kernel debugger.
Please re-read the original post which describes that this was done and why it is insufficient.
 
Let me ask this: does it work for anyone else? If so, we can start comparing sysctl -a output or something. I just booted a GENERIC kernel - 8/stable as of 20130531. No serial console. Same results.
 
cpu82 said:
Please, show output of # sysctl -a | grep debug.kdb

On one 8.x box:
Code:
debug.kdb.stop_cpus: 1
debug.kdb.alt_break_to_debugger: 1
debug.kdb.break_to_debugger: 0
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb

Another:
Code:
debug.kdb.stop_cpus: 1
debug.kdb.alt_break_to_debugger: 0
debug.kdb.break_to_debugger: 0
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb

9.x:
Code:
debug.kdb.alt_break_to_debugger: 0
debug.kdb.break_to_debugger: 0
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb

ctl-alt-esc works on none of these.
 
And a 7.x box where ctl-alt-esc works.

Code:
debug.kdb.stop_cpus: 1
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb
 
dove said:
Does it work for you?

Sorry I don't tested it.

The only requirement needed to drop into ddb(4)() debugger from the keyboard is compile the kernel with
Code:
options KDB
options DDB

Also, read this thread to fix your problem or at least try if works the panic on-demand by using # sysctl machdep.enable_panic_key=1 and include a 'panic' key combination for your keyboard layout:
Code:
[CMD]% grep -r panic /usr/share/syscons/keymaps/[/CMD]
/usr/share/syscons/keymaps/cs.latin2.qwertz.kbd:  001   esc    esc    esc    esc    esc    esc    debug  panic   O
/usr/share/syscons/keymaps/cs.latin2.qwertz.kbd:  129   esc    esc    esc    esc    esc    esc    debug  panic   O
/usr/share/syscons/keymaps/el.iso07.kbd:  001   esc    esc    esc    esc    esc    esc    debug  panic   O
/usr/share/syscons/keymaps/el.iso07.kbd:  129   esc    esc    esc    esc    esc    esc    debug  panic   O
 
cpu82 said:
Sorry I don't tested it.

Well, can you, please? Go to the main text console, hit ctl-alt-esc. If you get the db> prompt, you can get back to where you were by entering continue (or just c for short). That's assuming you have 'options DDB' in your kernel.

At this point, I'd settle for positive news that it works for someone, but while I can't believe that it doesn't, I have not gotten word from anyone that it works.

cpu82 said:
The only requirement needed to drop into ddb(4)() from the keyboard is compile the kernel with
Code:
options KDB
options DDB

Also, read this thread to fix your problem.

That thread relates to getting the machine to panic. I don't need to do that, although I can do so by using sysctl debug.kdb.enter=1 then panic at the db> prompt (if I had a non-locked shell in which to enter the sysctl command).

For some reason, all my installations after and including 8.x are not doing anything with the mapped 'debug' key. I'm sure this is working for someone, and I likely have a simple config issue on all my 8.x+ boxes, but I haven't heard from any soul that might have it working. If anyone could perform the simple experiment to see if it works, it would be a most appreciated starting point.

For some initial debugging, I looked at the scan codes using this nice utility:
http://hack.org/mc/hacks/kbdscan/

Code:
./kbdscan
Scancode 28 released.
Scancode 29 pressed.
Scancode 56 pressed.
Scancode 1 pressed.
Scancode 1 released.
Scancode 56 released.
Scancode 29 released.
Timeout. Exiting...

That looks reasonable to me (and matches the codes in the defined keyboard map as dumped by kbdcontrol -d).
Same results on a 7.x box (where ctl-alt-esc does take you to the kernel debugger as expected).

Also note that I configured an 8.x box with a serial console and options ALT_BREAK_TO_DEBUGGER (or sysctl debug.kdb.alt_break_to_debugger=1). I can get to the kernel debugger via the serial console using the sequence spelled out for ALT_BREAK_TO_DEBUGGER (i.e., ~ ctl-b). So between sysctl debug.kdb.enter=1 and using the alt break sequence on the serial console, I know that the kernel debugger is enabled and working. It's just the mysterious non-working ctl-alt-esc from the so-called vidconsole that's confounding me.
 
Ok, I'll take a look later. At least, you know that all methods works less <Ctrl+Alt+ESC> key sequence. In the meanwhile, you can use <CR>~^b to enter the debugger.

P.S. For me works fine, you need set # sysctl debug.kdb.break_to_debugger=1. To make permanent the change, add this line in /etc/sysctl.conf:
Code:
debug.kdb.break_to_debugger=1

Related MIBs/OIDs tunable via sysctl(8)():
Code:
[CMD]% sysctl -a | grep debug.kdb[/CMD]
debug.kdb.alt_break_to_debugger: 0
debug.kdb.break_to_debugger: 1
debug.kdb.trap_code: 0
debug.kdb.trap: 0
debug.kdb.panic: 0
debug.kdb.enter: 0
debug.kdb.current: ddb
debug.kdb.available: ddb

My kernel was compiled with the following debugging options:
Code:
makeoptions DEBUG=-g
options KDB
options KDB_TRACE
options DDB

dove said:
Well, can you, please? Go to the main text console, hit ctl-alt-esc. If you get the db> prompt, you can get back to where you were by entering continue (or just c for short). That's assuming you have 'options DDB' in your kernel.

At this point, I'd settle for positive news that it works for someone, but while I can't believe that it doesn't, I have not gotten word from anyone that it works.

Pressing "three-finger salute" to drop into ddb(4)() debugger:
Code:
login: KDB: enter: Break to debugger
[ thread pid 12 tid 100026 ]
Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
db> c
 
cpu82 said:
Ok, I'll take a look later. At least, you know that all methods works less <CTRL+ALT+ESC> key sequence. In the meanwhile, you can use <CR>~^b to enter the debugger.

Yes, I can use the serial debugger for all machines that have a serial console hooked up. Unfortunately, not all do.

I did some more debugging. I added printfs to sys/dev/syscons/syscons.c (see patch at end). After hitting ctl-alt-esc after enabling that debug, I get:

Code:
scgetc: DBG key (0x86).
scgetc: DBG key not disabled, enable: 1.
scgetc: calling kdb_break

So it's obviously getting through syscons correctly, but it's not doing anything once it gets into kdb_break(). I haven't had a chance to dig into that yet.

Code:
--- syscons.c   (revision 251058)
+++ syscons.c   (working copy)
@@ -3348,6 +3348,7 @@
     return 0;
 }
 
+int myscdebug=0;
 /*
  * scgetc(flags) - get character from keyboard.
  * If flags & SCGETC_CN, then avoid harmful side effects.
@@ -3567,9 +3568,17 @@
                break;
 
            case DBG:
+if (myscdebug == 1)
+  printf("scgetc: DBG key (%#x).\n", DBG);
 #ifndef SC_DISABLE_KDBKEY
+if (myscdebug == 1)
+  printf("scgetc: DBG key not disabled, enable: %d.\n", enable_kdbkey);
                if (enable_kdbkey)
+{
+if (myscdebug == 1)
+  printf("scgetc: calling kdb_break\n");
                        kdb_break();
+}
 #endif
                break;
 
dove said:
Code:
scgetc: DBG key (0x86).
scgetc: DBG key not disabled, enable: 1.
scgetc: calling kdb_break

So it's obviously getting through syscons correctly, but it's not doing anything once it gets into kdb_break(). I haven't had a chance to dig into that yet.

After looking at sys/kern/subr_kdb.c, it became obvious what is required:

Code:
sudo sysctl debug.kdb.break_to_debugger=1

(which @cpu82 mentioned today)

That got added between 7.x and 8.x:

Code:
sysctl -d debug.kdb.break_to_debugger
debug.kdb.break_to_debugger: Enable break to debugger

If you don't have
Code:
options BREAK_TO_DEBUGGER
(which I don't want because I don't want stray breaks on the serial port - such as what sometimes happens when the computer on the other end cycles power - to break into the kernel), then that defaults to 0.

So I now have to add the setting of that sysctl to loader.conf or sysctl.conf.

Possibly an unintended consequence of the change between 7.x and 8.x - i.e., the overloading of
Code:
options BREAK_TO_DEBUGGER
(allow break sequence in serial port debugger and enable vidconsole based debugger entry).

If this info was publicized, I missed it. It's not in the man pages or documented in sys/conf/NOTES that BREAK_TO_DEBUGGER has this side effect. It only says:

Code:
# Options for serial drivers that support consoles:
options         BREAK_TO_DEBUGGER       # A BREAK on a serial console goes to
                                        # ddb, if available.
 
Last edited by a moderator:
dove said:
So I now have to add the setting of that sysctl to loader.conf or sysctl.conf.

Please, read my previous post #14 ;)

dove said:
Possibly an unintended consequence of the change between 7.x & 8.x - i.e., the overloading of 'options BREAK_TO_DEBUGGER' (allow break sequence in serial port debugger _and_ enable vidconsole based debugger entry).

You ever notice that isn't necessary compile the kernel with those options, since it can be set via sysctl(8)():
options BREAK_TO_DEBUGGER, options ALT_BREAK_TO_DEBUGGER: allow a break signal or alternative signal on the console to enter the debugger. If the system hangs without a panic, this is a useful way to reach the debugger. Due to the current kernel locking, a break signal generated on a serial console is significantly more reliable at getting into the debugger, and is generally recommended. This option has little or no performance impact.

References:

http://svnweb.freebsd.org/base?view=revision&revision=225203.

http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html.
 
Bah, now there's no way to disable serial breaks from entering the debugger and still allow vidconsole breaks via ctl-alt-esc.
 
Back
Top