OS: stable/13-n247320-f941f0a06298 Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... sched_switch (td=td@entry=0xffffffff80eb4320 <thread0_st>, flags=<optimized out>, flags@entry=260) at /usr/src/sys/kern/sched_ule.c:2150 2150 cpuid = td->td_oncpu = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=td@entry=0xffffffff80eb4320 <thread0_st>, flags=<optimized out>, flags@entry=260) at /usr/src/sys/kern/sched_ule.c:2150 #1 0xffffffff8066f978 in mi_switch (flags=flags@entry=260) at /usr/src/sys/kern/kern_synch.c:542 #2 0xffffffff806b7b87 in sleepq_switch (wchan=wchan@entry=0xffffffff80eb3de8 <proc0>, pri=pri@entry=84) at /usr/src/sys/kern/subr_sleepqueue.c:608 #3 0xffffffff806b809f in sleepq_timedwait (wchan=<unavailable>, pri=<unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:690 #4 0xffffffff8066f145 in _sleep (ident=0xffffffff80eb3de8 <proc0>, lock=<optimized out>, lock@entry=0x0, priority=priority@entry=84, wmesg=0xffffffff809aea29 "swapin", sbt=42949670000, pr=<optimized out>, pr@entry=0, flags=256) at /usr/src/sys/kern/kern_synch.c:219 #5 0xffffffff80897149 in swapper () at /usr/src/sys/vm/vm_swapout.c:752 #6 0xffffffff802c0122 in btext () at /usr/src/sys/amd64/amd64/locore.S:80 (kgdb) I don't know how to reproduce this bug. I didn't work on the PC when the panic occur.
Thank you for your report. If you are not running a GENERIC kernel, please include the systems kernel configuration as an attachment
Created attachment 228074 [details] KERNEL-config
Don't you have exact panic message with instruction pointer fault address, etc? In the line quoted I can think only about td->td_oncpu deteference, but to get there the td pointer on stack was fine just before the context switch, so I see no reason for it to be different after, unless it got corrupted by something else.
(In reply to Alexander Motin from comment #3) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8314ac02 stack pointer = 0x28:0xfffffe00e1b44660 frame pointer = 0x28:0xfffffe014b77fdd0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 0 time = 1632167377 KDB: stack backtrace: #0 0xffffffff806a97c5 at kdb_backtrace+0x65 #1 0xffffffff80664a37 at vpanic+0x187 #2 0xffffffff806648a3 at panic+0x43 #3 0xffffffff80913557 at trap_fatal+0x387 #4 0xffffffff809135af at trap_pfault+0x4f #5 0xffffffff80912c8a at trap+0x26a #6 0xffffffff808ecc4e at calltrap+0x8
Hmm. td_oncpu offset within struct thread is not zero, so my guess about td being NULL is likely wrong, but then I have no clue what is NULL there. Could you disassemble the instructions near the "instruction pointer" value, or at least show more of the stack trace from the panic message for the relative address, so that I could try do build the same kernel ad disassemble myself.
(In reply to Alexander Motin from comment #5) Oh... I've compiled kernel a few times and lost that kernel which had panic :( Let's close this bug and next time I'll save all needed data for debug.