From owner-freebsd-current Thu May 31 6:28:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id F128237B423; Thu, 31 May 2001 06:28:08 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA11125; Thu, 31 May 2001 23:27:58 +1000 Date: Thu, 31 May 2001 23:26:24 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: David Taylor Cc: freebsd-current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' & panic In-Reply-To: <20010530203509.A789@gattaca.yadt.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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? */ } --- > One thing I got with ircd-hybrid-7 (when very heavily loaded with lots of > clones), which I _couldnt_ replicate with the test program (probably because > it wasn't very heavily loaded) was a panic: > ... > kernel trap 12 with interrupts disabled > panic: mutex sched lock recursed at /usr/src/sys/kern/kern_sync.c:858 > Debugger("panic") > Stopped at Debugger+0x45: pushl %ebx > db> t > Debugger(c02fa51b) at Debugger+0x45 > panic(c02f9684,c031d2a9,c02fad20,35a,282) at panic+0x70 > _mtx_assert(c03a7120,9,c02fad20,35a,282) at _mtx_assert+0x6c > mi_switch(d1748420,38,d1748420,e,d17c9e90) at mi_switch+0x25 > ithread_schedule(c26e3180,1) at ithread_schedule+0x165 > sched_ithd(e) at sched_ithd+0x3d > Xresume14() at Xresume14+0x7 > -- interrupt, eip = 0xc02c8a18, esp = 0xd17c9ed8, ebp = 0xd17c9f04 -- > trap(d1740018,d1740010,8080010,d17c9f72,85d02ec) at trap+0x94 > calltrap() at calltrap+0x5 > -- trap 0xc, eip = 0xc02c71f5, esp = 0xd17c9f4c, ebp = 0xd17c9f74 -- > generic_copyin(d1748420,809073d,1) at generic_copyin+0x39 > ast(d17c9fa8) at ast+0x318 > doreti_ast() at doreti_ast+0x6 I think this is caused by the same bug. "kernel trap 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message