Re: sort.core error doing installworld on Current.
> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > > > So you some how had a sort core dump sitting in > > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how > > did get there? I'd take a look at the date on the file and, it it is older > > than the buildworld, just assume that it was left-over garbage. In either > > case, you can delete it and do another installworld. > > > > That should most likely fix things, but, if the buildworld or installworld > > had a crash of sort(1) that left the file, further investigation might be > > needed. Re-making the zoneinfo would help track it down should this be a re > > al bug, but it's my uneducated guess that it's not. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > Please forgive that awful post! I missed a part of your message by laziness. > > It's odd that the error of sort(1) crashing was not caught by the script. Yes, that is a Makefile flaw someplace. Further there must be a wildcard being used to decide which files to install, that is a further Makefile flaw. Wildcards should NOT be used in the source of an install list, exactly because of this type of cruft that can be dropped in an obj dir. > Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch > something. Looking at the core might tell you which "sort" was involved... > the one you just built or the one in the base system. This could be just a > FOTU, but I would not bet on it. I suspect a recent zoneinfo commit as the root cause. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > > > > > > On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks > > wrote: > > > >> I have a machine running FreeBSD head. > >> rev 13.0-CURRENT #11 r360008 > >> > >> This is a quite powerful machine, so i thought it was a good idea to let > >> that server do the build and for my virtualbox machine i can use the > >> powerful machine to do a installword over NFS. > >> > >> But when i did the make installworld step the client so to say gives an > >> error. > >> > >> install -o root -g wheel -m 444 > >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu > >> /usr/share/zoneinfo/Zulu > >> install -o root -g wheel -m 444 > >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules > >> /usr/share/zoneinfo/posixrules > >> install -o root -g wheel -m 444 > >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core > >> /usr/share/zoneinfo/sort.core > >> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: > >> Permission denied > >> *** Error code 71 > >> > >> Stop. > >> bmake[5]: stopped in /usr/src/share/zoneinfo > >> *** Error code 1 > >> > >> Stop. > >> bmake[4]: stopped in /usr/src/share > >> *** Error code 1 > >> > >> Stop. > >> bmake[3]: stopped in /usr/src > >> *** Error code 1 > >> > >> Stop. > >> bmake[2]: stopped in /usr/src > >> *** Error code 1 > >> > >> Stop. > >> bmake[1]: stopped in /usr/src > >> *** Error code 1 > >> > >> Stop. > >> make: stopped in /usr/src > >> .ERROR_TARGET='installworld' > >> .ERROR_META_FILE='' > >> .MAKE.LEVEL='0' > >> MAKEFILE='' > >> .MAKE.MODE='normal' > >> _ERROR_CMD='.PHONY' > >> .CURDIR='/usr/src' > >> .MAKE='make' > >> .OBJDIR='/usr/obj/usr/src/amd64.amd64' > >> .TARGETS='installworld' > >> DESTDIR='' > >> LD_LIBRARY_PATH='' > >> MACHINE='amd64' > >> MACHINE_ARCH='amd64' > >> MAKEOBJDIRPREFIX='/usr/obj' > >> MAKESYSPATH='/usr/src/share/mk' > >> MAKE_VERSION='20181221' > >> PATH='/sbin:/bin:/usr/sbin:/usr/bin' > >> SRCTOP='/usr/src' > >> OBJTOP='/usr/obj/usr/src/amd64.amd64' > >> > >> It looks likes sort coredumps in the usr/share/zoneinfo part of the base. > >> As it has no permission on the NFS share it errors out. > >> On the server itself, the installworld goes well, but it leaves a > >> sort.core file behind in /usr/share/zoneinfo > >> > >> cd /usr/share/zoneinfo > >> ls -al > >> > >> > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sort.core error doing installworld on Current.
On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman wrote: > So you some how had a sort core dump sitting in > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how > did get there? I'd take a look at the date on the file and, it it is older > than the buildworld, just assume that it was left-over garbage. In either > case, you can delete it and do another installworld. > > That should most likely fix things, but, if the buildworld or installworld > had a crash of sort(1) that left the file, further investigation might be > needed. Re-making the zoneinfo would help track it down should this be a re > al bug, but it's my uneducated guess that it's not. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > Please forgive that awful post! I missed a part of your message by laziness. It's odd that the error of sort(1) crashing was not caught by the script. Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch something. Looking at the core might tell you which "sort" was involved... the one you just built or the one in the base system. This could be just a FOTU, but I would not bet on it. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks > wrote: > >> I have a machine running FreeBSD head. >> rev 13.0-CURRENT #11 r360008 >> >> This is a quite powerful machine, so i thought it was a good idea to let >> that server do the build and for my virtualbox machine i can use the >> powerful machine to do a installword over NFS. >> >> But when i did the make installworld step the client so to say gives an >> error. >> >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu >> /usr/share/zoneinfo/Zulu >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules >> /usr/share/zoneinfo/posixrules >> install -o root -g wheel -m 444 >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core >> /usr/share/zoneinfo/sort.core >> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core: >> Permission denied >> *** Error code 71 >> >> Stop. >> bmake[5]: stopped in /usr/src/share/zoneinfo >> *** Error code 1 >> >> Stop. >> bmake[4]: stopped in /usr/src/share >> *** Error code 1 >> >> Stop. >> bmake[3]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> bmake[2]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> bmake[1]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src >> .ERROR_TARGET='installworld' >> .ERROR_META_FILE='' >> .MAKE.LEVEL='0' >> MAKEFILE='' >> .MAKE.MODE='normal' >> _ERROR_CMD='.PHONY' >> .CURDIR='/usr/src' >> .MAKE='make' >> .OBJDIR='/usr/obj/usr/src/amd64.amd64' >> .TARGETS='installworld' >> DESTDIR='' >> LD_LIBRARY_PATH='' >> MACHINE='amd64' >> MACHINE_ARCH='amd64' >> MAKEOBJDIRPREFIX='/usr/obj' >> MAKESYSPATH='/usr/src/share/mk' >> MAKE_VERSION='20181221' >> PATH='/sbin:/bin:/usr/sbin:/usr/bin' >> SRCTOP='/usr/src' >> OBJTOP='/usr/obj/usr/src/amd64.amd64' >> >> It looks likes sort coredumps in the usr/share/zoneinfo part of the base. >> As it has no permission on the NFS share it errors out. >> On the server itself, the installworld goes well, but it leaves a >> sort.core file behind in /usr/share/zoneinfo >> >> cd /usr/share/zoneinfo >> ls -al >> >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sort.core error doing installworld on Current.
ai you some how had a sort core dump sitting in
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
did get there? I'd take a look at the date on the file and, it it is older
than the buildworld, just assume that it was left-over garbage. In either
case, you can delete it and do another installworld.
That should most likely fix things, but, if the buildworld or installworld
had a crash of sort(1) that left the file, further investigation might be
needed. Re-making the zoneinfo would help track it down should this be a
rel bug, but it's my uneducated guess that it's not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks
wrote:
> I have a machine running FreeBSD head.
> rev 13.0-CURRENT #11 r360008
>
> This is a quite powerful machine, so i thought it was a good idea to let
> that server do the build and for my virtualbox machine i can use the
> powerful machine to do a installword over NFS.
>
> But when i did the make installworld step the client so to say gives an
> error.
>
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> /usr/share/zoneinfo/Zulu
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> /usr/share/zoneinfo/posixrules
> install -o root -g wheel -m 444
> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> /usr/share/zoneinfo/sort.core
> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> Permission denied
> *** Error code 71
>
> Stop.
> bmake[5]: stopped in /usr/src/share/zoneinfo
> *** Error code 1
>
> Stop.
> bmake[4]: stopped in /usr/src/share
> *** Error code 1
>
> Stop.
> bmake[3]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> bmake[2]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> bmake[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
> .ERROR_TARGET='installworld'
> .ERROR_META_FILE=''
> .MAKE.LEVEL='0'
> MAKEFILE=''
> .MAKE.MODE='normal'
> _ERROR_CMD='.PHONY'
> .CURDIR='/usr/src'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64'
> .TARGETS='installworld'
> DESTDIR=''
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX='/usr/obj'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20181221'
> PATH='/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src/amd64.amd64'
>
> It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
> As it has no permission on the NFS share it errors out.
> On the server itself, the installworld goes well, but it leaves a
> sort.core file behind in /usr/share/zoneinfo
>
> cd /usr/share/zoneinfo
> ls -al
> -r--r--r-- 1 root wheel 118 Apr 16 20:25 Zulu
> -r--r--r-- 1 root wheel3519 Apr 16 20:25 posixrules
> -r--r--r-- 1 root wheel 8982528 Apr 16 20:25 sort.core
> -r--r--r-- 1 root wheel 19424 Apr 16 20:25 zone.tab
> -r--r--r-- 1 root wheel 17955 Apr 16 20:25 zone1970.tab
>
> my src.conf file looks like this
> WITHOUT_BLUETOOTH=yes
> WITHOUT_CALENDAR=yes
> WITHOUT_DICT=yes
> WITHOUT_GAMES=yes
> WITHOUT_I4B=yes
> WITHOUT_IPFILTER=yes
> WITHOUT_IPX=yes
> WITHOUT_LPR=yes
> WITHOUT_PROFILE=yes
> WITHOUT_SENDMAIL=yes
> WITHOUT_SHAREDOCS=yes
> WITHOUT_WIRELESS=yes
> WITHOUT_HAST=yes
> WITHOUT_LLVM_TARGET_{MIPS,POWERPC,SPARC,RISCV}= YES
> WITHOUT_LIB32=yes
>
> in /etc/make.conf i have the following
> MALLOC_PRODUCTION=yes
> BATCH_DELETE_OLD_FILES= yes
> CUPS_OVERWRITE_BASE=yes
>
>
> What can i do about this?
>
> Thank you for your time.
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sort.core error doing installworld on Current.
I have a machine running FreeBSD head.
rev 13.0-CURRENT #11 r360008
This is a quite powerful machine, so i thought it was a good idea to let
that server do the build and for my virtualbox machine i can use the
powerful machine to do a installword over NFS.
But when i did the make installworld step the client so to say gives an
error.
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
/usr/share/zoneinfo/Zulu
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
/usr/share/zoneinfo/posixrules
install -o root -g wheel -m 444
/usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
/usr/share/zoneinfo/sort.core
install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
Permission denied
*** Error code 71
Stop.
bmake[5]: stopped in /usr/src/share/zoneinfo
*** Error code 1
Stop.
bmake[4]: stopped in /usr/src/share
*** Error code 1
Stop.
bmake[3]: stopped in /usr/src
*** Error code 1
Stop.
bmake[2]: stopped in /usr/src
*** Error code 1
Stop.
bmake[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
.ERROR_TARGET='installworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='installworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
As it has no permission on the NFS share it errors out.
On the server itself, the installworld goes well, but it leaves a
sort.core file behind in /usr/share/zoneinfo
cd /usr/share/zoneinfo
ls -al
-r--r--r-- 1 root wheel 118 Apr 16 20:25 Zulu
-r--r--r-- 1 root wheel 3519 Apr 16 20:25 posixrules
-r--r--r-- 1 root wheel 8982528 Apr 16 20:25 sort.core
-r--r--r-- 1 root wheel 19424 Apr 16 20:25 zone.tab
-r--r--r-- 1 root wheel 17955 Apr 16 20:25 zone1970.tab
my src.conf file looks like this
WITHOUT_BLUETOOTH=yes
WITHOUT_CALENDAR=yes
WITHOUT_DICT=yes
WITHOUT_GAMES=yes
WITHOUT_I4B=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_LPR=yes
WITHOUT_PROFILE=yes
WITHOUT_SENDMAIL=yes
WITHOUT_SHAREDOCS=yes
WITHOUT_WIRELESS=yes
WITHOUT_HAST=yes
WITHOUT_LLVM_TARGET_{MIPS,POWERPC,SPARC,RISCV}= YES
WITHOUT_LIB32=yes
in /etc/make.conf i have the following
MALLOC_PRODUCTION=yes
BATCH_DELETE_OLD_FILES= yes
CUPS_OVERWRITE_BASE=yes
What can i do about this?
Thank you for your time.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildkernel failure because ctfconvert not installed
> On Apr 10, 2020, at 12:57 AM, Poul-Henning Kamp wrote:
>
>
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov
> writes:
>> Trond Endrestøl wrote:
>>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>>>
OK, I figured it out.
I used to have MK_CTF=no in src.conf, but I recently changed it to
WITH_CTF=no.
>>>
>>> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
>>
>> Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
>> value is NOT checked:
>>
>> The values of variables are ignored regardless of their setting; even if
>> they would be set to "FALSE" or "NO". The presence of an option
>> causes it to be honored by make(1).
>
> That is not even close to POLA-compliance...
>
> Obviously negative values ("false", "no") should either be reported as
> errors or preferably be respected.
>
> PS: [This is not the bikeshed you are looking for]
>
I remember being slightly astonished by the current behavior in the early/mid
2000’s. Then
I learned, adapted, and got over it. Change happens, often for the best.
Being stuck in the
past doesn’t help, and neither does Rodney’s action of berating, belittling,
and gaslighting
people who don't agree with him.
POLA is a good mental check to help guide decisions, but it’s not set in stone.
Nothing
should be set in stone, we should all be willing and able to evaluate
circumstances and
make new decisions. Being robotic and set in stone is an excuse for being lazy
and/or
egotistical.
Scott
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: if_bridge performance improvements
On 16 Apr 2020, at 8:34, Pavel Timofeev wrote: Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? I’ve not tested it, but I believe that epair scales significantly better than tap. It has a per-cpu mutex (or more accurately, a mutex in each of its per-cpu structures), so I’d expect much better throughput from epair than you’d see from tap. Best regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: if_bridge performance improvements
вт, 14 апр. 2020 г., 12:51 Kristof Provost : > Hi, > > Thanks to support from The FreeBSD Foundation I’ve been able to work > on improving the throughput of if_bridge. > It changes the (data path) locking to use the NET_EPOCH infrastructure. > Benchmarking shows substantial improvements (x5 in test setups). > > This work is ready for wider testing now. > > It’s under review here: https://reviews.freebsd.org/D24250 > > Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true > Patches for stable/12: > https://people.freebsd.org/~kp/if_bridge/stable_12/ > > I’m not currently aware of any panics or issues resulting from these > patches. > > Do note that if you run a Bhyve + tap on bridges setup the tap code > suffers from a similar bottleneck and you will likely not see major > improvements in single VM to host throughput. I would expect, but have > not tested, improvements in overall throughput (i.e. when multiple VMs > send traffic at the same time). > > Best regards, > Kristof > Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
