date:20200327

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

2020-03-27 Thread Graham Perrin


This occurs when I enable OpenZFS:

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?

From :

grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max
sysctl: unknown oid 'vfs.zfs.arc_max'
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Wed 25 Mar 2020 04:52:22 GMT
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs
 2    1 0x82108000   58ac58 openzfs.ko
grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf
# zfs_load="YES"
openzfs_load="YES"
grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf
vfs.zfs.min_auto_ashift=12
# HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816
# vfs.zfs.arc_max="7761553408"
vfs.zfs.arc_max="2147483648"
grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a

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

USB microphones with FreeBSD-CURRENT

2020-03-27 Thread Graham Perrin


I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

From :

grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sun 22 Mar 2020 08:49:07 GMT
FreeBSD 13.0-CURRENT #0 r359068: Wed Mar 18 21:14:12 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % cat /dev/sndstat
Installed devices:
pcm0:  (play)
pcm1:  (play/rec)
pcm2:  (play/rec)
pcm3:  (play/rec) default
pcm4:  (rec)
No devices installed from userspace.
grahamperrin@momh167-gjp4-8570p:~ % sysctl hw.snd.default_unit
hw.snd.default_unit: 3
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' firefox
www/firefox 74.0_5,1 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %
___
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: When will the FreeBSD (u)EFI work?

2020-03-27 Thread Chris


On Fri, 27 Mar 2020 18:31:50 -0700 bsd-li...@bsdforge.com said


On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh i...@bsdimp.com said

> On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:
> 
> > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com said

> >
> > > On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
> > > >
> > > > On an experiment of the FreeBSD EFI implementation. I installed
> > > > a copy of releng/12 from install media. Which left me with:
> > > > # gpart show ada0
> > > > =>   40  312581728  ada0  GPT  (149G)
> > > >  40 409600 1  efi  (200M)
> > > >  409640   31047680 2  freebsd-ufs  (15G)
> > > >31457320768 3  freebsd-swap  (3.7G)
> > > >74788904  237792864- free -  (141G)
> > > >
> > > > On this Intel based system, I can stab the F12 key to pick
> > > > my UEFI bootable OS, or let it boot according to the order
> > > > I setup in the BIOS. So far, so good.
> > > > I needed a copy of releng/13 to also work with. Installed a copy
> > > > from install media. Which left me with:
> > > > # gpart show ada0
> > > > =>   40  312581728  ada0  GPT  (149G)
> > > >  40 409600 1  efi  (200M)
> > > >  409640   31047680 2  freebsd-ufs  (15G)
> > > >31457320768 3  freebsd-swap  (3.7G)
> > > >39137320 532480 4  efi  (260M)
> > > >39669800   35119104 5  freebsd-ufs  (17G)
> > > >74788904  237792864- free -  (113G)
> > > > I *assumed* that the install would activate the new install, and I
> > > > would boot straight into it. But no. I am still on the previous
> > > > install, and worse, I can't get into the new install -- even if
> > > > picking it via stabbing the F12 key. I *still* end up in the previous
> > > > install. So looking at what might be causing it. I found the
> following:
> > > > # releng/12
> > > > # mount -t msdosfs /dev/ada0p1 /mnt/
> > > >
> > > > # ls /mnt/efi/boot/
> > > > BOOTx64.efi
> > > > startup.nsh
> > > >
> > > > # cat /mnt/efi/boot/startup.nsh
> > > > BOOTx64.efi
> > > >
> > > > # umount /mnt/
> > > >
> > > > releng/13
> > > > # mount -t msdosfs /dev/ada0p4 /mnt/
> > > >
> > > > # ls /mnt/EFI/freebsd/
> > > > loader.efi
> > > >
> > > > Why the difference? When will FreeBSD (u)EFI work as expected?
> > > >
> > > > Thanks in advance for any insights!
> > > >
> > >
> > > Require only single efi part
> > >
> > > See
> > >
> >
> https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
> > Thanks for they reply, and link, Andrey!
> > Well that confirms it. FreeBSD, unlike other OS implementations, will not
> > permit booting your chosen "version" via EFI.
> 
> 
Firstly, *huge* thanks for your informative reply, Warner!

> It does today. If you use efibootmgr, you can boot exactly what you want. I
> do it all the time...  Though your BIOS may overwrite the EFI vars if you
> set too many (I'm looking at you supermicro). When you use the efi Boot
> variables, it's possible to boot one of many different things on the
> system...  Though I've not done 11, just 12 and current.
Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
When I started this whole thing, I had some 15 entries returned by
efibootmgr(8) -v.
So I trimmed the list down to the 2 my BIOS presents as UEFI:
Boot0015  UEFI: WDC WD1600JS-98MHB0
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(4,GPT,6688c5af-6f93...
Boot0011* UEFI: WDC WD1600JS-98MHB0
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(1,GPT,260d2df2-6a10...
another entry created when I installed releng/13:
Boot0014  FreeBSD (ada0p4)
HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
and a Windows reference (currently not installed).
I activated *both* Boot0015 and Boot0011:
efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose
Boot0015. Which booted
initial releng/12 install. Fail. OK Try something different;
efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken,
but 00114 is active.
Bounce box && choose 0014. Boots to initial releng/12 install.

Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(

Thanks again for the reply, Warner! :)

--Chris
> 
> 
> > That is; not without dropping

> > to the loader prompt, or changing the status of slices, or boot entries
> > prior to
> > reboot. :(
> >
> 
> Not needed.
> 
> 
> > Looks like I'll need to install a third party OS, or bootmanager to use

> > FreeBSD.
> > Sigh...
> >
> 
> Again, not needed. Though there may be a few things that need to be MFC'd

> if you want 11 on that list...
> 
> 
> > There *may* be hope in the future (

> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940)
> >
> 
> This would require you to stop to select on the way up... Or am I not

> understanding what you want?
> 
> We should add that functionality to loader.efi, since boot1.efi is in the

> process of being deprecated... It should be a simple LUA script there...

I

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Julian H. Stacey

Ed Maste wrote:
> On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey  wrote:
> >
> > l  /usr/src/contrib/kyua/doc/manbuild.sh
> > -rw-r--r--  1 jhs  staff  5187 Mar 25 12:34 
> > /usr/src/contrib/kyua/doc/manbuild.sh
> 
> Indeed, this is the problem. manbuild.sh is +x in svn and in the git
> mirror, so it appears something's broken in ctm.

Thanks Ed !
I've logged in on the CTM generator server to investigate.
http://ctm.berklix.org

Cheers
--
Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/
UK stole 750,000 votes from EU Brits:  http://stolenvotes.uk
http://petition.parliament.uk/petitions/300059 http://berklix.uk/brexit/#russia
Limit Corona:  http://berklix.eu/corona/
___
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: When will the FreeBSD (u)EFI work?

2020-03-27 Thread Chris

On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh i...@bsdimp.com said

On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:

> On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com said
>
> > On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
> > >
> > > On an experiment of the FreeBSD EFI implementation. I installed
> > > a copy of releng/12 from install media. Which left me with:
> > > # gpart show ada0
> > > =>   40  312581728  ada0  GPT  (149G)
> > >  40 409600 1  efi  (200M)
> > >  409640   31047680 2  freebsd-ufs  (15G)
> > >31457320768 3  freebsd-swap  (3.7G)
> > >74788904  237792864- free -  (141G)
> > >
> > > On this Intel based system, I can stab the F12 key to pick
> > > my UEFI bootable OS, or let it boot according to the order
> > > I setup in the BIOS. So far, so good.
> > > I needed a copy of releng/13 to also work with. Installed a copy
> > > from install media. Which left me with:
> > > # gpart show ada0
> > > =>   40  312581728  ada0  GPT  (149G)
> > >  40 409600 1  efi  (200M)
> > >  409640   31047680 2  freebsd-ufs  (15G)
> > >31457320768 3  freebsd-swap  (3.7G)
> > >39137320 532480 4  efi  (260M)
> > >39669800   35119104 5  freebsd-ufs  (17G)
> > >74788904  237792864- free -  (113G)
> > > I *assumed* that the install would activate the new install, and I
> > > would boot straight into it. But no. I am still on the previous
> > > install, and worse, I can't get into the new install -- even if
> > > picking it via stabbing the F12 key. I *still* end up in the previous
> > > install. So looking at what might be causing it. I found the following:
> > > # releng/12
> > > # mount -t msdosfs /dev/ada0p1 /mnt/
> > >
> > > # ls /mnt/efi/boot/
> > > BOOTx64.efi
> > > startup.nsh
> > >
> > > # cat /mnt/efi/boot/startup.nsh
> > > BOOTx64.efi
> > >
> > > # umount /mnt/
> > >
> > > releng/13
> > > # mount -t msdosfs /dev/ada0p4 /mnt/
> > >
> > > # ls /mnt/EFI/freebsd/
> > > loader.efi
> > >
> > > Why the difference? When will FreeBSD (u)EFI work as expected?
> > >
> > > Thanks in advance for any insights!
> > >
> >
> > Require only single efi part
> >
> > See
> >
> https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
> Thanks for they reply, and link, Andrey!
> Well that confirms it. FreeBSD, unlike other OS implementations, will not
> permit booting your chosen "version" via EFI.

Firstly, *huge* thanks for your informative reply, Warner!

It does today. If you use efibootmgr, you can boot exactly what you want. I
do it all the time...  Though your BIOS may overwrite the EFI vars if you
set too many (I'm looking at you supermicro). When you use the efi Boot
variables, it's possible to boot one of many different things on the
system...  Though I've not done 11, just 12 and current.

Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into 13.
When I started this whole thing, I had some 15 entries returned by 
efibootmgr(8) -v.
So I trimmed the list down to the 2 my BIOS presents as UEFI:
Boot0015  UEFI: WDC WD1600JS-98MHB0 
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(4,GPT,6688c5af-6f93...
Boot0011* UEFI: WDC WD1600JS-98MHB0 
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0x,0x0)/HD(1,GPT,260d2df2-6a10...
another entry created when I installed releng/13:
Boot0014  FreeBSD (ada0p4) 
HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI\free...
and a Windows reference (currently not installed).
I activated *both* Boot0015 and Boot0011:
efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose 
Boot0015. Which booted
initial releng/12 install. Fail. OK Try something different;
efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is broken, but 
00114 is active.
Bounce box && choose 0014. Boots to initial releng/12 install.

Conclusion; FreeBSD EFI/ESP is not ready for prime time. :(

Thanks again for the reply, Warner! :)

--Chris

> That is; not without dropping
> to the loader prompt, or changing the status of slices, or boot entries
> prior to
> reboot. :(
>

Not needed.

> Looks like I'll need to install a third party OS, or bootmanager to use
> FreeBSD.
> Sigh...
>

Again, not needed. Though there may be a few things that need to be MFC'd
if you want 11 on that list...

> There *may* be hope in the future (
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940)
>

This would require you to stop to select on the way up... Or am I not
understanding what you want?

We should add that functionality to loader.efi, since boot1.efi is in the
process of being deprecated... It should be a simple LUA script there...

> Thanks again, Andrey. Greatly appreciated! :)
>

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@fre

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Ed Maste

On Fri, 27 Mar 2020 at 21:11, Enji Cooper  wrote:>
>
> Hi Julian,
> I just worked around the issue by bypassing the manpage generation as part of 
> buildworld: https://svnweb.freebsd.org/base?view=revision&revision=359385 . 
> While the approach you took makes wonderful sense, I thought it was best to 
> not have to continually rebuild the manpages for little to no gain.

We have lots of scripts in the tree so if there's some problem with
permissions with an obscure source code distribution tool those
problems should be fixed instead.
___
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: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Enji Cooper



> On Mar 27, 2020, at 6:04 PM, Ed Maste  wrote:
> 
> On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey  wrote:
>> 
>> l  /usr/src/contrib/kyua/doc/manbuild.sh
>>-rw-r--r--  1 jhs  staff  5187 Mar 25 12:34 
>> /usr/src/contrib/kyua/doc/manbuild.sh
> 
> Indeed, this is the problem. manbuild.sh is +x in svn and in the git
> mirror, so it appears something's broken in ctm.

Hi Julian,
I just worked around the issue by bypassing the manpage generation as 
part of buildworld: 
https://svnweb.freebsd.org/base?view=revision&revision=359385 
 . While the 
approach you took makes wonderful sense, I thought it was best to not have to 
continually rebuild the manpages for little to no gain.
Thank you very much for the report/submitted patch :)!
-Enji
___
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: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Ed Maste

On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey  wrote:
>
> l  /usr/src/contrib/kyua/doc/manbuild.sh
> -rw-r--r--  1 jhs  staff  5187 Mar 25 12:34 
> /usr/src/contrib/kyua/doc/manbuild.sh

Indeed, this is the problem. manbuild.sh is +x in svn and in the git
mirror, so it appears something's broken in ctm.
___
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"

src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Julian H. Stacey

src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Example:
cd /usr/src
cat .ctm_status 
src-cur 14430
cat .svn_revision 
359319
uname -a
FreeBSD lapr.js.berklix.net 13.0-CURRENT FreeBSD 13.0-CURRENT #14410: 
Sun Mar 15 16:28:46 CET 2020 
j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small  amd64

cd /usr/src/usr.bin/kyua ;  make
/usr/src/contrib/kyua/doc/manbuild.sh  -v "CONFDIR=/etc/kyua"  -v 
"DOCDIR=/nonexistant"  -v "EGDIR=/usr/share/examples/kyua"  -v 
"MISCDIR=/usr/share/kyua/misc"  -v "PACKAGE=kyua"  -v 
"STOREDIR=/usr/share/kyua/store"  -v "TESTSDIR=/usr/tests"  -v "VERSION=0.13"  
/usr/src/contrib/kyua/doc/kyua-about.1.in kyua-about.1
/bin/sh: /usr/src/contrib/kyua/doc/manbuild.sh: Permission denied
*** Error code 126

l  /usr/src/contrib/kyua/doc/manbuild.sh
-rw-r--r--  1 jhs  staff  5187 Mar 25 12:34 
/usr/src/contrib/kyua/doc/manbuild.sh

chmod a+x /usr/src/contrib/kyua/doc/manbuild.sh

make# succeeds but wrong solution

chmod a-x /usr/src/contrib/kyua/doc/manbuild.sh
cd /usr/src/usr.bin/kyua ;  make clean
source `which unsetenv.csh`
# SH is not set
make clean ; make
/bin/sh: /usr/src/contrib/kyua/doc/manbuild.sh: Permission denied

*** src/usr.bin/kyua/Makefile.orig  Wed Mar 25 12:34:45 2020
--- src/usr.bin/kyua/Makefile   Sat Mar 28 01:38:21 2020
***
*** 49,55 
  .PATH: ${KYUA_SRCDIR}/doc
  .for man in ${MAN}
  ${man}: ${man}.in
!   ${SH} ${KYUA_SRCDIR}/doc/manbuild.sh \
-v "CONFDIR=${KYUA_CONFDIR}" \
-v "DOCDIR=${KYUA_DOCDIR}" \
-v "EGDIR=${KYUA_EGDIR}" \
--- 49,55 
  .PATH: ${KYUA_SRCDIR}/doc
  .for man in ${MAN}
  ${man}: ${man}.in
!   /bin/sh ${KYUA_SRCDIR}/doc/manbuild.sh \
-v "CONFDIR=${KYUA_CONFDIR}" \
-v "DOCDIR=${KYUA_DOCDIR}" \
-v "EGDIR=${KYUA_EGDIR}" \

The diff above works, but is not sophisticated enough to represent what 
someone is trying to do with SH ?

Cheers
--
Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/
UK stole 750,000 votes from EU Brits:  http://stolenvotes.uk
http://petition.parliament.uk/petitions/300059 http://berklix.uk/brexit/#russia
Limit Corona:  http://berklix.eu/corona/
___
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: buildworld failed (usr.bin/kyua)

2020-03-27 Thread Brooks Davis

On Fri, Mar 27, 2020 at 08:07:08PM +, Brooks Davis wrote:
> On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
> > I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
> > 
> > End of the build log:
> > 
> > $ su root -c "make -j16 buildworld"
> > ...
> > ld: error: unable to find library -lkyua_cli_pie
> > ld: error: unable to find library -lkyua_drivers_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_engine_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_store_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_engine_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_store_pie
> > ld: error: too many errors emitted, stopping now (use -error-limit=0
> > to see all errors)
> > c++: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > --- all_subdir_lib ---
> > --- cpuset_getdomain.po ---
> > --- all_subdir_usr.bin ---
> > *** [kyua] Error code 1
> > 
> > make[4]: stopped in /usr/src/usr.bin/kyua
> > 1 error
> > 
> > make[4]: stopped in /usr/src/usr.bin/kyua
> > *** [all_subdir_usr.bin/kyua] Error code 2
> > ...
> > 
> > May be it's related to r359260[1].  Therefore, here is my TEST-settings:
> > 
> > $ fgrep TEST /etc/src.conf
> > WITHOUT_GOOGLETEST=
> > WITHOUT_TESTS=
> > WITH_TESTS_SUPPORT=
> > 
> > Also what has confused me: it's a virtual machine which failed to build.
> > A physical one built userland and kernel just fine.  Both the physical
> > and virtual machines have almost the same (differ only by CPU
> > "selection" options) make.conf and src.conf and different kernel
> > configurations.  Both the machines were FreeBSD 13.0-CURRENT amd64
> > r359231.  I've started to build on clean systems (no /usr/obj at all).
> > 
> > Can anyone help me to resolve this issue?
> 
> I've replicated this issue and it goes back the the way
> WITH_TESTS_SUPPORT was implemented way back in r273449
> 
> This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.
> 
> Index: Makefile.inc1
> ===
> --- Makefile.inc1   (revision 359367)
> +++ Makefile.inc1   (working copy)
> @@ -1100,7 +1100,7 @@
>   @echo
> "--"
>   ${_+_}cd ${.CURDIR}; \
>   ${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
> - MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
> libraries
> + MK_PROFILE=no MK_TESTS=no libraries
>  everything: .PHONY
>   @echo
>   @echo
> "--
> 
> I've not committed it yet because I'm trying to figure out why this was
> needed.  I simply don't see how there could be a race between lib/aft and
> libexec/aft as described.  I suspect this may have been an error.

I've committed a different fix in r359382.

The above change fixed the case at hand, but broke the default.

-- Brooks


signature.asc
Description: PGP signature

Re: When will the FreeBSD (u)EFI work?

2020-03-27 Thread Warner Losh

On Fri, Mar 27, 2020 at 4:54 PM Chris  wrote:

> On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com said
>
> > On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
> > >
> > > On an experiment of the FreeBSD EFI implementation. I installed
> > > a copy of releng/12 from install media. Which left me with:
> > > # gpart show ada0
> > > =>   40  312581728  ada0  GPT  (149G)
> > >  40 409600 1  efi  (200M)
> > >  409640   31047680 2  freebsd-ufs  (15G)
> > >31457320768 3  freebsd-swap  (3.7G)
> > >74788904  237792864- free -  (141G)
> > >
> > > On this Intel based system, I can stab the F12 key to pick
> > > my UEFI bootable OS, or let it boot according to the order
> > > I setup in the BIOS. So far, so good.
> > > I needed a copy of releng/13 to also work with. Installed a copy
> > > from install media. Which left me with:
> > > # gpart show ada0
> > > =>   40  312581728  ada0  GPT  (149G)
> > >  40 409600 1  efi  (200M)
> > >  409640   31047680 2  freebsd-ufs  (15G)
> > >31457320768 3  freebsd-swap  (3.7G)
> > >39137320 532480 4  efi  (260M)
> > >39669800   35119104 5  freebsd-ufs  (17G)
> > >74788904  237792864- free -  (113G)
> > > I *assumed* that the install would activate the new install, and I
> > > would boot straight into it. But no. I am still on the previous
> > > install, and worse, I can't get into the new install -- even if
> > > picking it via stabbing the F12 key. I *still* end up in the previous
> > > install. So looking at what might be causing it. I found the following:
> > > # releng/12
> > > # mount -t msdosfs /dev/ada0p1 /mnt/
> > >
> > > # ls /mnt/efi/boot/
> > > BOOTx64.efi
> > > startup.nsh
> > >
> > > # cat /mnt/efi/boot/startup.nsh
> > > BOOTx64.efi
> > >
> > > # umount /mnt/
> > >
> > > releng/13
> > > # mount -t msdosfs /dev/ada0p4 /mnt/
> > >
> > > # ls /mnt/EFI/freebsd/
> > > loader.efi
> > >
> > > Why the difference? When will FreeBSD (u)EFI work as expected?
> > >
> > > Thanks in advance for any insights!
> > >
> >
> > Require only single efi part
> >
> > See
> >
> https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
> Thanks for they reply, and link, Andrey!
> Well that confirms it. FreeBSD, unlike other OS implementations, will not
> permit booting your chosen "version" via EFI.


It does today. If you use efibootmgr, you can boot exactly what you want. I
do it all the time...  Though your BIOS may overwrite the EFI vars if you
set too many (I'm looking at you supermicro). When you use the efi Boot
variables, it's possible to boot one of many different things on the
system...  Though I've not done 11, just 12 and current.


> That is; not without dropping
> to the loader prompt, or changing the status of slices, or boot entries
> prior to
> reboot. :(
>

Not needed.


> Looks like I'll need to install a third party OS, or bootmanager to use
> FreeBSD.
> Sigh...
>

Again, not needed. Though there may be a few things that need to be MFC'd
if you want 11 on that list...


> There *may* be hope in the future (
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940)
>

This would require you to stop to select on the way up... Or am I not
understanding what you want?

We should add that functionality to loader.efi, since boot1.efi is in the
process of being deprecated... It should be a simple LUA script there...


> Thanks again, Andrey. Greatly appreciated! :)
>
___
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: When will the FreeBSD (u)EFI work?

2020-03-27 Thread Chris


On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0and...@gmail.com said


On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
>
> On an experiment of the FreeBSD EFI implementation. I installed
> a copy of releng/12 from install media. Which left me with:
> # gpart show ada0
> =>   40  312581728  ada0  GPT  (149G)
>  40 409600 1  efi  (200M)
>  409640   31047680 2  freebsd-ufs  (15G)
>31457320768 3  freebsd-swap  (3.7G)
>74788904  237792864- free -  (141G)
>
> On this Intel based system, I can stab the F12 key to pick
> my UEFI bootable OS, or let it boot according to the order
> I setup in the BIOS. So far, so good.
> I needed a copy of releng/13 to also work with. Installed a copy
> from install media. Which left me with:
> # gpart show ada0
> =>   40  312581728  ada0  GPT  (149G)
>  40 409600 1  efi  (200M)
>  409640   31047680 2  freebsd-ufs  (15G)
>31457320768 3  freebsd-swap  (3.7G)
>39137320 532480 4  efi  (260M)
>39669800   35119104 5  freebsd-ufs  (17G)
>74788904  237792864- free -  (113G)
> I *assumed* that the install would activate the new install, and I
> would boot straight into it. But no. I am still on the previous
> install, and worse, I can't get into the new install -- even if
> picking it via stabbing the F12 key. I *still* end up in the previous
> install. So looking at what might be causing it. I found the following:
> # releng/12
> # mount -t msdosfs /dev/ada0p1 /mnt/
>
> # ls /mnt/efi/boot/
> BOOTx64.efi
> startup.nsh
>
> # cat /mnt/efi/boot/startup.nsh
> BOOTx64.efi
>
> # umount /mnt/
>
> releng/13
> # mount -t msdosfs /dev/ada0p4 /mnt/
>
> # ls /mnt/EFI/freebsd/
> loader.efi
>
> Why the difference? When will FreeBSD (u)EFI work as expected?
>
> Thanks in advance for any insights!
>

Require only single efi part

See
https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/

Thanks for they reply, and link, Andrey!
Well that confirms it. FreeBSD, unlike other OS implementations, will not
permit booting your chosen "version" via EFI. That is; not without dropping
to the loader prompt, or changing the status of slices, or boot entries prior to
reboot. :(
Looks like I'll need to install a third party OS, or bootmanager to use FreeBSD.
Sigh...

There *may* be hope in the future 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940)

Thanks again, Andrey. Greatly appreciated! :)

--Chris


___
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: When will the FreeBSD (u)EFI work?

2020-03-27 Thread Andrey Fesenko

On Sat, Mar 28, 2020 at 12:53 AM Chris  wrote:
>
> On an experiment of the FreeBSD EFI implementation. I installed
> a copy of releng/12 from install media. Which left me with:
> # gpart show ada0
> =>   40  312581728  ada0  GPT  (149G)
>  40 409600 1  efi  (200M)
>  409640   31047680 2  freebsd-ufs  (15G)
>31457320768 3  freebsd-swap  (3.7G)
>74788904  237792864- free -  (141G)
>
> On this Intel based system, I can stab the F12 key to pick
> my UEFI bootable OS, or let it boot according to the order
> I setup in the BIOS. So far, so good.
> I needed a copy of releng/13 to also work with. Installed a copy
> from install media. Which left me with:
> # gpart show ada0
> =>   40  312581728  ada0  GPT  (149G)
>  40 409600 1  efi  (200M)
>  409640   31047680 2  freebsd-ufs  (15G)
>31457320768 3  freebsd-swap  (3.7G)
>39137320 532480 4  efi  (260M)
>39669800   35119104 5  freebsd-ufs  (17G)
>74788904  237792864- free -  (113G)
> I *assumed* that the install would activate the new install, and I
> would boot straight into it. But no. I am still on the previous
> install, and worse, I can't get into the new install -- even if
> picking it via stabbing the F12 key. I *still* end up in the previous
> install. So looking at what might be causing it. I found the following:
> # releng/12
> # mount -t msdosfs /dev/ada0p1 /mnt/
>
> # ls /mnt/efi/boot/
> BOOTx64.efi
> startup.nsh
>
> # cat /mnt/efi/boot/startup.nsh
> BOOTx64.efi
>
> # umount /mnt/
>
> releng/13
> # mount -t msdosfs /dev/ada0p4 /mnt/
>
> # ls /mnt/EFI/freebsd/
> loader.efi
>
> Why the difference? When will FreeBSD (u)EFI work as expected?
>
> Thanks in advance for any insights!
>

Require only single efi part

See https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/
___
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"

When will the FreeBSD (u)EFI work?

2020-03-27 Thread Chris


On an experiment of the FreeBSD EFI implementation. I installed
a copy of releng/12 from install media. Which left me with:
# gpart show ada0
=>   40  312581728  ada0  GPT  (149G)
40 409600 1  efi  (200M)
409640   31047680 2  freebsd-ufs  (15G)
  31457320768 3  freebsd-swap  (3.7G)
  74788904  237792864- free -  (141G)

On this Intel based system, I can stab the F12 key to pick
my UEFI bootable OS, or let it boot according to the order
I setup in the BIOS. So far, so good.
I needed a copy of releng/13 to also work with. Installed a copy
from install media. Which left me with:
# gpart show ada0
=>   40  312581728  ada0  GPT  (149G)
40 409600 1  efi  (200M)
409640   31047680 2  freebsd-ufs  (15G)
  31457320768 3  freebsd-swap  (3.7G)
  39137320 532480 4  efi  (260M)
  39669800   35119104 5  freebsd-ufs  (17G)
  74788904  237792864- free -  (113G)
I *assumed* that the install would activate the new install, and I
would boot straight into it. But no. I am still on the previous
install, and worse, I can't get into the new install -- even if
picking it via stabbing the F12 key. I *still* end up in the previous
install. So looking at what might be causing it. I found the following:
# releng/12
# mount -t msdosfs /dev/ada0p1 /mnt/

# ls /mnt/efi/boot/
BOOTx64.efi
startup.nsh

# cat /mnt/efi/boot/startup.nsh
BOOTx64.efi

# umount /mnt/

releng/13
# mount -t msdosfs /dev/ada0p4 /mnt/

# ls /mnt/EFI/freebsd/
loader.efi

Why the difference? When will FreeBSD (u)EFI work as expected?

Thanks in advance for any insights!

--Chris


___
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: buildworld failed (usr.bin/kyua)

2020-03-27 Thread Brooks Davis

On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
> I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
> 
> End of the build log:
> 
> $ su root -c "make -j16 buildworld"
> ...
> ld: error: unable to find library -lkyua_cli_pie
> ld: error: unable to find library -lkyua_drivers_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_engine_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_store_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_engine_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_store_pie
> ld: error: too many errors emitted, stopping now (use -error-limit=0
> to see all errors)
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> --- all_subdir_lib ---
> --- cpuset_getdomain.po ---
> --- all_subdir_usr.bin ---
> *** [kyua] Error code 1
> 
> make[4]: stopped in /usr/src/usr.bin/kyua
> 1 error
> 
> make[4]: stopped in /usr/src/usr.bin/kyua
> *** [all_subdir_usr.bin/kyua] Error code 2
> ...
> 
> May be it's related to r359260[1].  Therefore, here is my TEST-settings:
> 
> $ fgrep TEST /etc/src.conf
> WITHOUT_GOOGLETEST=
> WITHOUT_TESTS=
> WITH_TESTS_SUPPORT=
> 
> Also what has confused me: it's a virtual machine which failed to build.
> A physical one built userland and kernel just fine.  Both the physical
> and virtual machines have almost the same (differ only by CPU
> "selection" options) make.conf and src.conf and different kernel
> configurations.  Both the machines were FreeBSD 13.0-CURRENT amd64
> r359231.  I've started to build on clean systems (no /usr/obj at all).
> 
> Can anyone help me to resolve this issue?

I've replicated this issue and it goes back the the way
WITH_TESTS_SUPPORT was implemented way back in r273449

This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.

Index: Makefile.inc1
===
--- Makefile.inc1   (revision 359367)
+++ Makefile.inc1   (working copy)
@@ -1100,7 +1100,7 @@
@echo
"--"
${_+_}cd ${.CURDIR}; \
${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
-   MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
libraries
+   MK_PROFILE=no MK_TESTS=no libraries
 everything: .PHONY
@echo
@echo
"--

I've not committed it yet because I'm trying to figure out why this was
needed.  I simply don't see how there could be a race between lib/aft and
libexec/aft as described.  I suspect this may have been an error.

-- Brooks


signature.asc
Description: PGP signature

Re: link_elf_obj: symbol bcmp undefined

2020-03-27 Thread John D Groenveld

I reproduced with current CURRENT and updated BigID 244962:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244962>

$ sysctl -n kern.version
FreeBSD 13.0-CURRENT #0 r359311: Thu Mar 26 04:34:44 UTC 2020
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
$ uname -U  
1300085

Is the magic awk that the virtualbox port is using to generate a kernel
module from userspace code broken?
A clue stick gently or harshly applied to my noggin would be very much
appreciated.

John
groenv...@acm.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"

buildworld failed (usr.bin/kyua)

2020-03-27 Thread Ruslan Garipov

I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.

End of the build log:

$ su root -c "make -j16 buildworld"
...
ld: error: unable to find library -lkyua_cli_pie
ld: error: unable to find library -lkyua_drivers_pie
ld: error: unable to find library -lkyua_model_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_engine_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_utils_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_store_pie
ld: error: unable to find library -lkyua_model_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_utils_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_engine_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_utils_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_model_pie
ld: error: unable to find library -llutok_pie
ld: error: unable to find library -lkyua_store_pie
ld: error: too many errors emitted, stopping now (use -error-limit=0
to see all errors)
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
--- all_subdir_lib ---
--- cpuset_getdomain.po ---
--- all_subdir_usr.bin ---
*** [kyua] Error code 1

make[4]: stopped in /usr/src/usr.bin/kyua
1 error

make[4]: stopped in /usr/src/usr.bin/kyua
*** [all_subdir_usr.bin/kyua] Error code 2
...

May be it's related to r359260[1].  Therefore, here is my TEST-settings:

$ fgrep TEST /etc/src.conf
WITHOUT_GOOGLETEST=
WITHOUT_TESTS=
WITH_TESTS_SUPPORT=

Also what has confused me: it's a virtual machine which failed to build.
A physical one built userland and kernel just fine.  Both the physical
and virtual machines have almost the same (differ only by CPU
"selection" options) make.conf and src.conf and different kernel
configurations.  Both the machines were FreeBSD 13.0-CURRENT amd64
r359231.  I've started to build on clean systems (no /usr/obj at all).

Can anyone help me to resolve this issue?

I apologize in advance if I will delay my further replies, due to world
wide health situation.

Thanks!

[1] https://lists.freebsd.org/pipermail/svn-src-head/2020-March/134800.html

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

CFT: Next-hop objects and scalable multipath routing

2020-03-27 Thread Alexander V . Chernikov

I would like to introduce an implementation of scalable multipath routing.

Previous implementation (RADIX_MPATH) focused on a simpler case like having 2
defaults, with performance falling linearly proportional to the number of
paths. That implementation was also tightly coupled lookup algorithm details
with the routing details, making it hard to hack both.

The proposed one allows O(1) lookup and is more cache-efficient with the large
amount of routes. Furthermore, multipath functionality is based on the number
of internal changes, modernizing the old routing code.

Most of the changes revolves around introducing the concept of _nexthops_.
Nexthops are separate datastructures, containing all necessary information to
perform packet forwarding such as gateway, interface and mtu. Nexthops are
shared among the routes, providing more pre-computed cache-efficient data while
requiring less memory.
Multipath implementation adds _nexthop groups_ which are basically collection
of nexthops weights, compiled into an array, to allow direct nexthop selection.
More detailed technical description is available at [1].
Any comments/suggestions are welcome!

Presentation of the similar functionality in the other OS: [2]
Next-hop objects support was implemented in FRR in 2019 [3].

Next steps:
As these changes decouples routing code details from algorithm details and
abstracts callers, it is much easier to introduce a number of other relevant
features.
The most important proposed features are: nexthop-based route installation and
custom per-address-family route lookup algorithms.
The former targets improving convergence times for the large-fib boxes, while
the latter may improve dataplane performance, especially for IPv6.

How to test:
fetch the patch from https://reviews.freebsd.org/D24141
rebuild kernel with ROUTE_MPATH option (already added to amd64 GENERIC)
Optionally, rebuild world to get netstat nexthops/multipath groups reporting.

Use route(8) to add multiple routes for the same destination, optionally
specifying weight.
Example: add 2:1 load balancing for the default route:

route add -net default 192.168.53.1 -weight 100
route add -net default 192.168.53.2 -weight 200

netstat -4rnW
..
DestinationGatewayFlags Nhop#Mtu Netif Expire
default192.168.53.1 UGS 4 1500em0
default192.168.53.2 UGS 5 1500em0

netstat -4onW
Nexthop data
Idx Type IFAGateway Flags Use Mtu
Netif Addrif Refcnt Prepend
..
4v4/gw 192.168.53.128 192.168.53.1 GS0 1500
em0 2
5v4/gw 192.168.53.128 192.168.53.2 GS0 1500
em0 1
Nexthop groups data
MpIdx NHIdx Weigh SlotsGateway Netif Refcnt
1 1
4 100 1 192.168.53.1 em0
5 200 2 192.168.53.2 em0

[1] https://reviews.freebsd.org/D24141
[2]
https://linuxplumbersconf.org/event/4/contributions/434/attachments/251/436/nexthop-objects-talk.pdf
[3]
https://github.com/FRRouting/frr/commit/d9f5b2f50f53d625986dbd47cd12778c9f841f0c
___
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"

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

USB microphones with FreeBSD-CURRENT

Re: When will the FreeBSD (u)EFI work?

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Re: When will the FreeBSD (u)EFI work?

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

src/usr.bin/kyua breaks on manbuild.sh: Permission denied

Re: buildworld failed (usr.bin/kyua)

Re: When will the FreeBSD (u)EFI work?

Re: When will the FreeBSD (u)EFI work?

Re: When will the FreeBSD (u)EFI work?

When will the FreeBSD (u)EFI work?

Re: buildworld failed (usr.bin/kyua)

Re: link_elf_obj: symbol bcmp undefined

buildworld failed (usr.bin/kyua)

CFT: Next-hop objects and scalable multipath routing

18 matches

Site Navigation

Mail list logo

Footer information