FreeBSD 10-STABLE/sparc64 panic

Chris Ross cross+freebsd at distal.com
Sun Oct 5 05:04:14 UTC 2014


On Sep 29, 2014, at 00:22 , John-Mark Gurney <jmg at funkthat.com> wrote:
> If you could get a core dump (call doadump) that'd be good, but dumping
> the stack of the tid that held the spinlock too long would be a good
> start..

  Okay.  I have a core dump now, and the stack backtrace (unless I've
done it wrong) is:

spin lock 0xc0ccbdb0 (smp rendezvous) held by 0xfffff8000538c920 (tid 100346) too long
[...]
db> bt 100346
Tracing pid 239 tid 100346 td 0xfffff8000538c920
mi_switch() at mi_switch+0x19c
critical_exit() at critical_exit+0x9c
spinlock_exit() at spinlock_exit+0x8
turnstile_chain_unlock() at turnstile_chain_unlock+0x6c
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x9c
bge_init() at bge_init+0x5c
ether_ioctl() at ether_ioctl+0x70
M_PLIMIT() at M_PLIMIT+0x8
db>

  Let me know if you'd like me to provide any details from core.txt.0,
and I'll probably start looking around inside with kgdb tomorrow.  I'm
not sure I'll know how to identify a problem causing a lock problem
though.

  Thanks.

                - Chris




More information about the freebsd-sparc64 mailing list