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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.