panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Eric van Gyzen]

On 07/21/2015 15:21, Eric van Gyzen wrote:
> 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?

Blurf.  "I wonder if" it's a multicast destination.  (I need more chocolate.)

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20150721/3fe6db9f/attachment.bin>