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_spin(&sched_lock);
> addupc_task(p, p->p_stats->p_prof.pr_addr,
> + 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.
Yeah, just trying to cover up the problem and march on usually doesn't work
out very well in computing.. or anywhere else, really..