Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib
On 7/25/2019 12:09 PM, Dimitry Andric wrote: > Hmmm, is the logic reversed somehow ? The good news is if nothing is >>> defined, it does the right thing. >> The idea is that the default is to *not* bootstrap the compiler, if the >> system compiler is new enough. E.g. if you build r350256 from a system >> built before r350256, it will normally automatically bootstrap >> everything. >> >> E.g., your previous builds did not have to bootstrap, and now they do, >> which is why they take longer. >> >> So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and >> MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing. >> >> I did a few tests on a relatively fast machine, and buildworld with >> those settings on took approximately the same time at r350255 and >> r350256. I'm now repeating those experiments to feed the results to >> ministat. Thanks again for verifying and explaining all this. I was interpreting MK_SYSTEM_LINKER=yes as "along with building world, build the compiler and linker from scratch first" vs "using the existing installed system linker and compiler to build world" and as you pointed out, when its a version difference it gets overridden. > Repeating buildworld 3 times for r350255 and r350256 (with both The times on my machines all look normal now too! ---Mike ___ 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: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045
On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans wrote: > > On Thu, Jul 25, 2019 at 9:41 AM Trond Endrestøl > wrote: > > > > Hi, > > > > I have a VPN service running net/ocserv 0.12.4_1. Everything is ok > > until the first client disconnects. The main ocserv process hangs > > while destroying the tun interface, waiting indefinitely on > > "tun_cond". > > > > I ran an ocserv executable containing debug symbols through gdb and I > > had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, ), at > > tun.c:770 of net/ocserv. > > > > The call to ioctl() has apparently a valid file descriptor, fd, and > > the fields of ifr are all zero, save the ifr_name field which contains > > "vpns0" and is properly null terminated. > > > > On the first attempt, I let the code run its course and had to reboot > > to recover. > > > > On the second attempt, I killed the ocserv process from within gdb. I > > ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. > > Rebooting is the only way to recover. > > > > Reverting to stable/12 r345045 makes ocserv serve the clients again. > > > > My guess is that one or more of r345285, r347378, and/or r348124, all > > related to sys/net/if_tun.c, are to blame. > > > > Can someone verify my claims? > > > > Hi, > > I'll take a look when I get a bit- a hang on tun_cond would be > expected if a process has the tun cdev open()'d still. The device > should fail to destroy until it's closed so we don't leave the > controlling application in a funky state. There were some bugs around > that leaving the driver in a funky state that I fixed somewhere along > the way here. > > Thanks, > > Kyle Evans To follow-up to the list as well, I've added a comment on the Gitlab issue [0] -- my suspicion is that ocserv is violating the tunnel hand-off protocol (TUNSIFPID) and technically leaking the fd in the process that created it while trying to close/destroy it in another pid that actually controls the tunnel. [0] https://gitlab.com/openconnect/ocserv/issues/213 ___ 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: Random panics in 11.0 and 12.0 on J1900
Hi Marco and Adam, Thanks for the responses. Answers to your questions are inline On Sat, Jul 20, 2019 at 06:56:19PM +0200, Marco Steinbach wrote: > I've outfitted all of them with 4-port Intel PRO/1000 PCIe driven by > igb(4), and am not using the onboard re(4) NICs. We use the onboard re(4) NICs and they have been their own problem. It's possible they are implicated here. > I can't recall ever seeing a panic like you described. Could you share > a full dmesg and what mainboard(s) you are using ? /var/run/dmesg.boot from the 12.0 host that panicked is included below. The board is a "Q1900G2-M V2.0". On Wed, Jul 24, 2019 at 07:53:54PM -0500, Adam wrote: > What is the size of this J1900 set? Large enough that 1% panicking daily means I'm seeing multiple panics per day. > Do you also have J1900 which do not exhibit the problem? I do have a small set which have not exhibited the problem. They are about 2.5-3% of the fleet. What makes them unique is they are running 10.3. There are also some 11.0s which have not panicked, but given that we've seen hosts go ~620 days before a panic, it's possible they just haven't panicked yet; they are also a minority of the 11s. (It's also possible the 10.3s just haven't panicked yet, but as they have been deployed the longest, that seems less probable with each passing day.) Personally, I believe this is a hardware problem, but these 10.3s that don't panic are a big hole in that theory. > memtest cannot conclusively confirm dimm is good, it is only conclusive on > bad ones. You can find more info about others learning this lesson > here(see extended comments): > > https://superuser.com/questions/547822/how-many-passes-are-enough-with-memtest > > > > Two, a small number of systems on the same hardware are running > > 10.3-RELEASE, and have experienced no panics in their history. Panics > > have only happened on 11s, and now 12. > > > > Once upon a time in a hypothetical universe, I had a stick of ram which > would run on Win98 for very long periods without issue. It wouldn't even > boot with Win NT. After the manufacturer sent the same one back twice, I > tased it and RMA'd again. This time, I got a new stick and all was good. > > The point is memory issues can be very subtle and replacing with known good > modules is the easiest way to be sure. Duly noted, and I don't disagree, but given your comments about memtest and confirming memory to be good, how do you get to "known good?" Thanks for the input. dmesg output follows below. -Snow ---<>--- Copyright (c) 1992-2018 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-RELEASE r341666 GENERIC amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 Structured Extended Features3=0xc00 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8089657344 (7714 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20181003/tbfadt-748) ioapic0 irqs 0-86 on motherboard Launching APs: 3 2 1 Timecounter "TSC" frequency 256560 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module [ath_hal] loaded random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff irq 8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf080-0xf087 mem
Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib
On 24 Jul 2019, at 23:21, Dimitry Andric wrote: > > On 24 Jul 2019, at 22:56, mike tancsa wrote: >> >> On 7/24/2019 1:21 PM, mike tancsa wrote: >>> On 7/24/2019 12:02 PM, Dimitry Andric wrote: > ... >>> # cat /etc/src.conf /etc/make.conf >>> MK_SYSTEM_COMPILER=no >>> MK_SYSTEM_LINKER=no >>> KERNCONF=server >>> MK_SYSTEM_COMPILER=no >>> MK_SYSTEM_LINKER=no >> >> Hmmm, is the logic reversed somehow ? The good news is if nothing is >> defined, it does the right thing. > > The idea is that the default is to *not* bootstrap the compiler, if the > system compiler is new enough. E.g. if you build r350256 from a system > built before r350256, it will normally automatically bootstrap > everything. > > E.g., your previous builds did not have to bootstrap, and now they do, > which is why they take longer. > > So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and > MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing. > > I did a few tests on a relatively fast machine, and buildworld with > those settings on took approximately the same time at r350255 and > r350256. I'm now repeating those experiments to feed the results to > ministat. Repeating buildworld 3 times for r350255 and r350256 (with both MK_SYSTEM_COMPILER and MK_SYSTEM_LINKER set to "yes") shows no difference in measured real time, according to ministat: $ head real-*.txt ==> real-r350255.txt <== 1562.12 1587.61 1582.78 ==> real-r350256.txt <== 1574.50 1559.20 1584.50 $ ministat real-*.txt x real-r350255.txt + real-r350256.txt +--+ |+ x + x + x| | |_|A___M__AM__||| +--+ N Min MaxMedian AvgStddev x 3 1562.12 1587.61 1582.78 1577.5033 13.539477 + 31559.21584.51574.5 1572.7333 12.742187 No difference proven at 95.0% confidence -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!)
Hi Allan, Can ZFS use atomic_add_64() in the kernel for i386 instead of building its own variant? --HPS On 2019-07-25 13:13, Peter wrote: Hi Hans Petter, glad to read You! :) On Thu, Jul 25, 2019 at 09:39:26AM +0200, Hans Petter Selasky wrote: ! On 2019-07-25 01:00, Peter wrote: ! >> The offending feature is either ! >> options ZFS ! >> or ! >> device dtrace ! >> (Adding any of these to the GENERIC config gives the same error.) ! Can you attach your kernel configuration file? Yes, but to what point? I can reproduce this with the GENERIC configuration by adding "options ZFS" (My custom KERNCONF relates to my local patches, and is rather pointless without these. So at first I tried to reproduce without my local patches and with minimal changes from GENERIC config. And the minimal change is to add "options ZFS" into the GENERIC conf.) See here: root@disp:/usr/src/sys/i386/compile/GENERIC # make linking kernel.full atomic.o: In function `atomic_add_64': /usr/src/sys/i386/compile/GENERIC/./machine/atomic.h:629: multiple definition of `atomic_add_64' opensolaris_atomic.o:/usr/src/sys/i386/compile/GENERIC/../../../cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here *** Error code 1 Stop. make: stopped in /usr/src/sys/i386/compile/GENERIC root@disp:/usr/src/sys/i386/compile/GENERIC # root@disp:/usr/src/sys/i386/compile/GENERIC # cd ../../../.. root@disp:/usr/src # svn stat M sys/i386/conf/GENERIC root@disp:/usr/src # svn diff Index: sys/i386/conf/GENERIC === --- sys/i386/conf/GENERIC (revision 350287) +++ sys/i386/conf/GENERIC (working copy) @@ -1,3 +1,4 @@ +options ZFS # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # root@disp:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-east.freebsd.org/base/releng/11.3 Relative URL: ^/releng/11.3 Repository Root: https://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 350287 Node Kind: directory Schedule: normal Last Changed Author: gordon Last Changed Rev: 350287 Last Changed Date: 2019-07-24 12:58:21 + (Wed, 24 Jul 2019) ___ 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: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045
On Thu, Jul 25, 2019 at 9:41 AM Trond Endrestøl wrote: > > Hi, > > I have a VPN service running net/ocserv 0.12.4_1. Everything is ok > until the first client disconnects. The main ocserv process hangs > while destroying the tun interface, waiting indefinitely on > "tun_cond". > > I ran an ocserv executable containing debug symbols through gdb and I > had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, ), at > tun.c:770 of net/ocserv. > > The call to ioctl() has apparently a valid file descriptor, fd, and > the fields of ifr are all zero, save the ifr_name field which contains > "vpns0" and is properly null terminated. > > On the first attempt, I let the code run its course and had to reboot > to recover. > > On the second attempt, I killed the ocserv process from within gdb. I > ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. > Rebooting is the only way to recover. > > Reverting to stable/12 r345045 makes ocserv serve the clients again. > > My guess is that one or more of r345285, r347378, and/or r348124, all > related to sys/net/if_tun.c, are to blame. > > Can someone verify my claims? > Hi, I'll take a look when I get a bit- a hang on tun_cond would be expected if a process has the tun cdev open()'d still. The device should fail to destroy until it's closed so we don't leave the controlling application in a funky state. There were some bugs around that leaving the driver in a funky state that I fixed somewhere along the way here. Thanks, Kyle Evans ___ 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"
net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045
Hi, I have a VPN service running net/ocserv 0.12.4_1. Everything is ok until the first client disconnects. The main ocserv process hangs while destroying the tun interface, waiting indefinitely on "tun_cond". I ran an ocserv executable containing debug symbols through gdb and I had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, ), at tun.c:770 of net/ocserv. The call to ioctl() has apparently a valid file descriptor, fd, and the fields of ifr are all zero, save the ifr_name field which contains "vpns0" and is properly null terminated. On the first attempt, I let the code run its course and had to reboot to recover. On the second attempt, I killed the ocserv process from within gdb. I ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. Rebooting is the only way to recover. Reverting to stable/12 r345045 makes ocserv serve the clients again. My guess is that one or more of r345285, r347378, and/or r348124, all related to sys/net/if_tun.c, are to blame. Can someone verify my claims? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500 https://gitlab.com/openconnect/ocserv/issues/213 -- 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: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!)
Hi Hans Petter, glad to read You! :) On Thu, Jul 25, 2019 at 09:39:26AM +0200, Hans Petter Selasky wrote: ! On 2019-07-25 01:00, Peter wrote: ! >> The offending feature is either ! >> options ZFS ! >> or ! >> device dtrace ! >> (Adding any of these to the GENERIC config gives the same error.) ! Can you attach your kernel configuration file? Yes, but to what point? I can reproduce this with the GENERIC configuration by adding "options ZFS" (My custom KERNCONF relates to my local patches, and is rather pointless without these. So at first I tried to reproduce without my local patches and with minimal changes from GENERIC config. And the minimal change is to add "options ZFS" into the GENERIC conf.) See here: root@disp:/usr/src/sys/i386/compile/GENERIC # make linking kernel.full atomic.o: In function `atomic_add_64': /usr/src/sys/i386/compile/GENERIC/./machine/atomic.h:629: multiple definition of `atomic_add_64' opensolaris_atomic.o:/usr/src/sys/i386/compile/GENERIC/../../../cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here *** Error code 1 Stop. make: stopped in /usr/src/sys/i386/compile/GENERIC root@disp:/usr/src/sys/i386/compile/GENERIC # root@disp:/usr/src/sys/i386/compile/GENERIC # cd ../../../.. root@disp:/usr/src # svn stat M sys/i386/conf/GENERIC root@disp:/usr/src # svn diff Index: sys/i386/conf/GENERIC === --- sys/i386/conf/GENERIC (revision 350287) +++ sys/i386/conf/GENERIC (working copy) @@ -1,3 +1,4 @@ +options ZFS # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # root@disp:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-east.freebsd.org/base/releng/11.3 Relative URL: ^/releng/11.3 Repository Root: https://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 350287 Node Kind: directory Schedule: normal Last Changed Author: gordon Last Changed Rev: 350287 Last Changed Date: 2019-07-24 12:58:21 + (Wed, 24 Jul 2019) ___ 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"
FreeBSD CI Weekly Report 2019-07-21
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-07-21 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-07-15 to 2019-07-21. During this period, we have: * 1659 builds (96.7% (-0.7) passed, 3.3% (+0.7) failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 306 test runs (56.2% (+1.9) passed, 43.1% (+5.6) unstable, 0.7% (-7.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 18 doc builds (100% (+0) passed) Test case status (by 2019-07-21 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | | | --- | | head/amd64 | 7460 | 7411 | 0| 49 | | head/i386 | 7458 | 7406 | 4| 48 | | 12-STABLE/amd64 | 7388 | 7341 | 0| 47 | | 12-STABLE/i386 | 7386 | 7335 | 5| 46 | | 11-STABLE/amd64 | 6845 | 6800 | 0| 45 | | 11-STABLE/i386 | 6843 | 6759 | 34 | 50 | (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/rJJdcpCbH and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.opencrypto.runtests.main Fixed in http://svnweb.freebsd.org/changeset/base/350164 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * Analysis from kp@: * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001933.html * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001934.html * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * Same as -head: * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * lib.libregex.exhaust_test.regcomp_too_big * flaky, sometimes failed with: ``` /usr/src/contrib/netbsd-tests/lib/libc/regex/t_exhaust.c:72: p != NULL not met ``` * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## 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/ * 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 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 ## Issues ### Cause build fails * https://bugs.freebsd.org/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/233769 Possible build race: ld: error: unable to find library -lgcc_s * https://bugs.freebsd.org/238828 Possible build race: lib/libsysdecode/tables.h:948: error: 'IPV6_MIN_MEMBERSHIPS' undeclared ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * 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 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237652 tests.hotspare.hotspare_test.hotspare_snapshot_001_pos timeout since somewhere in (r346814, r 346845] * https://bugs.freebsd.org/237655 Non-deterministic panic when running pf tests in interface ioctl code (NULL passed to strncmp) * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18
Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!)
On 2019-07-25 01:00, Peter wrote:
Trying to compile my custom kernel in Rel. 11.3 results in this:
-- kernel.full ---
linking kernel.full
atomic.o: In function `atomic_add_64':
/usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of
`atomic_add_64'
opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71:
first defined here
*** [kernel.full] Error code 1
Same config worked with 11.2
The offending feature is either
options ZFS
or
device dtrace
(Adding any of these to the GENERIC config gives the same error.)
This happens only when building for i386. Building amd64 with these
options works.
Trying to analyze the issue:
The problem appears with SVN 334762 in 11.3:
This change adds two new functions to sys/i386/include/atomic.h:
atomic_add_64()
atomic_subtract_64()
[I don't really understand why this goes into a headerfile, but, well,
nevermind]
Also, this change deactivates two functions (only in case *i386*) from
sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c
atomic_add_64()
atomic_del_64()
[Now, there seems to be a slight strangeness here: if we *deactivate*
atomic_del_64(), and *insert* atomic_subtract_64(), then these two
names are not the same, and I might suppose that the atomic_del_64()
is then somehow missing. But, well, nevermind]
Now, the strange thing:
this file sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c
from which now two functions get excluded *only in case i386*, is not
even compiled for i386:
/usr/src/sys/conf$ grep opensolaris_atomic.c *
files.arm:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace
compile-with "${CDDL_C}"
files.mips:cddl/compat/opensolaris/kern/opensolaris_atomic.coptional zfs | dtrace
compile-with "${CDDL_C}"
files.powerpc:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional
zfs powerpc | dtrace powerpc compile-with "${ZFS_C}"
files.riscv:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace
compile-with "${CDDL_C}"
[So maybe that's the reason why the now lack of atomic_del_64() is not
complained? Or maybe it's not used, or maybe I didn't find some
definition whereever. Well, nevermind]
Anyway, the actual name clash happens between
sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S,
because that one *is* compiled:
/usr/src/sys/conf$ grep i386/opensolaris_atomic.S *
files.i386:cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S optional
zfs | dtrace compile-with "${ZFS_S}"
I tried to move out the changes from SVN 334762. Sadly, that didn't
work, because something does already use these atomic_add_64() stuff,
So instead, I did this one:
--- sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S
(revision 350287)
+++ sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S
(working copy)
@@ -66,8 +66,7 @@
* specific mapfile and remove the NODYNSORT attribute
* from atomic_add_64_nv.
*/
- ENTRY(atomic_add_64)
- ALTENTRY(atomic_add_64_nv)
+ ENTRY(atomic_add_64_nv)
pushl %edi
pushl %ebx
movl12(%esp), %edi // %edi = target address
@@ -87,7 +86,6 @@
popl%edi
ret
SET_SIZE(atomic_add_64_nv)
- SET_SIZE(atomic_add_64)
ENTRY(atomic_or_8_nv)
movl4(%esp), %edx // %edx = target address
And at least it compiles now. If it actually runs, that remains to be
found out.
Can you attach your kernel configuration file?
--HPS
___
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"
