Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Sep 2004 17:14:42 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Ken Smith <kensmith@cse.Buffalo.EDU>
Cc:        Kris Kennaway <kris@obsecurity.org>
Subject:   Re: 5.3-RELEASE TODO
Message-ID:  <200409021714.42674.jhb@FreeBSD.org>
In-Reply-To: <20040902155947.GA12006@electra.cse.Buffalo.EDU>
References:  <200407151424.i6FEOdoq060881@fledge.watson.org> <20040715220447.GA32888@xor.obsecurity.org> <20040902155947.GA12006@electra.cse.Buffalo.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 02 September 2004 11:59 am, Ken Smith wrote:
> > * ---
> > 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.
>
> The code you quote above hasn't changed recently but a few kse related
> fixes have gone in recently if I recall correctly.  Is this one still
> biting you?

This seems to be a symptom of the same bug that causes runq corruption when 
PREEMPTION is turned on.  I think it might have triggered on SMP w/o 
PREEMPTION turned on however.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409021714.42674.jhb>