Andreas Gustafsson wrote:
Yes, in the case of my test runs at least. On the monthly details
page you can see that the number of test failures increased from
2 to 10 with dyoung's commits of 2011.05.03.17.44.30 through
2011.05.03.18.28.46, and did not decrease when in6_pcb.c 1.114 was
committed on 2011.05.04.01.45.48
Interesting. I've only had two successful test runs since the 17:44:30
commit (got bit by the %x vs %zx build breaks in vtw.c). The first of these
was with sources from 2011-05-03 18:20:01 and had only three test failures,
none of which were network-related as far as I can tell.
1. lib/libc/stdlib/t_strtod : strtod_inf
2. lib/libm/t_infinity : infinity_long_double
3. lib/librumpclient/t_fd : sigio
The second run was _after_ the in6_pcb.c fix, with sources from 2011-05-04
05:20:01, and it has a total of nine failures (new ones flagged with *)
1. * fs/nfs/t_rquotad : get_nfs_be_1_user
2. lib/libc/stdlib/t_strtod : strtod_inf
3. * lib/libevent/t_event : kqueue
4. * lib/libevent/t_event : select
5. lib/libm/t_infinity : infinity_long_double
6. lib/librumpclient/t_fd : sigio
7. * lib/librumphijack/t_tcpip : http
8. * rump/rumpnet/t_shmif : crossping
9. * syscall/t_getrusage : getrusage_utime_back
Of the new ones, the nfs and libevent entries are common failures (there are
some interesting timing issues in qemu on amd!)