On 15.11.2014 05:42, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 > -0800: >> Well.. It looks like IPSEC is still broken in head... I can get >> pings to pass, but now on IPv4 transport mode, I can't get syn's >> to be sent out... I see the output packet in the protocol stats, >> but no packets go out the interface... >> >> If you could provide me w/ a simple set of spdadd commands, or the >> dumps from the machine, that'd be good... >> >> Hmm.... I just ran ping -f so I could generate some traffic, and >> managed to get a: panic: System call sendto returing with kernel >> FPU ctx leaked >> >> I'll look into this... > > I just verified that this happens on a clean HEAD _at_ r274534: FreeBSD > 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > jmg_at_carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC > amd64 > > No modifications, nothing, and I got the same panic: panic: System > call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack > backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at > vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at > kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at > amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD > ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = > 0x7ffffffee5c0 --- KDB: enter: panic > > So, it's clearly not my patch that is causing the issue... > > Andrey, can you verify that you do not receive the same panic w/o my > patches? 11.0-CURRENT r274469 after 20 minutes and # netstat -sp esp | grep out 424360710 packets out 17823149820 bytes out can't reproduce the panic. I'll update and retry on fresh CURRENT. My ipsec.conf: add 10.9.12.25 10.9.12.15 esp 15701 -E rijndael-cbc "1111111111111111" ; spdadd 192.168.0.0/16 192.168.0.0/16 any -P out ipsec esp/tunnel/10.9.12.25-10.9.12.15/default; aesni.ko is loaded and pmcstat shows that it is in use: PMC: [INSTR_RETIRED_ANY] Samples: 128994 (100.0%) , 7506 unresolved Key: q => exiting... %SAMP IMAGE FUNCTION CALLERS 13.5 kernel cpu_search_highest cpu_search_highest:11.3 sched_idletd:2.2 4.6 kernel __mtx_unlock_flags ip_output:0.8 key_checkrequest:0.6 ip_rtaddr:0.6 key_allocsp:0.5 4.0 kernel __mtx_lock_flags _key_freesp:0.8 rtalloc1_fib:0.8 key_checkrequest:0.6 3.5 kernel cpu_search_lowest cpu_search_lowest:2.6 sched_pickcpu:0.9 3.2 kernel bcopy m_copydata:1.7 m_copyback:0.7 3.2 libc.so.7 bsearch 3.0 kernel __rw_rlock rtalloc1_fib 2.5 kernel uma_zalloc_arg malloc:0.8 crypto_getreq:0.6 2.4 kernel uma_zfree_arg m_freem:1.0 free:0.7 2.2 kernel bzero uma_zalloc_arg 2.1 kernel _rw_runlock_cookie rtalloc1_fib:0.7 arpresolve:0.5 2.0 kernel rn_match rtalloc1_fib 1.7 kernel __mtx_lock_sleep __mtx_lock_flags 1.7 kernel ip_output ipsec_process_done:1.1 ip_forward:0.6 1.4 kernel critical_exit spinlock_exit 1.3 kernel spinlock_exit ether_nh_input 1.3 kernel ixgbe_rxeof ixgbe_msix_que 1.2 kernel malloc 1.2 kernel critical_enter 1.2 kernel ixgbe_xmit ixgbe_mq_start_locked 1.1 aesni.ko aesni_encrypt_cbc aesni_process 1.1 kernel esp_output ipsec4_process_packet 1.1 kernel key_allocsp ipsec_getpolicybyaddr 1.0 kernel __mtx_lock_spin_flag 1.0 kernel in_cksumdata in_cksum_skip 1.0 kernel free 1.0 kernel ip_input netisr_dispatch_src 1.0 kernel ether_nh_input netisr_dispatch_src 1.0 kernel bounce_bus_dmamap_lo bus_dmamap_load_mbuf_sg 0.9 kernel _mtx_lock_spin_cooki pmclog_reserve 0.8 kernel m_copydata 0.8 kernel ipsec4_process_packe ip_ipsec_output -- WBR, Andrey V. Elsukov
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC