Date: Thu, 22 Feb 2001 21:12:36 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Dag-Erling Smorgrav <des@ofug.org>, current@FreeBSD.org, "Alexander N. Kabaev" <ak03@gte.com> Subject: Re: A possible bug in the interrupt thread preemption code [Was: Message-ID: <3A9564A2.463789C3@FreeBSD.org> References: <XFMail.010222075402.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 22-Feb-01 Maxim Sobolev wrote: > > John Baldwin wrote: > > > >> On 22-Feb-01 Maxim Sobolev wrote: > >> > >> >> > Here it is (from DDB): > >> >> > panic(c027de93,c0297409,c027f878,368,80286) > >> >> > _mtx_assert(c02ea000,9,c027f878,368,80286) > >> >> > mi_switch(c32c5da0,3,c02cea44,c357be98) > >> >> > ithread_schedule(c0747c00,1) > >> >> > sched_ithd(e) > >> >> > Xresume14() > >> >> > --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 --- > >> >> > trap(18, 10, 10,c01597b6,20) > >> >> > calltrap() > >> >> > --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 --- > >> >> > sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94) > >> >> > ithread_loop(c0747c00,c357bfa8) > >> >> > fork_exit(c0146cbc,c0747c00,c357bfa8) > >> >> > fork_trampoline() > >> >> > >> >> *sigh* This is why enabling interrupts in trap() is such a bad idea. If > >> >> we > >> >> get a trap in the scheduler, then lots of bad crap starts to happen > >> >> because > >> >> we > >> >> can get an interrupt while we are in a trap. :( Can you compile your > >> >> kernel > >> >> with > >> >> INVARIANTS on though, as I think the kernel should've panic'd earlier if > >> >> it > >> >> is > >> >> doing what I think it is doing. > >> > > >> > It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB. > >> > >> Hmm, ouch, you do'nt want MUTEX_DEBUG, that'll slow your system to a crawl. > > > > It doesn't really matter, because system can't even boot into single-user due > > to > > panic. > > > >> >> Also, if you are feeling industrious, edit > >> >> sys/i386/i386/trap.c and comment out the enable_intr() call near the > >> >> beginning > >> >> of the trap() function right after the printf for 'kernel trap %d with > >> >> interrupts disabled'. > >> > > >> > Ok, I'll try so. > >> > > >> > -Maxim > >> > >> It will still panic, just hopefully a better panic. > > > > I did understand that, but the panic I see after the change is exactly the > > same as > > before. Any other ideas? > > A recursive sched_lock? Erm, well, stick these options in your kernel config: > > options KTR > options KTR_EXTEND > options KTR_COMPILE=KTR_LOCK > options KTR_MASK=KTR_MASK > > Then when it panics, use the 'show ktr' command to list the mutex operations up > until that point. Hopefully you can see where it is grabbing sched lock the > first time and then not releasing it. Got the following: 724: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 723: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 722: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 721: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 680: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 679: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 569: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 568: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 546: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 545: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 544: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 543: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 515: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 366: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 365: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 317: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 254: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 253: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 252: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 251: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 194: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 193: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 182: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 181: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 46: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 1020: REL (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:438 1019: GOT (spin) sched lock [0xc030c820] r=0 at ../../kern/kern_clock.c:350 -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9564A2.463789C3>