Re: page fault/panic: mi_switch: switch in a critical section

From: "Kris Kennaway" <kris_at_obsecurity.org>

> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x104
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc058a8cf
> stack pointer           = 0x10:0xdcb34cc4
> frame pointer           = 0x10:0xdcb34cec
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 50 (schedcpu)
> trap number             = 12
> panic: page fault
>
> syncing disks, buffers remaining... panic: mi_switch: switch in a critical
section
>
> addr2line says the panic was in kern/sched_4bsd.c:327
>
>                                 /*
>                                  * The kse slptimes are not touched in wakeup
>                                  * because the thread may not HAVE a KSE.
>                                  */
>                                 if (ke->ke_state == KES_ONRUNQ) {
>                                         awake = 1;
>                                         ke->ke_flags &= ~KEF_DIDRUN;
> --->                            } else if ((ke->ke_state == KES_THREAD) &&
>                                     (TD_IS_RUNNING(ke->ke_thread))) {
>                                         awake = 1;
>
> gdb -k got confused and couldn't make anything out of the backtrace.

That is only a few lines from what is bugging me already quite a few days on
amd64. Note that it only occurs with me when I'm running SMP. Disableing ACPI
also disables the second CPU, and the box stays up for as long as I leave it on.
I have not tried running with sched_bsd.

panic: mi_switch: called by old code
cpuid = 1;
Stack backtrace:
backtrace() at backtrace+0x17
panic() at panic+0x1d2
mi_switch() at mi_switch+0xcf
maybe_preempt() at maybe_preempt+0xd0
sched_add() at sched_add+0x2dd
kseq_assign() at kseq_assign+0x45
sched_choose() at sched_choose+0x5b
choosethread() at choosethread+0x3d
sched_switch() at sched_switch+0x126
mi_switch() at mi_switch+0x23b
ast() at ast+0x35f
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (0), rip = 0x20069afdc, rsp = 0x7fffffffe8a8, rbp =
0x7fffffffe8e0 ---
Debugger("panic")
timeout stopping cpus
Stopped at      Debugger+0x4d:  xchgl   %ebx,0x27d091

The dump gives me, from a huge garbled stack with soemthing like 72 frames:

 #26 0xffffffff8025b073 in panic (fmt=0xffffffffb4076940 "\205ðA\200ÿÿÿÿ\001")
     at /home2/src/sys/kern/kern_shutdown.c:543
#27 0xffffffff802619cb in mi_switch (flags=2, newtd=0xffffff007b566240)
     at /home2/src/sys/kern/kern_synch.c:306
#28 0xffffffff80260964 in maybe_preempt (td=0xffffff007b566240)
     at /home2/src/sys/kern/kern_switch.c:529
#29 0xffffffff8026cf41 in sched_add (td=0xffffff007b566240)
     at /home2/src/sys/kern/sched_ule.c:1633
#30 0xffffffff8026b591 in kseq_assign (kseq=0x0)
     at /home2/src/sys/kern/sched_ule.c:647
#31 0xffffffff8026cbcb in sched_choose ()
     at /home2/src/sys/kern/sched_ule.c:1516
#32 0xffffffff802602bd in choosethread ()
     at /home2/src/sys/kern/kern_switch.c:142
#33 0xffffffff8026c296 in sched_switch (td=0xffffff005abe96c0, newtd=0x0)
     at /home2/src/sys/kern/sched_ule.c:1168
#34 0xffffffff80261b37 in mi_switch (flags=-1274582128, newtd=0x0)
     at /home2/src/sys/kern/kern_synch.c:355
---Type <return> to continue, or q <return> to quit---
#35 0xffffffff8027c4ef in ast (framep=0xffffffffb4076c40)
     at /home2/src/sys/kern/subr_trap.c:245
#36 0xffffffff8039a84d in Xfast_syscall ()
     at /home2/src/sys/amd64/amd64/exception.S:259

So with guidance I can retreive needed data......

--WjW