Date: Thu, 22 Feb 2001 05:45: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.010222054502.jhb@FreeBSD.org> In-Reply-To: <3A95152B.5672D46E@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: >> > Dag-Erling Smorgrav wrote: >> > >> >> Maxim Sobolev <sobomax@FreeBSD.ORG> writes: >> >> > It's not an ata specific problem, but rather a problem of all ISA >> >> > devices (I have an ISA based ata controller). >> >> >> >> I don't think it has anything to do with ISA. I've had similar >> >> problems on a PCI-only system (actually, PCI+EISA motherboard with no >> >> EISA cards) with no ATA devices (disks, CD-ROM and streamer are all >> >> SCSI). >> >> >> >> Considering that backing out rev 1.14 of ithread.c eliminates the >> >> panics, and that that revision is supposed to enable interrupt thread >> >> preemption, and that the crashed kernels show signs of stack smashing, >> >> I'd say the cause is probably a bug in the preemption code. >> > >> > Update: the bug is still here, as of -current from 22 Feb. Hovewer, this >> > time >> > it even doesn't let to boot into single-user with following panic message: >> > kernel trap 12 with interrupts disabled >> > panic: mutex sched lock recursed at ../../kern/kern_synch.c:872 >> >> Errrr. That would be something that is leaking sched_lock. Hmm... >> >> Got a backtrace? What is really annoying is that preemption has been in the >> kernel since Feb 1. I just accidentally turned it off in the ithread code >> reorganization and then turned it back on. It was off for a few hours after >> only being on for 2 weeks, and now everyone magically has problems. > > 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. 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'. > -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.010222054502.jhb>