John Baldwin wrote: > Unfortunately it hung trying to dump, so all I have is the stack trace from > DDB. This is recent HEAD running stress2 > > panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry _at_ ../../1 > do you know what lock it was talking about? rt_check_fib is not really any different from what it was before in general the multi routing table code shouldn't add any locking paths that were not already present. I think there is some hint of a problem in the interaction of mrt and arp however so I think I need to re-visit that code.. (It's all flushed out of my brain-cache at the moment). > cpuid = 1 > KDB: enter: panic > [thread pid 14025 tid 100928 ] > Stopped at kdb_enter+0x3d: movq $0,0x435054(%rip) > db> tr > Tracing pid 14025 tid 100928 td 0xffffff0003773360 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x14b > _mtx_lock_flags() at _mtx_lock_flags > _mtx_lock_flags() at _mtx_lock_flags+0xc3 > rt_check_fib() at rt_check_fib+0x1ea > arpresolve() at arpresolve+0x77 > ether_output() at ether_output+0x180 > ip_output() at ip_output+0xb4f > udp_send() at udp_send+0x47d > sosend_dgram() at sosend_dgram+0x1fa > soo_write() at soo_write+0x30 > dofilewrite() at dofilewrite+0x7a > kern_writev() at kern_writev+0x52 > write() at write+0x4d > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (4, FreeBSD ELF64, write), rip = 0x80071cb7c, rsp = > 0x7fffffffe628,- > db> c > Uptime: 1h39m18s > Physical memory: 2038 MB > Dumping 263 MB:pid 14025 (udp), uid 26840, was killed: exceeded maximum CPU > limt > pid 14099 (udp), uid 26840, was killed: exceeded maximum CPU limit > pid 14100 (udp), uid 26840, was killed: exceeded maximum CPU limit >Received on Fri Aug 29 2008 - 19:35:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC