Re: FreeBSD CI Weekly Report 2020-04-12
On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to 2020-04-12. During this period, we have: * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% (+14.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) Test case status (on 2020-04-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | -- | | | | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) | | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) | | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) | | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) | | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) | | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * The test env now loads the required module for firewall tests. * New armv7 job is added (to replace armv6 one): * FreeBSD-head-armv7-testvm The images are available at https://artifact.ci.freebsd.org FreeBSD-head-armv7-test is ready but needs test env update. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ * See console log for the error details. ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.netpfil.common.forward.ipf_v4 * sys.netpfil.common.forward.ipfw_v4 * sys.netpfil.common.forward.pf_v4 * sys.netpfil.common.tos.ipfw_tos * sys.netpfil.common.tos.pf_tos * sys.netpfil.pf.forward.v4 I can’t actually reproduce this failure in my test VM, but with the ci test VM I can reproduce the problem. It’s not related to pf, because the sanity check ping we do before we set up pf already fails. Or rather pft_ping.py sends an incorrect packet, because `ping` does get the packet to go where it’s supposed to go. Scapy seems to fail to find the source IP address, so we get this: 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, seq 0, length 12 I have a vague recollection that we’ve seem this problem before, but I can’t remember what we did about it. In all likelihood most of the other netpfil tests fail for exactly the same reason. Best regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD CI Weekly Report 2020-04-12
On 15 Apr 2020, at 15:34, Kristof Provost wrote: On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to 2020-04-12. During this period, we have: * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% (+14.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) Test case status (on 2020-04-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | -- | | | | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) | | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) | | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) | | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) | | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) | | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * The test env now loads the required module for firewall tests. * New armv7 job is added (to replace armv6 one): * FreeBSD-head-armv7-testvm The images are available at https://artifact.ci.freebsd.org FreeBSD-head-armv7-test is ready but needs test env update. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ * See console log for the error details. ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.netpfil.common.forward.ipf_v4 * sys.netpfil.common.forward.ipfw_v4 * sys.netpfil.common.forward.pf_v4 * sys.netpfil.common.tos.ipfw_tos * sys.netpfil.common.tos.pf_tos * sys.netpfil.pf.forward.v4 I can’t actually reproduce this failure in my test VM, but with the ci test VM I can reproduce the problem. It’s not related to pf, because the sanity check ping we do before we set up pf already fails. Or rather pft_ping.py sends an incorrect packet, because `ping` does get the packet to go where it’s supposed to go. Scapy seems to fail to find the source IP address, so we get this: 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, seq 0, length 12 I have a vague recollection that we’ve seem this problem before, but I can’t remember what we did about it. In all likelihood most of the other netpfil tests fail for exactly the same reason. The problem appears to be that /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing the `netstat -rnW` output. For reference, this is the output in the test VM: Routing tables Internet: DestinationGatewayFlags Nhop#Mtu Netif Expire 127.0.0.1 link#2 UH 1 16384lo0 192.0.2.0/24 link#4 U 2 1500epair0a 192.0.2.1 link#4 UHS 1 16384lo0 198.51.100.0/24192.0.2.2 UGS 3 1500epair0a Internet6: Destination Gateway Flags Nhop#MtuNetif Expire ::/96 ::1 UGRS 4 16384 lo0 ::1 link#2UH 1 16384 lo0 :::0.0.0.0/96 ::1 UGRS 4 16384 lo0 fe80::/10 ::1 UGRS 4 16384 lo0 fe80::%lo0/64 link#2U 3 16384 lo0 fe80::1%lo0 link#2UHS 2 16384 lo0 fe80::%epair0a/64 link#4U 5 1500 epair0a fe80::3d:9dff:fe7c:d70a%epair0a link#4UHS 1 16384 lo0 fe80::%epair1a/64 link#6U 6 1500
Re: FreeBSD CI Weekly Report 2020-04-12
On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost wrote: > > The problem appears to be that > /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing > the `netstat -rnW` output. > Shouldn't scapy use the libxo output of netstat to mitigate this regression ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD CI Weekly Report 2020-04-12
On 15 Apr 2020, at 16:49, Olivier Cochard-Labbé wrote: On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost wrote: The problem appears to be that /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing the `netstat -rnW` output. Shouldn't scapy use the libxo output of netstat to mitigate this regression ? That would likely help, yes. I’m going to leave that decision up to the maintainer, because I’m not going to do the work :) I’m also not sure how “stable” we want the netstat output to be. Best regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: sleeping thread. Possibly related to drm and swapping.
Just recieved this panic. I am using drm-legacy-kmod-g20200306 on a Dell Latitude D530 laptop. The panic occurred as I was starting libreoffice. Suggestions? mobile dumped core - see /var/crash/vmcore.2 Wed Apr 15 09:22:07 PDT 2020 FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r359179M: Sat Mar 21 13:46:12 PDT 2020 root@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 panic: sleeping thread Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: Sleeping thread (tid 100154, pid 1072) owns a non-sleepable lock KDB: stack backtrace of thread 100154: sched_switch(22209e00,104) at sched_switch+0x173/frame 0x220e04c8 mi_switch(104) at mi_switch+0x13e/frame 0x220e0500 sleepq_switch(2239ecac,e8e0,2239ecac,2239ec2c,220e0574,...) at sleepq_switch+0xe3/frame 0x220e0518 sleepq_timedwait(2239ecac,50) at sleepq_timedwait+0x2a/frame 0x220e0540 _sleep(2239ecac,2239ec2c,50,fcc13e,e8e0,13,0,0,100) at _sleep+0x176/frame 0x220e0574 swap_pager_getpages_locked(1,0,0) at swap_pager_getpages_locked+0x6b5/frame 0x220e05dc swap_pager_getpages(2239ec2c,220e0640,1,0,0) at swap_pager_getpages+0x40/frame 0x220e05fc vm_pager_get_pages(2239ec2c,220e0640,1,0,0,...) at vm_pager_get_pages+0x26/frame 0x220e0624 i915_gem_wire_page(0,220e0677,2239ec2c,0,2239ec3c,...) at i915_gem_wire_page+0x6b/frame 0x220e0650 i915_gem_object_get_pages_gtt(8af4700,2189a000,102,22569800,1000,...) at i915_gem_object_get_pages_gtt+0xb0/frame 0x220e0684 i915_gem_object_pin(8af4700,0,0,0,22779000,...) at i915_gem_object_pin+0x3ca/frame 0x220e06c0 i915_gem_execbuffer_reserve_object(5f,4f2a700,8af2b5c,18e59a5c,22779110,...) at i915_gem_execbuffer_reserve_object+0x64/frame 0x220e06e8 i915_gem_execbuffer_reserve(22209e00,22779110,20,24da9600,0,...) at i915_gem_execbuffer_reserve+0x1e8/frame 0x220e0720 i915_gem_do_execbuffer(220e0b70,28f2a000,11,fff3,22569800,...) at i915_gem_do_execbuffer+0x845/frame 0x220e09a8 i915_gem_execbuffer2(22569800,220e0b70,22505200,69,21ca3410,...) at i915_gem_execbuffer2+0xf6/frame 0x220e09c8 drm_ioctl(1847fa00,c0406469,220e0b70,7,22209e00) at drm_ioctl+0x31b/frame 0x220e09f4 devfs_ioctl(220e0a60) at devfs_ioctl+0x99/frame 0x220e0a2c VOP_IOCTL_APV(10c0614,220e0a60) at VOP_IOCTL_APV+0x18/frame 0x220e0a40 vn_ioctl(218a3070,c0406469,220e0b70,22291d00,22209e00) at vn_ioctl+0x13a/frame 0x220e0af0 devfs_ioctl_f(218a3070,c0406469,220e0b70,22291d00,22209e00) at devfs_ioctl_f+0x2c/frame 0x220e0b18 kern_ioctl(22209e00,a,c0406469,220e0b70) at kern_ioctl+0x1ea/frame 0x220e0b50 sys_ioctl(22209e00,2220a090,220e0cdc,22209e00,3206,...) at sys_ioctl+0xd4/frame 0x220e0c08 syscall(220e0ce8,3b,3b,3b,ffbfeb90,...) at syscall+0x1fd/frame 0x220e0cdc Xint0x80_syscall() at 0xffc033f9/frame 0x220e0cdc --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0xffc05f6c, esp = 0xffc07fe8, ebp = 0xffbfeb54 --- panic: sleeping thread cpuid = 0 time = 1586967582 KDB: stack backtrace: db_trace_self_wrapper(aee2f1,1,21935470,1828d8e4,a0f170,...) at db_trace_self_wrapper+0x2a/frame 0x1828d8b8 kdb_backtrace(2,80,22209e00,8a5fa00,c,...) at kdb_backtrace+0x2e/frame 0x1828d918 vpanic(1002aba,1828d954,1828d954,1828d968,c7a399,...) at vpanic+0x11f/frame 0x1828d934 panic(1002aba,c,8a5fa00,17ffe000,8a5fa00,...) at panic+0x14/frame 0x1828d948 propagate_priority(0,246,0,0,22209e00,...) at propagate_priority+0x239/frame 0x1828d968 turnstile_wait(8a5fa00,22209e00,0) at turnstile_wait+0x285/frame 0x1828d984 __rw_wlock_hard(2239ec3c,22209e00) at __rw_wlock_hard+0x40d/frame 0x1828da00 swp_pager_async_iodone(18ef1000,0,157000,,18eec000,...) at swp_pager_async_iodone+0x294/frame 0x1828da24 bufdone(18ef1000) at bufdone+0x60/frame 0x1828da64 swapgeom_done(18eec000) at swapgeom_done+0x44/frame 0x1828da7c g_io_deliver(18eec000,0) at g_io_deliver+0x1e7/frame 0x1828dab8 g_std_done(2eae4b58) at g_std_done+0x78/frame 0x1828dacc g_io_deliver(2eae4b58,0) at g_io_deliver+0x1e7/frame 0x1828db08 g_std_done(246ee108) at g_std_done+0x78/frame 0x1828db1c g_io_deliver(246ee108,0) at g_io_deliver+0x1e7/frame 0x1828db58 g_disk_done(2ce1fd68,28,18f5e000,0,0,...) at g_disk_done+0x10a/frame 0x1828db8c adadone(8bfd880,2cddc800) at adadone+0x86e/frame 0x1828dbcc xpt_done_process(25a51,8ad8e68e,e7c6bed,18058000,0,...) at xpt_done_process+0x3fd/frame 0x1828dbf8 xpt_done_direct(2cddc800) at xpt_done_direct+0x39/frame 0x1828dc1c ahci_ch_intr_direct(18058000) at ahci_ch_intr_direct+0xe6/frame 0x1828dc48 ahci_intr_one(17fab454) at ahci_intr_one+0x23/frame 0x1828dc5c ithread_loop(8e23ea0,1828dce8) at ithread_loop+0x1a0/frame 0x1828dcb8 fork_exit(be4b10,8e23ea0,1828dce8,0,0,...) at fork_exit+0x66/frame 0x1828dcd4 fork_trampoline() at 0xffc0340e/frame 0x1828dcd4 --- kthread start KDB: enter: panic 0x00c1e379 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:393 393 savectx(&dumppcb); (kgdb) #0 0x00c1e379 in doadump (textdump=0) at /usr/src/sy
Re: FreeBSD CI Weekly Report 2020-04-12
15.04.2020, 15:10, "Kristof Provost" : > On 15 Apr 2020, at 15:34, Kristof Provost wrote: >> On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: >>> (Please send the followup to freebsd-testing@ and note Reply-To is >>> set.) >>> >>> FreeBSD CI Weekly Report 2020-04-12 >>> === >>> >>> Here is a summary of the FreeBSD Continuous Integration results for >>> the period >>> from 2020-04-06 to 2020-04-12. >>> >>> During this period, we have: >>> >>> * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld >>> and >>> buildkernel (GENERIC and LINT) were executed on aarch64, amd64, >>> armv6, >>> armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, >>> sparc64 architectures for head, stable/12, stable/11 branches. >>> * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% >>> (+14.1) >>> exception) were executed on amd64, i386, riscv64 architectures for >>> head, >>> stable/12, stable/11 branches. >>> * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) >>> >>> Test case status (on 2020-04-12 23:59): >>> | Branch/Architecture | Total | Pass | Fail | Skipped >>> | >>> | --- | - | -- | | >>> | >>> | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) >>> | >>> | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) >>> | >>> | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) >>> | >>> | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) >>> | >>> | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) >>> | >>> | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) >>> | >>> >>> (The statistics from experimental jobs are omitted) >>> >>> If any of the issues found by CI are in your area of interest or >>> expertise >>> please investigate the PRs listed below. >>> >>> The latest web version of this report is available at >>> https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is >>> available at >>> https://hackmd.io/@FreeBSD-CI/ , any help is welcome. >>> >>> ## News >>> >>> * The test env now loads the required module for firewall tests. >>> >>> * New armv7 job is added (to replace armv6 one): >>> * FreeBSD-head-armv7-testvm >>> The images are available at https://artifact.ci.freebsd.org >>> FreeBSD-head-armv7-test is ready but needs test env update. >>> >>> ## Failing jobs >>> >>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ >>> * See console log for the error details. >>> >>> ## Failing tests >>> >>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ >>> * local.kyua.integration.cmd_about_test.topic__authors__installed >>> * sys.netipsec.tunnel.empty.v4 >>> * sys.netipsec.tunnel.empty.v6 >>> * sys.netpfil.common.forward.ipf_v4 >>> * sys.netpfil.common.forward.ipfw_v4 >>> * sys.netpfil.common.forward.pf_v4 >>> * sys.netpfil.common.tos.ipfw_tos >>> * sys.netpfil.common.tos.pf_tos >>> * sys.netpfil.pf.forward.v4 >> I can’t actually reproduce this failure in my test VM, but with the >> ci test VM I can reproduce the problem. >> It’s not related to pf, because the sanity check ping we do before >> we set up pf already fails. >> Or rather pft_ping.py sends an incorrect packet, because `ping` does >> get the packet to go where it’s supposed to go. >> >> Scapy seems to fail to find the source IP address, so we get this: >> >> 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, >> seq 0, length 12 >> >> I have a vague recollection that we’ve seem this problem before, but >> I can’t remember what we did about it. >> >> In all likelihood most of the other netpfil tests fail for exactly the >> same reason. > > The problem appears to be that > /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing > the `netstat -rnW` output. Thanks for the analysis! Sorry for breaking the tests. I should have run tests with userland changes installed. I'll revert the netstat output changes shortly to unbreak the tests. Re longer-term: parsing textual output for the routes does not seem to be a good habit, especially in these days. Structural (libxo) approach looks better, however I guess this will make scapy unusable on the routers with full-view. So far light-weight sysctl-route reader looks like the best option. What do you folks think? > > For reference, this is the output in the test VM: > > Routing tables > > Internet: > Destination Gateway Flags Nhop# Mtu Netif > Expire > 127.0.0.1 link#2 UH 1 16384 lo0 > 192.0.2.0/24 link#4 U 2 1500 epair0a > 192.0.2.1 link#4 UHS 1 16384 lo0 > 198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a > > Internet6: > Destination Gateway Flags > Nhop# Mtu Netif Expire > ::/96 ::1 UGRS > 4 16384 lo0 > ::1 link#2 UH > 1 16384 lo0 > :::0.0.0.0/96 ::1 UGRS > 4
Re: FreeBSD CI Weekly Report 2020-04-12
Hi Alexandar, I have changed net/scapy to apply a simple patch as a workaround for the time being. ports@r531789 should do the trick for now. So no need to revert. Kind Regards, Moin > On 16 Apr, 2020, at 02:21, Alexander V. Chernikov wrote: > > > > 15.04.2020, 15:10, "Kristof Provost" : >> On 15 Apr 2020, at 15:34, Kristof Provost wrote: >>> On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to 2020-04-12. During this period, we have: * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% (+14.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) Test case status (on 2020-04-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | -- | | | | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) | | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) | | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) | | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) | | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) | | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * The test env now loads the required module for firewall tests. * New armv7 job is added (to replace armv6 one): * FreeBSD-head-armv7-testvm The images are available at https://artifact.ci.freebsd.org FreeBSD-head-armv7-test is ready but needs test env update. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ * See console log for the error details. ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.netpfil.common.forward.ipf_v4 * sys.netpfil.common.forward.ipfw_v4 * sys.netpfil.common.forward.pf_v4 * sys.netpfil.common.tos.ipfw_tos * sys.netpfil.common.tos.pf_tos * sys.netpfil.pf.forward.v4 >>> I can’t actually reproduce this failure in my test VM, but with the >>> ci test VM I can reproduce the problem. >>> It’s not related to pf, because the sanity check ping we do before >>> we set up pf already fails. >>> Or rather pft_ping.py sends an incorrect packet, because `ping` does >>> get the packet to go where it’s supposed to go. >>> >>> Scapy seems to fail to find the source IP address, so we get this: >>> >>> 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, >>> seq 0, length 12 >>> >>> I have a vague recollection that we’ve seem this problem before, but >>> I can’t remember what we did about it. >>> >>> In all likelihood most of the other netpfil tests fail for exactly the >>> same reason. >> >> The problem appears to be that >> /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing >> the `netstat -rnW` output. > Thanks for the analysis! > > Sorry for breaking the tests. > I should have run tests with userland changes installed. > > I'll revert the netstat output changes shortly to unbreak the tests. > Re longer-term: parsing textual output for the routes does not seem to be a > good habit, especially in these days. > Structural (libxo) approach looks better, however I guess this will make > scapy unusable on the routers with full-view. > > So far light-weight sysctl-route reader looks like the best option. > What do you folks think? > >> >> For reference, this is the output in the test VM: >> >> Routing tables >> >> Internet: >> Destination Gateway Flags Nhop# Mtu
anyone else seeing bind fail on recent -current?
This instance is/was running in a jail but now fails sometime after SVN r359823 .. I'm trying to bisect but any hints appreciated .. named[98746]: named[98746]: BIND 9 is maintained by Internet Systems Consortium, named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit named[98746]: corporation. Support and training for BIND 9 are named[98746]: available at https://www.isc.org/support named[98746]: named[98746]: command channel listening on 127.0.0.1#953 named[98746]: command channel listening on ::1#953 named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back trace named[98746]: #0 0x2cbb35 in ?? named[98746]: #1 0x4a7b4a in ?? named[98746]: #2 0x4bd297 in ?? named[98746]: #3 0x4c12a1 in ?? named[98746]: #4 0x8009f67f4 in ?? named[98746]: #5 0x8009f87b8 in ?? named[98746]: #6 0x8009e7e81 in ?? named[98746]: #7 0x4bb6e9 in ?? named[98746]: #8 0x800a15f39 in ?? named[98746]: exiting (due to assertion failure) root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: anyone else seeing bind fail on recent -current?
On 4/15/20 7:19 PM, Michael Butler wrote: > This instance is/was running in a jail but now fails sometime after SVN > r359823 .. I'm trying to bisect but any hints appreciated .. > > named[98746]: > named[98746]: BIND 9 is maintained by Internet Systems Consortium, > named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit > named[98746]: corporation. Support and training for BIND 9 are > named[98746]: available at https://www.isc.org/support > named[98746]: > named[98746]: command channel listening on 127.0.0.1#953 > named[98746]: command channel listening on ::1#953 > named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back > trace > named[98746]: #0 0x2cbb35 in ?? > named[98746]: #1 0x4a7b4a in ?? > named[98746]: #2 0x4bd297 in ?? > named[98746]: #3 0x4c12a1 in ?? > named[98746]: #4 0x8009f67f4 in ?? > named[98746]: #5 0x8009f87b8 in ?? > named[98746]: #6 0x8009e7e81 in ?? > named[98746]: #7 0x4bb6e9 in ?? > named[98746]: #8 0x800a15f39 in ?? > named[98746]: exiting (due to assertion failure) > root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named As it turns out, the update to devel/libuv on SVN r531786 causes this failure .. :-( imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: anyone else seeing bind fail on recent -current?
On 16/04/2020 10:24 am, Michael Butler wrote: On 4/15/20 7:19 PM, Michael Butler wrote: This instance is/was running in a jail but now fails sometime after SVN r359823 .. I'm trying to bisect but any hints appreciated .. named[98746]: named[98746]: BIND 9 is maintained by Internet Systems Consortium, named[98746]: Inc. (ISC), a non-profit 501(c)(3) public-benefit named[98746]: corporation. Support and training for BIND 9 are named[98746]: available at https://www.isc.org/support named[98746]: named[98746]: command channel listening on 127.0.0.1#953 named[98746]: command channel listening on ::1#953 named[98746]: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back trace named[98746]: #0 0x2cbb35 in ?? named[98746]: #1 0x4a7b4a in ?? named[98746]: #2 0x4bd297 in ?? named[98746]: #3 0x4c12a1 in ?? named[98746]: #4 0x8009f67f4 in ?? named[98746]: #5 0x8009f87b8 in ?? named[98746]: #6 0x8009e7e81 in ?? named[98746]: #7 0x4bb6e9 in ?? named[98746]: #8 0x800a15f39 in ?? named[98746]: exiting (due to assertion failure) root[98760]: /usr/local/etc/rc.d/named: WARNING: failed to start named As it turns out, the update to devel/libuv on SVN r531786 causes this failure .. :-( Tracked at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245653 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: if_bridge performance improvements
вт, 14 апр. 2020 г., 12:51 Kristof Provost : > Hi, > > Thanks to support from The FreeBSD Foundation I’ve been able to work > on improving the throughput of if_bridge. > It changes the (data path) locking to use the NET_EPOCH infrastructure. > Benchmarking shows substantial improvements (x5 in test setups). > > This work is ready for wider testing now. > > It’s under review here: https://reviews.freebsd.org/D24250 > > Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true > Patches for stable/12: > https://people.freebsd.org/~kp/if_bridge/stable_12/ > > I’m not currently aware of any panics or issues resulting from these > patches. > > Do note that if you run a Bhyve + tap on bridges setup the tap code > suffers from a similar bottleneck and you will likely not see major > improvements in single VM to host throughput. I would expect, but have > not tested, improvements in overall throughput (i.e. when multiple VMs > send traffic at the same time). > > Best regards, > Kristof > Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
