Re: RCS and $FreeBSD$ purge

[Gordon Bergling]

Hi Steve,

On Fri, Jan 26, 2024 at 06:32:26PM -0800, Steve Kargl wrote:
> I'm currently syncing src/lib/msun with my private libm 
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
> contains
> 
> /* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $") */
> 
> Should this be cleaned up or ws intentional left in the 
> source code?

the $FreeBSD$ tags can definitely be removed. I just did a grep through
my working tree and found a lot RCSIDs, so I would tend to keep them
as reference in the source files.

--Gordon


signature.asc
Description: PGP signature

Re: KTLS thread on 14.0-RC3

[Gordon Bergling]

Hi,

On Wed, Nov 01, 2023 at 09:01:32AM +0800, Zhenlei Huang wrote:
> > On Nov 1, 2023, at 8:37 AM, Rick Macklem  wrote:
> > On Tue, Oct 31, 2023 at 10:06 AM John Baldwin  > <mailto:j...@freebsd.org>> wrote:
> >> On 10/30/23 3:41 AM, Zhenlei Huang wrote:
> >>>> On Oct 30, 2023, at 12:09 PM, Zhenlei Huang  wrote:
> >>>>> On Oct 29, 2023, at 5:43 PM, Gordon Bergling  wrote:
> >>>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> I am currently building a new system, which should be based on 
> >>>>> 14.0-RELEASE.
> >>>>> Therefor I am tracking releng/14.0 since its creation and updating it 
> >>>>> currently
> >>>>> via the usualy buildworld steps.
> >>>>> 
> >>>>> What I have noticed recently is, that the [KTLS] is missing. I have a 
> >>>>> stable/13
> >>>>> system which shows the [KTLS] thread and a very recent -CURRENT that 
> >>>>> also shows
> >>>>> the [KTLS] thread.
> >>>>> 
> >>>>> The stable/13 and releng/14.0 systems both use the GENERIC kernel, 
> >>>>> without any
> >>>>> custom modifications.
> >>>>> 
> >>>>> Loaded KLDs are also the same.
> >>>>> 
> >>>>> Did I miss something, or is there something in releng/14.0 missing, 
> >>>>> which
> >>>>> is currenlty enabled in stable/13?
> >>>> 
> >>>> KTLS shall still work as intended, the creation of it threads is 
> >>>> deferred.

Thanks for the information, I wasn't aware of this change.

> >>>> See a72ee355646c (ktls: Defer creation of threads and zones until first 
> >>>> use)
> >>>>> Run ktls_init() when the first KTLS session is created rather than
> >>>>> unconditionally during boot.  This avoids creating unused threads and
> >>>>> allocating unused resources on systems which do not use KTLS.
> >>>> 
> >>>> ```
> >>>> -SYSINIT(ktls, SI_SUB_SMP + 1, SI_ORDER_ANY, ktls_init, NULL);
> >>>> ```
> >>> 
> >>> Seems 14.0 only create one KTLS thread.
> >>> 
> >>> IIRC 13.2 create one thread per core.
> >> 
> >> That part should not be different.  There should always be one thread per 
> >> core.
> > Just fyi, I see one thread/core.
> > Did you happen to do something like "ps ax" instead of "ps axHl"?
> 
> Yes, I typed "ps auxx".  `ps axHl` is the right way to get kernel threads.
> Sorry for the noise.
> 
> > 
> > rick
> > ps: I also see a reclaim_0 thread.

-- Gordon

KTLS thread on 14.0-RC3

[Gordon Bergling]

Hi,

I am currently building a new system, which should be based on 14.0-RELEASE.
Therefor I am tracking releng/14.0 since its creation and updating it currently
via the usualy buildworld steps.

What I have noticed recently is, that the [KTLS] is missing. I have a stable/13
system which shows the [KTLS] thread and a very recent -CURRENT that also shows
the [KTLS] thread.

The stable/13 and releng/14.0 systems both use the GENERIC kernel, without any
custom modifications.

Loaded KLDs are also the same.

Did I miss something, or is there something in releng/14.0 missing, which
is currenlty enabled in stable/13?

Any help for getting an insight on this would be much appreciated.

--Gordon


signature.asc
Description: PGP signature

Re: WITH_BEARSSL: -8112 bytes available

[Gordon Bergling]

Hi,

On Mon, May 29, 2023 at 10:58:27AM +0200, FreeBSD User wrote:
> on CURRENT, enabling in /etc/src.conf
> 
> WITH_BEARSSL=
> 
> seems to result in a slightly enlarged loader binary, which seems to have a 
> fixed size
> supposed on the error I get. See below.
> 
> The system is amd64 (64 bit), for the record.
> 
> Somewhere in the past developers mentioned this upcoming problem and provided 
> a knob to adjust
> the used size - I forgot about that knob and I couldn't find it even in the 
> loader docs - or
> looked at the wrong places.
> 
> Can someone help me out here?
> 
> The first error stops compileing world/kernel, but taking a second run, the 
> error goes away.
> 
> Kind regards and thanks in advance,
> 
> oh
> 
> 
> 
> [...]
> --- all_subdir_stand/efi ---
> SOURCE_DATE_EPOCH=1451606400  objcopy -j .peheader -j .text -j .sdata -j 
> .data  -j .dynamic -j
> .dynsym -j .rel.dyn  -j .rela.dyn -j .reloc -j .eh_frame -j set_Xcommand_set  
> -j
> set_Xficl_compile_set  --output-target=efi-app-x86_64 loader_4th.sym 
> loader_4th.efi ---
> all_subdir_stand/i386 --- 
> 
> -8112 bytes available 7.71 real12.86 user 3.08 sys
> 
> make[1]: stopped in /usr/src
> [...]

I often face a similiar error, not sure if it is BEARSSL related since I build
it since a few month per default, but it often helps just to restart the build.

--Gordon


signature.asc
Description: PGP signature

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hello Mina,

thanks for the PR, I can confirm that this bugfix is working.

@Warner, could you commit it?

I think creating a differential for the small change isn't neccessary.

--Gordon

On Thu, Feb 23, 2023 at 10:05:25AM +, Mina Galić wrote:
> taking Simon off the list, cuz his auto - reply indicates he's very busy.
> 
> Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657
> 
> Mina Galić
> 
> Try PkgBase: https://alpha.pkgbase.live/
> 
>  Original Message 
> On 23 Feb 2023, 09:57, Mina Galić wrote:
> 
> > given that this isn't contrib code, we can just fix it in our tree:
> >
> > https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52
> >
> > Mina Galić
> >
> > Try PkgBase: https://alpha.pkgbase.live/
> >
> >  Original Message 
> > On 23 Feb 2023, 09:27, Gordon Bergling wrote:
> >
> >> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty 
> >> wrote: > This has been fixed upstream, I'll look at importing an update. 
> >> Thanks for merging the upstream fix. BearSSL is now compiling, but I get a 
> >> different error now while building veriexec. 
> >> /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function 
> >> declaration without a prototype is deprecated in all versio ns of C 
> >> [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, 
> >> that the Makefile of veriexec should be updated as well. --Gordon

-- 

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi Simon,

On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote:
> This has been fixed upstream, I'll look at importing an update.

Thanks for merging the upstream fix. BearSSL is now compiling, but I get a
different error now while building veriexec.

  /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration 
without a prototype is deprecated in all versio  ns of C 
[-Werror,-Wstrict-prototypes]
  veriexec_usage()
^
 void

This looks to me, that the Makefile of veriexec should be updated as well.

--Gordon


signature.asc
Description: PGP signature

Re: Missing ktls_ocf.ko

[Gordon Bergling]

Hi Rick,

On Thu, Feb 16, 2023 at 05:49:02AM -0800, Rick Macklem wrote:
> On Thu, Feb 16, 2023 at 12:15 AM Gordon Bergling  wrote:
> >
> > Hi,
> >
> > I recently tried to load ktls_ocf.ko as stated in ktls(4), but on a very
> > recent -CURRENT there is no such kernel module present.
> >
> > Has there anything changed in -CURRENT about this kernel module?
> 
> I don't think the module exists or is needed any more, but jhb@ can confirm
> this.  Sounds like a man page update is needed and that's your specialty.
>

I had the same thought but actually the documentation is already correct,
I just looked at the 13-STABLE man page not on the -CURRENT one.

> >
> > On 13-STABLE and 13.1-RELEASE I find the module in /boot/kernel.

--Gordon


signature.asc
Description: PGP signature

Re: Missing ktls_ocf.ko

[Gordon Bergling]

Hi Herbert,

On Thu, Feb 16, 2023 at 09:37:14AM +0100, Herbert J. Skuhra wrote:
> On Thu, Feb 16, 2023 at 09:15:04AM +0100, Gordon Bergling wrote:
> > Hi,
> > 
> > I recently tried to load ktls_ocf.ko as stated in ktls(4), but on a very
> > recent -CURRENT there is no such kernel module present.
> > 
> > Has there anything changed in -CURRENT about this kernel module?
> > 
> > On 13-STABLE and 13.1-RELEASE I find the module in /boot/kernel.
> 
> commit 21e3c1fbe2460f144f6d4dfd61c3346b2de59667
> Author: John Baldwin
> Date:   Tue May 25 16:59:19 2021 -0700
> 
> Assume OCF is the only KTLS software backend.
> 
> This removes support for loadable software backends.  The KTLS OCF
> support is now always included in kernels with KERN_TLS and the
> ktls_ocf.ko module has been removed.  The software encryption routines
> now take an mbuf directly and use the TLS mbuf as the crypto buffer
> when possible.
> 
> Bump __FreeBSD_version for software backends in ports.
> 
> Reviewed by:gallatin, markj
> Sponsored by:   Netflix
> Differential Revision:  https://reviews.freebsd.org/D30138
> 
> 
> Does this answer your question?

Thanks for pointing me to this commit. This answers my question and I will
update the manual page for 14-CURRENT so that the documentation is matching
the state for 14-CURRENT.

--Gordon


signature.asc
Description: PGP signature

Missing ktls_ocf.ko

[Gordon Bergling]

Hi,

I recently tried to load ktls_ocf.ko as stated in ktls(4), but on a very
recent -CURRENT there is no such kernel module present.

Has there anything changed in -CURRENT about this kernel module?

On 13-STABLE and 13.1-RELEASE I find the module in /boot/kernel.

--Gordon


signature.asc
Description: PGP signature

Re: Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi Warner,

On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh  wrote:
> > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling  wrote:
> >
> >> Hi,
> >>
> >> I am currently seeing a build breakage when building -CURRENT with
> >> WITH_BEARSSL=1.
> >>
> >> The error is the following
> >>
> >>   make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
> >> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2>
> >> /dev/null" returned non-zero status
> >>   /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
> >> a function declaration without a prototype is deprecat  ed in all versions
> >> of C [-Werror,-Wstrict-prototypes]
> >>   br_rsa_i62_keygen_get()
> >>^
> >> void
> >>   1 error generated.
> >>   --- rsa_i62_keygen.pico ---
> >>
> >>
> >> When disabling BEARSSL in the src.conf the build succeeds as usual.
> >>
> >> Has anyone also seen this build error. Sources are very recent and the
> >> src.conf is the following:
> >>
> >> WITH_EXTRA_TCP_STACKS=1
> >> #WITH_BEARSSL=1
> >> WITH_PIE=1
> >> WITH_RETPOLINE=1
> >> WITH_INIT_ALL_ZERO=1
> >> WITH_OPENSSL_KTLS=1
> >> WITHOUT_CLEAN=1
> >>
> >> Any help is very appreciated.
> >>
> >>
> > What does the following do for you? It's a cut and pasted patch, but it
> > should be clear enough what to do if the mailer mangles it.
> >
> > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> > index dd0e242c8ef0..2af4864d8441 100644
> > --- a/lib/libbearssl/Makefile.inc
> > +++ b/lib/libbearssl/Makefile.inc
> > @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
> >  BEARSSL_SRC= ${BEARSSL}/src
> >
> >  CFLAGS+= -I${BEARSSL}/inc
> > -
> > +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
> >
> 
> I went ahead and committed this. Please let me know if the problem persists.

Sorry for the late reply. I just tried a fresh build and it still fails with

[..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function
declaration without a prototype is deprecated in all versions of C 
[-Werror,-Wstrict-prototypes]
  br_rsa_i62_keygen_get()

Did you see any other possibilty to fix this?

--Gordon


signature.asc
Description: PGP signature

Build breakage with WITH_BEARSSL=1

[Gordon Bergling]

Hi,

I am currently seeing a build breakage when building -CURRENT with 
WITH_BEARSSL=1.

The error is the following

  make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109: 
warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls'   -1 *.pem t*.asc 2> 
/dev/null" returned non-zero status
  /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a 
function declaration without a prototype is deprecat  ed in all versions of C 
[-Werror,-Wstrict-prototypes]
  br_rsa_i62_keygen_get()
   ^
void
  1 error generated.
  --- rsa_i62_keygen.pico ---


When disabling BEARSSL in the src.conf the build succeeds as usual.

Has anyone also seen this build error. Sources are very recent and the
src.conf is the following:

WITH_EXTRA_TCP_STACKS=1
#WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1
WITH_INIT_ALL_ZERO=1
WITH_OPENSSL_KTLS=1
WITHOUT_CLEAN=1

Any help is very appreciated.

--Gordon

Re: Buildword Error on a recent -CURRENT

[Gordon Bergling]

Hi Michael,

On Fri, Dec 02, 2022 at 12:02:15PM +0100, Michael Tuexen wrote:
> > On 2. Dec 2022, at 00:30, Gordon Bergling  wrote:
> > 
> > Hello,
> > 
> > I am currently having the following build work error on a recent
> > -CURRENT.
> > 
> > = ===> usr.bin/less (all)
> >  -16372 bytes available
> Not enough space available on the disk?
> 
> Best regards
> Michael

Thanks for the reply.

The ZFS volumes have more then enough diskspace available, but after a second
run the build succeed. I hit that problem often after a few weeks, but maybe
there were some stale files or something like this present.

--Gordon

[...] 
> > Has anyone seen this error before or has recommandation on how to solve it.
> > 
> > My src.conf for building -CURRENT is the following:
> > 
> > WITH_EXTRA_TCP_STACKS=1
> > WITH_BEARSSL=1
> > WITH_PIE=1
> > WITH_RETPOLINE=1
> > WITH_INIT_ALL_ZERO=1
> > WITH_OPENSSL_KTLS=1
> > WITHOUT_CLEAN=1
> > 
> > The usual step if something with WITHOUT_CLEAN isn't working
> > (deleting the obj directory) had no effect.


signature.asc
Description: PGP signature

Buildword Error on a recent -CURRENT

[Gordon Bergling]

Hello,

I am currently having the following build work error on a recent
-CURRENT.

= ===> usr.bin/less (all)
  -16372 bytes available
  --- loader_lua.bin ---
  *** [loader_lua.bin] Error code 1

  make[5]: stopped in /boiler/nfs/src/stand/i386/loader_lua
  --- all_subdir_stand ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_lib ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_usr.bin ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_usr.sbin ---

  make[2]: stopped in /boiler/nfs/src
240.29 real   849.36 user73.97 sys
  --- everything ---

  make[1]: stopped in /boiler/nfs/src
  --- buildworld ---

  make: stopped in /boiler/nfs/src
  make[1]: "/boiler/nfs/src/Makefile.inc1" line 331: SYSTEM_COMPILER: libclang 
will be built for bootstrapping a cross-compiler
  .
  make[1]: "/boiler/nfs/src/Makefile.inc1" line 334: SYSTEM_LINKER: Determined 
that LD=ld matches the source tree.  Not bootstr
  apping a cross-linker.

Has anyone seen this error before or has recommandation on how to solve it.

My src.conf for building -CURRENT is the following:

WITH_EXTRA_TCP_STACKS=1
WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1
WITH_INIT_ALL_ZERO=1
WITH_OPENSSL_KTLS=1
WITHOUT_CLEAN=1

The usual step if something with WITHOUT_CLEAN isn't working
(deleting the obj directory) had no effect.

--Gordon


signature.asc
Description: PGP signature

Re: HEADS-UP: PIE enabled by default on main

[Gordon Bergling]

On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote:
> > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> > > As of 9a227a2fd642 (main-n245052) base system binaries are now built
> > > as position-independent executable (PIE) by default, for 64-bit
> > > architectures. PIE executables are used in conjunction with address
> > > randomization as a mitigation for certain types of security
> > > vulnerabilities.
> > > 
> > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to
> > > do one initial clean build -- either run `make cleanworld` or set
> > > WITH_CLEAN=yes.
> > > 
> > > No significant user-facing changes are expected from this change, but
> > > there are some minor ones. For example, `file` will indicate that
> > > binaries are PIE by reporting something like `ELF 64-bit LSB pie
> > > executable` rather than `ELF 64-bit LSB executable`. Also, for most
> > > workloads no notable performance impact is expected.
> > > 
> > > For almost all ports this should result in no change. There are a
> > > small number of ports that use base system /usr/share/mk
> > > infrastructure and thus inherit the base system default, and some of
> > > those initially failed to build. Those found during an exp-run in
> > > PR253275 have been addressed or have patches waiting.
> > > 
> > > Please watch out for any new issues after you next update the base
> > > system and/or ports, and report issues via a Bugzilla PR or in reply
> > > here.
> > 
> > Thats a huge step forward in terms on security.
> Can you explain why?
> 
> Thanks.

I can try. Enabling PIE for every 64bit architecture is in that matter a step
forward in security as it enables ASLR for further adoption.

Thank You, again.

--Gordon

> > Thanks for the efforts and anyone involved.


signature.asc
Description: PGP signature

Re: HEADS-UP: PIE enabled by default on main

[Gordon Bergling]

On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote:
> As of 9a227a2fd642 (main-n245052) base system binaries are now built
> as position-independent executable (PIE) by default, for 64-bit
> architectures. PIE executables are used in conjunction with address
> randomization as a mitigation for certain types of security
> vulnerabilities.
> 
> If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to
> do one initial clean build -- either run `make cleanworld` or set
> WITH_CLEAN=yes.
> 
> No significant user-facing changes are expected from this change, but
> there are some minor ones. For example, `file` will indicate that
> binaries are PIE by reporting something like `ELF 64-bit LSB pie
> executable` rather than `ELF 64-bit LSB executable`. Also, for most
> workloads no notable performance impact is expected.
> 
> For almost all ports this should result in no change. There are a
> small number of ports that use base system /usr/share/mk
> infrastructure and thus inherit the base system default, and some of
> those initially failed to build. Those found during an exp-run in
> PR253275 have been addressed or have patches waiting.
> 
> Please watch out for any new issues after you next update the base
> system and/or ports, and report issues via a Bugzilla PR or in reply
> here.

Thats a huge step forward in terms on security. Thanks for the efforts and
anyone involved.

--Gordon


signature.asc
Description: PGP signature

Re: review request: loader: implement framebuffer console

[Gordon Bergling]

On Fri, Dec 04, 2020 at 11:23:41PM +0200, Toomas Soome wrote:
> > On 4. Dec 2020, at 23:03, Gordon Bergling  wrote:
> > Tested on a recent -CURRENT, no problems seen so far.
> > 
> > Is there a special src.conf setting that is necessary for a
> > complete build / test sequence.
> 
> No, except that the last update did change default for bios loader to text 
> and did add the knob to change that to gfx mode.
> 
> For test, the default mode should be readable and logo/brand images ok and 
> the console after boot usable as well. The resolution switch (gop or vbe) 
> should end up with usable screen as well, and when you enter menu, the boot 
> menu should be ok.
> 
> gop get/vbe get will list current mode, show screen.font will tell font size.
> 
> Currently it is known the 8-bit depth may have issues in some systems (bios, 
> UEFI only does have 32-bit depth).
> 
> thanks,
> toomas

I have set hw.vga.textmode="0" in the /boot/loader.conf and dmesg
reports "VT(efifb): resolution 1024x768" with the patch applied.
A kyua testrun was successfull.

Hope that helps.

--Gordon

> > On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> >> I have been working on proper framebuffer support on FreeBSD loader and 
> >> there is the current state: https://reviews.freebsd.org/D27420 
> >> <https://reviews.freebsd.org/D27420>
> >> 
> >> All feedback is welcome, and especially if you can spare some time for 
> >> testing:)
> >> 
> >> thanks,
> >> toomas
___
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: review request: loader: implement framebuffer console

[Gordon Bergling]

Tested on a recent -CURRENT, no problems seen so far.

Is there a special src.conf setting that is necessary for a
complete build / test sequence.

--Gordon

On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> I have been working on proper framebuffer support on FreeBSD loader and there 
> is the current state: https://reviews.freebsd.org/D27420 
> 
> 
> All feedback is welcome, and especially if you can spare some time for 
> testing:)
> 
> thanks,
> toomas
> ___
> 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"

Re: review request: loader: implement framebuffer console

[Gordon Bergling]

Hi Toomas,

thanks for working on this. I have a build running and report back
the results from Hyper-V FreeBSD instance.

--Gordon

PS: A few months ago I had a look at all the OpenSolaris incarnations and this
feature was something I had on my TODO list for FreeBSD for a very long time. :)

On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> hi!
> 
> I have been working on proper framebuffer support on FreeBSD loader and there 
> is the current state: https://reviews.freebsd.org/D27420 
> 
> 
> All feedback is welcome, and especially if you can spare some time for 
> testing:)
> 
> thanks,
> toomas
> ___
> 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"

installworld error (Shared object "libncursesw.so.8" not found)

[Gordon Bergling]

Hi,

I am currently getting the following error during a "make installworld":

---
[...]
===> share/zoneinfo/tests (install)
install  -o root  -g wheel -m 555  backward_test  
/usr/tests/share/zoneinfo/backward_test
installing DIRS TESTFILESDIR testsFILESDIR
install  -d -m 0755 -o root  -g wheel  /usr/tests/share/zoneinfo
install  -o root  -g wheel -m 444  /boiler/nfs/src/contrib/tzdata/backward 
/usr/tests/share/zoneinfo/backward
install  -o root  -g wheel -m 444  
/boiler/nfs/src/share/zoneinfo/tests/zoneinfo_common.sh 
/usr/tests/share/zoneinfo/zoneinfo_common.sh
install  -o root  -g wheel -m 444  Kyuafile /usr/tests/share/zoneinfo/Kyuafile
Updating /etc/localtime
ld-elf.so.1: Shared object "libncursesw.so.8" not found, required by "tzsetup"
*** Error code 1

Stop.
make[5]: stopped in /boiler/nfs/src/share/zoneinfo
*** Error code 1
*** Error code 1
*** Error code 1
*** Error code 1

Stop.
make[1]: stopped in /boiler/nfs/src
*** Error code 1
---

I did a complete build with a "make clean cleandepend" before.

Has anyone a hint on how to solve this error?

--Gordon
___
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: Undeletable files after kyua test runs

[Gordon Bergling]

On Sat, Jul 04, 2020 at 10:02:45AM -0700, Enji Cooper wrote:
> > On Jul 4, 2020, at 8:59 AM, Enji Cooper  wrote:
> >> On Jul 2, 2020, at 7:57 PM, Enji Cooper  >> <mailto:yaneurab...@gmail.com>> wrote:
> >>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling  >>> <mailto:g...@freebsd.org>> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> I recently stumbled across undeletable files that are generated by kyua 
> >>> test runs,
> >>> for example
> >>> 
> >>> -rwxr-xr-x  1 root  wheel  0 May  9 13:10 
> >>> /tmp/kyua.aB4q62/8676/work/fileforaudit
> >>> 
> >>> I haven't yet identified the test that generate those files, but it is 
> >>> impossible
> >>> to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, 
> >>> but 
> >>> on every boot the system argues that these file aren't deletable. 
> >>> I tried to 'rm -rf' them by hand but, even this wasn't possible. I have 
> >>> looked for
> >>> any extend attributes, but I didn't find any.
> >>> 
> >>> Has anyone an idea how this is possible and may how these files can be 
> >>> deleted?
> >> 
> >> The issue is tests/sys/audit/file-attribute-modify.c , based on the file 
> >> present that can’t be deleted. Can you please provide more information 
> >> about the test run in a PR (I see how it can leave files behind, but I 
> >> want to make sure it is what I think it is, first)?
> > 
> > PR filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761 
> > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247761> . Working on a 
> > CR.
> 
> Hi,
>   I just created the following CR: https://reviews.freebsd.org/D25561 
> <https://reviews.freebsd.org/D25561> and added the following related GitHub 
> issue to PR: https://github.com/jmmv/kyua/issues/142 
> <https://github.com/jmmv/kyua/issues/142> . This should be completed to avoid 
> issues like this in the future from occurring.
> Thank you for the report!
> -Enji

Hi Enji,

thanks for taking care of this issue and creating a PR. I didn't find the time 
in the last 3 days. Are you still need informationen about the kyua runs?

I usually just do a
# kyua test -k /usr/tests/Kyuafile
once in a while, which results for example in the following undeletable
files / directories.

-rwxr-xr-x  1 root  wheel  0 Jul  1 12:44 
/tmp/kyua.gv1loN/8718/work/fileforaudit
-rwxr-xr-x  1 root  wheel  0 Jul  5 08:50 
/tmp/kyua.FH0CAp/8718/work/fileforaudit

--Gordon
___
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: Undeletable files after kyua test runs

[Gordon Bergling]

On Mon, Jun 29, 2020 at 01:18:12PM -0600, Ian Lepore wrote:
> On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote:
> > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > > g...@freebsd.org> wrote:
> > > > > > I recently stumbled across undeletable files that are
> > > > > > generated by kyua
> > > > > > test runs,
> > > > > > for example
> > > > > > 
> > > > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > > > > 
> > > > > > I haven't yet identified the test that generate those files,
> > > > > > but it is
> > > > > > impossible
> > > > > > to delete them. I have clear_tmp_enable="YES" set in the
> > > > > > /etc/rc.conf, but
> > > > > > on every boot the system argues that these file aren't
> > > > > > deletable.
> > > > > > I tried to 'rm -rf' them by hand but, even this wasn't
> > > > > > possible. I have
> > > > > > looked for
> > > > > > any extend attributes, but I didn't find any.
> > > > > > 
> > > > > > Has anyone an idea how this is possible and may how these
> > > > > > files can be
> > > > > > deleted?
> > > > > 
> > > > > Have you done 'ls -o' to check for flags like schg?
> > > > > --
> > > > > Kevin Oberman, Part time kid herder and retired Network
> > > > > Engineer
> > > > > E-mail: rkober...@gmail.com
> > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > > > 
> > > > Argh, I haven't thought about chflags for quite some time. The
> > > > chflags
> > > > bit was set and after an
> > > > 
> > > > # find /tmp/ -type f -exec chflags -R 0 {} \;
> > > 
> > >^^Only files  ^^ meaningless when chflags is
> > > given ONLY files
> > > 
> > > You probably could of done:
> > > chflags -R 0 /tmp/
> > 
> > Okay, I am currently working on an update for clear_tmp_enable="YES"
> > to include
> > a check like this. I would think that an rc option like this should
> > delete 
> > everything in /tmp.
> > 
> 
> I disagree.  One of the few things those immutable flags are good for
> is protecting files from things like an rc script or other automation
> that deletes files.  Those flags are typically set and maintained by
> users and admins, and automation should not change them in order to
> delete files.
> 
> The real fix we need is for the kyua tests to properly clean up after
> themselves, including fixing the flags on temporary files created or
> used by the tests, and then deleting them.
> 
> -- Ian

A fix for the causing RC script was my first idea, but I had of course
the same idea that a kyua test could be fixed to not end in a state that
leads to file that has chflags set to a value that couldn't be deleted
by a job that is proposed to so.

I take this as a homework and look at the kyua scripts that created
those files.

--Gordon


signature.asc
Description: PGP signature

Re: Undeletable files after kyua test runs

[Gordon Bergling]

On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote:
> > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > > > I recently stumbled across undeletable files that are generated by kyua
> > > > test runs,
> > > > for example
> > > >
> > > > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > > > /tmp/kyua.aB4q62/8676/work/fileforaudit
> > > >
> > > > I haven't yet identified the test that generate those files, but it is
> > > > impossible
> > > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, 
> > > > but
> > > > on every boot the system argues that these file aren't deletable.
> > > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > > > looked for
> > > > any extend attributes, but I didn't find any.
> > > >
> > > > Has anyone an idea how this is possible and may how these files can be
> > > > deleted?
> > > 
> > > Have you done 'ls -o' to check for flags like schg?
> > > --
> > > Kevin Oberman, Part time kid herder and retired Network Engineer
> > > E-mail: rkober...@gmail.com
> > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > 
> > Argh, I haven't thought about chflags for quite some time. The chflags
> > bit was set and after an
> > 
> > # find /tmp/ -type f -exec chflags -R 0 {} \;
>^^Only files  ^^ meaningless when chflags is given 
> ONLY files
> 
> You probably could of done:
> chflags -R 0 /tmp/

Okay, I am currently working on an update for clear_tmp_enable="YES" to include
a check like this. I would think that an rc option like this should delete 
everything in /tmp.
 
> > I was able to finally delete them.
> > 
> > Thanks for the fast respone,
> > 
> > Gordon

--Gordon
___
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: Undeletable files after kyua test runs

[Gordon Bergling]

Hi Kevin,
Hi David,

On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote:
> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling  wrote:
> > I recently stumbled across undeletable files that are generated by kyua
> > test runs,
> > for example
> >
> > -rwxr-xr-x  1 root  wheel  0 May  9 13:10
> > /tmp/kyua.aB4q62/8676/work/fileforaudit
> >
> > I haven't yet identified the test that generate those files, but it is
> > impossible
> > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but
> > on every boot the system argues that these file aren't deletable.
> > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have
> > looked for
> > any extend attributes, but I didn't find any.
> >
> > Has anyone an idea how this is possible and may how these files can be
> > deleted?
> 
> Have you done 'ls -o' to check for flags like schg?
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Argh, I haven't thought about chflags for quite some time. The chflags
bit was set and after an

# find /tmp/ -type f -exec chflags -R 0 {} \;

I was able to finally delete them.

Thanks for the fast respone,

Gordon
___
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"

Undeletable files after kyua test runs

[Gordon Bergling]

Hi,

I recently stumbled across undeletable files that are generated by kyua test 
runs,
for example

-rwxr-xr-x  1 root  wheel  0 May  9 13:10 
/tmp/kyua.aB4q62/8676/work/fileforaudit

I haven't yet identified the test that generate those files, but it is 
impossible
to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but 
on every boot the system argues that these file aren't deletable. 
I tried to 'rm -rf' them by hand but, even this wasn't possible. I have looked 
for
any extend attributes, but I didn't find any.

Has anyone an idea how this is possible and may how these files can be deleted?

--Gordon
___
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: Error loading tcp_bbr kernel module

[Gordon Bergling]

Hi Michael,

On Sat, May 09, 2020 at 05:42:55PM +0200, Michael Tuexen wrote:
> > On 9. May 2020, at 16:25, Gordon Bergling  wrote:
> > I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just 
> > posted the wrong error message. Both TCP stacks weren’t loadable as a 
> > kernel module with just the former mentioned build option.
> > 
> > I currently have build running with both kernel options  you mentioned.
> > 
> > If the build is successful and I can change the default TCP stack to RACK 
> > and BBR I let you know.
> That would be great. I have them running on my machines, but I might have 
> missed something.
> > 
> > Further I didn’t find any documentation within tcp(4) regarding RACK and 
> > BBR. Since I am about to enhance the manpages, I’ll extent tcp(4) about 
> > information about RACK and BBR, but this is a different topic.
> > 
> Yes it is. And I would suggest to use separate man pages, a single one for 
> each stack.
> The the generic man page might refer to them...

My first thoughts on this topic were about to extent tcp(4) and create links to
tcp_rack(4) and tcp_bbr(4), but separate manpages maybe the way to go. I just
have to investigate the respective details. I was once very deep into TCP/IP, 
while building perimeter firewalls with FreeBSD, but this was 20 years ago.

I add you as a reviever for the differential once I have a rough cut 
for the manpages ready.

Best regards,

Gordon

> >> Am 09.05.2020 um 14:37 schrieb Michael Tuexen :
> >>> On 9. May 2020, at 14:18, Gordon Bergling  
> >>> wrote:
> >>> 
> >>> Greetings,
> >>> 
> >>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following 
> >>> error
> >>> when I try to load for example tcp_bbr.ko.
> >>> z
> >>> kldload: an error occurred while loading module tcp_rack.ko. Please check 
> >>> dmesg(8) for more details.
> >> This indicates that you want to load the RACK stack.
> >> 
> >> Please note that you need for BBR and RACK:
> >> optionsTCPHPTS
> >> in the kernel config and in addition to that for RACK
> >> optionsRATELIMIT
> >> 
> >>> dmesg shows:
> >>> 
> >>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
> >>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
> >>> 
> >>> Any hints on solving the problem?
> >>> 
> >>> The kernel config is GENERIC.
> >>> 
> >>> Best regards,
> >>> 
> >>> Gordon
___
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: Error loading tcp_bbr kernel module

[Gordon Bergling]

Hi Michael,

with a kernel config which includes

include GENERIC
options RATELIMIT
options TCPHPTS

applied, I could successfully use
net.inet.tcp.functions_default=bbr
to switch the TCP stack.

Thanks for the fast help,

Gordon

> Am 09.05.2020 um 16:25 schrieb Gordon Bergling :
> 
> Hi Michael,
> 
> thanks for your reply.
> 
> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just 
> posted the wrong error message. Both TCP stacks weren’t loadable as a kernel 
> module with just the former mentioned build option.
> 
> I currently have build running with both kernel options  you mentioned.
> 
> If the build is successful and I can change the default TCP stack to RACK and 
> BBR I let you know.
> 
> Further I didn’t find any documentation within tcp(4) regarding RACK and BBR. 
> Since I am about to enhance the manpages, I’ll extent tcp(4) about 
> information about RACK and BBR, but this is a different topic.
> 
> Best regards,
> 
> Gordon
> 
>> Am 09.05.2020 um 14:37 schrieb Michael Tuexen :
>> 
>>> On 9. May 2020, at 14:18, Gordon Bergling  wrote:
>>> 
>>> Greetings,
>>> 
>>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error
>>> when I try to load for example tcp_bbr.ko.
>>> z
>>> kldload: an error occurred while loading module tcp_rack.ko. Please check 
>>> dmesg(8) for more details.
>> This indicates that you want to load the RACK stack.
>> 
>> Please note that you need for BBR and RACK:
>> options  TCPHPTS
>> in the kernel config and in addition to that for RACK
>> options  RATELIMIT
>> 
>> Best regards
>> Michael
>>> 
>>> dmesg shows:
>>> 
>>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
>>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
>>> 
>>> Any hints on solving the problem?
>>> 
>>> The kernel config is GENERIC.
>>> 
>>> Best regards,
>>> 
>>> Gordon
>>> ___
>>> 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"
> 

___
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: Error loading tcp_bbr kernel module

[Gordon Bergling]

Hi Michael,

thanks for your reply.

I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just posted 
the wrong error message. Both TCP stacks weren’t loadable as a kernel module 
with just the former mentioned build option.

I currently have build running with both kernel options  you mentioned.

If the build is successful and I can change the default TCP stack to RACK and 
BBR I let you know.

Further I didn’t find any documentation within tcp(4) regarding RACK and BBR. 
Since I am about to enhance the manpages, I’ll extent tcp(4) about information 
about RACK and BBR, but this is a different topic.

Best regards,

Gordon

> Am 09.05.2020 um 14:37 schrieb Michael Tuexen :
> 
>> On 9. May 2020, at 14:18, Gordon Bergling  wrote:
>> 
>> Greetings,
>> 
>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error
>> when I try to load for example tcp_bbr.ko.
>> z
>> kldload: an error occurred while loading module tcp_rack.ko. Please check 
>> dmesg(8) for more details.
> This indicates that you want to load the RACK stack.
> 
> Please note that you need for BBR and RACK:
> options   TCPHPTS
> in the kernel config and in addition to that for RACK
> options   RATELIMIT
> 
> Best regards
> Michael
>> 
>> dmesg shows:
>> 
>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
>> 
>> Any hints on solving the problem?
>> 
>> The kernel config is GENERIC.
>> 
>> Best regards,
>> 
>> Gordon
>> ___
>> 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"

___
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"

Error loading tcp_bbr kernel module

[Gordon Bergling]

Greetings,

I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error
when I try to load for example tcp_bbr.ko.

kldload: an error occurred while loading module tcp_rack.ko. Please check 
dmesg(8) for more details.

dmesg shows:

KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type

Any hints on solving the problem?

The kernel config is GENERIC.

Best regards,

Gordon
___
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"

Tinderbox / universe buildfailure with custom options

[Gordon Bergling]

Hi,

I tried to make a tinderbox / universe build today, but it was failing with 
some custom buildoptions. The options are the following:

WITH_EXTRA_TCP_STACKS=1
WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1

What strange is, is, that with a "make buildworld buildkernel" everything works 
fine.
Only the tinderbox / universe target seems to be broken by these options.

Has anyone an idea why the tinderbox / universe target is broken with these
build options?

The following are the, rather shortened, error messages.

===> rescue/rescue (obj,build-tools)
ld: error: can't create dynamic relocation R_X86_64_32S against local symbol in 
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to 
allow text relocations in the output
>>> defined in jsmn.o
>>> referenced by jsmn.c:0 (/boiler/nfs/src/lib/libpmc/pmu-events/jsmn.c:0)
>>>   jsmn.o:(jsmn_parse)

ld: error: can't create dynamic relocation R_X86_64_32S against local symbol in 
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to 
allow text relocations in the output
>>> defined in jsmn.o
>>> referenced by jsmn.c:0 (/boiler/nfs/src/lib/libpmc/pmu-events/jsmn.c:0)
>>>   jsmn.o:(jsmn_parse)

ld: error: can't create dynamic relocation R_X86_64_32S against local symbol in 
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to 
allow text relocations in the output
>>> defined in jsmn.o
>>> referenced by jsmn.c:304 (/boiler/nfs/src/lib/libpmc/pmu-events/jsmn.c:304)
>>>   jsmn.o:(jsmn_strerror)

ld: error: can't create dynamic relocation R_X86_64_32 against local symbol in 
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to 
allow text relocations in the output
>>> defined in jsmn.o
>>> referenced by jsmn.c:316 (/boiler/nfs/src/lib/libpmc/pmu-events/jsmn.c:316)
>>>   jsmn.o:(jsmn_strerror)

ld: error: can't create dynamic relocation R_X86_64_64 against local symbol in 
readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to 
allow text relocations in the output
>>> defined in jsmn.o
>>> referenced by jsmn.c
>>>   jsmn.o:(.rodata+0x0)

--Gordon
___
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: Outdated jemalloc in CURRENT

[Gordon Bergling]

I am not sure, that this info is correct. As far as I remember the update for 
jemalloc was reverted due to build problems, on some architecture. An updated 
revision has still to be commited to -CURRENT.

Gordon

On Sat, Apr 18, 2020 at 07:20:03AM -0700, Steve Kargl wrote:
> On Sat, Apr 18, 2020 at 03:05:25PM +0300, nonamel...@ukr.net wrote:
> > Hi everyone!
> > 
> > As I see, CURRENT still uses outdated jemalloc 5.1.0 with some performance 
> > regressions that was fixed in 5.2.1.
> > 
> > Are there some issues that blocking update jemalloc to recent version?
> > 
> 
> 
> r354606 | jasone | 2019-11-10 21:06:49 -0800 (Sun, 10 Nov 2019) | 4 lines
> 
> Revert r354605: Update jemalloc to version 5.2.1.
> 
> Compilation fails for non-llvm-based platforms.
> 
> 
> r354605 | jasone | 2019-11-10 19:27:14 -0800 (Sun, 10 Nov 2019) | 2 lines
> 
> Update jemalloc to version 5.2.1.
> 
> -- 
> Steve
> ___
> 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"

-- 
Gordon Bergling
Mobile: +49 170 23 10 948
Web: https://www.gordons-perspective.com/
Mail: gbergl...@gmail.com

Think before you print!
___
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"

Build world error with PIE option

[Gordon Bergling]

Hello,

I am trying to build -CURRENT with some custom build options, which are
the following:

WITH_EXTRA_TCP_STACKS=1
WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1

But WITH_PIE=1 seems to break the build while linking sbin/veriexec with the
following error messages.

===> sbin/veriexec (all)
===> lib/libkvm/tests (all)
ld: error: unable to find library -lveriexec_pie
ld: error: unable to find library -lsecureboot_pie
ld: error: unable to find library -lbearssl_pie
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- veriexec.full ---
*** [veriexec.full] Error code 1

make[4]: stopped in /boiler/nfs/src/sbin/veriexec
1 error

make[4]: stopped in /boiler/nfs/src/sbin/veriexec
--- all_subdir_sbin/veriexec ---
*** [all_subdir_sbin/veriexec] Error code 2

Has anyone experienced the same error and was able to solve it? Or has anyone
an idea how to solve this problem?

Best regards,

Gordon
___
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: about loader & console

[Gordon Bergling]

nd now I am porting it to different 
> terminal emulator.
> 
> I hope this writeup does give some light about what is happening in this area.
> 
> thanks,
> toomas
> ___
> 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"

-- 
Gordon Bergling
Mobile: +49 170 23 10 948
Web: https://www.gordons-perspective.com/
Mail: gbergl...@gmail.com

Think before you print!
___
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"

KCSAN error messages and system hang

[Gordon Bergling]

Greetings,

I recently experimented with a KCSAN enabled kernel on -CURRENT and got the
following error messages.

CSan: Racy Access [Cpu0 Write Addr=0xfe000297f0c8 Size=4 
PC=0x8116a31a] [Cpu1 Read Addr=0xfe000297f0c8 Size=4 
PC=0x8116b3b8]

CSan: Racy Access [Cpu0 Read Addr=0x82314e10 Size=8 
PC=0x8113a66c] [Cpu1 Write Addr=0x82314e10 Size=8 
PC=0x8113c3a8]

CSan: Racy Access [Cpu0 Write Addr=0xf8003eb646e8 Size=8 
PC=0x811cd358] [Cpu1 Write Addr=0xf8003eb646e8 Size=8 
PC=0x811cd358]

CSan: Racy Access [Cpu0 Write Addr=0x831fd0dc Size=1 
PC=0x81169f38] [Cpu1 Read Addr=0x831fd0dc Size=1 
PC=0x811672f8]

CSan: Racy Access [Cpu0 Write Addr=0x831fd0dc Size=1 
PC=0x81169f38] [Cpu1 Read Addr=0x831fd0dc Size=1 
PC=0x8116512c]

CSan: Racy Access [Cpu1 Write Addr=0xfe0015897400 Size=8 
PC=0x82bf5877] [Cpu0 Read 
Addr=0xfe0015897400 Size=8 PC=0x82bf545c]

CSan: Racy Access [Cpu1 Write Addr=0xf800fee000b0 Size=4 
PC=0x819574b0] [Cpu0 Write Addr=0xf800fee000b0 
Size=4 PC=0x819574b0]

CSan: Racy Access [Cpu0 Write Addr=0xf800fee00320 Size=4 
PC=0x81959f1a] [Cpu1 Write Addr=0xf800fee00320 
Size=4 PC=0x81959f1a]

CSan: Racy Access [Cpu1 Write Addr=0xf8000bb268c4 Size=4 
PC=0x8168f96b] [Cpu0 Read Addr=0xf8000bb268c4 
Size=4 PC=0x8166f847]

CSan: Racy Access [Cpu0 Read Addr=0x831fd0c8 Size=4 
PC=0x81169e81] [Cpu1 Write Addr=0x831fd0c8 
Size=4 PC=0x8116a31a]

CSan: Racy Access [Cpu1 Write Addr=0xf800fee00320 Size=4 
PC=0x81959f1a] [Cpu0 Write Addr=0xf800fee00320 
Size=4 PC=0x81959f1a]

CSan: Racy Access [Cpu0 Write Addr=0x831fd0c8 Size=4 
PC=0x81167b4e] [Cpu1 Read Addr=0x831fd0c8 Size=4 
PC=0x811654de]

These messages appeared during boot. Any hints on debugging this further? 
I am not sure on how to find the corresponding code that leads to this error 
messages.

Another problem with the KCSAN configuration is that the system reproducibly 
hangs after a few minutes. Any hints how to debug a hang where also much 
appreciated.

Best regards,

Gordon
___
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: Building -CURRENT on -STABLE

[Gordon Bergling]

Hi,

if someone is facing the same error, the build variable MAKEOBJDIRPREFIX must 
be set within the environment and _not_ within the make context. I would also 
suggest that the source and object directories are on the same partition. 

My sources where located in my home directory and the object directory on a 
separate zfs pool, but using symlinks to fake the directory structure 
wasn't successful. With the following steps I was able to build on the fast
machine, and install via nfs on the client.

On the build machine:
# mkdir -p /boiler/nfs/{src,obj}
# export MAKEOBJDIRPREFIX=/boiler/nfs/obj
# cd /boiler/nfs/src && git pull
# make -s -j 4 buildworld buildkernel > /boiler/nfs/logs/build.log 2>&1

On the target machine (assuming server:/boiler/nfs is mounted on /boiler/nfs at 
the client)
# env MAKEOBJDIRPREFIX=/boiler/nfs/obj make installkernel
# env MAKEOBJDIRPREFIX=/boiler/nfs/obj make installworld
# mergemaster -Ui -m /boiler/nfs/src/

Best,

Gordon

On Thu, Jan 09, 2020 at 11:45:21AM +0100, Gordon Bergling wrote:
> Hi,
> 
> I am currently about to setup an -CURRENT system, which should gets updated 
> via a build 
> server that’s runs on -STABLE and shares the src and obj directories via NFS 
> to -CURRENT system.
> 
> While doing a „make -s -j 4 buildworld buildkernel“ the builds fails randomly 
> with the following error.
> 
> -
> ===> sbin/fsirand (all)
> ===> sbin/gbde (all)
> ===> sbin/geom (all)
> ===> kerberos5/libexec/kimpersonate (all)
> ld: error: undefined symbol: glabel_class_commands
> >>> referenced by geom.c
> >>>   geom.o:(get_class)
> 
> ld: error: undefined symbol: glabel_version
> >>> referenced by geom.c
> >>>   geom.o:(get_class)
> 
> ld: error: undefined symbol: gpart_class_commands
> >>> referenced by geom.c
> >>>   geom.o:(get_class)
> 
> ld: error: undefined symbol: gpart_version
> >>> referenced by geom.c
> >>>   geom.o:(get_class)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> --- geom.full ---
> *** [geom.full] Error code 1
> 
> make[4]: stopped in /home/gbergling/sources/freebsd/freebsd/sbin/geom
> 1 error
> 
> make[4]: stopped in /home/gbergling/sources/freebsd/freebsd/sbin/geom
> A failure has been detected in another branch of the parallel make
> -
> 
> I also tried the build without the „j“-Flag but the error was the same.
> 
> Do you have any hints what could have caused this?
> 
> The -STABLE machine is stock and no special things are setup within src.conf 
> or make.conf.
> 
> Best regards,
> 
> Gordon
___
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"

Building -CURRENT on -STABLE

[Gordon Bergling]

Hi,

I am currently about to setup an -CURRENT system, which should gets
updated via a build server that’s runs on -STABLE and shares the src
and obj directories via NFS to -CURRENT system.

While doing a „make -s -j 4 buildworld buildkernel“ the builds fails
randomly with the following error.

-
===> sbin/fsirand (all)
===> sbin/gbde (all)
===> sbin/geom (all)
===> kerberos5/libexec/kimpersonate (all)
ld: error: undefined symbol: glabel_class_commands
>>> referenced by geom.c
>>>   geom.o:(get_class)

ld: error: undefined symbol: glabel_version
>>> referenced by geom.c
>>>   geom.o:(get_class)

ld: error: undefined symbol: gpart_class_commands
>>> referenced by geom.c
>>>   geom.o:(get_class)

ld: error: undefined symbol: gpart_version
>>> referenced by geom.c
>>>   geom.o:(get_class)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
--- geom.full ---
*** [geom.full] Error code 1

make[4]: stopped in /home/gbergling/sources/freebsd/freebsd/sbin/geom
1 error

make[4]: stopped in /home/gbergling/sources/freebsd/freebsd/sbin/geom
A failure has been detected in another branch of the parallel make
-

I also tried the build without the „j“-Flag but the error was the same.

Do you have any hints what could have caused this?

The -STABLE machine is stock and no special things are setup within
src.conf or make.conf.

Best regards,

Gordon
___
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"

-current want't boot this morning

[Gordon Bergling]

Hi,

I tried to boot my -current this morning but the boot process only goes
to bootmgr. She shows normal

F1  FreeBSD
F2  Other   (not sure if this is (Other||Unknown)

After pressing F1-Key the computer resets himself. I tried to wait but
on autoboot the same thing happens.

For less then a second it show something like a hexdump. It is too fast
to read it. ;)

The -current was build yesterday with recent sources.

Any hints?


best regards,

Gordon
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

lock order reversal under recent -CURRENT

[Gordon Bergling]

Hi,

under a recent -CURRENT I get this:
---
lock order reversal
 1st 0xc2e475c8 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:432
 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:328
Stack backtrace:
backtrace(c03c9d09,c082f110,c03d8851,c03d8851,c03d86ec) at backtrace+0x17
witness_lock(c082f110,8,c03d86ec,148,0) at witness_lock+0x697
_mtx_lock_flags(c082f110,0,c03d86ec,148,3) at _mtx_lock_flags+0xb1
_vm_map_lock(c082f0b0,c03d86ec,148,d26e3a54,c0247ce4) at _vm_map_lock+0x36
kmem_malloc(c082f0b0,1000,101,d26e3ac0,c03586e0) at kmem_malloc+0x66
page_alloc(c083a240,1000,d26e3ab3,101,c041066c) at page_alloc+0x27
slab_zalloc(c083a240,101,c03da0b0,66e,c26c56e4) at slab_zalloc+0x150
uma_zone_slab(c083a240,101,c03da0b0,66e,0) at uma_zone_slab+0xd8
uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55
uma_zfree_arg(c26c56c0,d1db6bdc,0,1,0) at uma_zfree_arg+0x2cb
swp_pager_meta_free_all(c2e475c8,c03d8044,c03d7fd8,1b2) at 
swp_pager_meta_free_all+0x1b0
swap_pager_dealloc(c2e475c8,1,c03d9fb3,10c,0) at swap_pager_dealloc+0x113
vm_pager_deallocate(c2e475c8,0,c03d9189,25f,0) at vm_pager_deallocate+0x3d
vm_object_terminate(c2e475c8,0,c03d9189,1b0,c02388e0) at vm_object_terminate+0x1f4
vm_object_deallocate(c2e475c8,c2da999c,c2e475c8,c2da999c,d26e3c64) at 
vm_object_deallocate+0x377
vm_map_entry_delete(c2dad800,c2da999c,c03d88bf,86d,c03c54da) at 
vm_map_entry_delete+0x3b
vm_map_delete(c2dad800,0,bfc0,c2dad800,c26b7400) at vm_map_delete+0x413
vm_map_remove(c2dad800,0,bfc0,11d,c03c4a8b) at vm_map_remove+0x58
exit1(c2c8c980,0,c03c4a8b,65,d26e3d40) at exit1+0x696
sys_exit(c2c8c980,d26e3d10,c03dd56d,3fd,1) at sys_exit+0x41
syscall(2f,2f,2f,0,e34) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (1), eip = 0x2851d44f, esp = 0xbfbff840, ebp = 0xbfbff86c ---
-

`uname -a` says:
-
FreeBSD nemesis.bsd-network.org 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Mon
Jun 23 00:30:36 CEST 2003 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEMESIS  i386
-

The LOR happens at normal work under X. A few xterm, mozilla, gimp and
gqview. Not very wild things.

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [solved] buildworld error

[Gordon Bergling]

Hi all,

On Tue Jun 10, 2003 at 07:50PM -0400, Garance A Drosihn wrote:
 At 9:42 PM +0200 6/10/03, Gordon Bergling wrote:
 Since I disable BDECFLAGS in /etc/make.conf this problem goes
 away. I don't know if this effects the build process in any
 other way. I had enable them around 4.5-RELEASE or so. ;)
 
 I'm not sure what you mean by that.  Did you remove a line
 which had
 BDECFLAGS=...etc...
 
 or did you remove a line which said something like
 CFLAGS=$BDECFLAGS
 ?

I comment out the BDECFLAGS lines in /etc/make.conf. The
appendanting lines I comment out, too.

 If you mean the first one, that probably means some makefile
 has a reference to BDECFLAGS and it (probably) should not.

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Serious ppp failure on 5.1

[Gordon Bergling]

Hi,

On Tue Jun 10, 2003 at 09:02AM +0200, Lukas Kaminski wrote:
 On Mon, 9 Jun 2003, Kris Kennaway wrote:
  On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
   after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
   anymore.
   Using ppp manually I receive:
 Unexpected node type socket (wanted ether)
   The connection works fine on my 4.8 with identical ppp.conf .
  
   What can I do ?
 Same problem with cvsup from 5.1 Beta to 5.1-CURRENT
 The ppp.conf is the same as described in the handbook (pppoe).
 mpd still works.

Same here. All modules are compiled into the kernel. Iam using now the
ppp from a 5.1-RELEASE ISO.

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [solved] buildworld error

[Gordon Bergling]

Hi all,

On Mon Jun 09, 2003 at 11:09PM +0200, Gordon Bergling wrote:
 On Mon Jun 09, 2003 at 11:06PM +0300, Ruslan Ermilov wrote:
  On Mon, Jun 09, 2003 at 06:42:11PM +0200, Gordon Bergling wrote:
   since a few days I getting a curious error when I try to build the
   world. Iam using -CURRENT, with sources from a few minutes ago.
   The first error with full error messages can be found on
   http://www.0xfce3.net/error.txt. It seems that src/usr.sbin/config was
   broken. After the commit of the src/Makefile.inc1 to 1.364. This error
   goes away. Now the make process goes nearly to the end but after compiling
   src/usr.sbin/config again (at the later build process) I getting the
   same error again. This error message can be found at
   http://www.0xfce3.net/buildworld.txt. The same error appears. If it is
   from interesst my dmesg output and the `uname -a` can be viewed at
   http://www.0fce3.net/system.txt!

Since I disable BDECFLAGS in /etc/make.conf this problem goes away. I
don't know if this effects the build process in any other way. I had
enable them around 4.5-RELEASE or so. ;)

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [solved] buildworld error

[Gordon Bergling]

On Tue Jun 10, 2003 at 01:17PM -0700, Kris Kennaway wrote:
  Since I disable BDECFLAGS in /etc/make.conf this problem goes away. I
  don't know if this effects the build process in any other way. I had
  enable them around 4.5-RELEASE or so. ;)
 
 That's entirely expected.  Whatever gave you the idea that this would
 be good thing to add to CFLAGS in the first place?

-From /etc/make.conf --
# BDECFLAGS are a set of gcc warning settings that Bruce Evans has
# suggested
# for use in developing FreeBSD and testing changes.  They can be used
# by
# putting CFLAGS+=${BDECFLAGS} in /etc/make.conf.  -Wconversion is not
# included here due to compiler bugs, e.g., mkdir()'s mode_t argument.
---
This sounds for me the right thing for use in -CURRENT.
Iam sure this was wrong, but I make this setting months ago and forgot
it. There were never be problems until these days.

best regards,

Gordon

-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

buildworld error

[Gordon Bergling]

Hi folks,

since a few days I getting a curious error when I try to build the
world. Iam using -CURRENT, with sources from a few minutes ago.
The first error with full error messages can be found on
http://www.0xfce3.net/error.txt. It seems that src/usr.sbin/config was
broken. After the commit of the src/Makefile.inc1 to 1.364. This error
goes away. Now the make process goes nearly to the end but after compiling
src/usr.sbin/config again (at the later build process) I getting the
same error again. This error message can be found at
http://www.0xfce3.net/buildworld.txt. The same error appears. If it is
from interesst my dmesg output and the `uname -a` can be viewed at
http://www.0fce3.net/system.txt!

That seems to be a local problem, because now one has reported this
error, too. I don't have any compilers flags in /etc/make.conf set.

Any Ideas?

best regards and sorry for my bad english ;)

Gordon


-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: buildworld error

[Gordon Bergling]

On Mon Jun 09, 2003 at 11:06PM +0300, Ruslan Ermilov wrote:
 On Mon, Jun 09, 2003 at 06:42:11PM +0200, Gordon Bergling wrote:
  since a few days I getting a curious error when I try to build the
  world. Iam using -CURRENT, with sources from a few minutes ago.
  The first error with full error messages can be found on
  http://www.0xfce3.net/error.txt. It seems that src/usr.sbin/config was
  broken. After the commit of the src/Makefile.inc1 to 1.364. This error
  goes away. Now the make process goes nearly to the end but after compiling
  src/usr.sbin/config again (at the later build process) I getting the
  same error again. This error message can be found at
  http://www.0xfce3.net/buildworld.txt. The same error appears. If it is
  from interesst my dmesg output and the `uname -a` can be viewed at
  http://www.0fce3.net/system.txt!
  
  That seems to be a local problem, because now one has reported this
  error, too. I don't have any compilers flags in /etc/make.conf set.
  
 Just a wild guess.  Make sure the ident /usr/bin/sed | grep -w process
 command doesn't show you revision 1.30.

[EMAIL PROTECTED]:~ ident /usr/bin/sed | grep -w process
 $FreeBSD: src/usr.bin/sed/process.c,v 1.29 2002/09/20 19:40:23 eric
 Exp $

It seems that this had nothing to do with a broken sed.

Any other ideas?

best regards,

Gordon


-- 
There is no place like 127.0.0.1/8!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]