Re: Random panics in 11.0 and 12.0 on J1900
On Wed, Jul 10, 2019 at 11:28 AM James Snow wrote: > I have a set of J1900 hosts running 11.0-RELEASE-p1 that experience > seemingly random panics. What is the size of this J1900 set? Do you also have J1900 which do not exhibit the problem? > One, memtest has turned up no errors on 12.0 host I witnessed the panic > on. > 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. -- Adam ___ 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"
Bug 239100 - r348991 breaks unionfs
While upgrading my ports from 12.0-RELEASE to 12-STABLE, I encountered a lot of Text file busy errors, and almost no ports I could update successfully. Then I attempted to fix/workaround the issue, and finally I found that r348991 Switch to use shared vnode locks for text files during image activation broke my uinonfs, which was the culprit for Text file busy issue. https://svnweb.freebsd.org/base?view=revision=348991 I filed the issue in Bugzilla. Someone please look at the issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239100 P.S. For freebsd-current, r348991 was MFC r347151,347181,347968,348421,348698,348701 . -- UEMURA, Tetsuya ___ 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!)
> 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.
Bottomline:
Please, please, please, sort this out and fix it.
___
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: 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 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. -Dimitry signature.asc Description: Message signed with OpenPGP
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/24/2019 1:21 PM, mike tancsa wrote: > On 7/24/2019 12:02 PM, Dimitry Andric wrote: >> On 24 Jul 2019, at 17:12, mike tancsa wrote: >>> On 7/24/2019 9:45 AM, Dimitry Andric wrote: On 24 Jul 2019, at 14:47, mike tancsa wrote: > On 7/23/2019 2:40 PM, Dimitry Andric wrote: >> Author: dim >> Date: Tue Jul 23 18:40:32 2019 >> New Revision: 350256 >> URL: https://svnweb.freebsd.org/changeset/base/350256 >> > Hi, > >Not sure if this is just a difference in the versions or more things > are being compiled, but I noticed a buildworld on my Ryzen went from ~ > 31min to just over 40min. Is this expected ? Most likely this is because it will now build a bootstrap compiler, whereas previously your system may have skipped this step. Can you compare the results when setting MK_SYSTEM_COMPILER=no and MK_SYSTEM_LINKER=no ? >>> Adding those two to src.conf and make.conf still shows 40min >>> >>> time make -j14 buildworld > /var/log/build.out ; time make -j14 >>> buildkernel > /var/log/build.out. >>> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >>> 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 65+320io >>> 214633pf+0w >>> 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io >>> 61829pf+0w >>> >>> Should I be setting these vars somewhere else ? >> Ah, setting them in src.conf, make.conf or the environment will be >> overridden from Makefile.inc1, unfortunately. It will then show >> something like: >> >> make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: >> libclang will be built for bootstrapping a cross-compiler. >> make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: >> libclang will be built for bootstrapping a cross-linker. >> >> E.g, it detects that your system compiler is of a lower version than >> the compiler in the source tree, and will thus bootstrap the latter. >> >> Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and >> MK_SYSTEM_LINKER=yes? In that case, both before and after r350256, the >> results should be fairly similar, I expect. > odd, its still taking the same 40min > > # time make -j14 buildworld > /var/log/build.out ; time make -j14 > buildkernel > > /var/log/build.out. > [Creating objdir /usr/obj/usr/src/amd64.amd64...] > 25281.564u 1233.340s 40:31.08 1090.6% 45595+3474k 633698+3288574io > 213653pf+0w > 1675.796u 172.082s 2:38.19 1168.1% 37746+3170k 205909+3329072io > 61654pf+0w > > > Looking at /var/log/build.out, the top line show > > # head /var/log/build.out > --- buildworld --- > make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang > will be built for bootstrapping a cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will > be built for bootstrapping a cross-linker. > --- buildworld_prologue --- > > despite > > # 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. # head -3 /var/log/build.out.2 --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. # time make -j14 buildworld > /var/log/build.out.2 [Creating objdir /usr/obj/usr/src/amd64.amd64...] 19068.507u 1118.866s 31:07.44 1081.0% 54443+3546k 579241+2828231io 173288pf+0w # cat /etc/src.conf /etc/make.conf MK_SYSTEM_COMPILER=yes MK_SYSTEM_LINKER=yes KERNCONF=server MK_SYSTEM_COMPILER=yes MK_SYSTEM_LINKER=yes If I comment them out, head -4 /var/log/build.out.3-no-defs-in-src-or-make --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. --- buildworld_prologue --- # cat /etc/src.conf /etc/make.conf #MK_SYSTEM_COMPILER=yes #MK_SYSTEM_LINKER=yes KERNCONF=server #MK_SYSTEM_COMPILER=yes #MK_SYSTEM_LINKER=yes vs head -4 /var/log/build.out.3-no-in-src-dot-conf --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. --- buildworld_prologue --- # 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 ___
Rel. 11.3: Kernel doesn't compile anymore :(
Trying to compile my custom kernel in Rel. 11.3 results in this: [code]--- 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[/code] 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. ___ 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: 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/24/2019 12:02 PM, Dimitry Andric wrote: > On 24 Jul 2019, at 17:12, mike tancsa wrote: >> On 7/24/2019 9:45 AM, Dimitry Andric wrote: >>> On 24 Jul 2019, at 14:47, mike tancsa wrote: On 7/23/2019 2:40 PM, Dimitry Andric wrote: > Author: dim > Date: Tue Jul 23 18:40:32 2019 > New Revision: 350256 > URL: https://svnweb.freebsd.org/changeset/base/350256 > Hi, Not sure if this is just a difference in the versions or more things are being compiled, but I noticed a buildworld on my Ryzen went from ~ 31min to just over 40min. Is this expected ? >>> Most likely this is because it will now build a bootstrap compiler, >>> whereas previously your system may have skipped this step. Can you >>> compare the results when setting MK_SYSTEM_COMPILER=no and >>> MK_SYSTEM_LINKER=no ? >> Adding those two to src.conf and make.conf still shows 40min >> >> time make -j14 buildworld > /var/log/build.out ; time make -j14 >> buildkernel > /var/log/build.out. >> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >> 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 65+320io >> 214633pf+0w >> 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io >> 61829pf+0w >> >> Should I be setting these vars somewhere else ? > Ah, setting them in src.conf, make.conf or the environment will be > overridden from Makefile.inc1, unfortunately. It will then show > something like: > > make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: > libclang will be built for bootstrapping a cross-compiler. > make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: > libclang will be built for bootstrapping a cross-linker. > > E.g, it detects that your system compiler is of a lower version than > the compiler in the source tree, and will thus bootstrap the latter. > > Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and > MK_SYSTEM_LINKER=yes? In that case, both before and after r350256, the > results should be fairly similar, I expect. odd, its still taking the same 40min # time make -j14 buildworld > /var/log/build.out ; time make -j14 buildkernel > /var/log/build.out. [Creating objdir /usr/obj/usr/src/amd64.amd64...] 25281.564u 1233.340s 40:31.08 1090.6% 45595+3474k 633698+3288574io 213653pf+0w 1675.796u 172.082s 2:38.19 1168.1% 37746+3170k 205909+3329072io 61654pf+0w Looking at /var/log/build.out, the top line show # head /var/log/build.out --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. --- buildworld_prologue --- despite # 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 ___ 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: 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 17:12, mike tancsa wrote: > > On 7/24/2019 9:45 AM, Dimitry Andric wrote: >> On 24 Jul 2019, at 14:47, mike tancsa wrote: >>> On 7/23/2019 2:40 PM, Dimitry Andric wrote: Author: dim Date: Tue Jul 23 18:40:32 2019 New Revision: 350256 URL: https://svnweb.freebsd.org/changeset/base/350256 >>> Hi, >>> >>>Not sure if this is just a difference in the versions or more things >>> are being compiled, but I noticed a buildworld on my Ryzen went from ~ >>> 31min to just over 40min. Is this expected ? >> Most likely this is because it will now build a bootstrap compiler, >> whereas previously your system may have skipped this step. Can you >> compare the results when setting MK_SYSTEM_COMPILER=no and >> MK_SYSTEM_LINKER=no ? > > Adding those two to src.conf and make.conf still shows 40min > > time make -j14 buildworld > /var/log/build.out ; time make -j14 > buildkernel > /var/log/build.out. > [Creating objdir /usr/obj/usr/src/amd64.amd64...] > 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 65+320io > 214633pf+0w > 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io > 61829pf+0w > > Should I be setting these vars somewhere else ? Ah, setting them in src.conf, make.conf or the environment will be overridden from Makefile.inc1, unfortunately. It will then show something like: make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. E.g, it detects that your system compiler is of a lower version than the compiler in the source tree, and will thus bootstrap the latter. Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and MK_SYSTEM_LINKER=yes? In that case, both before and after r350256, the results should be fairly similar, I expect. -Dimitry signature.asc Description: Message signed with OpenPGP
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/24/2019 9:45 AM, Dimitry Andric wrote: > On 24 Jul 2019, at 14:47, mike tancsa wrote: >> On 7/23/2019 2:40 PM, Dimitry Andric wrote: >>> Author: dim >>> Date: Tue Jul 23 18:40:32 2019 >>> New Revision: 350256 >>> URL: https://svnweb.freebsd.org/changeset/base/350256 >>> >> Hi, >> >> Not sure if this is just a difference in the versions or more things >> are being compiled, but I noticed a buildworld on my Ryzen went from ~ >> 31min to just over 40min. Is this expected ? > Most likely this is because it will now build a bootstrap compiler, > whereas previously your system may have skipped this step. Can you > compare the results when setting MK_SYSTEM_COMPILER=no and > MK_SYSTEM_LINKER=no ? Adding those two to src.conf and make.conf still shows 40min time make -j14 buildworld > /var/log/build.out ; time make -j14 buildkernel > /var/log/build.out. [Creating objdir /usr/obj/usr/src/amd64.amd64...] 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 65+320io 214633pf+0w 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io 61829pf+0w Should I be setting these vars somewhere else ? ---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: 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 14:47, mike tancsa wrote: > > On 7/23/2019 2:40 PM, Dimitry Andric wrote: >> Author: dim >> Date: Tue Jul 23 18:40:32 2019 >> New Revision: 350256 >> URL: https://svnweb.freebsd.org/changeset/base/350256 >> > Hi, > > Not sure if this is just a difference in the versions or more things > are being compiled, but I noticed a buildworld on my Ryzen went from ~ > 31min to just over 40min. Is this expected ? Most likely this is because it will now build a bootstrap compiler, whereas previously your system may have skipped this step. Can you compare the results when setting MK_SYSTEM_COMPILER=no and MK_SYSTEM_LINKER=no ? -Dimitry signature.asc Description: Message signed with OpenPGP
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/Obj
On 7/23/2019 2:40 PM, Dimitry Andric wrote: > Author: dim > Date: Tue Jul 23 18:40:32 2019 > New Revision: 350256 > URL: https://svnweb.freebsd.org/changeset/base/350256 > Hi, Not sure if this is just a difference in the versions or more things are being compiled, but I noticed a buildworld on my Ryzen went from ~ 31min to just over 40min. Is this expected ? ---Mike ps. Thanks for all the work you put in to keeping clang up to date btw!! ___ 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"
