Date: Thu, 22 Feb 2001 07:54:02 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Maxim Sobolev <sobomax@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: <XFMail.010222075402.jhb@FreeBSD.org> In-Reply-To: <3A953037.780CDCAB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Also, hsa the backtrace changed at all? If not, then you may have commented out the wrong enable_intr(). :) > -Maxim -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010222075402.jhb>