CONFIG_KDB_KEYBOARD

CONFIG_KDB_KEYBOARD

[jim.cromie]

.config - Linux/x86 5.8.0-rc7 Kernel Configuration
 > Kernel hacking > Generic Kernel Debugging Instruments > KGDB: kernel debugger
KGDB_KDB: keyboard as input device
\  │ CONFIG_KDB_KEYBOARD:
                                    │ KDB can use a PS/2 type keyboard
for an input device
 │

I notice this excludes USB keyboard.

does this mean it doesnt work early enough to be useful for early panics etc ?

what does it mean for a panic right after starting 2nd CPUs ?

[    0.402982] smp: Bringing up secondary CPUs ...
[    0.403553] smp: Brought up 1 node, 1 CPU
[    0.404226] smpboot: Max logical packages: 1
[    0.404552] smpboot: Total of 1 processors activated (5184.01 BogoMIPS)
[    0.406816] devtmpfs: initialized
[    0.408058] x86/mm: Memory block size: 128MB
[    0.416908] kthreadd invoked oom-killer:
gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO),
order=0, oom_score_adj=0
[    0.417551] CPU: 0 PID: 2 Comm: kthreadd Not tainted
5.8.0-rc7-00023-gede6954dc460-dirty #101
[    0.418541] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.13.0-2.fc32 04/01/2014
[    0.418541] Call Trace:
[    0.418541]  dump_stack+0x91/0xc8
[    0.418541]  dump_header+0x105/0x710
[    0.418541]  out_of_memory+0x63a/0x760
[    0.418541]  ? get_page_from_freelist+0x10b/0x950

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: CONFIG_KDB_KEYBOARD

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1153 bytes --]

On Mon, 03 Aug 2020 11:30:05 -0600, jim.cromie@gmail.com said:

> I notice this excludes USB keyboard.
>
> does this mean it doesnt work early enough to be useful for early panics etc?

Very early panics and hangs are always a royal pain to deal with.  There's no
really good way to deal with it, because let's face it - if the operating
system hasn't gotten its act together yet, it's going to have a hard time
talking to you unless you can run it in a virtual machine or similar that has
the tooling to allow you to usefully explore the memory entrails.

> what does it mean for a panic right after starting 2nd CPUs ?

> [    0.416908] kthreadd invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GF
> gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0
> [    0.417551] CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.8.0-rc7-00023-gede6954dc460-dirty #101
> [    0.418541] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014

Hitting the OOM killer on PID 2 in QEMU sounds suspiciously like you started
QEMU and specified an insanely small memory space for the image.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: CONFIG_KDB_KEYBOARD

[jim.cromie]

On Mon, Aug 3, 2020 at 11:48 AM Valdis Klētnieks
<valdis.kletnieks@vt.edu> wrote:
>
> On Mon, 03 Aug 2020 11:30:05 -0600, jim.cromie@gmail.com said:
>
> > I notice this excludes USB keyboard.
> >
> > does this mean it doesnt work early enough to be useful for early panics etc?
>
> Very early panics and hangs are always a royal pain to deal with.  There's no
> really good way to deal with it, because let's face it - if the operating
> system hasn't gotten its act together yet, it's going to have a hard time
> talking to you unless you can run it in a virtual machine or similar that has
> the tooling to allow you to usefully explore the memory entrails.
>
> > what does it mean for a panic right after starting 2nd CPUs ?
>
> > [    0.416908] kthreadd invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GF
> > gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0
> > [    0.417551] CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.8.0-rc7-00023-gede6954dc460-dirty #101
> > [    0.418541] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
>
> Hitting the OOM killer on PID 2 in QEMU sounds suspiciously like you started
> QEMU and specified an insanely small memory space for the image.
>

Ok, I will look for the relevant docs.

FWIW, Im using virtme, in case youre familiar with it.
it is using QEMU/KVM, virtme is my 1st foray into this kernel magic.

If you see the relevant setting, please shout out.

[jimc@frodo build-v2]$ krun -q=-s -q=-S
./.virtme_mods/lib/modules/0.0.0
/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly -device
virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -fsdev
local,id=virtfs5,path=/usr/lib/python3.8/site-packages/virtme/guest,security_model=none,readonly
-device virtio-9p-pci,fsdev=virtfs5,mount_tag=virtme.guesttools
-machine accel=kvm:tcg -watchdog i6300esb -cpu host -parallel none
-net none -echr 1 -serial none -chardev
stdio,id=console,signal=off,mux=on -serial chardev:console -mon
chardev=console -vga none -display none -kernel
./arch/x86/boot/bzImage -append
'virtme_link_mods=/home/jimc/projects/lx/linux.git/build-v2/.virtme_mods/lib/modules/0.0.0
earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 26 cols 113 iutf8" TERM=xterm-256color
rootfstype=9p rootflags=version=9p2000.L,trans=virtio,access=any
raid=noautodetect ro nokaslr dynamic_debug.verbose=3 module.dyndbg=+pm
init=/bin/sh -- -c "mount -t tmpfs run /run;mkdir -p
/run/virtme/guesttools;/bin/mount -n -t 9p -o
ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools
/run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init"' -s -S
Wrong EFI loader signature.
early console in extract_kernel
input_data: 0x00000000027f33a8
input_len: 0x00000000009eed25
output: 0x0000000001000000
output_len: 0x00000000021afbb4
kernel_total_size: 0x0000000001e2c000
needed_size: 0x0000000002200000
trampoline_32bit: 0x000000000009d000


KASLR disabled: 'nokaslr' on cmdline.


Decompressing Linux... Parsing ELF... No relocation needed... done.
Booting the kernel.
[    0.000000] Linux version 5.8.0-rc7-00024-gb86020ac9dfd
(jimc@frodo) (gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1), GNU ld
version 2.34-4.fc32) #21 SMP Mon Aug 3 13:35:05 MDT 2020
[    0.000000] Command line:
virtme_link_mods=/home/jimc/projects/lx/linux.git/build-v2/.virtme_mods/lib/modules/0.0.0
earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 26 cols 113 iutf8" TERM=xterm-256color
rootfstype=9p rootflags=version=9p2000.L,trans=virtio,access=any
raid=noautodetect ro nokaslr dynamic_debug.verbose=3 module.dyndbg=+pm
init=/bin/sh -- -c "mount -t tmpfs run /run;mkdir -p
/run/virtme/guesttools;/bin/mount -n -t 9p -o
ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools
/run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init"
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
...

btw, Id be happy to post the code here, hopefully fix it with advice/help,
and eventually submit it.

so thanks in advance ;-)
Jim

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies