Re: Panic / wedge from bridging tap and vlan
John Klos <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.kernel,gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
> Can you get a stack trace out of this? > > gunzip -c </var/crash/netbsd.1.core.gz >/var/crash/netbsd.1.core > echo bt | crash -M /var/crash/netbsd.1.core > > or maybe just see if dmesg shares the previous boot's output which > might contain the panic and stack trace. dmesg output didn't have anything, but crash gave: Crash version 10.1_STABLE, image version nsfers . WARNING: versions differ, you may not be able to examine this image. crash: _kvm_kvatop(0) Kernel compiled without options LOCKDEBUG. System panicked: lock error: Mutex: mutex_vector_enter,548: locking against myself: lock 0xffffd152aab57080 cpu 0 lwp 0xffffd152a9aeb480 Backtrace from time of crash is available. sljit_modcmd() at 0 crash: _kvm_kvatop(ffffa508562b3ad8) crash: kvm_read(0xffffa508562b3ad8, 8): invalid translation (invalid level 2 PDE) > Obviously yes, this is a garden-variety unintended lock recursion > probably in tap(4) whose locking is hokey, but we need the stack trace > to track it down. > > Do you have steps to reproduce? Because this is used for NAT for Internet, I can't test whenever I'd like. I'm still looking for a window. > Can you take all of that information -- the panic message, the stack > trace, the steps to reproduce -- and file a PR with it so it doesn't > get lost and we can track pullups and close it when done? Certainly. As soon as I can test again, I will. Thanks! John