FreeBSD CI Weekly Report 2019-06-02
(Please send the followup discussions to freebsd-testing@ list.) FreeBSD CI Weekly Report 2019-06-02 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-05-27 to 2019-06-02. During this period, we have: * 1752 builds (97.8% passed, 2.2% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 327 test runs (36.7% passed, 63.3% unstable) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 23 doc builds (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/ryVi1WiaN and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Removed Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * sys.geom.class.eli.init_test.init * sys.geom.class.eli.init_test.init_a * sys.geom.class.eli.init_test.init_alias * sys.geom.class.eli.integrity_test.copy * sys.geom.class.eli.integrity_test.data * sys.geom.class.eli.integrity_test.hmac Those geli(8) test cases are failing because some algorithms are deprecated in [r348206](https://reviews.freebsd.org/rS348206) and the return value and output are changed. The fix to the test cases are under development. Those tests are removed in [r348454](https://reviews.freebsd.org/rS348454), while it is still wothy to adjust the test code to check if the deprecated algorithms are correctly marked deprecated in the future. * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * Same as amd64 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * sys.netinet.socket_afinet.socket_afinet_bind_zero Affected by mac_portacl(4), which is loaded by MAC tests. Need to specify AF_INET to workaround and fix is being discussed. * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * i386 test is current suffering from loading ipsec(4) kernel module, which is needed after https://svnweb.freebsd.org/changeset/base/347410 , causes kernel panic. For more information, see: * https://bugs.freebsd.org/238012 * https://bugs.freebsd.org/230857 * https://reviews.freebsd.org/D17512 * Same as amd64: * sys.netinet.socket_afinet.socket_afinet_bind_zero * Others: * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * sys.opencrypto.runtests.main * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.opencrypto.runtests.main Failed with: ``` File "/usr/tests/sys/opencrypto/cryptodev.py", line 179, in __init__ ioctl(_cryptodev, CIOCGSESSION2, s, 1) IOError: [Errno 22] Invalid argument ``` * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Fixed Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * There are ~980 test cases failure with message: `dtrace: failed to compile script err.D_AGG_SCALAR.maxnoarg.d: [D_UNKNOWN] "/usr/lib/dtrace/mbuf.d", line 114: failed to copy type of 'm_data': Type information is in parent and unavailable` Fixed by https://svnweb.freebsd.org/changeset/base/348329 ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * This job is currently suffering from timeout because of https://bugs.freebsd.org/237652 * 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_loogle.com/ine_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues * https://bugs.freebsd.org/237077 possible race in build: /usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected relocatable expression * https://bugs.freebsd.org/237403
Re: Kernel panic on 12-STABLE-r348203 amd64
On Wed, Jun 5, 2019 at 2:42 PM Mark Saad wrote: > > On Wed, Jun 5, 2019 at 12:29 PM Mark Saad wrote: > > > > All > > I was wondering if anyone could shed some light on this boot panic I > > saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting > > 12.0-STABLE-r348203 amd64. > > I reverted this back to 12.0-RELEASE-p4 and its fine . > > > > The only custom options I had were in loader.conf > > > > kern.geom.label.gptid.enable="0" > > ipmi_load="YES" > > boot_multicons="YES" > > boot_serial="YES" > > console="comconsole,vidconsole" > > net.inet.tcp.tso="0" > > cc_htcp_load="YES" > > autoboot_delay="5" > > hw.mfi.mrsas_enable="1" > > hw.usb.no_pf="1"# Disable USB packet filtering > > hw.usb.no_shutdown_wait="1" > > hw.vga.textmode="1" # Text mode > > machdep.hyperthreading_allowed="0" > > > > Any ideas ? > > > > Screen shot here > > https://imgur.com/a/nGvHtIs > > > > -- > > mark saad | nones...@longcount.org > > Plain text version of the crash > > Loading kernel... > /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 > syms=[0x8+0x1778e8+0x8 / > +0x194f1d] > Loading configured modules... > /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 > loading required module 'smbus' > /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 > /boot/entropy size=0x1000 > /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 > ---<>---c_hmodule 'smbus' > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-STABLE r348693 GENERIC amd64 > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > LLVM 8.0.0) > panic: UMA zone "UMA Zones": Increase vm.boot_pages > cpuid = 0 > time = 1 > KDB: stack backtrace: > #0 0x80c16df7 at ??+0 > #1 0x80bcaccd at ??+0 > #2 0x80bcab23 at ??+0 > #3 0x80f0b03c at ??+0 > #4 0x80f08d8d at ??+0 > #5 0x80f0bb3d at ??+0 > #6 0x80f0b301 at ??+0 > #7 0x80f0b3d1 at ??+0 > #8 0x80f066c4 at ??+0 > #9 0x80f0543f at ??+0 > #10 0x80f23aef at ??+0 > #11 0x80f1133b at ??+0 > #12 0x80b619c8 at ??+0 > #13 0x8036a02c at ??+0 > Uptime: 1s > > > Also increasing the vm.boot_pages to 128 in the loader works. Anyone > know why ? This box has 64G ram. > > -- > mark saad | nones...@longcount.org So after some poking in the bios this has to do with how the Dell NUMA options are set. If the system is set Cluster On Die mode, you get a kernel panic Home Snoop or Early Snoop no issue. -- mark saad | nones...@longcount.org ___ 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: Kernel panic on 12-STABLE-r348203 amd64
On Wed, Jun 5, 2019 at 12:29 PM Mark Saad wrote: > > All > I was wondering if anyone could shed some light on this boot panic I > saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting > 12.0-STABLE-r348203 amd64. > I reverted this back to 12.0-RELEASE-p4 and its fine . > > The only custom options I had were in loader.conf > > kern.geom.label.gptid.enable="0" > ipmi_load="YES" > boot_multicons="YES" > boot_serial="YES" > console="comconsole,vidconsole" > net.inet.tcp.tso="0" > cc_htcp_load="YES" > autoboot_delay="5" > hw.mfi.mrsas_enable="1" > hw.usb.no_pf="1"# Disable USB packet filtering > hw.usb.no_shutdown_wait="1" > hw.vga.textmode="1" # Text mode > machdep.hyperthreading_allowed="0" > > Any ideas ? > > Screen shot here > https://imgur.com/a/nGvHtIs > > -- > mark saad | nones...@longcount.org Plain text version of the crash Loading kernel... /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 syms=[0x8+0x1778e8+0x8 / +0x194f1d] Loading configured modules... /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 loading required module 'smbus' /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 /boot/entropy size=0x1000 /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 ---<>---c_hmodule 'smbus' Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-STABLE r348693 GENERIC amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) panic: UMA zone "UMA Zones": Increase vm.boot_pages cpuid = 0 time = 1 KDB: stack backtrace: #0 0x80c16df7 at ??+0 #1 0x80bcaccd at ??+0 #2 0x80bcab23 at ??+0 #3 0x80f0b03c at ??+0 #4 0x80f08d8d at ??+0 #5 0x80f0bb3d at ??+0 #6 0x80f0b301 at ??+0 #7 0x80f0b3d1 at ??+0 #8 0x80f066c4 at ??+0 #9 0x80f0543f at ??+0 #10 0x80f23aef at ??+0 #11 0x80f1133b at ??+0 #12 0x80b619c8 at ??+0 #13 0x8036a02c at ??+0 Uptime: 1s Also increasing the vm.boot_pages to 128 in the loader works. Anyone know why ? This box has 64G ram. -- mark saad | nones...@longcount.org ___ 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"
Kernel panic on 12-STABLE-r348203 amd64
All I was wondering if anyone could shed some light on this boot panic I saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting 12.0-STABLE-r348203 amd64. I reverted this back to 12.0-RELEASE-p4 and its fine . The only custom options I had were in loader.conf kern.geom.label.gptid.enable="0" ipmi_load="YES" boot_multicons="YES" boot_serial="YES" console="comconsole,vidconsole" net.inet.tcp.tso="0" cc_htcp_load="YES" autoboot_delay="5" hw.mfi.mrsas_enable="1" hw.usb.no_pf="1"# Disable USB packet filtering hw.usb.no_shutdown_wait="1" hw.vga.textmode="1" # Text mode machdep.hyperthreading_allowed="0" Any ideas ? Screen shot here https://imgur.com/a/nGvHtIs -- mark saad | nones...@longcount.org ___ 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: ZFS - Problem removing files after changing the compression type
Hello, In the logs I don't have any output about problems with the filesystem. Indeed I had a corrupted file after learning about the zpool status -v, but the ones that I can't delete didn't show up. Searching on the web I found that running the command #echo > /path/to/undetelable/file seems to fix the file to become deletable, but Im not sure why the file was stuck in the first place... Taking advantage of the opportunity, where is the best place I can seek advice to solve issues with 3D acceleration with Intel while I have this notebook with Optimus? Thank you for the pacience, Best regards, Mario Em qua, 5 de jun de 2019 às 10:34, Dean E. Weimer escreveu: > On 2019-06-05 8:14 am, Mario Olofo wrote: > > Hello guys, > > > > I'm configuring a new installation of FreeBSD-12.0-RELEASE and > > installed > > with ZFS for the root file system. > > I run the command zfs set compression=lz4 root, and after this, the > > system > > become a little weird. > > I tried to test some npm install to see if the compression was working > > and > > it is, but when I try to run some commands (ie. ng serve), it fails > > with > > I/O error. > > Deleted the node_modules directory and when I tried to delete the .npm > > dir, > > the system returns "Directory not empty". > > When run as sudo rm -rf, the result is "Unknown error: 122" > > > > I did something that I was not supposed to? > > In the btrfs one can change the compression on the fly without issues > > because of metadata, don't know if zfs behaves this way too. > > > > My system is a Dell G3, with a i5 8gen and an SSD on the m.2 slot > > running > > the FreeBSD (on UFS the notebook freezes and halt when I run npm > > install). > > Gentoo and Windows running on the same SSD and it's all good. > > > > Thank you, > > Best reggards, > > > > Mario > > You should be able to change ZFS compression on the fly. Old data > already written is not changed, but new writes will use the new > compression setting. I have done this before, It looks like something > else is happening I don't think the issue is related to the ZFS > compression setting. I am not familiar with npm, so I have no idea whats > going on there. Look at your dmesg output and check logs to see if the > system logged any disk access errors also check status of zpool with > zpool status. > > -- > Thanks, > Dean E. Weimer > http://www.dweimer.net/ > ___ 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: ZFS - Problem removing files after changing the compression type
On 2019-06-05 8:14 am, Mario Olofo wrote: Hello guys, I'm configuring a new installation of FreeBSD-12.0-RELEASE and installed with ZFS for the root file system. I run the command zfs set compression=lz4 root, and after this, the system become a little weird. I tried to test some npm install to see if the compression was working and it is, but when I try to run some commands (ie. ng serve), it fails with I/O error. Deleted the node_modules directory and when I tried to delete the .npm dir, the system returns "Directory not empty". When run as sudo rm -rf, the result is "Unknown error: 122" I did something that I was not supposed to? In the btrfs one can change the compression on the fly without issues because of metadata, don't know if zfs behaves this way too. My system is a Dell G3, with a i5 8gen and an SSD on the m.2 slot running the FreeBSD (on UFS the notebook freezes and halt when I run npm install). Gentoo and Windows running on the same SSD and it's all good. Thank you, Best reggards, Mario You should be able to change ZFS compression on the fly. Old data already written is not changed, but new writes will use the new compression setting. I have done this before, It looks like something else is happening I don't think the issue is related to the ZFS compression setting. I am not familiar with npm, so I have no idea whats going on there. Look at your dmesg output and check logs to see if the system logged any disk access errors also check status of zpool with zpool status. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ 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"
ZFS - Problem removing files after changing the compression type
Hello guys, I'm configuring a new installation of FreeBSD-12.0-RELEASE and installed with ZFS for the root file system. I run the command zfs set compression=lz4 root, and after this, the system become a little weird. I tried to test some npm install to see if the compression was working and it is, but when I try to run some commands (ie. ng serve), it fails with I/O error. Deleted the node_modules directory and when I tried to delete the .npm dir, the system returns "Directory not empty". When run as sudo rm -rf, the result is "Unknown error: 122" I did something that I was not supposed to? In the btrfs one can change the compression on the fly without issues because of metadata, don't know if zfs behaves this way too. My system is a Dell G3, with a i5 8gen and an SSD on the m.2 slot running the FreeBSD (on UFS the notebook freezes and halt when I run npm install). Gentoo and Windows running on the same SSD and it's all good. Thank you, Best reggards, Mario ___ 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"
