Re: propagate_priority panic [backtrace]

On Thursday 13 January 2005 01:48 pm, John Baldwin wrote:
> On Thursday 13 January 2005 11:27 am, Anish Mistry wrote:
> > On Thursday 13 January 2005 01:10 am, Anish Mistry wrote:
> > > 	Not sure if anyone else is seeing this, but I'm pretty sure the
> > > following commit broke my system.  When mysql tries to shutdown I get a
> > > panic in propagate_priority. As well as X freezing when I go to start
> > > it. Actually one of the applictions or the WM causes it to freeze, but
> > > same problem I think but I can't see the console.  Before this
> > > everything worked fine.  I can post the hand transcribed panic
> > > backtrace message tomorrow if anyone is interested since I don't have a
> > > serial port on the machine.
> > > I'm using the 4BSD scheduler with the latest -CURRENT.
> > >
> > > jhb         2004-12-30 20:52:44 UTC
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/kern             sched_4bsd.c sched_ule.c subr_turnstile.c
> > >     sys/sys              proc.h sched.h turnstile.h
> > >
> > >   Revision  Changes    Path
> > >   1.71      +102 -14   src/sys/kern/sched_4bsd.c
> > >   1.144     +77 -20    src/sys/kern/sched_ule.c
> > >   1.151     +120 -71   src/sys/kern/subr_turnstile.c
> > >   1.415     +1 -0      src/sys/sys/proc.h
> > >   1.23      +2 -0      src/sys/sys/sched.h
> > >   1.6       +1 -0      src/sys/sys/turnstile.h
> >
> > Dmesg and kernel config attached.
> > Ok, here is the panic and backtrace:
> > kernel trap 12 with interrupts disabled
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address = 0x4
> > fault code = supervisor read, page not present
> > instruction pointer = 0x8:0xc04d5a4f
> > stack pointer = 0x10:0xcc53bbdc
> > frame pointer = 0x10:0xcc53bbec
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags = resume, IOPL = 0
> >  current process = 628 (mysqld)
> > [thread pid 628 tid 100085 ]
> > Stopped at propagate_priority+0x153: pushl 0x4(%eax)
> > db> tr
> > Tracing pid 628 tid 100085 td 0xc14e4730
> > propagate_priority(c0645cb4,c0645cb0,c15ac650,c14e4730,c14e4730) at
> > propagate_priority+0x153
> > turnstile_wait(c15as650,c15ac650,2,c05f401e,21e) at turnstile_wait+0x1ae
> > _mtx_lock_sleep(c15ac650,c14e4730,0,c05f8604,206) at _mtx_lock_sleep+0x85
> > _mtx_lock_flags(c15ac650,0,c05f8604,206,c15ac650) at _mtx_lock_flags+0x50
> > sleepq_calc_signal_retval(0,0,100,ci4e4730,8476f4c) at
> > sleep_calc_signal_retval+0x2b
> > msleep(c10bb334,c15ac650,168,c05f399a,402) at msleep+0x3eb
> > kse_release(c14e4730,cc53bd14,1,12,296) at kse_release+0x186
> > syscall(2f,2f,2f,8472000,0) at syscall+0x128
> > Xint-x80_syscall() at Xint0x80_syscall+0x1f
> > --- syscall (383, FreeBSD ELF32, kse_release), eip = 0x285851eb, esp =
> > 0x8476f28, ebp = 0x8476f64
>
> Does this still happen if you turn FULL_PREEMPTION off?  Note from NOTES:
>
> # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel
> #         threads.  Its sole use is to expose race conditions and other
> #         bugs during development.  Enabling this option will reduce
> #         performance and increase the frequency of kernel panics by
> #         design.  If you aren't sure that you need it then you don't.
> #         Relies on the PREEMPTION option.  DON'T TURN THIS ON.
Yeah, that was it.
-- 
Anish Mistry