Date: Fri, 1 Jun 2001 16:55:51 +0100 From: David Taylor <davidt@yadt.co.uk> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' & panic Message-ID: <20010601165551.A12821@gattaca.yadt.co.uk> In-Reply-To: <Pine.BSF.4.21.0105312300070.25846-100000@besplex.bde.org>; from bde@zeta.org.au on Thu, May 31, 2001 at 23:26:24 %2B1000 References: <20010530203509.A789@gattaca.yadt.co.uk> <Pine.BSF.4.21.0105312300070.25846-100000@besplex.bde.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Thu, 31 May 2001, Bruce Evans wrote: > On Wed, 30 May 2001, David Taylor wrote: > > > When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm > > madness version first, then tried a version cvsuped today), I reliably get > > lots of: > > > > kernel trap 12 with interrupts disabled > > > > messages on the console (one every 5-10 seconds, when the ircd is reasonably > > loaded). > > This is because ast() calls addupc_task() with sched_lock held. > addupc_task() calls copyin() and copyin() sometimes traps to fault in the > profiling buffer. > > This seems to be just a bug in ast(). userret() is missing the bug. > Untested fix: > > --- > Index: trap.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v > retrieving revision 1.189 > diff -u -1 -r1.189 trap.c > --- trap.c 2001/05/23 22:58:09 1.189 > +++ trap.c 2001/05/31 13:09:02 > @@ -1285,5 +1341,6 @@ > mtx_lock(&Giant); > - mtx_lock_spin(&sched_lock); > addupc_task(p, p->p_stats->p_prof.pr_addr, > p->p_stats->p_prof.pr_ticks); > + mtx_lock_spin(&sched_lock); > + /* XXX why not unlock Giant? */ > } > --- I tested this, and it works! No more `kernel trap 12 with interrupts disabled' messages, and also, thankfully, no more panics. (Related to this anyway, I'm still getting freelist corruption related things). > I think this is caused by the same bug. > > "kernel trap <almost any> with interrupts disabled" > > should be fatal (the case of trap 12 (only) _is_ fatal in my version), > but the kernel attempts to fix the problem and continue. This sort > of worked when things were locked by disabling interrupts. Now, things > may be locked by a spinlock as well as by disabling interrupts, and > the corresponding fixup would be to release the spinlock. But this > is more obviously wrong. > > Bruce > Yeah, just trying to cover up the problem and march on usually doesn't work out very well in computing.. or anywhere else, really.. -- David Taylor davidt@yadt.co.uk [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7F7sHfIqKXSsJ/xERAnqzAJwOhdT7CD38+hHAztghaQH6XsqE9QCgisH0 9WatArxiMmZPkwk/V2APGp0= =eAgj -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010601165551.A12821>