.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
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.
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
participants (2)
-
jim.cromie＠gmail.com -
Valdis Klētnieks