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