Re: propagate_priority panic [backtrace]

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.

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