Bug 258649 - kern/sched_ule: Panic in sched_switch (...) at /usr/src/sys/kern/sched_ule.c:2150
Summary: kern/sched_ule: Panic in sched_switch (...) at /usr/src/sys/kern/sched_ule.c:...
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Keywords: crash, needs-qa
Depends on:
Reported: 2021-09-21 00:47 UTC by iron.udjin
Modified: 2021-09-22 16:12 UTC (History)
1 user (show)

See Also:
koobs: maintainer-feedback? (mav)
koobs: mfc-stable13?

KERNEL-config (14.79 KB, text/plain)
2021-09-21 02:33 UTC, iron.udjin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description iron.udjin 2021-09-21 00:47:31 UTC
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

I don't know how to reproduce this bug. I didn't work on the PC when the panic occur.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-09-21 01:14:06 UTC
Thank you for your report. If you are not running a GENERIC kernel, please include the systems kernel configuration as an attachment
Comment 2 iron.udjin 2021-09-21 02:33:56 UTC
Created attachment 228074 [details]
Comment 3 Alexander Motin freebsd_committer 2021-09-22 13:02:23 UTC
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.
Comment 4 iron.udjin 2021-09-22 13:12:50 UTC
(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
Comment 5 Alexander Motin freebsd_committer 2021-09-22 13:26:07 UTC
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.
Comment 6 iron.udjin 2021-09-22 15:38:26 UTC
(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.