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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC