Re: panic: witness_warn head/amd64 _at_r285741 on 1 of 2 machines

From: Eric van Gyzen <eric_at_vangyzen.net>
Date: Tue, 21 Jul 2015 15:21:16 -0500
On 07/21/2015 15:05, David Wolfskill wrote:
> On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
>> ...
>> Indeed, thank you.
>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe083b9c0a70
>> fork_exit() at fork_exit+0x84/frame 0xfffffe083b9c0ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe083b9c0ab0
>> --- trap 0, rip = 0, rsp = 0xfffffe083b9c0b70, rbp = 0 ---
>> suspending ithread with the following locks held:
>> shared rw udpinp (udpinp) r = 3 (0xfffff80010c7d7b0) locked _at_ /usr/src/sys/netinet6/in6_pcb.c:1174
>> panic: witness_warn
>> cpuid = 3
>>
>> So it looks like net swi, leaking some udp6 lock.
> Curiouser and curiouser...  While I'm not taking any special pains to
> avoid building IPv6, I'm not actively actually doing anything with it
> (IPv6), either (for both the failing machine and my laptop).
>
> Once I'm back home, I should be able to poke around in ddb after
> re-creating the panic, if that would be a useful thing for me to do (and
> given some hints as to what to poke).
>
> Naturally, I'm also happy to change bits of sources, rebuild, and
> smoke-test.
>
> A quick check from the SVN update output only shows r285710, r285711, and
> r285740 in the range from (r285685,r285741] -- as the kernel running
> r285685 had no known issues -- that touched sys/netinet6/*.

It's a multicast destination.  Maybe something is using mDNS?

Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?

Eric


Received on Tue Jul 21 2015 - 18:21:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC