Date: Tue, 1 Feb 2011 08:58:12 -0800 From: mdf@FreeBSD.org To: John Baldwin <jhb@freebsd.org>, freebsd-current@freebsd.org Subject: Panic with mca trap Message-ID: <AANLkTik8QJF61gwodmF6iHU4s7y9ORsNZ0H7NW0o8Mxq@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
On a piece of hardware trying to verify basic build tests, we got an
MCA exception that then panic'd the kernel due to WITNESS/INVARIANTS
interaction.
panic @ time 1296563157.510, thread 0xffffff0005540000: blockable
sleep lock (sleep mutex) 128 @ /build/mnt/src/sys/vm/uma_core.c:1872
Stack: --------------------------------------------------
kernel:witness_checkorder+0x7a2
kernel:_mtx_lock_flags+0x81
kernel:uma_zalloc_arg+0x256
kernel:malloc+0xc5
kernel:mca_record_entry+0x30
kernel:mca_scan+0xc9
kernel:mca_intr+0x79
kernel:trap+0x30b
kernel:witness_checkorder+0x66
kernel:_mtx_lock_spin_flags+0xa4
kernel:witness_checkorder+0x2a8
kernel:_mtx_lock_spin_flags+0xa4
kernel:tdq_idled+0xe8
kernel:sched_idletd+0x5b
kernel:fork_exit+0x9b
That's this bit of code in uma_zalloc_arg():
#ifdef INVARIANTS
ZONE_LOCK(zone);
uma_dbg_alloc(zone, NULL, item);
ZONE_UNLOCK(zone);
#endif
I don't know uma(9) well enough to know the best workaround. Clearly
there are times we can be in uma_zalloc_arg() and taking a regular
mutex is not acceptable. But what to do for the uma_dbg_free() call
so it's happy, and whether to guard taking the ZONE lock with M_NOWAIT
or td_critnest > 0 or both is outside my current knowledge.
I don't expect we'll see this panic again any time soon, but it would
be nice to fix the story for WITNESS of when an M_NOWAIT allocation
can be done.
Thanks,
matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTik8QJF61gwodmF6iHU4s7y9ORsNZ0H7NW0o8Mxq>