FreeBSD CI Weekly Report 2019-04-14
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-04-14 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-04-08 to 2019-04-14. During this period, we have: * 1702 builds (95.7% passed, 4.3% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 274 test runs (47.1% passed, 45.6% unstable, 7.3% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 13 doc buils (100% passed) (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/s/r1EE3jotE and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * sys.geom.class.eli.online_resize_test.online_resize (at clean up stage) Fixed in https://svnweb.freebsd.org/changeset/base/346057 * https://ci.freebsd.org/job/FreeBSD-head-riscv64-test/ * Because Python default version switched 3, fixed in the test code. ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.opencrypto.runtests.main * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * lib.libc.sys.sendfile_test.fd_positive_shm_v4 * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4 * lib.libc.gen.floatunditf_test.floatunditf * lib.libc.stdio.printfloat_test.hexadecimal_rounding * lib.msun.ctrig_test.test_small_inputs * lib.msun.precision_test.t_precision https://bugs.freebsd.org/236936 (fixed when this report published) * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) * lib.libc.sys.sendfile_test.fd_positive_shm_v4 * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4 ## Failing Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Closed Issues * https://bugs.freebsd.org/237128 sys/geom/class/eli:online_resize_test fails to clean up cleanly, causing false positives * https://bugs.freebsd.org/237129 sys.netmap.ctrl-api-test.main fails on ^/stable/11 and ^/stable/12 i386 because the kernel lacks netmap support ## Oepn Issues * https://bugs.freebsd.org/237077 possible race in build: /usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected relocatable expression ### In progress * https://bugs.freebsd.org/236936 4 test cases failing on i386 after r345562 ### Cause build fails * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with STABLE-12
On Apr 17, 2019, at 9:44 AM, Filippo Moretti via freebsd-stable wrote: I previously reported that I was unable to boot my system with STABLE-12 of april 13 the system stop at Loading kernel modules.I installed stable-12 snapshot of april 11 on a second disc to try to rescue the first one.I could go on with my plan until I installed drm kmodand addedd kld_list=/boot/modules/radeonkms.ko in /etc/rc.conf I have a radeon graphics card, too. Recently, I had a problem with the graphics/drm-kmod hanging on boot in multi-user. My fix was to switch to graphics/drm-legacy-kmod, which at least lets the system boot again. I figure the newer graphics/drm-kmod no longer supports my old radeon card. now also this second disk no longer boots,it stops in Loading kernel modules.Further how can I mount ada0p3 partition rw on this second disc considering that bot are zfs?(I could not figure this out mysel)I plan to reinstall on the second disksincerelyFilippo The easiest way to be able to edit the configuration of the existing system to fix things is to boot it in single user mode (press "2" from the loader menu). When you get to the single user prompt, you can then mount your ZFS file systems for writing as follows: mount -uw / /etc/rc.d/zfsbe start /etc/rc.d/zfs start You can then, e.g., edit /etc/rc.conf and remove the problematic kld_list entry. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problem with STABLE-12
I previously reported that I was unable to boot my system with STABLE-12 of april 13 the system stop at Loading kernel modules.I installed stable-12 snapshot of april 11 on a second disc to try to rescue the first one.I could go on with my plan until I installed drm kmodand addedd kld_list=/boot/modules/radeonkms.ko in /etc/rc.conf now also this second disk no longer boots,it stops in Loading kernel modules.Further how can I mount ada0p3 partition rw on this second disc considering that bot are zfs?(I could not figure this out mysel)I plan to reinstall on the second disksincerelyFilippo ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On Wed, 17 Apr 2019 12:05+0200, Trond Endrestøl wrote: > On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > > > On 15.04.2019 16:31, Trond Endrestøl wrote: > > > Has anyone else witnessed a panic during reboot involving > > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > > > > > The stack trace goes more or less like this: > > > > > > db_trace_self_wrapper() > > > vpanic() > > > panic() > > > trap_fatal() > > > trap() > > > calltrap() > > > nd6_dad_start() > > > nd6_timer() > > > softclock_call_cc() > > > softclock() > > > ithread_loop() > > > fork_exit() > > > fork_trampoline() > > > > > > This was last seen while transitioning from r345628 to r346220 on > > > amd64 stable/12. > > > > Hi, > > > > do you have exact panic message and/or backtrace from core dump? > > Here's another system I had to shut down recently: > > root@HOSTNAME:/var/crash # kgdb /boot/kernel/kernel vmcore.0 > [...] > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x410 > fault code = supervisor read data , page not present > instruction pointer = 0x20:0x807ea33d > stack pointer = 0x28:0xfe005ad3c8d0 > frame pointer = 0x28:0xfe005ad3c960 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (swi4: clock (0)) > trap number = 12 > panic: page fault > cpuid = 0 > time = 1555402802 > KDB: stack backtrace: > db_trace_self_wrapper() at 0x8054125b = > db_trace_self_wrapper+0x2b/frame 0xfe005ad3c570 > vpanic() at 0x8080aae4 = vpanic+0x1b4/frame 0xfe005ad3c5d0 > panic() at 0x8080a923 = panic+0x43/frame 0xfe005ad3c630 > trap_fatal() at 0x80b76244 = trap_fatal+0x394/frame 0xfe005ad3c690 > trap_pfault() at 0x80b762a9 = trap_pfault+0x49/frame > 0xfe005ad3c6f0 > trap() at 0x80b7588f = trap+0x29f/frame 0xfe005ad3c800 > calltrap() at 0x80b514c5 = calltrap+0x8/frame 0xfe005ad3c800 > --- trap 0xc, rip = 0x807ea33d, rsp = 0xfe005ad3c8d0, rbp = > 0xfe005ad3c960 --- > __mtx_lock_sleep() at 0x807ea33d = __mtx_lock_sleep+0xbd/frame > 0xfe005ad3c960 > mld_fasttimo() at 0x80a3ae32 = mld_fasttimo+0x492/frame > 0xfe005ad3ca50 > pffasttimo() at 0x80899fa4 = pffasttimo+0x54/frame 0xfe005ad3ca80 > softclock_call_cc() at 0x80824e0e = softclock_call_cc+0x12e/frame > 0xfe005ad3cb30 > softclock() at 0x808252f9 = softclock+0x79/frame 0xfe005ad3cb50 > ithread_loop() at 0x807cd824 = ithread_loop+0x1d4/frame > 0xfe005ad3cbb0 > fork_exit() at 0x807ca2d3 = fork_exit+0x83/frame 0xfe005ad3cbf0 > fork_trampoline() at 0x80b524be = fork_trampoline+0xe/frame > 0xfe005ad3cbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 34d16h8m2s > Dumping 4593 out of 12258 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > This particular system uses lagg0 comprised of bce0, bce1, em0, and > em1. Also, it runs a custom kernel. > > > It would be good to submit PR about such problems. > > I'll submit the details in a PR. PR is 237329. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237329 -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > On 15.04.2019 16:31, Trond Endrestøl wrote: > > Has anyone else witnessed a panic during reboot involving > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > > > The stack trace goes more or less like this: > > > > db_trace_self_wrapper() > > vpanic() > > panic() > > trap_fatal() > > trap() > > calltrap() > > nd6_dad_start() > > nd6_timer() > > softclock_call_cc() > > softclock() > > ithread_loop() > > fork_exit() > > fork_trampoline() > > > > This was last seen while transitioning from r345628 to r346220 on > > amd64 stable/12. > > Hi, > > do you have exact panic message and/or backtrace from core dump? Here's another system I had to shut down recently: root@HOSTNAME:/var/crash # kgdb /boot/kernel/kernel vmcore.0 [...] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x410 fault code = supervisor read data , page not present instruction pointer = 0x20:0x807ea33d stack pointer = 0x28:0xfe005ad3c8d0 frame pointer = 0x28:0xfe005ad3c960 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 0 time = 1555402802 KDB: stack backtrace: db_trace_self_wrapper() at 0x8054125b = db_trace_self_wrapper+0x2b/frame 0xfe005ad3c570 vpanic() at 0x8080aae4 = vpanic+0x1b4/frame 0xfe005ad3c5d0 panic() at 0x8080a923 = panic+0x43/frame 0xfe005ad3c630 trap_fatal() at 0x80b76244 = trap_fatal+0x394/frame 0xfe005ad3c690 trap_pfault() at 0x80b762a9 = trap_pfault+0x49/frame 0xfe005ad3c6f0 trap() at 0x80b7588f = trap+0x29f/frame 0xfe005ad3c800 calltrap() at 0x80b514c5 = calltrap+0x8/frame 0xfe005ad3c800 --- trap 0xc, rip = 0x807ea33d, rsp = 0xfe005ad3c8d0, rbp = 0xfe005ad3c960 --- __mtx_lock_sleep() at 0x807ea33d = __mtx_lock_sleep+0xbd/frame 0xfe005ad3c960 mld_fasttimo() at 0x80a3ae32 = mld_fasttimo+0x492/frame 0xfe005ad3ca50 pffasttimo() at 0x80899fa4 = pffasttimo+0x54/frame 0xfe005ad3ca80 softclock_call_cc() at 0x80824e0e = softclock_call_cc+0x12e/frame 0xfe005ad3cb30 softclock() at 0x808252f9 = softclock+0x79/frame 0xfe005ad3cb50 ithread_loop() at 0x807cd824 = ithread_loop+0x1d4/frame 0xfe005ad3cbb0 fork_exit() at 0x807ca2d3 = fork_exit+0x83/frame 0xfe005ad3cbf0 fork_trampoline() at 0x80b524be = fork_trampoline+0xe/frame 0xfe005ad3cbf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 34d16h8m2s Dumping 4593 out of 12258 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% This particular system uses lagg0 comprised of bce0, bce1, em0, and em1. Also, it runs a custom kernel. > It would be good to submit PR about such problems. I'll submit the details in a PR. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()
On 15.04.2019 16:31, Trond Endrestøl wrote: > Has anyone else witnessed a panic during reboot involving > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > The stack trace goes more or less like this: > > db_trace_self_wrapper() > vpanic() > panic() > trap_fatal() > trap() > calltrap() > nd6_dad_start() > nd6_timer() > softclock_call_cc() > softclock() > ithread_loop() > fork_exit() > fork_trampoline() > > This was last seen while transitioning from r345628 to r346220 on > amd64 stable/12. Hi, do you have exact panic message and/or backtrace from core dump? It would be good to submit PR about such problems. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ZFS parallel mounting gone wrong?
On Mon, 15 Apr 2019 15:24+0200, Trond Endrestøl wrote: > I upgraded a non-critical system running amd64 stable/12 to r346220. > > During multiuser boot not all ZFS filesystems below zroot/usr/local > was mounted. Some more explaining is in order: This system has two 7 year old pools that complement each other. /usr/local comes mostly from the zroot pool, but other children comes from a zdata pool. The intermediary filesystems have their canmount property set to off and mountpoints are specified at the top level only. The same goes for other parts of the filesystem hierarchy, such as /var/db and /var/spool. I just upgraded to stable/12 global r346269, local r346268. During a routine "zfs mount -av" performed in single user mode, the kernel proceeded to mount a child filesystem (enterprise_zdata/var/db/mysql) without the parent filesystems being mounted first. I rebooted back to r345628 from March 28th, and this kernel has no problems correctly mounting the ZFS filesystems in parallel. That BE used LLVM 7.0.1 from base as its system compiler. Rebooting into r346220 (April 15th) or r346269 (April 17th) clearly shows problems mounting filesystems in the correct order. These BEs was compiled using LLVM 8.0.0 from base. Maybe the system compiler is irrelevant. The name of the pools might also be a factor, the zdata pool preceedes the zroot pool in alphanumerical order. Maybe there is a bug in the code, or the code breaks when parts of the filesystem hierarchy is being built from multiple pools. Here's an attempt at explaining how this fits together: zfs list -ro name,canmount,mountpoint enterprise_zroot/usr enterprise_zdata/usr enterprise_zroot/var enterprise_zdata/var [the list has been slightly edited, moving zdata below zroot and adding an empty line] NAME CANMOUNT MOUNTPOINT enterprise_zroot/usroff /usr enterprise_zroot/usr/compat on /usr/compat enterprise_zroot/usr/local on /usr/local enterprise_zroot/usr/local/certs on /usr/local/certs enterprise_zroot/usr/local/etc on /usr/local/etc enterprise_zroot/usr/local/etc/shellkonfig3 on /usr/local/etc/shellkonfig3 enterprise_zroot/usr/local/etc/shellkonfig3/head on /usr/local/etc/shellkonfig3/head enterprise_zroot/usr/local/etc/shellkonfig3/stable-10on /usr/local/etc/shellkonfig3/stable-10 enterprise_zroot/usr/local/etc/shellkonfig3/stable-11on /usr/local/etc/shellkonfig3/stable-11 enterprise_zroot/usr/local/etc/shellkonfig3/stable-8 on /usr/local/etc/shellkonfig3/stable-8 enterprise_zroot/usr/local/etc/shellkonfig3/stable-9 on /usr/local/etc/shellkonfig3/stable-9 enterprise_zroot/usr/local/info on /usr/local/info enterprise_zroot/usr/local/var on /usr/local/var enterprise_zroot/usr/obj on /usr/obj enterprise_zroot/usr/ports on /usr/ports enterprise_zroot/usr/ports/distfiles on /usr/ports/distfiles enterprise_zroot/usr/ports/localoff /usr/ports/local enterprise_zroot/usr/ports/packages on /usr/ports/packages enterprise_zroot/usr/ports/workdirs on /usr/ports/workdirs enterprise_zroot/usr/src on /usr/src enterprise_zdata/usroff /usr enterprise_zdata/usr/local off /usr/local enterprise_zdata/usr/local/moodledataon /usr/local/moodledata enterprise_zdata/usr/local/pgsql on /usr/local/pgsql enterprise_zdata/usr/local/restaurering on /usr/local/restaurering enterprise_zdata/usr/local/www on /usr/local/www enterprise_zdata/usr/local/www/moodleon /usr/local/www/moodle enterprise_zroot/varoff /var enterprise_zroot/var/Named on /var/Named enterprise_zroot/var/account on /var/account enterprise_zroot/var/audit on /var/audit enterprise_zroot/var/cache off /var/cache enterprise_zroot/var/cache/ccacheon /var/cache/ccache enterprise_zroot/var/cache/synth on /var/cache/synth enterprise_zroot/var/crash on /var/crash enterprise_zroot/var/db on /var/db enterprise_zroot/var/db/darkstat on /var/db/darkstat enterprise_zroot/var/db/dkim
