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 @ 
>> /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?


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to