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

On Monday 12 July 2004 04:22 am, Willem Jan Withagen wrote:
> 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 =

This should be fixed in HEAD as kseq_assign() now calls sched_add_internal() 
which no longer recursively mi_switch()'s.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org