FreeBSD CI Weekly Report 2020-03-08
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-03-08 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-02 to 2020-03-08. During this period, we have: * 2239 builds (48.2% (-39.2) passed, 51.8 (+39.2) 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. * 120 test runs (87.5% (+10.0) passed, 4.2% (-17.3) unstable, 8.3% (+7.3) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 29 doc and www builds (82.8% (-11.3) passed, 17.2% (+11.3) failed) Test case status (on 2020-03-08 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | -- | -- | --- | | head/amd64 | 7709 (+10) | 7617 (+19) | 0 (-9) | 92 (0) | | head/i386 | 7707 (+10) | 7609 (+19) | 0 (-9) | 98 (0) | | 12-STABLE/amd64 | 7501 (0) | 7452 (0) | 0 (0) | 49 (0) | | 12-STABLE/i386 | 7499 (0) | 7442 (0) | 0 (0) | 57 (0) | | 11-STABLE/amd64 | 6878 (0) | 6831 (+3) | 0 (0) | 47 (-3) | | 11-STABLE/i386 | 6876 (0) | 6824 (-3) | 0 (0) | 52 (+3) | (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-20200308 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * Most of the build was failed due to pkg repository ABI mismatching. (Fixed) For more details: https://bugs.freebsd.org/244549 * https://ci.freebsd.org/job/FreeBSD-head-mips64-build This job is using devel/gcc6@mips64 port (mips64-gcc6 pacakge) ``` ===> include/rpcsvc (includes) RPCGEN_CPP=/usr/local/bin/mips64-unknown-freebsd12.0-cpp6\ --sysroot=/usr/home/lwhsu/freebsd-obj-gcc6/usr/home/lwhsu/freebsd-src/mips.mips64/tmp\ -B/usr/local/mips64-unknown-freebsd12.0/bin/ rpcgen -C -h -DWANT_NFS3 /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x -o mount.h /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x:1:0: error: '-march=mips1' is not compatible with the selected ABI /*- *** [mount.h] Error code 1 make[4]: stopped in /usr/home/lwhsu/freebsd-src/include/rpcsvc 1 error ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` --- all_subdir_usr.bin/clang/lldb --- /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandler.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' collect2: error: ld returned 1 exit status ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-test Usually panics when executing sys.netpfil.pf.nat.exhaust For more details: https://bugs.freebsd.org/244703 ## Regressions * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.l
Re: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]
On 2020-03-10 01:04, Konstantin Belousov wrote: Take a look at r334530. "or the user really hates this feature and can't wait to turn it off" Excellently explained by Bruce as usual: "Revision 314641 - (view) (download) (annotate) - [select for diffs] Modified Sat Mar 4 06:19:12 2017 UTC (3 years ago) by bde File length: 107771 byte(s) Diff to previous 312910 Colorize syscons kernel console output according to a table indexed by the CPU number. This was originally for debugging near-deadlock conditions where multiple CPUs either deadlock or scramble each other's output trying to report the problem, but I found it interesting and sometimes useful for ordinary kernel messages. Ordinary kernel messages shouldn't be interleaved, but if they are then the colorization makes them readable even if the interleaving is for every character (provided the CPU printing each message doesn't change). The default colors are 8-15 starting at 15 (bright white on black) for CPU 0 and repeating every 8 CPUs. This works best with 8 CPUs. Non-bright colors and nonzero background colors need special configuration to avoid unreadable and ugly combinations so are not configured by default. The next bright color after 15 is 8 (bright black = dark gray) is not very readable but is the only other color used with 2 CPUs. After that the next bright color is 9 (bright blue) which is not much brighter than bright black, but is used with 3+ CPUs. Other bright colors are brighter. Colorization is configured by default so that it gets tested. It can only be turned off by configuring SC_KERNEL_CONS_ATTR to anything other than FG_WHITE. After booting, all colors can be changed using the syscons.kattr sysctl. This is a SYSCTL_OPAQUE, and no utility is provided to change it (sysctl only displays it). The default colors work in all VGA modes that I could test. In 2-color graphics modes, all 8 bright colors are displayed as bright white, so the colorization has no effect, but anything with a nonzero background gives white on white unless the foreground is zero. I don't have an mono or VGA grayscale hardware to test on. Support for mono mode seems to have never worked right in syscons (I think bright white gives white underline with either bold or bright), but VGA grayscale should work better than 2-color graphics." RIP https://photos.app.goo.gl/YiVmFtWiK8Niy3Fw6 -andyf ___ 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: Any sync-serial driver users (ce/cp/ctau/cx)?
On Mon, 2 Mar 2020 at 14:03, Ed Maste wrote: > > On Sat, 29 Feb 2020 at 15:57, Warner Losh wrote: > > > > Given the ~15 years of nothing but API changes to these cards, and the lack > > of testing of those changes, and the large technology transitions in net > > and tty layers of the system, I'd honestly be surprised if these drivers > > still work. > > Deprecation notices in review D23928 https://reviews.freebsd.org/D23928. > > As rgrimes points out cx(4) is for an ISA card (Cronyx Sigma family), > and I assume there's no conflict over removing it. Likewise with ctau, > which is also ISA, discontinued by the manufacturer and not supported > in FreeBSD 7+ by them. I've MFC'd the deprecation notices for cx and ctau and will remove them from HEAD before too long. glebius@ is going to follow up with Cronyx for more details about the cards supported by ce and cp. I would still appreciate any report that these drivers have been used / tested on contemporary FreeBSD. ___ 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: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]
On Mon, Mar 09, 2020 at 10:37:52AM -0400, Ed Maste wrote: > On Sun, 8 Mar 2020 at 17:13, Andy Farkas wrote: > > > > Is anyone actually working on the vt(4) driver? Will it ever > > become feature-parity with the old sc(4) driver? > > Yes, and yes. What specific missing functionality are you affected by? > > > I've noticed some weird things happening on my console recently... > > like psychedelicly-colour-coded kernel messages.. far out, man. > > I don't think this is related to vt(4), but it would help if you > provided more details (including the version you're running). Take a look at r334530. ___ 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: vt [was: Re: [Bug 235564] INDEX.keymaps for vt contains "from-" keymaps but the files are missing]
On Sun, 8 Mar 2020 at 17:13, Andy Farkas wrote: > > Is anyone actually working on the vt(4) driver? Will it ever > become feature-parity with the old sc(4) driver? Yes, and yes. What specific missing functionality are you affected by? > I've noticed some weird things happening on my console recently... > like psychedelicly-colour-coded kernel messages.. far out, man. I don't think this is related to vt(4), but it would help if you provided more details (including the version you're running). ___ 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"
