On Sat, Jan 06, 2018 at 10:29:23PM +0100, Martin Husemann wrote: > We should have 0 unexpected failures, but the latest run got: > > Failed test cases: > lib/librumphijack/t_config:fdoff, lib/librumphijack/t_tcpip:http, > lib/librumphijack/t_tcpip:nfs, lib/librumphijack/t_tcpip:ssh, > lib/librumphijack/t_vfs:cpcopy, lib/librumphijack/t_vfs:mv_x, > lib/librumphijack/t_vfs:paxcopy, > net/net/t_forwarding:ipforwarding_fastforward_v4, > net/net/t_forwarding:ipforwarding_fastforward_v6, > net/net/t_forwarding:ipforwarding_fragment_v4, > net/net/t_forwarding:ipforwarding_misc, net/net/t_mtudisc6:mtudisc6_basic, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_aesxcbcmac, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacmd5, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacripemd160, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacsha1, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacsha256, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacsha384, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_hmacsha512, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_keyedmd5, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_keyedsha1, > net/ipsec/t_ipsec_tunnel_odd:ipsec_tunnel_v6v4_ah_null, > net/npf/t_npf:npf_state, fs/nfs/t_rquotad:get_nfs_be_1_both, > fs/nfs/t_rquotad:get_nfs_be_1_group, fs/nfs/t_rquotad:get_nfs_be_1_user, > fs/nfs/t_rquotad:get_nfs_le_1_both, fs/nfs/t_rquotad:get_nfs_le_1_group, > fs/nfs/t_rquotad:get_nfs_le_1_user > > > See http://www.netbsd.org/~martin/sparc64-atf for details.
The ipsec failures are gone, but now the tests leave lots of rump_server processes running. Attaching gdb looks like the rump kernel is just idle and listening on one "network" interface - nothing interesting, and they probably could just be halted if the proper socket would still be available. Martin
