Re: sort.core error doing installworld on Current.

[Rodney W. Grimes]

> 
> Op 17-04-2020 om 03:31 schreef Rodney W. Grimes:
> >> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:
> >>
> >>> So you some how had a sort core dump sitting in
> >>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> >>> did get there? I'd take a look at the date on the file and, it it is older
> >>> than the buildworld, just assume that it was left-over garbage. In either
> >>> case, you can delete it and do another installworld.
> >>>
> >>> That should most likely fix things, but, if the buildworld or installworld
> >>> had a crash of sort(1) that left the file, further investigation might be
> >>> needed. Re-making the zoneinfo would help track it down should this be a 
> >>> re
> >>> al bug, but it's my uneducated guess that it's not.
> >>> --
> >>> Kevin Oberman, Part time kid herder and retired Network Engineer
> >>> E-mail: rkober...@gmail.com
> >>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>>
> >> Please forgive that awful post! I missed a part of your message by 
> >> laziness.
> >>
> >> It's odd that the error of sort(1) crashing was not caught by the script.
> > Yes, that is a Makefile flaw someplace.
> > Further there must be a wildcard being used to decide which files to
> > install, that is a further Makefile flaw.  Wildcards should NOT be used
> > in the source of an install list, exactly because of this type of cruft
> > that can be dropped in an obj dir.
> >
> >> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> >> something. Looking at the core might tell you which "sort" was involved...
> >> the one you just built or the one in the base system. This could be just a
> >> FOTU, but I would not bet on it.
> > I suspect a recent zoneinfo commit as the root cause.
> >
> I have no idea how to bypass this issue.
> I have used sort from the latest snapshot and placed that file on the 
> system and in the build dir, but i keep getting the core
> 
> How can i test an build and install part for zoneinfo
> 
> If i go into the dir /usr/src/share/zoneinfo and do make install it does 
> not work, do i need to add something?

Can you show us the output from
cd /usr/src/share/zoneinfo
make clean && make depend && make all && make install
Someplace in that we should get to see sort crashing...

> 
> Thank you both for your time
> 
> >> --
> >> Kevin Oberman, Part time kid herder and retired Network Engineer
> >> E-mail: rkober...@gmail.com
> >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >>
> >>
> >>>
> >>> On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
> >>> wrote:
> >>>
> >>>> I have a machine running FreeBSD head.
> >>>> rev 13.0-CURRENT #11 r360008
> >>>>
> >>>> This is a quite powerful machine, so i thought it was a good idea to let
> >>>> that server do the build and for my virtualbox machine i can use the
> >>>> powerful machine to do a installword over NFS.
> >>>>
> >>>> But when i did the make installworld step the client so to say gives an
> >>>> error.
> >>>>
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> >>>> /usr/share/zoneinfo/Zulu
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> >>>> /usr/share/zoneinfo/posixrules
> >>>> install   -o root -g wheel -m 444
> >>>> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> >>>> /usr/share/zoneinfo/sort.core
> >>>> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> >>>> Permission denied
> >>>> *** Error code 71
> >>>>
> >>>> Stop.
> >>>> bmake[5]: stopped in /usr/src/share/zoneinfo
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[4]: stopped in /usr/src/share
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[3]: stopped in /usr/src
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[2]: stopped in /usr/src

Re: sort.core error doing installworld on Current.

[Rodney W. Grimes]

> On Thu, Apr 16, 2020 at 12:39 PM Kevin Oberman  wrote:
> 
> > So you some how had a sort core dump sitting in
> > /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir. The questions, how
> > did get there? I'd take a look at the date on the file and, it it is older
> > than the buildworld, just assume that it was left-over garbage. In either
> > case, you can delete it and do another installworld.
> >
> > That should most likely fix things, but, if the buildworld or installworld
> > had a crash of sort(1) that left the file, further investigation might be
> > needed. Re-making the zoneinfo would help track it down should this be a re
> > al bug, but it's my uneducated guess that it's not.
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >
> Please forgive that awful post! I missed a part of your message by laziness.
> 
> It's odd that the error of sort(1) crashing was not caught by the script.

Yes, that is a Makefile flaw someplace.
Further there must be a wildcard being used to decide which files to
install, that is a further Makefile flaw.  Wildcards should NOT be used
in the source of an install list, exactly because of this type of cruft
that can be dropped in an obj dir.

> Clearly, sort should NOT crash! Again, a re-build of zoneinfo might catch
> something. Looking at the core might tell you which "sort" was involved...
> the one you just built or the one in the base system. This could be just a
> FOTU, but I would not bet on it.

I suspect a recent zoneinfo commit as the root cause.

> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> 
> >
> >
> > On Thu, Apr 16, 2020 at 11:49 AM Johan Hendriks 
> > wrote:
> >
> >> I have a machine running FreeBSD head.
> >> rev 13.0-CURRENT #11 r360008
> >>
> >> This is a quite powerful machine, so i thought it was a good idea to let
> >> that server do the build and for my virtualbox machine i can use the
> >> powerful machine to do a installword over NFS.
> >>
> >> But when i did the make installworld step the client so to say gives an
> >> error.
> >>
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/Zulu
> >> /usr/share/zoneinfo/Zulu
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/posixrules
> >> /usr/share/zoneinfo/posixrules
> >> install   -o root -g wheel -m 444
> >> /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core
> >> /usr/share/zoneinfo/sort.core
> >> install: /usr/obj/usr/src/amd64.amd64/share/zoneinfo/builddir/sort.core:
> >> Permission denied
> >> *** Error code 71
> >>
> >> Stop.
> >> bmake[5]: stopped in /usr/src/share/zoneinfo
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[4]: stopped in /usr/src/share
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[3]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[2]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> bmake[1]: stopped in /usr/src
> >> *** Error code 1
> >>
> >> Stop.
> >> make: stopped in /usr/src
> >> .ERROR_TARGET='installworld'
> >> .ERROR_META_FILE=''
> >> .MAKE.LEVEL='0'
> >> MAKEFILE=''
> >> .MAKE.MODE='normal'
> >> _ERROR_CMD='.PHONY'
> >> .CURDIR='/usr/src'
> >> .MAKE='make'
> >> .OBJDIR='/usr/obj/usr/src/amd64.amd64'
> >> .TARGETS='installworld'
> >> DESTDIR=''
> >> LD_LIBRARY_PATH=''
> >> MACHINE='amd64'
> >> MACHINE_ARCH='amd64'
> >> MAKEOBJDIRPREFIX='/usr/obj'
> >> MAKESYSPATH='/usr/src/share/mk'
> >> MAKE_VERSION='20181221'
> >> PATH='/sbin:/bin:/usr/sbin:/usr/bin'
> >> SRCTOP='/usr/src'
> >> OBJTOP='/usr/obj/usr/src/amd64.amd64'
> >>
> >> It looks likes sort coredumps in the usr/share/zoneinfo part of the base.
> >> As it has no permission on the NFS share it errors out.
> >> On the server itself, the installworld goes well, but it leaves a
> >> sort.core file behind in /usr/share/zoneinfo
> >>
> >> cd /usr/share/zoneinfo
> >> ls -al
> >>
> >>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: Working on Zoom port

[Rodney W. Grimes]

> All,
> 
> Given how Zoom is getting used a lot more these days, I've started
> working on a port that installs the Zoom linux client.
> 
> Here is a link to my github if anyone wants to help:
> 
> https://github.com/emc2/freebsd-ports/tree/zoom
> 
> 
> I'm not done yet.  The zoom linux client installs a bunch of Qt
> libraries in its own directory.  These either need to be installed with
> a port, or else the right configs need to be set to search for libraries
> there.
> 
> I'm going to take a break, but I'm going to circle back to this.
> 

You are aware of the rather large pile of recent security issues
surronding zoom I hope.

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

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > > 
> > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri
> > Pankov writes:
> > > >Trond Endrest?l wrote:
> > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> > > >>
> > > >>> OK, I figured it out.
> > > >>>
> > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> > > >>> WITH_CTF=no.
> > > >>
> > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes
> >
> 
> It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no  never enters into it.

Then we *COULD*, maybe even *SHOULD* check for a value and
complain if one is set.

> 
> 
> > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that
> > > >value is NOT checked:
> > > >
> > > >The values of variables are ignored regardless of their setting; even
> > if
> > > >  they would be set to "FALSE" or "NO".  The presence of an option
> > > >causes it to be honored by make(1).
> > >
> > > That is not even close to POLA-compliance...
> >
> 
> It took 20 years for someone to notice. If it takes 20 years to be
> astonished, I suspect that it comes close to 'least' by any sane measure.

I do not see the word *recent* in POLA.
As far as I can tell POLA is time invariant.

> 
> > I am not a fan of it either, not sure when this idea came about
> > of doing WITH_ and WITHOUT and ignoring the set value, but it
> > is very non POLA given how many variables we do have with set values.
> >
> 
> We've literally ignored the value for the last 20 years or so (we started
> in the 4.x time frame). This is the first time it's come up. It's hard to
> make a convincing POLA argument based on this data.

Wrong or bad for 20 years makes it no less wrong.

> We specifically ignored it because we had crazy s*** in the tree like
> NOSHARED=no meaning something. And it wasn't quite the something you'd
> think it would mean without careful study (it meant do link this shared,
> which is straight forward enough. But it didn't mean do create this library
> as shared).

What you call crazy s*** is just double negatives, and though it is
poor it actually has clear symantics.

You want crazy s***
WITH_xxx=yes
WITH_xxx=no
do exactly the same thing!   Now thats crazy s***

> 
> 
> > > Obviously negative values ("false", "no") should either be reported as
> > > errors or preferably be respected.
> >
> 
> You can't make something foolproof because fools are so ingenious. Also,
> turns out it's trickier to "fix" than you might think.

It really isnt hard to fix... just stop using, then later allowing a value
on WITH_xxx or WITHOUT_xxx.

Right now we could add a warning if a value is set, people would slowly
weed out this poor use, and in time up the warning to an error.

> 
> We almost certainly are not going to change this.
Your position, others are free to disagree, as I do.

> Why aren't we going to
> change it? It took 20 years for someone to complain and it may break
> currently working scripts that rely on the documented behavior of the
> variable being defined to define WITH_FOO=n for  some crazy reason. And
> this isn't a theoretical example, I know of at least two build systems that
> define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no
> mean "I don't want foo"? or "I don't not want foo?" So if you don't do it
> for WITHOUT but do to it for WITH, you wind up with another mess of
> inconsistency, or you wind up getting close to have NOSHARED=no again.

See proposed "change and fix".  

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

Re: buildkernel failure because ctfconvert not installed

[Rodney W. Grimes]

> 
> In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov 
> writes:
> >Trond Endrest?l wrote:
> >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
> >> 
> >>> OK, I figured it out.
> >>>
> >>> I used to have MK_CTF=no in src.conf, but I recently changed it to
> >>> WITH_CTF=no.
> >> 
> >> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
> >
> >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
> >value is NOT checked:
> >
> >The values of variables are ignored regardless of their setting; even if 
> >  they would be set to "FALSE" or "NO".  The presence of an option 
> >causes it to be honored by make(1).
> 
> That is not even close to POLA-compliance...

I am not a fan of it either, not sure when this idea came about
of doing WITH_ and WITHOUT and ignoring the set value, but it
is very non POLA given how many variables we do have with set values.

> 
> Obviously negative values ("false", "no") should either be reported as
> errors or preferably be respected.
> 
> PS: [This is not the bikeshed you are looking for]

BLUE!

> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS: OpenZFS: lost the ability to boot a BE

[Rodney W. Grimes]

> To temporarily mount a ZFS filesystem:
> 
> mount -t zfs poolname/data/set /path/here

Is there anyway to get the zfs command to add mountpoint as
a temporary value like it does some of the others so that

zfs mount -o mountpoint=/mnt poolname/data/set

would just do the right thing?

> 
> 
> On 2020-03-30 19:53, Graham Perrin wrote:
> > On 30/03/2020 19:47, Graham Perrin wrote:
> >> I lost the ability to boot the environment named 'r357746', I suspect
> >> this occurred after I set it to use OpenZFS in lieu of ZFS.
> >>
> >> I would like to edit its /boot/loader.conf (revert to zfs_load="YES")
> >> but re: https://github.com/openzfs/zfs/issues/4553 I can not think of
> >> a way to mount the dataset.
> >>
> >> Please, how can I proceed?
> > 
> > Whilst booted from a different environment, I mounted the dataset whilst
> > in single user mode, edited /boot/loader.conf ? a little tricky, because
> > after the mount I could no longer use zfs commands (ZFS library
> > initialisation failed, words to that effect). Then beadm to activate the
> > BE, and shutdown -r now
> > 
> > Success :-)
> > 
> > With zfs_load="YES" (in lieu of openzfs_load="YES") the BE is usable.
> > 
> >> 
> >>
> >> Re: ZFS: destroying snapshots without compromising boot environments
> >>
> >> On 28/03/2020 15:36, Graham Perrin wrote:
> >>> On 28/03/2020 15:19, Allan Jude wrote:
> >>>
> >>> > You can try to destroy the snapshot, if it is the basis of a clone,
> >>> then
> >>> > you will get an error, that you'd need to destroy the BE first, so you
> >>> > might decide to keep that snapshot. As long as you don't use the -R
> >>> flag
> >>> > to zfs destroy dataset@snapshot, it will not destroy the clones.
> >>> >
> >>> > You can also use 'zfs promote' to make the clone into the parent,
> >>> making
> >>> > the original parent into the clone. This allows you to destroy that
> >>> > original and the snapshot while keeping the clone.
> >>>
> >>> Perfect, thank you. I was nervous about destruction without warning.
> >>>
> >>> Below, are the differences (in measurement) between beadm and bectl
> >>> to be expected?
> >>>
> >>> 
> >>>
> >>> root@momh167-gjp4-8570p:~ # beadm list
> >>> BE?? Active Mountpoint? Space Created
> >>> Waterfox -? -?? 15.9G 2020-03-10 18:24
> >>> r357746f -? -??? 1.3G 2020-03-20 06:19
> >>> r359249b NR /?? 74.7G 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # beadm list -aDs
> >>> BE/Dataset/Snapshot??? Active Mountpoint
> >>> Space Created
> >>>
> >>> Waterfox
> >>> ? copperbowl/ROOT/Waterfox -? - 137.0M
> >>> 2020-03-10 18:24
> >>> ??? r359249b@2020-03-17-21:57:17?? -? - 59.2G
> >>> 2020-03-17 21:57
> >>> ? copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -? - 67.0M
> >>> 2020-03-20 06:19
> >>>
> >>> r357746f
> >>> ? copperbowl/ROOT/r357746f -? - 1.2G
> >>> 2020-03-20 06:19
> >>> ??? Waterfox@2020-03-20-06:19:45?? -? - 59.2G
> >>> 2020-03-20 06:19
> >>>
> >>> r359249b
> >>> ? copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -? - 15.7G
> >>> 2020-03-17 21:57
> >>> ? copperbowl/ROOT/r359249b NR / 59.0G
> >>> 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # bectl list
> >>> BE?? Active Mountpoint Space Created
> >>> Waterfox -? -? 204M? 2020-03-10 18:24
> >>> r357746f -? -? 1.21G 2020-03-20 06:19
> >>> r359249b NR /? 74.7G 2020-03-28 01:19
> >>> root@momh167-gjp4-8570p:~ # bectl list -aDs
> >>> BE/Dataset/Snapshot? Active Mountpoint
> >>> Space Created
> >>>
> >>> Waterfox
> >>> ? copperbowl/ROOT/Waterfox?? -? - 204M
> >>> 2020-03-10 18:24
> >>> ? Waterfox@2020-03-20-06:19:45?? -? - 67.0M
> >>> 2020-03-20 06:19
> >>>
> >>> r357746f
> >>> ? copperbowl/ROOT/r357746f?? -? - 1.21G
> >>> 2020-03-20 06:19
> >>>
> >>> r359249b
> >>> ? copperbowl/ROOT/r359249b?? NR / 74.7G
> >>> 2020-03-28 01:19
> >>> ? r359249b@2020-03-17-21:57:17?? -? - 15.7G
> >>> 2020-03-17 21:57
> >>> root@momh167-gjp4-8570p:~ # zfs list -t snapshot
> >>> NAME USED AVAIL?
> >>> REFER? MOUNTPOINT
> >>> copperbowl/ROOT/Waterfox@2020-03-20-06:19:45??? 67.0M - 59.2G? -
> >>> copperbowl/ROOT/r359249b@2020-03-17-21:57:17??? 15.7G - 59.2G? -
> >>> copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G? -
> >>> copperbowl/poudriere/jails/head@clean??? 328K - 1.89G? -
> >>> root@momh167-gjp4-8570p:~ # zfs destroy
> >>> copperbowl/ROOT/r359249b@2020-03-17-21:57:17
> >>> cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17':
> >>> snapshot has dependent clones
> >>> use '-R' to destroy the following datasets:
> >>> copperbowl/ROOT/r357746f
> >>> copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
> >>> copperbowl/ROO

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

[Rodney W. Grimes]

> On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
> 
> >
> > 3. based solution looks good to me.
> >
> > IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
> > or EFI environment pointing to either one is properly used,
> 
> 
> That's another thing: we should be installing loader.efi as  
> \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's  
> entirely possible to lose the Boot Manager entry and end up with an  
> unbootable system as a result. Unfortunately people have had bad  
> experiences with other operating systems overwriting bootx64.efi and  
> don't believe we should do that.
> 
> 
> Perhaps I just need to come up with a proof of concept or demo to show  
> that it is possible without breaking other OSes.

Yes please.

> Rebecca Cran
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Rodney W. Grimes]

> 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

Is zfs actually loaded?

kldstat | grep zfs


Does perhaps openZfs use a seperate tree?
sysctl -a | grep arc_max

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

Re: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Rodney W. Grimes]

> In message <202001261745.00qhjkuw044...@gndrsh.dnsmgr.net>, "Rodney W. 
> Grimes"
> writes:
> > > In message <20200125233116.ga49...@troutmask.apl.washington.edu>, Steve 
> > > Kargl w
> > > rites:
> > > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote:
> > > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl 
> > > > >  > ingt
> > > > on.edu> wrote:
> > > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote:
> > > > > >> 
> > > > > >> It's not just poudeiere. Standard port builds of chromium, rust
> > > > > >> and thunderbird also fail on my machines with less than 8 GB.
> > > > > >>
> > > > > >
> > > > > >Interesting.  I routinely build chromium, rust, firefox,
> > > > > >llvm and few other resource-hunger ports on a i386-freebsd
> > > > > >laptop with 3.4 GB available memory.  This is done with
> > > > > >chrome running with a few tabs swallowing a 1-1.5 GB of
> > > > > >memory.  No issues.  
> > > > > 
> > > > > Number of threads makes a difference too. How many core/threads does 
> > > > > yo
> > ur l
> > > > aptop have?
> > > >
> > > > 2 cores.
> > > 
> > > This is why.
> > > 
> > > >
> > > > > Reducing number of concurrent threads allowed my builds to complete
> > > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per
> > > > > core. Reducing concurrent threads circumvented the issue. 
> > > >
> > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build.
> > > > Laptop isn't doing too much, but an update and browsing.  It does
> > > > take a long time especially if building llvm is required.
> > > 
> > > I use portmaster as well (for quick incidental builds). It uses 
> > > MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines 
> > > with not enough memory to support their cores with certain builds might 
> > > have a better chance of having this problem.
> > > 
> > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per 
> > > core might be an option. Looking at it this way, instead of an extra 3 
> > > GB, 
> > > the extra 60% more memory in the other machine makes a big difference. A 
> > > rule of thumb would probably be, have ~ 2 GB RAM for every core or thread 
> > > when doing large parallel builds.
> >
> > Perhaps we need to redo some boot time calculations, for one the
> > ZFS arch cache, IMHO, is just silly at a fixed percent of total
> > memory.  A high percentage at that.
> >
> > One idea based on what you just said might be:
> >
> > percore_memory_reserve = 2G (Your number, I personally would use 1G here)
> > arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb)
> >
> > I think that simple change would go a long ways to cutting down the
> > number of OOM reports we see.  ALSO IMHO there should be a way for
> > sub systems to easily tell zfs they are memory pigs too and need to
> > share the space.  Ie, bhyve is horrible if you do not tune zfs arc
> > based on how much memory your using up for VM's.
> >
> > Another formulation might be
> > percore_memory_reserve = alpha * memory_zire / cores
> >
> > Alpha most likely falling in the 0.25 to 0.5 range, I think this one
> > would have better scalability, would need to run some numbers.
> > Probably needs to become non linear above some core count.
> 
> Setting a lower arc_max at boot is unlikely to help. Rust was building on 
> the 8 GB and 5 GB 4 core machines last night. It completed successfully on 
> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB.
> 
> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap was 
> used. ARC was reported at 941 MB. arc_min on this machine is 489.2 MB.

What is arc_max?   

> Cy Schubert 
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Rodney W. Grimes]

> In message <20200125233116.ga49...@troutmask.apl.washington.edu>, Steve 
> Kargl w
> rites:
> > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote:
> > > On January 25, 2020 1:52:03 PM PST, Steve Kargl 
> > >  > on.edu> wrote:
> > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote:
> > > >> 
> > > >> It's not just poudeiere. Standard port builds of chromium, rust
> > > >> and thunderbird also fail on my machines with less than 8 GB.
> > > >>
> > > >
> > > >Interesting.  I routinely build chromium, rust, firefox,
> > > >llvm and few other resource-hunger ports on a i386-freebsd
> > > >laptop with 3.4 GB available memory.  This is done with
> > > >chrome running with a few tabs swallowing a 1-1.5 GB of
> > > >memory.  No issues.  
> > > 
> > > Number of threads makes a difference too. How many core/threads does your 
> > > l
> > aptop have?
> >
> > 2 cores.
> 
> This is why.
> 
> >
> > > Reducing number of concurrent threads allowed my builds to complete
> > > on the 5 GB machine. My build machines have 4 cores, 1 thread per
> > > core. Reducing concurrent threads circumvented the issue. 
> >
> > I use portmaster, and AFIACT, it uses 'make -j 2' for the build.
> > Laptop isn't doing too much, but an update and browsing.  It does
> > take a long time especially if building llvm is required.
> 
> I use portmaster as well (for quick incidental builds). It uses 
> MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines 
> with not enough memory to support their cores with certain builds might 
> have a better chance of having this problem.
> 
> MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per 
> core might be an option. Looking at it this way, instead of an extra 3 GB, 
> the extra 60% more memory in the other machine makes a big difference. A 
> rule of thumb would probably be, have ~ 2 GB RAM for every core or thread 
> when doing large parallel builds.

Perhaps we need to redo some boot time calculations, for one the
ZFS arch cache, IMHO, is just silly at a fixed percent of total
memory.  A high percentage at that.

One idea based on what you just said might be:

percore_memory_reserve = 2G (Your number, I personally would use 1G here)
arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb)

I think that simple change would go a long ways to cutting down the
number of OOM reports we see.  ALSO IMHO there should be a way for
sub systems to easily tell zfs they are memory pigs too and need to
share the space.  Ie, bhyve is horrible if you do not tune zfs arc
based on how much memory your using up for VM's.

Another formulation might be
percore_memory_reserve = alpha * memory_zire / cores

Alpha most likely falling in the 0.25 to 0.5 range, I think this one
would have better scalability, would need to run some numbers.
Probably needs to become non linear above some core count.

> Cy Schubert 
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Rodney W. Grimes]

> Yasuhiro KIMURA yasu at utahime.org wrote on
> Sat Jan 25 14:45:13 UTC 2020 :
> 
> > I use VirtualBox to run 13-CURRENT. Host is 64bit Windows 10 1909 and
> > spec of VM is as following.
> > 
> > * 4 CPU
> > * 8GB memory
> > * 100GB disk
> >   - 92GB ZFS pool (zroot)
> >   - 8GB swap
> > 
> > Today I updated this VM to r357104. And after that I tried to update
> > poudriere jail with `poudriere jail -u -j jailname -b`. But it failed
> > at install stage. After the failure I found following message is
> > written to syslog.
> > 
> > Jan 25 19:18:25 rolling-vm-freebsd1 kernel: pid 7963 (strip), jid 0, uid 0, 
> > was killed: out of swap space
> 
> This message text's detailed wording is a misnomer.
> Do you also have any messages of the form:
> 
> . . . sentinel kernel: swap_pager_getswapspace(32): failed
> 
> If yes: you really were out of swap space.
> If no:  you were not out of swap space,
> or at least it is highly unlikely that you were.
> 
> FreeBSD kills processes for multiple potential reasons.
> For example:
> 
> a) Still low on free RAM after a number of tries to increase it above a 
> threshold.
> b) Slow paging I/O.
> c) . . . (I do not know the full list) . . .
> 
> Unfortunately, FreeBSD is not explicit about the category
> of problem that leads to the kill activity that happens.
> 
> You might learn more by watching how things are going
> via top or some such program or other way of monitoring.
> 
> 
> Below are some notes about specific tunables that might
> or might not be of help. (There may be more tunables
> that can help that I do not know about.)
> 
> For (a) there is a way to test if it is the issue by
> adding to the number of tries before it gives up and
> starts killing things. That will either:
> 
> 1) let it get more done before kills start
> 2) let it complete before the count is reached
> 3) make no significant difference
> 
> (3) would imply that (b) or (c) are involved instead.
> 
> (1) might be handled by having it do even more tries.
> 
> For delaying how long free RAM staying low is
> tolerated, one can increase vm.pageout_oom_seq from
> 12 to larger. The management of slow paging I've
> less experience with but do have some notes about
> below.
> 
> Examples follow that I use in contexts with
> sufficient RAM that I do not have to worry about
> out of swap/page space. These I've set in
> /etc/sysctl.conf . (Of course, I'm not trying to
> deliberately run out of RAM.)
> 
> #
> # Delay when persisstent low free RAM leads to
> # Out Of Memory killing of processes:
> vm.pageout_oom_seq=120
> 
> I'll note that figures like 1024 or 1200 or
> even more are possible. This is controlling how
> many tries at regaining sufficient free RAM
> that that level would be tolerated long-term.
> After that it starts Out Of Memory kills to get
> some free RAM.
> 
> No figure is designed to make the delay
> unbounded. There may be large enough figures to
> effectively be bounded beyond any reasonable
> time to wait.
> 
> 
> As for paging I/O (this is specific to 13,
> or was last I checked):
> 
> #
> # For plunty of swap/paging space (will not
> # run out), avoid pageout delays leading to
> # Out Of Memory killing of processes:
> vm.pfault_oom_attempts=-1
> 
> (Note: In my context "plunty" really means
> sufficient RAM that paging is rare. But
> others have reported on using the -1 in
> contexts where paging was heavy at times and
> OOM kills had been happening that were
> eliminated by the assignment.)
> 
> I've no experience with the below alternative
> to that -1 use:
> 
> #
> # For possibly insufficient swap/paging space
> # (might run out), increase the pageout delay
> # that leads to Out Of Memory killing of
> # processes:
> #vm.pfault_oom_attempts= ???
> #vm.pfault_oom_wait= ???
> # (The multiplication is the total but there
> # are other potential tradoffs in the factors
> # multiplied, even for nearly the same total.)
> 
> 
> I'm not claiming that these 3 vm.???_oom_???
> figures are always sufficient. Nor am I
> claiming that tunables are always available
> that would be sufficient. Nor that it is easy
> to find the ones that do exist that might
> help for specific OOM kill issues.
> 
> I have seen reports of OOM kills for other
> reasons when both vm.pageout_oom_seq and
> vm.pfault_oom_attempts=-1 were in use.
> As I understand, FreeBSD did not report
> what kind of condition lead to the
> decision to do an OOM kill.
> 
> So the above notes may or may-not help you.

All the advice by Mark above is very sound and solid, however my
first step would be to cut back the memory pig that is ZFS with:
vfs.zfs.arc_max=4294967296
added to loader.conf

> 
> > To make sure I shutdown both VM and host, restarted them and tried
> > update of jail again. Then the problem was reproduced.
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> ___
> freebsd-current@freebsd.org mailing list
> https:/

Re: OpenSSL breaks factor(6)

[Rodney W. Grimes]

> On Sat, Dec 28, 2019 at 10:46:52PM -0500, Garance A Drosehn wrote:
> > On 27 Dec 2019, at 17:42, Steve Kargl wrote:
> > >
> > > This patch now includes a fix for hexadecimal conversion.  It
> > > simple scans the string for a hex digit in [a,...,f] and assumes
> > > that a hexadecimal string has been entered.  A string that includes
> > > character from the decimal digits is assumed to by a decimal
> > > representation.
> > 
> > What if the user wants to factor a hexadecimal value which does not
> > happen to include [a...f]?
> > 
> > How about recognizing a prefix of '0x' as a way to indicate the value
> > is hexadecimal?
> > 
> 
> An interested user will need to add that support.  AFAIK, factor(6)
> has never recognized the 0x prefix, and I'm not trying to add new 
> features.  I'm simply fixing factor(6) to match its documentation, 
> and trying to ensure WITH_OPENSSL and WITHOUT_OPENSSL give the 
> same results where applicable.
> 
> The logic is to first try to convert the string to a decimal if
> the leading digits are members of the set [0,...,9].  If this
> conversion fails, then try to convert the string as a hexadecimal
> number.  A problem occurs because OpenSSL's BN_dec2bn does not fail
> for a number like '1abc' (converts it to 1) whereas the local
> implementation of BN_dec2bn fails during the conversion, and so
> the BN_hex2bn function is executed and '1abc' is converted.

Wasnt the hex conversion undocumented? 
Since it seems to have issues, and is of dubious value
might it might be best to just remove it?

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

Re: OpenSSL breaks factor(6)

[Rodney W. Grimes]

> On Fri, Dec 27, 2019 at 07:00:04PM -0800, Rodney W. Grimes wrote:
> > > On Fri, Dec 27, 2019 at 01:47:17PM -0800, Steve Kargl wrote:
> > > > On Fri, Dec 27, 2019 at 01:25:30PM -0800, Steve Kargl wrote:
> > > > > The use of OpenSSL in factor(6) breaks factor(6) with respect to
> > > > > its documentation.
> > > > > 
> > > > > % man factor
> > > > >   ...
> > > > >   Numbers may be preceded by a single '+'.
> > > > >   ...
> > > > > 
> > > > > % factor +125
> > > > > factor: +125: illegal numeric format.
> > > > > 
> > > > 
> > > > This fixes factor(6) for the above issue.  The issue with
> > > > hexadecimal is not easily fixed.
> > > >
> > >  
> > > This patch now includes a fix for hexadecimal conversion.  It
> > > simple scans the string for a hex digit in [a,...,f] and assumes
> > > that a hexadecimal string has been entered.  A string that includes
> > > character from the decimal digits is assumed to by a decimal
> > > representation.  
> > 
> > It looks to me that the old code did the common method of
> > try to convert as decimal, if that fails, try it as hex,
> > if that fails report an error.
> > 
> > Why is is that this common logic no longer works?
> 
> AFAICT, BN_dec2bn and BN_hex2bn from OpenSSL scan from left
> to right, does a conversion with what is possible, and reports
> success.  That is, for 1abc, BN_dec2bn can convert 1 to 1 and
> reports success.  The local implementations of these functions,
> when OpenSSL is not used, does not do this partial conversion.

I think I see now, the local implementaton checks for whole
string conversion with a test for newline or null as the last
byte converted by strtoul, the OpenSSL does not do this.

So why ever use the, um, IMHO broken for this application,
SSL versions of these functions?  Or if we do need to use
them for some reason apply the whole string conversion
checks as wrappers around them?

> > > 
> > > Index: factor.c
> > > ===
> > > --- factor.c  (revision 355983)
> > > +++ factor.c  (working copy)
> > > @@ -71,6 +71,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -104,6 +105,7 @@
> > >  
> > >  #endif
> > >  
> > > +static bool  is_hex(char *str);
> > >  static void  BN_print_dec_fp(FILE *, const BIGNUM *);
> > >  
> > >  static void  pr_fact(BIGNUM *);  /* print factors of a value */
> > > @@ -148,21 +150,25 @@
> > >   for (p = buf; isblank(*p); ++p);
> > >   if (*p == '\n' || *p == '\0')
> > >   continue;
> > > + if (*p == '+') p++;
> > >   if (*p == '-')
> > >   errx(1, "negative numbers aren't permitted.");
> > > - if (BN_dec2bn(&val, buf) == 0 &&
> > > - BN_hex2bn(&val, buf) == 0)
> > 
> > Why does this logic fail?
> 
> See BN_hex2bn manpage.   C/C++ does shortcircuits.  With 1abc,
> BN_dec2bn converts the string to 1, puts it in val, and returns
> nonzero.  BN_hex2bn is never called.  Flipping the conditionals,
> of course, doesn't work because 0-9 are digits in the hexadecimal
> set (e.g., 111 is a valid hex and decimal string).
> 
> > > - errx(1, "%s: illegal numeric format.", buf);
> > > + ch = is_hex(p) ? BN_hex2bn(&val, p) :
> > > + BN_dec2bn(&val, p);
> > > + if (ch == 0)
> > > + errx(1, "%s: illegal numeric format.", p);
> > >   pr_fact(val);
> > >   }
> > >   /* Factor the arguments. */
> > >   else
> > > - for (; *argv != NULL; ++argv) {
> > > - if (argv[0][0] == '-')
> > > + for (p = *argv; p != NULL; p = *++argv) {
> > > + if (*p == '-')
> > >   errx(1, "negative numbers aren't permitted.");
> > > - if (BN_dec2bn(&val, argv[0]) == 0 &&
> > > -  

Re: OpenSSL breaks factor(6)

[Rodney W. Grimes]

> On Fri, Dec 27, 2019 at 02:42:12PM -0800, Steve Kargl wrote:
> > On Fri, Dec 27, 2019 at 01:47:17PM -0800, Steve Kargl wrote:
> > > On Fri, Dec 27, 2019 at 01:25:30PM -0800, Steve Kargl wrote:
> > > > The use of OpenSSL in factor(6) breaks factor(6) with respect to
> > > > its documentation.
> > > > 
> > > > % man factor
> > > >   ...
> > > >   Numbers may be preceded by a single '+'.
> > > >   ...
> > > > 
> > > > % factor +125
> > > > factor: +125: illegal numeric format.
> > > > 
> > > 
> > > This fixes factor(6) for the above issue.  The issue with
> > > hexadecimal is not easily fixed.
> > >
> >  
> > This patch now includes a fix for hexadecimal conversion.  It
> > simple scans the string for a hex digit in [a,...,f] and assumes
> > that a hexadecimal string has been entered.  A string that includes
> > character from the decimal digits is assumed to by a decimal
> > representation.  
> 
> Might as well fix the documentation.  Acknowledges that factor(6)
> can deal with hexidecimal strings, and as a bonus fixes the bogus
> information about the maximum value considered by primes(6).
> 
> Index: factor.6
> ===
> --- factor.6  (revision 355983)
> +++ factor.6  (working copy)
> @@ -36,7 +36,7 @@
>  .\"
>  .\"   chongo  /\oo/\
>  .\"
> -.Dd October 10, 2002
> +.Dd December 27, 2019
>  .Dt FACTOR 6
>  .Os
>  .Sh NAME
> @@ -67,11 +67,20 @@
>  .Nm
>  is invoked with no arguments,
>  .Nm
> -reads numbers, one per line, from standard input, until end of file or error.
> +reads numbers, one per line, from standard input, until end of file or 0
> +is entered or an error occurs.
>  Leading white-space and empty lines are ignored.
>  Numbers may be preceded by a single
>  .Ql + .
>  Numbers are terminated by a non-digit character (such as a newline).
> +Numbers can be either decimal or hexadecimal strings.
> +If the string contains only decimal digits, it is treated as a
> +decimal representation for a number.
> +A hexadecimal string should not a
  ^contain? s/a/an/

> +.Em 0x
> +or
> +.Em 0X
> +prefix.
>  After a number is read, it is factored.
>  .Pp
>  The
> @@ -89,7 +98,7 @@
>  value must not be greater than the maximum.
>  The default and maximum value of
>  .Ar stop
> -is 3825123056546413050.
> +is 18446744073709551615.
>  .Pp
>  When the
>  .Nm primes
> 
> -- 
> Steve

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

Re: OpenSSL breaks factor(6)

[Rodney W. Grimes]

> On Fri, Dec 27, 2019 at 01:47:17PM -0800, Steve Kargl wrote:
> > On Fri, Dec 27, 2019 at 01:25:30PM -0800, Steve Kargl wrote:
> > > The use of OpenSSL in factor(6) breaks factor(6) with respect to
> > > its documentation.
> > > 
> > > % man factor
> > >   ...
> > >   Numbers may be preceded by a single '+'.
> > >   ...
> > > 
> > > % factor +125
> > > factor: +125: illegal numeric format.
> > > 
> > 
> > This fixes factor(6) for the above issue.  The issue with
> > hexadecimal is not easily fixed.
> >
>  
> This patch now includes a fix for hexadecimal conversion.  It
> simple scans the string for a hex digit in [a,...,f] and assumes
> that a hexadecimal string has been entered.  A string that includes
> character from the decimal digits is assumed to by a decimal
> representation.  

It looks to me that the old code did the common method of
try to convert as decimal, if that fails, try it as hex,
if that fails report an error.

Why is is that this common logic no longer works?

> 
> Index: factor.c
> ===
> --- factor.c  (revision 355983)
> +++ factor.c  (working copy)
> @@ -71,6 +71,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -104,6 +105,7 @@
>  
>  #endif
>  
> +static bool  is_hex(char *str);
>  static void  BN_print_dec_fp(FILE *, const BIGNUM *);
>  
>  static void  pr_fact(BIGNUM *);  /* print factors of a value */
> @@ -148,21 +150,25 @@
>   for (p = buf; isblank(*p); ++p);
>   if (*p == '\n' || *p == '\0')
>   continue;
> + if (*p == '+') p++;
>   if (*p == '-')
>   errx(1, "negative numbers aren't permitted.");
> - if (BN_dec2bn(&val, buf) == 0 &&
> - BN_hex2bn(&val, buf) == 0)

Why does this logic fail?

> - errx(1, "%s: illegal numeric format.", buf);
> + ch = is_hex(p) ? BN_hex2bn(&val, p) :
> + BN_dec2bn(&val, p);
> + if (ch == 0)
> + errx(1, "%s: illegal numeric format.", p);
>   pr_fact(val);
>   }
>   /* Factor the arguments. */
>   else
> - for (; *argv != NULL; ++argv) {
> - if (argv[0][0] == '-')
> + for (p = *argv; p != NULL; p = *++argv) {
> + if (*p == '-')
>   errx(1, "negative numbers aren't permitted.");
> - if (BN_dec2bn(&val, argv[0]) == 0 &&
> - BN_hex2bn(&val, argv[0]) == 0)
> - errx(1, "%s: illegal numeric format.", argv[0]);
> + if (*p == '+') p++;
> + ch = is_hex(p) ? BN_hex2bn(&val, p) :
> + BN_dec2bn(&val, p);
> + if (ch == 0)
> + errx(1, "%s: illegal numeric format.", p);
>   pr_fact(val);
>   }
>   exit(0);
> @@ -343,10 +349,9 @@
>  BN_dec2bn(BIGNUM **a, const char *str)
>  {
>   char *p;
> -
This blank line is part of style(9)

>   errno = 0;
>   **a = strtoul(str, &p, 10);
> - return (errno == 0 && (*p == '\n' || *p == '\0'));
> + return (errno == 0 ? 1 : 0);/* OpenSSL returns 0 on error! */
>  }
>  
>  static int
> @@ -356,7 +361,7 @@
>  
>   errno = 0;
>   **a = strtoul(str, &p, 16);
> - return (errno == 0 && (*p == '\n' || *p == '\0'));
> + return (errno == 0 ? 1 : 0);/* OpenSSL returns 0 on error! */
>  }
>  
>  static BN_ULONG
> @@ -370,3 +375,17 @@
>  }
>  
>  #endif
> +
> +/* Check if the string contains a hexadecimal digit. */
> +static bool
> +is_hex(char *str)
This function is poorly named as it does not check for
all valid hex digits, only for alpha hex digits.  It
also only accepts lower case hex alpha, I would expect
hex input to be case insensitive.

is_hexalpha?

> +{
> + char c, *p;
> + for (p = str; *p; p++) {
> + c = tolower(*p);
> + if (c == 'a' || c == 'b' || c == 'c' || c == 'd' ||
> + c == 'e' || c == 'f')
if ( c >= 'a' || c <= 'f')

> + return true;
> + }
> + return false;
> +}
> 
> -- 
> Steve

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

Re: Best way to print something from the kernel at 1s intervals?

[Rodney W. Grimes]

> > I?ve been looking into the ?kernel looks to be hung at reboot? problem at 
> > bit. Adding a lot of printf() calls to the relevant parts it looks like it 
> > actually isn?t hung but busy unmounting filesystems (which we have 
> > thousands of), flushing disk caches, calling registered callbacks and stuff 
> > and sometimes it takes a bit longer than usual - probably due to ZFS having 
> > stuff queued up that needs to be written to disk before it finishes?
> > 
> > Anyway, I?d like to propose that we add some kind of counter/printf() calls 
> > in that code area so we can see that things are indeed progressing. 
> > However, I?d probably prefer not to print _every_ filesystem (or registered 
> > callbacks - a lot of those...) - that generates a lot of output (tried that 
> > :-) but something like:
> > 
> > Unmounting filesystems:
> > 1234 done
> > (With the "1234 done? updated something like once per second).
> > 
> > What?s the right/best way to do that from the kernel? In user space I?d 
> > just call time(&t) at some convenient points and only print something if 
> > ?t? has changed. :-)
> 
> How about updated every 128 unmounts?
> 
> if ((i & 0x7f) == i) printf("%i done\n:");

if ((i & 0x7f) == 0) printf("%i done\n:");

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

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

Re: Best way to print something from the kernel at 1s intervals?

[Rodney W. Grimes]

> I?ve been looking into the ?kernel looks to be hung at reboot? problem at 
> bit. Adding a lot of printf() calls to the relevant parts it looks like it 
> actually isn?t hung but busy unmounting filesystems (which we have thousands 
> of), flushing disk caches, calling registered callbacks and stuff and 
> sometimes it takes a bit longer than usual - probably due to ZFS having stuff 
> queued up that needs to be written to disk before it finishes?
> 
> Anyway, I?d like to propose that we add some kind of counter/printf() calls 
> in that code area so we can see that things are indeed progressing. However, 
> I?d probably prefer not to print _every_ filesystem (or registered callbacks 
> - a lot of those...) - that generates a lot of output (tried that :-) but 
> something like:
> 
> Unmounting filesystems:
> 1234 done
> (With the "1234 done? updated something like once per second).
> 
> What?s the right/best way to do that from the kernel? In user space I?d just 
> call time(&t) at some convenient points and only print something if ?t? has 
> changed. :-)

How about updated every 128 unmounts?

if ((i & 0x7f) == i) printf("%i done\n:");

> 
> - Peter

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

Re: ntpd segfaults on start

[Rodney W. Grimes]

> On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin
> > > > Belousov writes:
> > > > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > > > > I've been able to set the memlock rlimit as low as 20 MB. The
> > > > > > issue is 
> > > > > > letting it default to 0 which allows ntp to mlockall()
> > > > > > anything it wants. 
> > > > > > ntpd on my sandbox is currently using 18 MB.
> > > > > 
> > > > > Default stack size on amd64 is 512M, and default stack gap
> > > > > percentage is
> > > > > 3%. This means that the gap can be as large as ~17MB. If 3MB is
> > > > > enough
> > > > > for the stack of the main thread of ntpd, then fine.
> > > > 
> > > > The default stack is 200K, which is also tuneable in ntp.conf.
> > > > 
> > > > [...]
> > > 
> > > I haven't seen anyone ask what I consider to be the crucial
> > > question
> > > yet:  why are we locking ntpd into memory by default at all?
> > > 
> > > I have seen two rationales for ntpd using mlockall() and
> > > setrlimit(): 
> > > 
> > >- There are claims that it improves timing performance.
> > > 
> > >- Because ntpd is a daemon that can run for months at a time,
> > >setting limits on memory and stack growth can help detect and
> > >mitigate against memory leak problems in the daemon.
> > 
> > Doesn't locking this memory down also protect ntpd from OOM kills?
> > If so that is a MUST preserve functionality, as IMHO killing ntpd
> > on a box that has it configured is a total no win situation.
> > 
> 
> Does it have that effect?  I don't know.  But I would argue that that's
> a separate issue, and we should make that happen by adding
> ntpd_oomprotect=YES to /etc/defaults/rc.conf
> 
> Right now only syslogd has oomprotect set to YES by default.  Maybe
> that's a good choice -- once we start declaring one daemon to be more
> important than others, you'll discover there's a whole back lot full of
> bikesheds that need painting.
> 
> So maybe we should just document ntpd_oomprotect=YES in some more-
> prominent way.  If we were to add a comment block to ntp.conf
> describing rlimit, that might be a good place to mention setting
> ntpd_oomprotect in rc.conf.
>
> -- Ian

All very reasonable, thanks Ian.

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

Re: ntpd segfaults on start

[Rodney W. Grimes]

> On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin Belousov writes:
> > > On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote:
> > > > I've been able to set the memlock rlimit as low as 20 MB. The issue is 
> > > > letting it default to 0 which allows ntp to mlockall() anything it 
> > > > wants. 
> > > > ntpd on my sandbox is currently using 18 MB.
> > > 
> > > Default stack size on amd64 is 512M, and default stack gap percentage is
> > > 3%. This means that the gap can be as large as ~17MB. If 3MB is enough
> > > for the stack of the main thread of ntpd, then fine.
> > 
> > The default stack is 200K, which is also tuneable in ntp.conf.
> > 
> > [...]
> 
> I haven't seen anyone ask what I consider to be the crucial question
> yet:  why are we locking ntpd into memory by default at all?
> 
> I have seen two rationales for ntpd using mlockall() and setrlimit(): 
> 
>- There are claims that it improves timing performance.
> 
>- Because ntpd is a daemon that can run for months at a time,
>setting limits on memory and stack growth can help detect and
>mitigate against memory leak problems in the daemon.

Doesn't locking this memory down also protect ntpd from OOM kills?
If so that is a MUST preserve functionality, as IMHO killing ntpd
on a box that has it configured is a total no win situation.

Regards,
Rod

> I am *highly* skeptical of claims that locking ntpd in memory will
> improve timing performance on freebsd (to the point where I'm inclined
> to dismiss them out of hand, but I'd be willing to look at any actual
> evidence).
> 
> The second point has at least some validity, but would be better
> implemented (IMO) by decoupling the address space limit from the act of
> locking down memory, and allowing configuration of RLIMIT_AS separately
> from RLIMIT_MEMLOCK.  If there's any interest in this, I could try to
> put together a patchset and submit it upstream for that.
> 
> I would propose that for freebsd, the autoconf-generated value for
> DFLT_RLIMIT_MEMLOCK should be -1 to avoid calling setrlimit() and
> mlockall() by default.  Then in the ntp.conf we distribute we have a
> section like:
> 
># To lock ntpd into memory, uncomment the following rlimit line.
># This should not be necessary on most systems, but may improve
># performance on heavily-loaded servers experiencing enough
># memory pressure to cause ntpd to be paged out.
># rlimit memlock  stacksize 
> 
> Then we would need to come up with reasonable values for .
> 
> -- Ian
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: HEADSUP: drm-current-kmod now installs sources

[Rodney W. Grimes]

> On Fri, 16 Aug 2019 15:40:24 -0700
> Cy Schubert  wrote:
> 
> > On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes"
> >  wrote:
> > >> On 8/14/19 3:40 PM, Daniel Eischen wrote:  
> > >> > I've lost the original thread, but would the sources in  
> > >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX
> > >is?  And, now that sources may be installed by a port, what is the
> > >method for _just_ updating the sources?  Why do I even need to build
> > >and install the port?  Personally, I would just rather have the
> > >drm-kmod sources just imported into base and maintained there.  If I
> > >have 2 or more different checked out base src trees, how do I get the
> > >correct drm-kmod to go with them if there is only one
> > >/usr/local/sys/modules?  Do I need multiple port trees just to pull
> > >in out of tree module sources?  
> > >> 
> > >> In some ways, installing sources for DRM is a compromise for the
> > >> fact  
> > >that we  
> > >> can't have DRM in the base source anymore (for various reasons).   
> > >However,  
> > >> virtualbox is also probably in that camp as well.  
> > >
> > >I applaud this effort to provide a source compile mode for DRM,
> > >but I think it has come up a bit short on execution with numorious
> > >problems sited.
> > >
> > >I too am not real happy that /usr/local/src is going to get
> > >automatically invoked from my some odd 10+ src trees that
> > >are of various WIP's.  I need a way to easily disable this
> > >both on a global scale, and on a per src tree way.
> > >
> > >Rather than a default to on with an opt out mechanism perhaps
> > >while we gain experience change this to a default to off with
> > >an opt in mechanism?
> > >
> > >Sadly I do not have proposed solution, but something better
> > >than what is there now needs to be found.
> > >
> > >Regards,  
> > 
> > Could we have a .src.conf in the root of the tree to configure this
> > on a tree by tree basis?
> > 
> > 
> 
> 
> I use better way:
> /etc/make.conf:

That file is global to all src trees,
so that does not achive the desired effect.

> # Modules to build with kernel.
> PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod

Can we some how trigger that from either a kernel conf file,
or at least on a per src tree basis?  Ala cy's .src.conf?
 
> +
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290

I do like the patch that makes these go into the obj dir, good stuff!


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

Re: HEADSUP: drm-current-kmod now installs sources

[Rodney W. Grimes]

> On 8/14/19 3:40 PM, Daniel Eischen wrote:
> > I've lost the original thread, but would the sources in 
> > /usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX is?  
> > And, now that sources may be installed by a port, what is the method for 
> > _just_ updating the sources?  Why do I even need to build and install the 
> > port?  Personally, I would just rather have the drm-kmod sources just 
> > imported into base and maintained there.  If I have 2 or more different 
> > checked out base src trees, how do I get the correct drm-kmod to go with 
> > them if there is only one /usr/local/sys/modules?  Do I need multiple port 
> > trees just to pull in out of tree module sources?
> 
> In some ways, installing sources for DRM is a compromise for the fact that we
> can't have DRM in the base source anymore (for various reasons).  However,
> virtualbox is also probably in that camp as well.

I applaud this effort to provide a source compile mode for DRM,
but I think it has come up a bit short on execution with numorious
problems sited.

I too am not real happy that /usr/local/src is going to get
automatically invoked from my some odd 10+ src trees that
are of various WIP's.  I need a way to easily disable this
both on a global scale, and on a per src tree way.

Rather than a default to on with an opt out mechanism perhaps
while we gain experience change this to a default to off with
an opt in mechanism?

Sadly I do not have proposed solution, but something better
than what is there now needs to be found.

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

Re: Stop installing /usr/bin/clang

[Rodney W. Grimes]

> On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote:
> > On 15/08/2019 17:48, Konstantin Belousov wrote:
> >  > Please look at https://reviews.freebsd.org/D21060
> >  > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> >  >
> >  > It probably does not matter when all your software comes from ports or
> >  > packages, but is actually very annoying when developing on FreeBSD.
> >  > In particular, you never know which `clang' is called in the user
> >  > environment, because it depends on the $PATH elements ordering.
> > 
> > What is the confusion here?
> Between /usr/bin/clang and /usr/local/bin/clang.

Why is that a confusion?  Any installed port that overloades
a base system component expects to do exactly that type of thing.
Why is clang special in this respect?

> > The binary that is invoked as clang is from the base system.
> Not necessary.
> 
> > The binary that is invoked as clang{version number} is from ports.
> This is irrelevant.
> 
> > If the user has built clang from source and has set up 
> > their path to put that first, then they will get a different clang, but 
> > there's no way we can stop that kind of behaviour.
> This is irrelevant as well.
> 
> You did not read neither review summary nor followups.  clang also
> comes from devel/llvm.  Users that want clang do install it, esp. when
> version in base is different.

Exactly what is installed from devel/llvm that was not
covered below as clang-devel?  And why is it any different
than any other port of clang listed below?

> > For reference, on my machine, I have:
> > 
> > clang <- this one is from the base system
> > clang60 <- this one if from ports
> > clang70 <- this one if from ports
> > clang80 <- this one if from ports
> > clang-devel <- this one if from ports
> > 
> > Nothing in my PATH order affects this.
> > 
> > The only source of confusion that I regularly encounter comes from the 
> > fact that FreeBSD packages install clang80, when every other system 
> > installs clang-8, so I end up having to have a special case in CMake 
> > logic for finding specific versions of tools like clang-format on FreeBSD.
> > 
> > That said, I don't know what the impact would be on configure scripts if 
> > we didn't have a clang binary.  CMake seems to run ${CC} -v and parse 
> > the output, so it's quite happy finding that cc is clang (and the 
> > specific version).  How do most autoconf things handle this?  Apple 
> > shipped a gcc symlink to clang for years because, in the absence of a 
> > gcc binary, a load of programs detected /usr/bin/cc and decided not to 
> > enable any GNU extensions.  We've managed to avoid having to do that, 
> > but how many things look for clang, gcc, and cc in the path and enable 
> > features based on which one they find?
> 
> I plan to ask for exp run with the patch after some more time to gather
> feedback.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: Stop installing /usr/bin/clang

[Rodney W. Grimes]

> On Fri, Aug 16, 2019 at 08:57:13AM +0300, nonamel...@ukr.net wrote:
> > I see the same thing with base?/usr/bin/ld and?/usr/local/bin/ld from 
> > binutils.
> Yes but a direct ld use is very rare. When it is needed, usually the
> level of hackery applied is already high enough for the user to already
> know what she does.  I did not see it causing issues practically, while
> multiple clangs in the path cause real problems.

Though I have accepted the change, I have now heard this "multiple foo
in path" argument twice, could you please elaborate on it?

If /usr/bin /bin are first I should get base stuff, 
if /usr/local/bin are first I should get local stuff,
what exactly is this "real problems" your refering too?

Is it that something is flipping paths around?  If so that
should be fixed!  People have been using path to pick which
overload order they prefer for decades, and if we have some
how broken this.. well that should get fixed asap, not
removing stuff out of base because something is broken by
incorrect path manipulations.

Regards,
Rod
> > --- Original message ---
> > From: "Konstantin?Belousov"?
> > Date: 15?August?2019,?19:48:37
> > 
> > Please look at https://reviews.freebsd.org/D21060
> > I propose to stop installing /usr/bin/clang, clang++, clang-cpp.
> > 
> > It probably does not matter when all your software comes from ports or
> > packages, but is actually very annoying when developing on FreeBSD.
> > In particular, you never know which `clang' is called in the user
> > environment, because it depends on the $PATH elements ordering.
> > 
> > To clear some confusion: this has nothing to do with not installing
> > compiler from base, /usr/bin/c{c,++,pp} are still there after the change
> > is applied.  It only to make clang on par with gcc, and to remove one
> > thing that was quite time-consuming in multi-target environment for me
> > during porting something large in FreeBSD userspace.
> > ___
> > 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"
> 
> 

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

Re: rc script: manual stop vs system shutdown

[Rodney W. Grimes]

> On Aug 1, 2019, at 08:53, Rodney W. Grimes  
> wrote:
> 
> >> 
> >> Is it possible in an rc script to distinguish between a manual stop
> >> (e.g., service foo stop) and a stop during a system shutdown (via
> >> rc.shutdown) ?
> >> Are there any marker variables for that?
> >> Or something in the global system state?
> > 
> > Not that I can think of, but I like this idea,
> > I am sure that use cases exist.
> 
> Have you looked at:
> keyword: shutdown
> etc?

Well that does indeed seem to wipe out my
"Not that I can think of".  So infact an rc script
can tell, it is invoked as:

/etc/rc.d/foo shutdown
during a system shutdown

vs

/etc/rc.d/foo stop
when invoked by service foo stop?

Is that correct?

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

Re: rc script: manual stop vs system shutdown

[Rodney W. Grimes]

> 
> Is it possible in an rc script to distinguish between a manual stop
> (e.g., service foo stop) and a stop during a system shutdown (via
> rc.shutdown) ?
> Are there any marker variables for that?
> Or something in the global system state?

Not that I can think of, but I like this idea,
I am sure that use cases exist.

> Andriy Gapon
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Rodney W. Grimes]

> The .iso files are for a dvd install. If you want to use a usb, download
> the .img files.
> 
> FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img
> 

The FreeBSD projects amd64 .iso images are hybrid now,
they should work both as a memstick image and as a burned .iso.

IFF this is failing it is a bug and should be addressed.

file FreeBSD-13.0-CURRENT-amd64-20181213-r342020-disc1.iso
FreeBSD-13.0-CURRENT-amd64-20181213-r342020-disc1.iso: DOS/MBR boot sector; 
partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 
1, 1758779 sectors

file FreeBSD-12.0-CURRENT-amd64-20171206-r326622-disc1.iso
FreeBSD-12.0-CURRENT-amd64-20171206-r326622-disc1.iso: ISO 9660 CD-ROM 
filesystem data '12_0_CURRENT_AMD64_CD' (bootable)


> ( or get the .xz version and extract it on your machine - it's smaller)
> 
> This "mount root" problem got me too, so don't feel alone.
> 
> Clay
> clay@fbsd13:~ $ uname -a
> FreeBSD fbsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r350322 GENERIC  amd64
> 
> 
> On Mon, Jul 29, 2019 at 4:03 PM Nick Wolff  wrote:
> 
> > I just tested the snapshot from 20190725 and still am getting the root
> > mount rating for "boot on boot. I think something deeper broke between
> > r349133 and r349160 because even when I turn off wait for Root Mount on usb
> > root via a loader variable boot just get's stuck later on in the process.
> >
> > This is all happening on an x11-dpi-nt board.
> >
> >
> > http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
> >
> > On Mon, Jul 22, 2019 at 12:57 PM Nick Wolff 
> > wrote:
> >
> > > Hans,
> > >
> > > I'm building r350003  at the moment which is after the acpi change was
> > > moved into an unloaded module.
> > >
> > >
> > >
> > > On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky 
> > > wrote:
> > >
> > >> On 2019-07-22 17:23, Nick Wolff wrote:
> > >> > Sorry for email spam but I was wrong. Just gets stuck now during
> > >> reproping
> > >> > a pci device after init happens(this is actually a trueos build which
> > is
> > >> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
> > >> CBDMA
> > >> > Registers" which shouldn't have a driver attached.
> > >> >
> > >>
> > https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
> > >> >
> > >> > Though it maybe something else getting stuck at this point and that
> > just
> > >> > happens to be the last thing on the screen.
> > >> >
> > >>
> > >> There was a recent change to add an ACPI wrapper for the USB HUB driver,
> > >> but that was a bit premature and introduced some bugs. For now the ACPI
> > >> USB HUB wrapper is not enabled by default. Do you experience issues with
> > >> the latest -current ?
> > >>
> > >> --HPS
> > >>
> > >>
> > ___
> > 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"
> 

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

Re: Checking out the CSRG repository?

[Rodney W. Grimes]

> On 19-06-20 05 h 59, Warner Losh wrote:
> > On Wed, Jun 19, 2019 at 7:55 PM Alan Somers  wrote:
> > 
> >> On Wed, Jun 19, 2019 at 8:41 PM Warner Losh  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Jun 19, 2019, 7:09 PM Alan Somers  wrote:
> 
>  On Wed, Jun 19, 2019 at 5:38 PM Warner Losh  wrote:
> >
> >
> >
> > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers 
> >> wrote:
> >>
> >> Does anybody know how to check out a local copy of the CSRG
> >> repository?  I can view it with ViewVC, but I would really like local
> >> access.  It doesn't seem to be available on the usual
> >> repo.FreeBSD.org
> >> or svn.FreeBSD.org.
> >>
> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg
> >> svn: E170013: Unable to connect to a repository at URL
> >> 'https://svn.freebsd.org/csrg'
> >> svn: E175009: The XML response contains invalid XML
> >> svn: E130003: Malformed XML: no element found at line 1
> >>
> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg
> >> svn: E170013: Unable to connect to a repository at URL
> >> 'svn+ssh://asom...@repo.freebsd.org/csrg'
> >> svn: E210005: No repository found in 'svn+ssh://
> >> asom...@repo.freebsd.org/csrg'
> >
> >
> > Can't answer this question directly about svn
> >
> > But I have been using
> >> https://github.com/dspinellis/unix-history-repo.git to look at historical
> >> sources. https://github.com/csrg has a number of additional repos of
> >> historical interest, though they are all forks from somewhere else.
> >
> > Warner
> 
>  Thanks for that Github link; it's pretty useful.  Also, I found this
>  site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl .  I just
>  wish I had a better understanding of the relationship between CSRG and
>  the various releases.  It seems like some stuff got committed to CSRG
>  yet didn't make it into an official release for years, if ever.
> >>>
> >>>
> >>> TUHS is awesome. I use it too, bit the historical github tree is more
> >> convenient.
> >>>
> >>> CSRG's 4.x series was pretty linear. What didn't make it?
> >>>
> >>> Warner
> >>
> >> I'm looking at bmap.  When I wrote that email, the earliest released
> >> reference I could find was in 4.3-Reno.  However, I just spotted it in
> >> 4.2, which is a much more reasonable time frame (it moved to a
> >> different file which is why I missed it before).  However, the files
> >> in question don't even exist in the git branches from dspinellis's
> >> repository.  I had to find them on tuhs.org.  Am I doing something
> >> wrong, or are dspinellis's release branches not fully populated?
> >> Compare
> >> https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys
> >> to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys
> > 
> > 
> > I'm guessing the SCCS -> SVN -> Git process broke files that were renamed
> > or copied... I've not dug deeper though... This tells me that we need to
> > send dspinellis some corrections :)
> > 
> > Warner
> > ___
> > 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"
> > 
> 
> Replying to an arbitrary message..
> 
> Using svnweb it so EASY to see that the correct invocation is
> 
> svn co https://svn.freebsd.org/base/vendor/CSRG
> 
> as I just done..

Well once you know that it is obvious, I think is what
is happening is that people go to https://svn.freebsd.org/
and there is csrg listed there and the paths you get once
you follow that is wrong from then on.

Maybe obliterarate that top level miss leading link
would be the right thing to do?  Or put a roadmap
file at that level in place and then delete that csrg link.

Thank you for pointing us all to where the "real data"
is at.

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

Re: Checking out the CSRG repository?

[Rodney W. Grimes]

> > From: Alan Somers 
> > Date: Wed, 19 Jun 2019 14:12:21 -0600
> > Subject: Checking out the CSRG repository?
> > To: FreeBSD CURRENT 
> > 
> > Does anybody know how to check out a local copy of the CSRG
> > repository?  I can view it with ViewVC, but I would really like local
> > access.  It doesn't seem to be available on the usual repo.FreeBSD.org
> > or svn.FreeBSD.org.
> > 
> > $ svn checkout https://svn.FreeBSD.org/csrg csrg
> > svn: E170013: Unable to connect to a repository at URL
> > 'https://svn.freebsd.org/csrg'
> > svn: E175009: The XML response contains invalid XML
> > svn: E130003: Malformed XML: no element found at line 1
> > 
> > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg
> > svn: E170013: Unable to connect to a repository at URL
> > 'svn+ssh://asom...@repo.freebsd.org/csrg'
> > svn: E210005: No repository found in 
> > 'svn+ssh://asom...@repo.freebsd.org/csrg'
> > 
> > -Alan
> > ___
> > 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"
> 
> You can browse the history at http://svnweb.freebsd.org/csrg/

Since svnweb seems to be able to get to it there should be a near
0 cost of making this work with a straight svn checkout as
Alan originally asked for.  It is probably something missing,
or not configured so that the checkout "can just work".

> The repository is also available via FTP:
> 
>  ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz
>
> Hope this helps,

Thank you, mirroring locally to my repo server so I can infact
use svn directly on it.

>   Kirk McKusick

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

Re: error: yacc.h: No such file or directory

[Rodney W. Grimes]

> In message 
> , Ian Le
> pore writes:
> > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> > > > On Jun 18, 2019, at 06:59, Enji Cooper 
> > > > wrote:
> > > > 
> > > > 
> > > > > On Jun 18, 2019, at 06:53, Ian Lepore  wrote:
> > > > 
> > > > ...
> > > > 
> > > > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) 
> > > > > that
> > > > > were all somehow related to dependency processing in the
> > > > > build.  I
> > > > > don't know the details, just remember seeing some commits about
> > > > > that.
> > > > 
> > > > I remember that as well. This might have changed the dependency
> > > > order subtly, introducing a race.
> > > > 
> > > > The headers might not be built in all cases in time now.
> > > > 
> > > > Thanks,
> > > > -Enji
> > > > 
> > > > PS This is one of the reasons why I wasn???t quick to discount Peter
> > > > Jeremy???s reported build issue.
> > > 
> > > Correction: I meant Julian Stacey.
> >
> > Julian Stacey has 3 problems:
> >
> >  1. Missing opt_cam.h
> >  2. Missing yacc.h
> >  3. A years-long inability to report a problem without hurling personal
> > insults at the project and everyone associated with it.
> >
> > Because of #3, I don't much care about 1 and 2.
> 
> Bingo! My point exactly!

You can't understand the frustration of 25 years of
having system build breakage on a pretty regular basis
as a trigger point for anger?

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

Re: pkg: Cannot open /dev/null:No such file or directory

[Rodney W. Grimes]

> On 04/06/2019 06:32, O. Hartmann wrote:
> > As far as I know,, the package installation is performed via "chroot'ed"
> > environment and somehow /dev/null is out of a sudden not accessible anymore
> > while pkg tries to delegate some output to /dev/null.
> 
> Assuming you're chroot'd to /chroot, then:
> 
> mount -t devfs devfs /chroot/dev

Perhaps it is time to update the documentation in chroot(8) to
at least provide a pointer to the fact you now need to do either
the above, or somehow populate a /chroot/dev directory?

Can you even still statically create device nodes and have that
work, or is that now totally imposible with the full conversion
to devfs?

> should allow pkg(8) to work as usual.
> 
>   Cheers,
> 
>   Matthew

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

Re: UEFI boot broken in 13?

[Rodney W. Grimes]

> Hi
> 
> I'm using poudriere-image to create usb memstick images. The images are
> identical except OS version. They are tested on a laptop with 13-CURRENT
> installed as only OS, having UEFI boot and root on zfs.
> 
> 12-STABLE memstick boots fine with in UEFI mode.
Does it actually boot via a UEFI, or did UEFI fall back to CSM
and do a legacy boot?

What does "sysctl machdep.bootmethod" say?
machdep.bootmethod: BIOS

> 
> With 13-CURRENT memstick it boots the installed FreeBSD from the SSD
> instead (I choose USB UEFI OS in boot menu but it silently boots from
> the SSD instead). If I switch to legacy boot, the memstick image boots fine.
> 
> Any ideas?

The .iso building was updated to create hybrid boot images some
time back, these .iso images should be usable as boot .iso on a
cd/dvd and as memstick images.  I would encourage there use over
the memstick images, as there is a plan to remove them once we
get better experience with the hybrid .iso.

It is also possible that something has munged the boot in head.
Have you tried a downloaed ^/head snapshot from the last week,
as it could also be your build system that is not producing
a proper boot image?

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

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[Rodney W. Grimes]

> rai...@ultra-secure.de wrote:
> 
> > I have a 32bit FreeBSD 6 binary that I'll need for a bit until the 
> > department who is technically responsible for the service gets around 
> > redoing that service.
> 
> >From my understanding from reading the bug (though it's not entirely clear
> in this thread), this relates to removing the options from the generic (et 
> al.)
> kernels, not deleting the code itself.

That would make GENERIC less than GENERIC as you can not load
these changes as modules, nor would it be easy to make them modules.

> You'd therefore be able to just keep the options enabled in your own
> config..  , or is this just the first stage of full deprecation?

And that too, if you take stuff out of GENERIC it gets built less
often and that often leads to bit rot and that often leads to 
deprecation because it "must not be used it has rotted and look
no one has complained."  (Which, imho, is a rotton support model.)

> Cheers, Jamie
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD and Coreboot

[Rodney W. Grimes]

> On 5/28/19 12:46 AM, Warner Losh wrote:
> > 
> > 
> > On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn  > > wrote:
> > 
> > 
> > 
> > On 2019-05-27 19:14, Warner Losh wrote:
> > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn
> > mailto:nwhiteh...@freebsd.org>>
> > > wrote:
> > >
> > >>
> > >> On 2019-05-27 15:50, Eric McCorkle wrote:
> > >>> On 5/27/19 5:53 PM, Edward Napierala wrote:
> >  On Mon, 27 May 2019 at 16:14, Eric McCorkle
> > mailto:e...@metricspace.net>>
> > >> wrote:
> >  [..]
> > 
> > > My plan is roughly this:
> > >
> > > * Refurbish the GRUB port, get it working again in QEMU
> > (possibly on
> > >> one
> > > of my machines), also possibly push a patch to GRUB to use the
> > keybufs
> > > mechanism to pass in GELI keys.
> > >
> > > * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU
> > >
> > > * Possibly create a coreboot port (uncertain how this would
> > work, since
> > > Coreboot has its own extensive config menu)
> > >
> > > * Hold my breath and test it out on real hardware (I have a
> > Librem 13
> > >> r1
> > > for this purpose)
> > >
> > > * Possibly try getting the FreeBSD kernel to work as a coreboot
> > >> payload.
> >  Out of curiosity - why the kernel and not loader(8)?
> > 
> > >>> If I understand coreboot correctly, loader would have to directly
> > >>> manipulate devices _without a BIOS_.? That is, it would have to
> > have an
> > >>> entire device detection/interface layer, which I don't believe
> > is the
> > >>> case today.
> > >>>
> > >>> At least in the EFI case, loader is talking through the system's EFI
> > >>> implementation, which takes care of all that for you.? BIOS
> > works in a
> > >>> similar way.? My sense is getting loader to the point where it
> > could be
> > >>> a coreboot (without Seabios/GRUB/Tianocore) would be quite an
> > >> undertaking.
> > >> On IBM PowerNV systems, which also don't provide interfaces to a
> > >> second-stage loader, we just abandoned loader(8). It's way too
> > much work.
> > >>
> > > How do you use tunables and loadable modules?
> > >
> > > Warner
> > >
> > 
> > The firmware on PowerNV has a way to write tunables to the device-tree,
> > which we rehydrate into something that looks like it came from loader.
> > 
> > We don't usefully support loadable modules at the moment. The firmware
> > can optionally load exactly one file from the boot filesystem and pass
> > it to the kernel (for Linux, the initrd). There are a couple of ways to
> > imagine exploiting this for kernel modules, but all of them are kind of
> > crummy.
> > 
> > 
> > Now that the loader supports a ram disk, we are almost to something
> > useful... but yea, almost and crummy often go hand in hand.
> 
> This is looking out ahead of my current roadmap, but if you were to do a
> kernel as the coreboot payload, there'd need to be some kind of trick to
> support ZFS-only systems.
> 
> ZFS requires modules, which are typically pre-loaded (and linked) by
> loader (or GRUB).  Coreboot has no disk or filesystem or even device
> access facilities, however.  It's just "pull an image out of flash, do
> the bare essential hardware initialization to get to a C runtime
> environment, then jump into the image".

ZFS does not "require" modules, you can statically compile both
opensolaris and zfs into your kernel.

> 
> One way around it might be to concatenate the modules and a kernel
> together with a kind of mezzanine level that does all the module
> linking, then jumps into the kernel.  I suppose you could also build
> that functionality into the kernel itself, or perhaps even coreboot.

It is called a statically linked kernel, no modules at all.

> I suspect there might be some license issues that kept us from being
> able to build these modules into the kernel in the first place, though,
> and that might affect the choice as well.

I do not know of a license issue for US, linux has one due to
incompatibility of a GPL kernel with a CDDL ZFS module, thankfully
we do not have that issue.


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

Re: FCP-101: obsolete driver removal planned for 2019-05-18

[Rodney W. Grimes]

> Eugene Grosbein wrote:
> > 11.05.2019 22:59, Julian H. Stacey wrote:
> > 
> > >> 11.05.2019 21:32, Julian H. Stacey wrote:
> > >>
> >  I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers
> >  as previous approved in FCP-101.
> >  The following drivers are slated for
> >  removal from FreeBSD-HEAD (to be FreeBSD-13):
> > 
> >  ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe
> > >>>
> > >>> OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of
> > >>> spare)  that will never be able to upgrade.
> > >>
> > >> Do those boxes have 10M-only or 100Mbps variants of ed(4)?
> > >> What kind of hardware do they have (CPU and memory-wise)?
> > > 
> > > Thanks for question.  I ran a quick check:
> > > cd /usr/src; 
> > > # Apply my patches:
> > > # customise `pwd` 
> > > # http://www.berklix.com/~jhs/bin/.csh/customise
> > > cd /sys/amd64/conf
> > > grep device [A-Z][A-Z][A-Z][A-Z].small | grep ed
> > > DUAL.small:device ed
> > > FILM.small:device ed
> > > KING.small:device ed
> > > LAPA.small:device ed
> > > LAPD.small:device ed
> > > LAPL.small:device ed
> > > LAPN.small:device ed
> > > LOFT.small:device ed
> > > MINI.small:device ed
> > > SCAN.small:device ed0 at isa? port 0x280 irq 15 iomem 0xd iosiz 
> > > 0x1
> > > SLIM.small:device ed
> > > SNOW.small:device ed0 at isa? port 0x280 irq 5 iomem 0xc8000
> > > WIND.small:device ed
> > 
> > I've asked not for configuration files but for description of hardware.
> > ed(4) supports many different models. Some of them do 10Mbps only
> > but some are 100M-capable including PCI-connected.
> > 
> > And it's interesting to know what is CPU and memory type/amount of boxes.
> 
> Info I had long pre saved, exported here:
>   http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/
> Many boxes run newer releases than logs show, but eg dmesg shows memory etc.

It would help if you could run this from the hosts directory above and
post the output here, I doubt anyone besides me well bother looking
any further than this email at this data, but they well if you post
this output:

find . -type f | grep /dmesg | xargs egrep 'CPU:|real memory|Ethernet'

That should give us machine name by file path, CPU type, memory and
what ethernet cards are in it.

I found one box, the second one I looked at,
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/logs/blak/dmesg0
that clearly has enough CPU and memory to run 13:
CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
real memory  = 536858624 (511 MB)
ed0:  at port 0x240-0x25f iomem 0xcc000-0xc irq 
5 pnpid EDI0119 on isa0
ed0: [ITHREAD]
ed0: WARNING: using obsoleted if_watchdog interface
ed0: Ethernet address: 00:00:b4:36:a5:04

> Re Gary's:
> > 2) what versions of FBSD is Julian now running on his hardware?
> > 3) does he ever plan to upgrade this hardware to >= FBSD 13?
> 
> Not many, if any of them; I should idealy find time to purge some,
> but I also have sundry newer PCs, & spare ed etc cards, so a pity to loose ed.
> 
> 
> More generaly It won't be just me with ed.  With 13 I can power up any time,
> (+ other pcmcia & PCI & ISA cards in boxes) there's probably many more 
> globaly.
> 
> But sys admins often don't have time to read developer lists like
> current@ & arch@.  So developer considering zapping things, will
> not be seen by users it will hit later.
> 
> First many will know is seeing in a RELNOTES "XYZ will be removed
> in release [0-9].[0-9]" No chance to answer an earlier "Are many
> still using XYZ, we're thinking of deleting it ?"

I believe all of the proposed cards have been announcing
they are gone in FreeBSD 13 starting at FreeBSD 12.

I am NOT clear if these gonein notices got backported to
11, if not they should be ASAP as getting notice out to
the 11.3 users is important too.

> If ed is the biggest legacy NIC, best be cautious ?

I agree to some extent, but have no hard use evedence.

> (BTW I also have 2 boxes running today's current, not just old Rels here.)
> 
> Cheers,
> Julian
> -- 
> Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent
>  http://stolenvotes.uk  Brexit ref. stole votes from 700,000 Brits in EU.
>  Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: FCP-101: obsolete driver removal planned for 2019-05-18

[Rodney W. Grimes]

> 12.05.2019 8:21, Warner Losh wrote:
> 
> > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet 
> > drivers
> > >> as previous approved in FCP-101.
> > >> The following drivers are slated for
> > >> removal from FreeBSD-HEAD (to be FreeBSD-13):
> > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe
> > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of
> > > spare)  that will never be able to upgrade.
> > Do those boxes have 10M-only or 100Mbps variants of ed(4)?
> > What kind of hardware do they have (CPU and memory-wise)?
> > 
> > There are no 100M ed variants. There are some PC Card variants that have 
> > 100M MII connections, but they are limited to about 12Mbps due to bus 
> > limits. Even the PCI ones didn't have 100M mii connections. 
> 
> There was RTL8029AS "NE2000-compatible" 100M 32 bit PCI 2.1 adapter.
> Not sure if ed(4) supports RTL8029AS.

That is what I was hunting for, but I can not seem to
locate a data sheet on that.  

I also thought there was a 100mb version of the DP83905,
but can not seem to locate any data thier either.

Given this lack of findable data I shall continue to support
the ed removal, unless Julian comes up with the needed criteria,
and with holding my own fact that I do have a pile of these
around, but they are not in use and are only retained for
testing and resurection of ancient things.

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

Re: FCP-101: obsolete driver removal planned for 2019-05-18

[Rodney W. Grimes]

> > I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers
> > as previous approved in FCP-101.
> > The following drivers are slated for
> > removal from FreeBSD-HEAD (to be FreeBSD-13):
> > 
> > ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe
> 
> OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of
> spare)  that will never be able to upgrade.

I thought ed was already saved from this process, as that is the NE2000
driver, probably the most cloned network device on the planet.


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

Re: New vm-image size is much smaller than previos

[Rodney W. Grimes]

> On Fri, May 03, 2019 at 07:39:00PM -0700, Rodney W. Grimes wrote:
> > > On Fri, May 3, 2019, 7:42 PM bob prohaska  wrote:
> > > 
> > > > On Fri, May 03, 2019 at 11:06:15AM -0700, Rodney W. Grimes wrote:
> > > > > -- Start of PGP signed section.
> > > > > > On Fri, May 03, 2019 at 10:12:58AM -0700, Enji Cooper wrote:
> > > > > > >
> > > > > > > > On May 3, 2019, at 9:57 AM, Alan Somers 
> > > > wrote:
> > > > > > > >
> > > > > > > > See r346959.  Before first boot, you should expand the image up 
> > > > > > > > to
> > > > > > > > whatever size you want.  growfs(8) will automatically expand the
> > > > file
> > > > > > > > system.
> > > > > > > > -Alan
> > > > > > > >
> > > > > > > > On Fri, May 3, 2019 at 10:32 AM David Boyd 
> > > > > > > > 
> > > > wrote:
> > > > > > > >>
> > > > > > > >> The vm-image for 13.0-CURRENT
> > > > > > > >>
> > > > > > > >> FreeBSD-13.0-CURRENT-amd64-20190503-r347033.vmdk
> > > > > > > >>
> > > > > > > >> is only 4.0 GB in size.  Previous images were about 31.0 GB.
> > > > > > > >>
> > > > > > > >> This smaller image doesn't leave much room to add packages and
> > > > other
> > > > > > > >> customizations.
> > > > > > >
> > > > > > > This probably deserves a release note.
> > > > > >
> > > > > > It will certainly be mentioned in the 11.3 release notes.
> > > > >
> > > > > And those running head snapshots without reading commit messages
> > > > > are likely to have lots of foot shooting.
> > > > >
> > > > > > Glen
> > > > > --
> > > > > Rod Grimes
> > > > rgri...@freebsd.org
> > > >
> > > > At the risk of being branded a wishful thinker, a firstboot script that
> > > > asked the user for some configuration information would be a great help
> > > > to both new and experienced foot-shooters. I'm thinking of Raspberry Pi,
> > > > but perhaps it applies to non-embedded platforms also.
> > > >
> > > 
> > > That's not a bad idea... we could press bsdinstall into service for that
> > > perhaps... we already expand the partition / filesystem to match the media
> > > size...
> > 
> > As asommers already pointed out a) we already do the for real media
> > like on the rasberry pi's, etc all in that on first boot they do a
> > growfs to fill the real media up with the file system.
> > 
> 
> I misunderstood the significance of "vm-image", thinking it was
> the same as a bootable microSD image. Apologies for the blunder.

It could be better documented, I have no doubts about that.

> My thoughts are about physical media. In that situation the default 
> growfs on firstboot is a real handicap. It makes difficult any local 
> customization of the microSD card, in particular adding a swap partition. 
> A Pi2 is sort of usable without swap, a Pi3 is badly hampered with no swap. 
> 
> Having the existence of /firstboot trigger a configuration script 
> that sets up swap, storage, accounts and network would be a great aid
> to new users (and old users with imperfect memories). 

That is a very good idea.  As well as documenting things like the
/firstboot and growfs behavior of the physical media images.  One
can also modify them pre-boot (adding a swap before boot for example.)
and do much of what you discuss above *iff* you know to do it,
which again is a documentation issue.

> A man page for firstboot would be useful in any case. "What's that empty
> file supposed to do?" is a very natural question. Unfortunately, by the
> time the question is discovered it's too late to ask, and the user has
> to start over. There are references to firstboot in man rc, but that's
> a very hard way to answer a relatively simple question. Working around
> /firstboot requires a serial console and considerable patience, at least
> on a physical Raspberry Pi 2 or 3. 

Do we even have install note(s) pages for these things, or a wiki page
that documents it, or ?Working around /firstboot does not require
a serial console, if you know about it ahead of time, you can even
mount the sd image up on another system, and remove firstboot if you
want, or create a swap partition at the end of the device, make the
boot partition use up the rest and then iirc growfs on firstboot does
what you want. (Untested at this time, but that should just work.)

> Thanks for reading,  
Thanks for writting, some very good valid input!

> bob prohaska

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

Re: New vm-image size is much smaller than previos

[Rodney W. Grimes]

> On Fri, May 3, 2019, 7:42 PM bob prohaska  wrote:
> 
> > On Fri, May 03, 2019 at 11:06:15AM -0700, Rodney W. Grimes wrote:
> > > -- Start of PGP signed section.
> > > > On Fri, May 03, 2019 at 10:12:58AM -0700, Enji Cooper wrote:
> > > > >
> > > > > > On May 3, 2019, at 9:57 AM, Alan Somers 
> > wrote:
> > > > > >
> > > > > > See r346959.  Before first boot, you should expand the image up to
> > > > > > whatever size you want.  growfs(8) will automatically expand the
> > file
> > > > > > system.
> > > > > > -Alan
> > > > > >
> > > > > > On Fri, May 3, 2019 at 10:32 AM David Boyd 
> > wrote:
> > > > > >>
> > > > > >> The vm-image for 13.0-CURRENT
> > > > > >>
> > > > > >> FreeBSD-13.0-CURRENT-amd64-20190503-r347033.vmdk
> > > > > >>
> > > > > >> is only 4.0 GB in size.  Previous images were about 31.0 GB.
> > > > > >>
> > > > > >> This smaller image doesn't leave much room to add packages and
> > other
> > > > > >> customizations.
> > > > >
> > > > > This probably deserves a release note.
> > > >
> > > > It will certainly be mentioned in the 11.3 release notes.
> > >
> > > And those running head snapshots without reading commit messages
> > > are likely to have lots of foot shooting.
> > >
> > > > Glen
> > > --
> > > Rod Grimes
> > rgri...@freebsd.org
> >
> > At the risk of being branded a wishful thinker, a firstboot script that
> > asked the user for some configuration information would be a great help
> > to both new and experienced foot-shooters. I'm thinking of Raspberry Pi,
> > but perhaps it applies to non-embedded platforms also.
> >
> 
> That's not a bad idea... we could press bsdinstall into service for that
> perhaps... we already expand the partition / filesystem to match the media
> size...

As asommers already pointed out a) we already do the for real media
like on the rasberry pi's, etc all in that on first boot they do a
growfs to fill the real media up with the file system.

That does not work for a VM, as it is the host that has to increase
the size of the file so that the growfs (which IS already in these
images) can do its jobs.

What we should do is document the FreeBSD VM images are shipped
very small, but have this autogrow capability, and that a user
wanting say a 40G VM should simply expand the file to the proper
larger size via truncate -s 40G filename before starting the guest,
the guest well automagically do the right thing via growfs on
first boot.

> > The original FreeBSD install program (the one by Jordan Hubbard) did a
"original" would be mine, the second gen would by jkh,

> > very serviceable job. Could it (the user interface) be resurrected?
> >
> 
> Unlikely. It's too far bit rotted these days. It was extremely tailored to
> the i386 env, and a lot has changed since we retired it.
> 
> This is an interesting idea. It seems like it wouldn't be too hard to
> prototype.

It already is done, just needs a documentation cleanup.

> Warner
> 
> Thanks for reading,
> >
> > bob prohaska
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New vm-image size is much smaller than previos

[Rodney W. Grimes]

-- Start of PGP signed section.
> On Fri, May 03, 2019 at 10:12:58AM -0700, Enji Cooper wrote:
> > 
> > > On May 3, 2019, at 9:57 AM, Alan Somers  wrote:
> > > 
> > > See r346959.  Before first boot, you should expand the image up to
> > > whatever size you want.  growfs(8) will automatically expand the file
> > > system.
> > > -Alan
> > > 
> > > On Fri, May 3, 2019 at 10:32 AM David Boyd  wrote:
> > >> 
> > >> The vm-image for 13.0-CURRENT
> > >> 
> > >> FreeBSD-13.0-CURRENT-amd64-20190503-r347033.vmdk
> > >> 
> > >> is only 4.0 GB in size.  Previous images were about 31.0 GB.
> > >> 
> > >> This smaller image doesn't leave much room to add packages and other
> > >> customizations.
> > 
> > This probably deserves a release note.
> 
> It will certainly be mentioned in the 11.3 release notes.

And those running head snapshots without reading commit messages
are likely to have lots of foot shooting.

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

Re: Rotating (efi) framebuffer

[Rodney W. Grimes]

> Hi
> 
> I have a Lenovo Ideapad where the screen is rotated 90 degrees and I
> can't rotate it to landscape mode until I'm in X. How many of you are in
> the same situation and would like a fix? Seeing how development is going
> with small (tiny) computers it will probably be more and more common
> with ultra portables having a "phone screen" which most likely is in
> portrait mode by default. This also applies to embedded and home brew /
> prototype devices.
> 
> It would certainly be nice if we could have a boot time parameter that
> could rotate the framebuffer (just as a data point, I'm pretty sure
> Linux can do this). How many would be interested in this? Is there
> anyone working on this atm? Not sure I will have the time to develop
> this all of my own but thought I'd check the interest at least. Perhaps
> a GSoC project?

Yes please.

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

Re: CFT: FreeBSD Package Base

[Rodney W. Grimes]

> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > >
> > > Correct, this is ZFS only. And it's something we're using specific to
> > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of
> > our CFT.
> >
> > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
> > calling this FreeBSD pkg base when it is not was wrong,
> > and miss leading.
> >
> 
> Sorry, I disagree.
Which is fine.

> This pkg base is independent of the ZFS tool we're using
> to wrangle boot-environments. Hence why it wasn't mentioned in the CFT.
> These base packages work the same as existing in-tree pkg base on UFS, no
> difference. If anything are probably safer due to being able to update all
> of userland in single extract operation, so you don't have out of order
> extraction of libc or some such.

You missed the major string change and focused on the edge,
No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS?

That was the major point of my statement, your miss leading the user
community, you yourself said this would never be imported into FreeBSD
base, so I see no reason that it should be called "FreeBSD package Base",
as it is not, that is a different project.

> > > For UFS, there will need to be additional care taken when doing updates.
> > >
> > > --
> > > Kris Moore
> > > Vice President of Engineering
> > > iXsystems, Inc
> > > Ph: (408) 943-4100
> > > Ph: (408) 943-4101
> > > The Groundbreaking TrueNAS M-Series -
> > > Enterprise Storage & Servers Driven By Open Source
> > >
> > > -Original Message-
> > > From: Goran Meki? 
> > > Sent: Monday, April 29, 2019 9:43 AM
> > > To: Kris Moore 
> > > Cc: Emmanuel Vadot ; FreeBSD Stable <
> > freebsd-sta...@freebsd.org>; FreeBSD Current ;
> > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org;
> > freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org
> > > Subject: Re: CFT: FreeBSD Package Base
> > >
> > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote:
> > > > We've written our own tool "sysutils/sysup" in GO which handles this.
> > > > It performs updates using Boot-Environments to ensure that
> > > > kernel/world are updated at same time.
> > >
> > > If I'm right, UFS doesn't support boot environments, so how would it
> > work for UFS based installs?
> > >
> > > I personally feel GO is a bit ackward choice of language for something
> > that practically should be part of base. At least I would expect OS
> > update/upgrade not to require any external package.
> > >
> > > Regards,
> > > meka
> > >
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> > >
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

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

Re: CFT: FreeBSD Package Base

[Rodney W. Grimes]

> 
> Correct, this is ZFS only. And it's something we're using specific to FreeNAS 
> / TrueOS, which is why I didn't originally mention it as apart of our CFT. 

Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
calling this FreeBSD pkg base when it is not was wrong,
and miss leading.

> For UFS, there will need to be additional care taken when doing updates. 
> 
> -- 
> Kris Moore
> Vice President of Engineering
> iXsystems, Inc
> Ph: (408) 943-4100
> Ph: (408) 943-4101
> The Groundbreaking TrueNAS M-Series -
> Enterprise Storage & Servers Driven By Open Source
> 
> -Original Message-
> From: Goran Meki?  
> Sent: Monday, April 29, 2019 9:43 AM
> To: Kris Moore 
> Cc: Emmanuel Vadot ; FreeBSD Stable 
> ; FreeBSD Current ; 
> freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; 
> freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org
> Subject: Re: CFT: FreeBSD Package Base
> 
> On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote:
> > We've written our own tool "sysutils/sysup" in GO which handles this. 
> > It performs updates using Boot-Environments to ensure that 
> > kernel/world are updated at same time.
> 
> If I'm right, UFS doesn't support boot environments, so how would it work for 
> UFS based installs?
> 
> I personally feel GO is a bit ackward choice of language for something that 
> practically should be part of base. At least I would expect OS update/upgrade 
> not to require any external package.
> 
> Regards,
> meka
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

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

Re: SVN r346700 breaks build

[Rodney W. Grimes]

> On Thu, Apr 25, 2019 at 3:33 PM Michael Butler
>  wrote:
> >
> > Seems that the lib32 piece (on amd64) is now broken; as follows:
> >
> 
> *sigh*
> 
> Strike two of three for me today, it seems. Should be fixed in
> r346705... sorry about that, thanks for the report!

Perfection:  A finely polished collection of mistakes,
your just adding to your collection!!!

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

Re: r346025: ZFS filesystems do not mount anymore

[Rodney W. Grimes]

> In message <19ca3a5d-4e41-4f17-a788-b9545f104...@gmail.com>, "Enji 
> Cooper (yane
> urabeya)" writes:
> > 
> > > On Apr 9, 2019, at 21:51, Enji Cooper  wrote:
> >
> > ???
> >
> > > CCing crees@, the author of r346017, for context. I will file a PR soon 
> > > if 
> > one hasn???t already been filed.
> >
> > I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237172 to tra
> > ck the issue.
> 
> This should probably be reverted until it is tested and resolved.

Has been reverted, we may want to clarify the policy when a
none source committer has approval for a commit to src that
turns out to need reverted they need to revert they do not
need an approval to revert, or that this approval is implicit?

crees delayed the revert of this while waiting for that approval.

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

Re: lsof hangs with latest 13.0-CURRENT snapshot

[Rodney W. Grimes]

> On Tue, 2019-04-09 at 12:20 -0700, Rodney W. Grimes wrote:
> > > After upgrading from FreeBSD-13.0-CURRENT-amd64-20190328-r345620 to
> > > FreeBSD-13.0-CURRENT-amd64-20190404-r345863, lsof (4.92 from
> > > packages)
> > > hangs.
> > > 
> > > This is true for bare metal installs and virtual machine installs.
> > > 
> > > How to recreate:
> > >   
> > >   Install FreeBSD-13.0-CURRENT-amd64-20190404-r345863 snapshot.
> > > 
> > >   as root: lsof /sbin/init
> > > 
> > > By running command with -b option, this error is displayed:
> > > 
> > > lsof: status error on /sbin/init: Resource temporarily unavailable
> > > 
> > > The return code is 1.
> > > 
> > > This probably requires adjustment to lsof, but only the FreeBSD
> > > snapshot changed, so I'll start here.
> > 
> > Where did you get your lsof binary from?
> > 
> > lsof has internal knowledge of kernel data structures 
> > and must be compiled to match the running system.
> > 
> > 
> > > Thanks.
> > > David Boyd.
> 
> 
> lsof was installed via pkg install from pkg.freebsd.org.

That does not work well on ^head or for that mater any snapshot,
as I said, lsof has internal knowledge of kernel data structures
and must match the running kernel for it to work.

It should be complaining about a version mismatch, but perhaps
it was compiled recently enough that these are matching, but
there is still a datastruct that changed.

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

Re: lsof hangs with latest 13.0-CURRENT snapshot

[Rodney W. Grimes]

> After upgrading from FreeBSD-13.0-CURRENT-amd64-20190328-r345620 to
> FreeBSD-13.0-CURRENT-amd64-20190404-r345863, lsof (4.92 from packages)
> hangs.
> 
> This is true for bare metal installs and virtual machine installs.
> 
> How to recreate:
>   
>   Install FreeBSD-13.0-CURRENT-amd64-20190404-r345863 snapshot.
> 
>   as root: lsof /sbin/init
> 
> By running command with -b option, this error is displayed:
> 
> lsof: status error on /sbin/init: Resource temporarily unavailable
> 
> The return code is 1.
> 
> This probably requires adjustment to lsof, but only the FreeBSD
> snapshot changed, so I'll start here.

Where did you get your lsof binary from?

lsof has internal knowledge of kernel data structures 
and must be compiled to match the running system.


> Thanks.
> David Boyd.
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS no longer mounted in alphanumerical order

[Rodney W. Grimes]

> On 12/03/2019 11:37, Trond Endrest?l wrote:
> > # Parallel mounting of ZFS filesystems leaves a chaotic listing of
> > # mounted filesystems when viewed by df(1).
> 
> df reports filesystems in the order they were mounted.
> If you unmount and remount a filesystem or mount a new filesystem, you can see
> it for yourself.  Also, if you ever used fstab then you could see that too.
> Just because previously the output happened to look like it was sorted does 
> not
> mean that it was or that there was such an intention.

Valid point.  So how do I control the order of mounts of zfs?

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

Re: ZFS no longer mounted in alphanumerical order

[Rodney W. Grimes]

> On 12/03/2019 02:12, Rodney W. Grimes wrote:
> >> On 11/03/2019 23:03, Freddie Cash wrote:
> >>> Wouldn't it make more sense to teach df, du, "zfs list", and other things
> >>> that list the mounted filesystems to use sorted output?
> >>
> >> | sort [desired options]
> > 
> > Except that df and zfs list have a header that you have to deal with,
> > which is not so easy to get sort to do the right things with out
> > some hoop jumping.
> 
> Like "| tail +2" ?
> Or if it's just for visual inspection (as seems to be the case for the 
> original
> poster) just mentally filter out that line.

That just deletes the header.  Try to write a one liner that gives you
the exact same prior behavior.  It is not really fair to make a change
to the system that changes behavior and just tell all the users to
adapt to the change, it makes FreeBSD "user unfriendly."  If I have
to adapt to much or too often I see alternatives.

> >> P.S.
> >> zfs list already supports sorting by a specific property.
> > 
> > Perhaps make zfs list -s mountpoint a default?
> 
> Why?

P O L A   People have become use to this being sorted, now it is not.

> Andriy Gapon
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS no longer mounted in alphanumerical order

[Rodney W. Grimes]

> On 11/03/2019 23:03, Freddie Cash wrote:
> > Wouldn't it make more sense to teach df, du, "zfs list", and other things
> > that list the mounted filesystems to use sorted output?
> 
> | sort [desired options]

Except that df and zfs list have a header that you have to deal with,
which is not so easy to get sort to do the right things with out
some hoop jumping.


> P.S.
> zfs list already supports sorting by a specific property.

Perhaps make zfs list -s mountpoint a default?

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

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Rodney W. Grimes]

> On Thu, Feb 28, 2019 at 12:46 PM John Baldwin  wrote:
> 
> > On 2/28/19 11:14 AM, Cy Schubert wrote:
> > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer 
> > wrote:
> > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl
> > >>  wrote:
> > >>> This is interesting as well.  Does this mean that amd64 is now
> > >>> the only tier 1 platform and all other architectures are after
> > >>> thoughts?
> > >>
> > >> This has been the de facto truth for years.  i386 is mostly only
> > >> supported by virtue of sharing code with amd64.  There are efforts to
> > >> promote arm64 to Tier 1, but it isn't there yet.  Power8+ might be
> > >> another good alternative Tier 1 candidate eventually.  None have
> > >> anything like the developer popularity that amd64 enjoys.
> > >>
> > >> Conrad
> > >> ___
> > >> 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"
> > >
> > > We deprecated and removed support for 386 and 486 processors. We should
> > consider removing support for low end Pentium as well. I'm specifically
> > thinking of removing the workarounds like F00F. Are there any processors
> > that are still vulnerable to this?
> >
> > We have only removed support for 386 since it didn't support cmpxchg.  We
> > still
> > nominally support 486s.  I don't know how well FreeBSD 13 would run on a
> > 486, but
> > in theory the code is still there and the binaries shouldn't die with
> > illegal
> > instruction faults.
> >
> 
> The biggest barrier to running on a real 486 is that it's hard for FreeBSD
> to fit into 32MB that was the maximum config you could have. You can barely
> boot it w/o tuning, though it will still fit a few jobs if you are looking
> at something super low-end with a lot of effort.

Effort that has been completed in several places, wifi-build for one,
where I did boot a 12.0 image of 8MB in size running in 32MB iirc on
a D-Link DIR-855? router.

> There are a few later CPUs built on basically a 486 whose chipsets could
> support up to 128MB or 256MB which is enough to run FreeBSD still.

Amd Geode would be in that group?

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

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Rodney W. Grimes]

> On 2/28/19 11:14 AM, Cy Schubert wrote:
> > On February 28, 2019 11:06:46 AM PST, Conrad Meyer  wrote:
> >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl
> >>  wrote:
> >>> This is interesting as well.  Does this mean that amd64 is now
> >>> the only tier 1 platform and all other architectures are after
> >>> thoughts?
> >>
> >> This has been the de facto truth for years.  i386 is mostly only
> >> supported by virtue of sharing code with amd64.  There are efforts to
> >> promote arm64 to Tier 1, but it isn't there yet.  Power8+ might be
> >> another good alternative Tier 1 candidate eventually.  None have
> >> anything like the developer popularity that amd64 enjoys.
> >>
> >> Conrad
> >> ___
> >> 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"
> > 
> > We deprecated and removed support for 386 and 486 processors. We should 
> > consider removing support for low end Pentium as well. I'm specifically 
> > thinking of removing the workarounds like F00F. Are there any processors 
> > that are still vulnerable to this?
> 
> We have only removed support for 386 since it didn't support cmpxchg.  We 
> still
> nominally support 486s.  I don't know how well FreeBSD 13 would run on a 486, 
> but
> in theory the code is still there and the binaries shouldn't die with illegal
> instruction faults.

I know I can still boot FreeBSD 12, diskless no less, on a 
Transmeta Crusoe TM-5800.  I'll go digging for a 486 and
confirm or deny if we can boot ^head on it.

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

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Rodney W. Grimes]

> On 2/28/19 10:32 AM, Steve Kargl wrote:
( ... trimmed ... )

> > The BIOS does have a enable/disable button for virtualization.
> > During the great drm-legacy-kmod event of the last month, enabling
> > virtualization locks up a i386 FreeBSD kernel very quickly.
> > Perhaps, virtualization works under amd64.  Guess I'll burn
> > an image onto a memstick an d give it a whirl.
> 
> bhyve is definitely amd64-only.  We don't have any support for bhyve on i386
> kernels and likely never will.  However, if an i386 chroot works, it's 
> probably
> faster than an i386 VM anyway.

bhyve/vmm.ko does not come into play here at all, the real question
is why does our i386 kernel "lock up" simply because a newer CPU
feature appears, it should not do that, as far as I am aware turing
VT-x on does not or should not in anyway change the "i386" behavior
or a machine.   What am I missing?

> >> However, an amd64 kernel is going to be a more stable, better
> >> supported kernel for running i386 binaries than an i386 kernel
> >> at this point, and that will become even more true in the future.
> > 
> > This is interesting as well.  Does this mean that amd64 is now 
> > the only tier 1 platform and all other architectures are after
> > thoughts?
> 
> i386 is still marked as tier 1.  However, it's becoming increasingly harder to
> maintain that level of support for the kernel.  core@ is currently exploring
> some ideas about how to make our tiering for i386 more closely reflect what we
> as a project are able to provide.  Originally we were considering a proposal 
> to
> demote all of i386 to tier 2, but after some initial conversations we think a
> better model is to keep the i386 user ABI as tier 1 and only demote the i386
> kernel.  However, we still need to think about what that looks like and update
> our tiering language to reflect what that looks like.  I think the short 
> version
> is that we might no longer guarantee i386-specific fixes for kernel SAs, but
> there are probably additional wrinkles that will arise as that is fleshed out
> further.

Is core talking to the stake holders about this issue?  IMHO this topic
should be an open discussion some place with all parties involved, not
just core deciding what is or is not a tier 1 and/or how to fix our
tier 1 situation with i386 (which I do agree needs to change, but
to what I have not a solid idea.)

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

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Rodney W. Grimes]

> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > Supposely, the laptop only has 4 GB of memory.  Not sure how
> > it finds memory above 4 GB.
> >
> 
> Some older chipsets had a 'hole' in memory that they mapped the PCI bus
> into and then remapped RAM in that range up above the 4GB boundary. That's
> how it can find memory above 4GB when you have only 4GB of RAM. I hit it
> with the PC Card stuff I did back in the day since it broke certain
> heuristics I had in the code that turned out to be unwise for many reasons
> (not just this one). I don't recall all the details, since it's been so
> long ago.
> 
> So I think kib@ is right when he highlights
> > +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages)
> 
> as the memory, since this is indeed above the 4GB limit.  It's about 128k
> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly
> round number. Also one that's easy to implement in hardware. So it
> certainly "smells" the same...
> 
> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for

It sounds like that this sysctl didnt show up for him,
he said he set it, but it does not show up in sysctl when
he is booted, that seems very odd, unless it didnt get
added until a later commit.

> at least diagnostic purposes. This memory wasn't used before and if it's
> used now by the drm drivers, and those aren't PAE safe (meaning they cope
> with allocations beyond 4GB), then that's quite useful to know. Or maybe
> it's a different driver hating things and stomping on video memory due to
> wrap around.

I'll see if I can spend a few moments this afternoon duplicating this,
I have 2 thinkpads that are 64 bit, with >4G of ram, that I can install
i386 on and test.

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

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

[Rodney W. Grimes]

> On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote:
> > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote:
> > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote:
> > > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote:
> > > > > r343567 merges the PAE vs non-PAE pmap headers for i386
> > > > > freebsd.  After bisection and dealing with the drm-legacy-kmod
> > > > > fallout, I bisected /usr/src to r343567.  Building world and
> > > > > a GENERIC kernel and the minimum set of ports to start Xorg
> > > > > on my Dell Latitude D530 laptop, results in a black screen
> > > > > of death and a locked up laptop (no keyboard, mouse, or video).
> > > > > 
> > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads
> > > > > and functions) and r353467 (Xorg black screen of death) shows
> > > > > that /boot/modules/i915kms.ko loads correctly as the log
> > > > > files are identical.
> > > > > 
> > > > > Comparing dmesg for r343566 to r343567 shows the following
> > > > >  
> > > > > --- dmesg.343566  2019-02-20 08:13:07.727202000 -0800
> > > > > +++ dmesg.343567  2019-02-21 19:02:24.469562000 -0800
> > > > > @@ -3,11 +3,11 @@
> > > > >  Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 
> > > > > 1994
> > > > >   The Regents of the University of California. All rights 
> > > > > reserved.
> > > > >  FreeBSD is a registered trademark of The FreeBSD Foundation.
> > > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386
> > > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386
> > > > >  FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based 
> > > > > on LLVM 7.0.1)
> > > > >  WARNING: WITNESS option enabled, expect reduced performance.
> > > > >  VT(vga): resolution 640x480
> > > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 
> > > > > 686-class CPU)
> > > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 
> > > > > 686-class CPU)
> > > > >Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
> > > > >
> > > > > Features=0xbfebfbff
> > > > >
> > > > > Features2=0xe3bd
> > > > > @@ -16,7 +16,7 @@
> > > > >VT-x: (disabled in BIOS) HLT,PAUSE
> > > > >TSC: P-state invariant, performance statistics
> > > > >  real memory  = 4294967296 (4096 MB)
> > > > > -avail memory = 3639914496 (3471 MB)
> > > > > +avail memory = 4154175488 (3961 MB)
> > > > > 
> > > > > Somehow the r343567 kernel found an addition 490 MB of memory,
> > > > > which leads me to believe the after loading i915kms.ko there
> > > > > is some serious memory stomping issues.
> > > > > 
> > > > > I willing to do whatever is necessary to fix this issue (shorter
> > > > > of mailing the laptop to someone).  Is it possible to revert
> > > > > r343567 and move forward? 
> > > > > 
> > > > 
> > > > More info from sysctl.  With the "good" r343566, I see
> > > > 
> > > > vm.kmem_map_free: 1187033088
> > > > vm.kmem_map_size: 27234304
> > > > vm.kmem_size_scale: 3
> > > > vm.kmem_size_max: 1715470336
> > > > vm.kmem_size_min: 12582912
> > > > vm.kmem_zmax: 65536
> > > > vm.kmem_size: 1214267392
> > > > hw.physmem: 3714269184
> > > > hw.usermem: 3650867200
> > > > hw.realmem: 4294963200
> > > > 
> > > > With the problematic r343567, I see
> > > > 
> > > > vm.kmem_map_free: 1683152896
> > > > vm.kmem_map_size: 28123136
> > > > vm.kmem_size_scale: 1
> > > > vm.kmem_size_max: 1711276032
> > > > vm.kmem_size_min: 12582912
> > > > vm.kmem_zmax: 65536
> > > > vm.kmem_size: 1711276032
> > > > hw.physmem: 4252360704
> > > > hw.usermem: 4146999296
> > > > hw.realmem: 4294963200
> > > > 
> > > > Ideas?
> > > > 
> > > 
> > > Here's the 'diff -uw' between a verbose dmesg boot of r343566
> > > and dmesg boot of r343567.  The memory size looks rather puzzling.
> > > Can the people responsible for the i386 pmap.h merging take a
> > > look?
> > What is puzzling ?
> 
> Supposely, the laptop only has 4 GB of memory.  Not sure how
> it finds memory above 4 GB.

It probably has what is called UMA and the graphics
framebuffer is mapped into memory below 4G and the
original memory is mapped above 4G, giving you this
little bit of >4G memory that is trigger PAE now.

This may not be desired, is there any performance
advantage to not turning on PAE in this situation?

> I build 343566 and minimum ports needed for Xorg including
> drm-legacy-kmod.  I can load xorg, and in fact, I am typing
> this email now on the laptop with vi in xterm.
> 
> I build 343567 and minimum ports needed for Xorg including
> drm-legacy-kmod.  I try to start Xorg.  Black screen of death.
> No mouse.  No keyboard.  Just a hard reset.

That would be a regression caused by PAE coming into play.

> I build 343567 and minimum ports needed for Xorg including
> drm-legacy-kmod.  I load i915kms.ko, do not start Xorg.  There
> are surprising strikes/blotches of color on screen.  Building any
> port with the system's cc results in occasion segfaults. 
> 
> > 

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> > On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko  wrote:
> > 
> > Michael Gmelin (gre...@freebsd.org) wrote:
> >> 
> >> 
> >>>> On 18. Feb 2019, at 23:54, Mark Linimon  wrote:
> >>>> 
> >>>> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
> >>>> I think one serious problem here is the summary dismissal of things
> >>>> simply on the "5 year old" basis.
> >>> 
> >>> IIUC the graphics changes are being forced upon FreeBSD by external
> >>> projects (mainly Linux-based) that are making huge architectural changes
> >>> that rely more and more on features from newer hardware.

The port was created long ago to get newer graphcis, that port even
had very nice instructions on how to bypass the inbase kmod of the
same name that accsesed the same hardware.

> >>> 
> >>> If our upstreams aren't willing to do the work to keep from violating
> >>> POLA on older hardware, IMHO it's an awful lot to ask of our already
> >>> thinly stretched graphics volunteers to provide it in their stead.
> >>> 
> >>> w/rt graphics, we are at far more danger of being left further and
> >>> further behind on modern hardware than we are at risk of losing users
> >>> on older hardware here.

We had the kmod in ports that supported this, no one was being
left behind in any respect of the word.  We are certainly driving
users away by our operation model, I here it often from several
different places I interact with users, linux conferences, oscon,
local user group meetings, other BSD users that have moved to
another platform, our own #freebsd irc channel.

> >>> 
> >>> Again all IMHO.
> >>> 
> >>> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> >>> say around here)
> >> 
> >> I?m very happy (and grateful) that 2018 was the first year in over a 
> >> decade I was able to run FreeBSD on a state of the art laptop with all the 
> >> features that are essential to me working - which included decent touchpad 
> >> support provided through evdev+libinput.
> > 
> > I want to second this. evdev + libinput was the only option out of
> > several that provided smooth multitouch experience for Xorg on my 2018
> > laptop I really appreciate all the efforts to make it work both on
> > kernel and ports side.
> > 
> > -- 
> > gonzo
> 
> If I may throw my 0,02?, getting a newer graphics stack also gives me (and 
> others) the option to combine many machine functions into one; for example, I 
> can use a single machine as all the usual things like: router+firewall(ipfw), 
> fileserver which can satuate 1Gbps LAN and WAN with NFSv4 and/or SMB, and 
> many other things (those aren?t _that_ new)
> What is new is that we can now use it as a media center for efficient 
> hardware accelerated playback of h264 and h265, as well as on-the-fly 
> transcoding to stream to mobile devices via libva or vdpau, qsv or similar.

The new driver exists and existsted before any touching of in base DRM2
happened.  Many seem to be ignoring that fact, you did not get any new
software, you simply moved the bits around a little.

And the root problem, not being able to easily over ride an inbase
module with a module for ports is only slighly better addressed
in that we can now blacklist modules (that is a net gain, but from
looking at things that is the only gain here.)

Let me repeat, there is no new supported hardware or software that
did not exist before the removal of in base DRM2, and it is only
very slightly easier to use the new drm2 kmod for new hardware,
and slighly more difficult to use the legacy drm2 kmod moved
to ports.

This is not some leap forward for anyone, and defanitly a slight
step backwards for some, many, who knows, I put it in the 1000's,
of users.

We have never been very good at having kmod's
work well over a long period, we break them left and right, and
we got away with it in virtualbox, but you start doing that to
the graphics driver and you are going to driver users away as
they simply can not have there desktop go non-functional for
even hours, let alone days.

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

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > > > On 2/18/19, Vladimir Kondratyev  wrote:
> > > > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > > > >>> Anyone have insight into what evdev is?
> > > > > >> evdev.ko is a small in-kernel library that makes all your input
> > events
> > > > > >> like keyboard presses libinput-compatible.
> > > > > >
> > > > > > And libinput was created by the Freedesktop Wayland team to create
> > > > > > pressure on OS people to make their systems Wayland-compatible.
> > > > > >
> > > > > >>> I do not need nor what these modules loaded.
> > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config
> > should
> > > > > >> disable most of evdev.ko dependencies
> > > > > >
> > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as
> > well
> > > > > > as libinput not be part of the standard packages?
> > > > > >
> > > > > > The Freedesktop Wayland team consists of people with the Kay
> > Sievers
> > > > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > > > not care about the bugs they introduce, forcing others to clean up
> > the
> > > > > > mess they create.
> > > > > >
> > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland
> > fad...
> > > > >
> > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve
> > > > > input device handling in X and Wayland.  Not having it means that a
> > lot
> > > > > of input devices stop working, or work much worse.
> > > > >
> > > > > We in the FreeBSD Graphics Team are working very hard to improve the
> > > > > FreeBSD Desktop experience, since it is an avenue to recruit new
> > users,
> > > > > and make current users use FreeBSD more.
> > > >
> > > > Sadly your execution on that seems to be missing the mark,
> > > > telling people they have to go get a port now to get drm working
> > > > because it could not be maintained in base, and then telling them,
> > > > oh, you need this new code in base so that it is so much easier
> > > > to use graphical stuff this way.
> > > >
> > > > These seem to be conflicting stories.
> > > >
> > > You are missing the point, one does not evolve as fast as the other,
> > meaning
> > > one can be maintained within usual freebsd lifecycle, the other cannot
> > or it
> > > becomes very painful.
> >
> > So to ditch our 5 years support model, kick the code out of the tree and
> > make the users suffer?  The support model is suppose to be under review,
> > and IMHO, if kicking functional code out of the base system is to make
> > it possible to meet some support model we should defanitly take a very
> > close look at that issue.
> >
> > The code has simply gone from being in base to a few git repositories
> > which are probably going to rot every time a breaking ABI change occurs
> > and we wend up with un happy users, un happy developers and bugmisters
> > who have to close bogus bug reports.
> >
> > Have we really moved the state of the art forward by this action, simply
> > in the name of "we could not suppor that code?"
> >
> 
> I don't know. I think the fact that drm2 doesn't support anything newer
> than 5-year-old hardware is a pretty convincing evidence that the old way
> is broken and doesn't work.

But it DOES work, I am pretty sure we have 1000's of users on that 5 year
old hardware that are totally happy with the intree DRM2 that is in stable/12,
and some of whom have ventured into head/13 are having issues with the
"new" model (ie kmod broken by a base commit).  I know that there is wip
to get CI coverage for that, but wip is wip, and we need to start changing
the cart horse driver order we keep doing and get things right.  Port
up and working, with CI testing *before* we go remove kmod'ed code from
base would be a much more appropriate path.

I think one serious problem here

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > > On 2/18/19, Vladimir Kondratyev  wrote:
> > > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > > >>> Anyone have insight into what evdev is?
> > > >> evdev.ko is a small in-kernel library that makes all your input events
> > > >> like keyboard presses libinput-compatible.
> > > > 
> > > > And libinput was created by the Freedesktop Wayland team to create
> > > > pressure on OS people to make their systems Wayland-compatible.
> > > > 
> > > >>> I do not need nor what these modules loaded.
> > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > > >> disable most of evdev.ko dependencies
> > > > 
> > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > > as libinput not be part of the standard packages?
> > > > 
> > > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > > mentality, which made Linus Torvalds ban his contributions. They do
> > > > not care about the bugs they introduce, forcing others to clean up the
> > > > mess they create.
> > > > 
> > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> > > 
> > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> > > input device handling in X and Wayland.  Not having it means that a lot 
> > > of input devices stop working, or work much worse.
> > > 
> > > We in the FreeBSD Graphics Team are working very hard to improve the 
> > > FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> > > and make current users use FreeBSD more.
> > 
> > Sadly your execution on that seems to be missing the mark,
> > telling people they have to go get a port now to get drm working
> > because it could not be maintained in base, and then telling them,
> > oh, you need this new code in base so that it is so much easier
> > to use graphical stuff this way.
> > 
> > These seem to be conflicting stories.
> > 
> You are missing the point, one does not evolve as fast as the other, meaning
> one can be maintained within usual freebsd lifecycle, the other cannot or it
> becomes very painful.

So to ditch our 5 years support model, kick the code out of the tree and
make the users suffer?  The support model is suppose to be under review,
and IMHO, if kicking functional code out of the base system is to make
it possible to meet some support model we should defanitly take a very
close look at that issue.

The code has simply gone from being in base to a few git repositories
which are probably going to rot every time a breaking ABI change occurs
and we wend up with un happy users, un happy developers and bugmisters
who have to close bogus bug reports.

Have we really moved the state of the art forward by this action, simply
in the name of "we could not suppor that code?"

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

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > On 2/18/19, Vladimir Kondratyev  wrote:
> >> On 2019-02-17 21:03, Steve Kargl wrote:
> >>> Anyone have insight into what evdev is?
> >> evdev.ko is a small in-kernel library that makes all your input events
> >> like keyboard presses libinput-compatible.
> > 
> > And libinput was created by the Freedesktop Wayland team to create
> > pressure on OS people to make their systems Wayland-compatible.
> > 
> >>> I do not need nor what these modules loaded.
> >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> >> disable most of evdev.ko dependencies
> > 
> > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > as libinput not be part of the standard packages?
> > 
> > The Freedesktop Wayland team consists of people with the Kay Sievers
> > mentality, which made Linus Torvalds ban his contributions. They do
> > not care about the bugs they introduce, forcing others to clean up the
> > mess they create.
> > 
> > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> 
> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> input device handling in X and Wayland.  Not having it means that a lot 
> of input devices stop working, or work much worse.
> 
> We in the FreeBSD Graphics Team are working very hard to improve the 
> FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> and make current users use FreeBSD more.

Sadly your execution on that seems to be missing the mark,
telling people they have to go get a port now to get drm working
because it could not be maintained in base, and then telling them,
oh, you need this new code in base so that it is so much easier
to use graphical stuff this way.

These seem to be conflicting stories.

> 
> Evdev and libinput is used by both Wayland and xorg.  You are free to 
> use either one.

And sadly now must take action when no action was required before
when using neither.

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

Re: What is evdev and autoloading?

[Rodney W. Grimes]

> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
> > 
> > 
> > On 2019-Feb-17, at 10:03, Steve Kargl  
> > wrote:
> > 
> > Anyone have insight into what evdev is?  There appears to
> > be no manual page.  When I reboot a system with custom
> > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > wmt.ko.  I do not need nor what these modules loaded.
> > How does one prevent this autoloading?
> > 
> > Looking via the web lead to:
 ^^^
web lies

> > 
> > https://www.freebsd.org/cgi/man.cgi?query=evdev&apropos=0&sektion=4&manpath=FreeBSD+12.0-RELEASE&arch=default&format=html
> > So:
> > 
> > NAME
> >evdev - Generic Linux input driver
> > 
> > DESCRIPTION
> > 
> > evdev is an Xorg input driver for Linux's generic event devices. It
> > therefore supports all input  devices  that  the kernel  knows about,
> > including most mice, keyboards, tablets and touchscreens. evdev
> > is the default driver on the major Linux distributions.
> > . . .
> > 
> > 
> > 
> > but it seems to not have a 13-current entry. It does have
> > a 12.0-RELEASE entry.
> > 
> 
> Thanks.  Kinda odd that freebsd-current doesn't have a manual
> page, but FreeBSD-12 does.

rgrimes@t400:~ % man evdev
No manual entry for evdev
rgrimes@t400:~ % man -k evdev
apropos: nothing appropriate
rgrimes@t400:~ % uname -a
FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC  amd64
rgrimes@t400:~ % 
There is no man page for evdev in 12.0-RELEASE

> 
> I have a wireless logitech mouse.  It seems that the
> wireless USB dongle is causing the load of the modules.
> I still understand why as ums(4) does not should a 
> dependency on uhid, wmt, or evdev.
> 

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

Re: problem building dev/e1000

[Rodney W. Grimes]

> 
> > On Feb 15, 2019, at 11:47, Robert Huff  wrote:
> > 
> > Lev Serebryakov writes:
> > 
> >>> My question would be: why? If some drivers have a new 
> >>> dependency on iflib, why isn't that expressed in sys/conf/files 
> >>> and handled automatically?
As expressed elsewhere that gets a bit messy when it is more than
just a few things that depend on this module, and historically
has been done by adding comments to GENERIC that describe the
dependency in the form of "requires iflib".

Though there are some ideas floating around that might better
address this, for the time being that is how it is being handled.

> >>  My question exactly.
> > 
> >I am so glad people who know what they're talking about have the
> > same response I did.  :-)
> 
> I totally missed the part where Robert said he was compiling it
> into the kernel. Also, I remember the days when drivers didn?t
> automatically compile in dependent options (example: ?device re?
> requires ?device miibus?). I guess things have changed a bit in
> the past year [while I was away] with some drivers?
> Thanks,
> -Enji
> >Respectcfully,
> >Robert Huff

Nothing has changed, other than we now have another miibus
type thing called iflib and there are a half dozen drivers
that need to have iflib compiled in if you use them.  What
is new is that these drivers already existed in the past,
but have been re-written to use iflib, so if your carrying
an old kernel config file around and update accross the
iflib'ification of that driver you have to pick up the
change that went into GENERIC that pulls in iflib.

These are probably the types of changes that we should
consider not merging to something called stable/.

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

Re: what do jails map 127.0.0.1 to?

[Rodney W. Grimes]

[ Charset windows-1252 unsupported, converting... ]
> Bjoern A. Zeeb wrote:
> [good stuff snipped]
> >Yes, could do easily but wouldn?t work for my above case, would it?  I
> >can help you with the code for v4 and jails if you help me with the code
> >for IPv6?
> Well, not quite what you volunteered to do, but can you fill in the INET6 code
> for this code snippet? (It does what Alan suggested for INET.)
> 
> 
>   /*
>* Find out what IP# localhost maps to and whether or not use of
>* INET6 is required.  Jails will map 127.0.0.1 to another INET
>* address.
>*/
>   use_inet6 = 0;
>   s = socket(PF_INET, SOCK_DGRAM, 0);
>   if (s < 0) {
>   use_inet6 = 1;
>   s = socket(PF_INET6, SOCK_DGRAM, 0);
>   }
>   if (s < 0)
>   err(1, "Can't create a inet/inet6 socket");
>   if (use_inet6 != 0) {
>   ;   /* Needs code... */
>   } else {
>   memset(&sad, 0, sizeof(sad));
>   sad.sin_len = sizeof(sad);
>   sad.sin_family = AF_INET;
>   sad.sin_addr.s_addr = inet_addr("127.0.0.1");
>   sad.sin_port = 0;
>   ret = bind(s, (struct sockaddr *)&sad, sizeof(sad));
>   if (ret > 0)
>   err(1, "Can't bind 127.0.0.1");
>   memset(&sad, 0, sizeof(sad));
>   slen = sizeof(sad);
>   ret = getsockname(s, (struct sockaddr *)&sad, &slen);
>   if (ret < 0)
>   err(1, "Can't get bound sockaddr");
>   printf("locaddr: %s\n", inet_ntoa(sad.sin_addr));
>   }
> 
> If the IPv4 code isn't sufficient, please let me know. (I think I know how to 
> make
> the RPC code use IPv6, but I need to know what IPv6 address to use. I get 
> confused
> by link local/site local/? It needs to be an address that is "this machine".

ipv4 127.0.0.1 == ipv6 ::1, see /etc/hosts

> 
> Thanks for your help with this, rick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

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

Re: drm2 removed?

[Rodney W. Grimes]

> On Mon, Feb 11, 2019 at 04:33:24PM +, Johannes Lundberg wrote:
> > 
> > On 2/11/19 4:23 PM, Niclas Zeising wrote:
> > > On 2/11/19 5:20 PM, Steve Kargl wrote:
> > >> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:
> > >>> Anyone have any idea which recent change broke the
> > >>> drm-legacy-kmod port.? This is why I raised an issue
> > >>> with removal of drm2 from src/sys.? How is suppose
> > >>> to be fixed?
> > >>>
> > >>
> > >> It was r343567.? The merging of PAE and NO PAE pmap.h
> > >> by kib removed all of the missing macros. :(
> > >>
> > >
> > > The code is still in base, but disabled by default.? I have to have a
> > > look at this, but it might take a couple of days before we have a fix.
> > > Regards
> > 
> > Commit from 12 days ago and we get the news now... Any progress on the
> > CI for drm modules?
> > 
> 
> The commit ends with 
> 
> In collaboarion with: pho
> Discussed with: emaste
> Reviewed by:markj
> MFC after:  2 weeks
> Sponsored by:   The FreeBSD Foundation
> Differential revision:  https://reviews.freebsd.org/D18894
> 
> No exp-run over ports.  You'll likely see more reports when
> the indicated MFC occurs in a day or two.

If this breaks drm2, it must not be MFC'ed until that
breakage is fixed, and I am sure kib knows that.  I
doubt there was any intent to brek drm2, it seems to
have been over looked, and yet another reason to
not unhook this from the builds in ^head.

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

Re: "Oddness" in head since around r343678 or so

[Rodney W. Grimes]

> I run and track stable/11, stable/12, and head (from separate slices --
> no VMs involved) on my laptop; among other things, this permits some
> degree of comparison among them.
> 
> The laptop is configured to run xdm; while running stable/11 or
> stable/12, there's a period of about 5 seconds after xdm's login banner
> shows up before either the mouse or keyboard responds.
> 
> Up to a few days ago, head was the same, but as of about last weekend (I
> think), that period is about 40 seconds while running head.
> 
> I realize that's a little ... lacking in specificity, and I apologize
> for that.  And while I noticed it a few days ago, I hadn't actually
> timed it until this morning.

My addition is going to lack even worse, I have been seeing very
long periods of lag, on this 40 second order, when a bhyve instance
is started.  The interactive response for this time is 0, not
even ^t produces any output.  The prompt comes back almost immediatly
after typing the bhyve command, but that prompt is dead for a
very long time.

I am running 12.0-RELEASE, and see this issue on multiple machines.

> 
> Information, including verbose dmesg.boot copies and a log of uname
> outputs, may be found from the page at
> .
> 
> Here's a list of the uname outputs for head over the last several days:
> 
> FreeBSD 13.0-CURRENT #245 r343551M/343551: Tue Jan 29 03:54:46 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #246 r343572M/343572: Wed Jan 30 05:14:44 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #247 r343604M/343604: Thu Jan 31 03:53:37 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #248 r343646M/343658: Fri Feb  1 04:05:45 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #249 r343678M/343678: Sat Feb  2 03:55:23 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #250 r343707M/343711: Sun Feb  3 04:06:08 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #251 r343732M/343741: Mon Feb  4 04:24:07 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #252 r343770M/343771: Tue Feb  5 04:27:38 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #253 r343828M/343834: Wed Feb  6 03:59:36 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #254 r343867M/343867: Thu Feb  7 04:52:38 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> "It was like reading a Donald Trump tweet.  It didn't make any sense."
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

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

Re: timed restoral until deleter makes a port

[Rodney W. Grimes]

> On Thu, Jan 24, 2019 at 4:13 PM Julian H. Stacey  wrote:
> 
> > Current box here is now about 10 seconds ahead, since timed was deleted,
> > still waiting for the code vandal who removed timed from src/
> > without proper discussion in advance, to move timed from src/ to ports/
> >
> > timed absence will bite more people when 13 is released.  timed
> > should be restored to src/ until the code vandal is forced to write
> > a ports/ entry.  Temporary removal of the src/ commit bit could encourage
> > this & admonish irresponsible conduct.
> >
> > The tech issues have been discussed before, no need to repeat,
> > this is just a question of enforcing responsible procedure.
> >
> 
> The ball is in my court to approve a pull request so we can finish the
> port. We have plenty of time before 13 and current, is after all, current.
> So there's no need to do anything rash here.
> 
> I think all the rest of this is without merit and an overreaction.

Lets prevent this in the future and make it formal policy that
if the solution to a removal from src is that a port be created
the order must be port created and working, then src de-orbit.

Agreeable?


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

Re: Multiport serial card Exsys EX-44388, where are the devices ?

[Rodney W. Grimes]

> Hi!
> 
> > Well no longer needed as puc0 has found and allocated the
> > device(s) which would of shown up had you done this before
> > you fixed puc0 to find them.
> 
> The problem is that the found 4 uarts are not 8 uarts, and they do not
> seem to work (tested using kermit), either 8-(

But you showed it found 8, numbered 2-10.
I do not know what the other uarts are that are now showing up,
is there other hardware in this box?

> 
> Any hints on how to debug this ?

If you remove just the card do the other uarts still show
up with that same patched kernel?


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

Re: Multiport serial card Exsys EX-44388, where are the devices ?

[Rodney W. Grimes]

> Hi!
> 
> > > It only detects four (or six?) serials...
> > Are perhaps 2 of them being consumed by sio?
> 
> See my other post, the system found 13 uarts 8-}
>  
> > > So I think I found a 'somehow' working setup and have to add stuff to
> > > sys/dev/puc/pucdata.c to match it. Thanks for the pointer!
> > 
> > Ok, heading in the right direction, try
> > pciconf -lB
> > that should show the hierarchy with the simple comms connected
> > behind the pci-pci bridge.  More readable without the -v your
> > using above.
> 
> Here we go:

Well no longer needed as puc0 has found and allocated the
device(s) which would of shown up had you done this before
you fixed puc0 to find them.

Anyway, your fixed, so enjoy your serial bits :-)

> -
> hostb0@pci0:0:0:0:class=0x06 card=0x87611043 chip=0x14501022 rev=0x00 
> hdr=0x00
> none0@pci0:0:0:2: class=0x080600 card=0x14511022 chip=0x14511022 rev=0x00 
> hdr=0x00
> hostb1@pci0:0:1:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> pcib1@pci0:0:1:1: class=0x060400 card=0x87611043 chip=0x14531022 rev=0x00 
> hdr=0x01
> bus range  = 1-9
> window[1c] = type I/O Port, range 32, addr 0x1000-0x2fff, enabled
> window[20] = type Memory, range 32, addr 0xba30-0xba5f, enabled
> window[24] = type Prefetchable Memory, range 64, addr 0xfff0-0xf, 
> disabled
> pcib10@pci0:0:1:2:class=0x060400 card=0x87611043 chip=0x14531022 rev=0x00 
> hdr=0x01
> bus range  = 10-10
> window[1c] = type I/O Port, range 32, addr 0xfff000-0xfff, disabled
> window[20] = type Memory, range 32, addr 0xba70-0xba7f, enabled
> window[24] = type Prefetchable Memory, range 64, addr 0xfff0-0xf, 
> disabled
> hostb2@pci0:0:2:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> hostb3@pci0:0:3:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> hostb4@pci0:0:4:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> hostb5@pci0:0:7:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> pcib11@pci0:0:7:1:class=0x060400 card=0x14541022 chip=0x14541022 rev=0x00 
> hdr=0x01
> bus range  = 11-11
> window[1c] = type I/O Port, range 32, addr 0xfff000-0xfff, disabled
> window[20] = type Memory, range 32, addr 0xba00-0xba2f, enabled
> window[24] = type Prefetchable Memory, range 64, addr 0xfff0-0xf, 
> disabled
> hostb6@pci0:0:8:0:class=0x06 card=0x chip=0x14521022 rev=0x00 
> hdr=0x00
> pcib12@pci0:0:8:1:class=0x060400 card=0x14541022 chip=0x14541022 rev=0x00 
> hdr=0x01
> bus range  = 12-12
> window[1c] = type I/O Port, range 32, addr 0xfff000-0xfff, disabled
> window[20] = type Memory, range 32, addr 0xba60-0xba6f, enabled
> window[24] = type Prefetchable Memory, range 64, addr 0xfff0-0xf, 
> disabled
> intsmb0@pci0:0:20:0:  class=0x0c0500 card=0x87611043 chip=0x790b1022 rev=0x59 
> hdr=0x00
> isab0@pci0:0:20:3:class=0x060100 card=0x87611043 chip=0x790e1022 rev=0x51 
> hdr=0x00
> hostb7@pci0:0:24:0:   class=0x06 card=0x chip=0x14601022 rev=0x00 
> hdr=0x00
> hostb8@pci0:0:24:1:   class=0x06 card=0x chip=0x14611022 rev=0x00 
> hdr=0x00
> hostb9@pci0:0:24:2:   class=0x06 card=0x chip=0x14621022 rev=0x00 
> hdr=0x00
> hostb10@pci0:0:24:3:  class=0x06 card=0x chip=0x14631022 rev=0x00 
> hdr=0x00
> hostb11@pci0:0:24:4:  class=0x06 card=0x chip=0x14641022 rev=0x00 
> hdr=0x00
> hostb12@pci0:0:24:5:  class=0x06 card=0x chip=0x14651022 rev=0x00 
> hdr=0x00
> hostb13@pci0:0:24:6:  class=0x06 card=0x chip=0x14661022 rev=0x00 
> hdr=0x00
> hostb14@pci0:0:24:7:  class=0x06 card=0x chip=0x14671022 rev=0x00 
> hdr=0x00
> hostb15@pci0:0:25:0:  class=0x06 card=0x chip=0x14601022 rev=0x00 
> hdr=0x00
> hostb16@pci0:0:25:1:  class=0x06 card=0x chip=0x14611022 rev=0x00 
> hdr=0x00
> hostb17@pci0:0:25:2:  class=0x06 card=0x chip=0x14621022 rev=0x00 
> hdr=0x00
> hostb18@pci0:0:25:3:  class=0x06 card=0x chip=0x14631022 rev=0x00 
> hdr=0x00
> hostb19@pci0:0:25:4:  class=0x06 card=0x chip=0x14641022 rev=0x00 
> hdr=0x00
> hostb20@pci0:0:25:5:  class=0x06 card=0x chip=0x14651022 rev=0x00 
> hdr=0x00
> hostb21@pci0:0:25:6:  class=0x06 card=0x chip=0x14661022 rev=0x00 
> hdr=0x00
> hostb22@pci0:0:25:7:  class=0x06 card=0x chip=0x14671022 rev=0x00 
> hdr=0x00
> xhci0@pci0:1:0:0: class=0x0c0330 card=0x11421b21 chip=0x43ba1022 rev=0x02 
> hdr=0x00
> ahci0@pci0:1:0:1: class=0x010601 card=0x10621b21 chip=0x43b61022 rev=0x02 
> hdr=0x00
> pcib2@pci0:1:0:2: class=0x060400 card=0x02011b21 chip=0x43b11022 rev=0x02 
> hdr=0x01
> bus range  = 2-9
> window[1c] = type I/O Port, range 32, addr 0x1000-0x2fff, enabled
> window[20] = type Memory, rang

Re: Multiport serial card Exsys EX-44388, where are the devices ?

[Rodney W. Grimes]

> Hi!
> 
> > uart is the new thing. sio info should be ignored.
> > 
> > Chances are good that this device doesn't have the proper entries in the
> > puc driver. Do you have any pci devices that show up as unclaimed?
> 
> In a different box, I got this:
> 
> none1@pci0:7:4:0:   class=0x070002 card=0x000814a1 chip=0x000814a1 
> rev=0xb0 hdr=0x00
> vendor = 'Systembase Co Ltd'
> class  = simple comms
> subclass   = UART
> bar   [10] = type I/O Port, range 32, base 0x1040, size 64, enabled
> bar   [14] = type I/O Port, range 32, base 0x1000, size 64, enabled
> 
> and:
> 
> pcib7@pci0:6:0:0:   class=0x060400 card=0x chip=0x10801b21 
> rev=0x04 hdr=0x01
> vendor = 'ASMedia Technology Inc.'
> device = 'ASM1083/1085 PCIe to PCI Bridge'
> class  = bridge
> subclass   = PCI-PCI
> 
> The chips on the card are:
> 
>   ASMedia asm1083 b0bk4911b3 1543 (?)
>   SystemBase SB16C1058PCI 1624
> 
> It only detects four (or six?) serials...
Are perhaps 2 of them being consumed by sio?

> 
> So I think I found a 'somehow' working setup and have to add stuff to
> sys/dev/puc/pucdata.c to match it. Thanks for the pointer!

Ok, heading in the right direction, try
pciconf -lB
that should show the hierarchy with the simple comms connected
behind the pci-pci bridge.  More readable without the -v your
using above.

Please do post the complete output of exactly:
pciconf -lB

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

Re: Multiport serial card Exsys EX-44388, where are the devices ?

[Rodney W. Grimes]

> Hi!
> 
> > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0
> 
> Ah, that is a false lead.
> 
> I compared it to a second, similar hardware and there I found the same uart2,
> even if no card was installed 8-(
> 
> So it seems the card is not detected at all 8-(

Need to find out why it is not showing up in the PCI
listings.  Can you post the output from

pciconf -l


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

Re: Multiport serial card Exsys EX-44388, where are the devices ?

[Rodney W. Grimes]

> On Sat, Jan 19, 2019 at 2:52 AM Kurt Jaeger  wrote:
> 
> > Hi!
> >
> > > uart is the new thing. sio info should be ignored.
> > >
> > > Chances are good that this device doesn't have the proper entries in the
> > > puc driver. Do you have any pci devices that show up as unclaimed?
> >
> > In a different box, I got this:
> >
> > none1@pci0:7:4:0:   class=0x070002 card=0x000814a1 chip=0x000814a1
> > rev=0xb0 hdr=0x00
> > vendor = 'Systembase Co Ltd'
> > class  = simple comms
> > subclass   = UART
> > bar   [10] = type I/O Port, range 32, base 0x1040, size 64, enabled
> > bar   [14] = type I/O Port, range 32, base 0x1000, size 64, enabled
> >
> 
> This is the one you want. You'll need to add vendor 14a1 device 8 to the
> puc tables. Do you need help with this? It will be a bit tricky because
> each of these defines several ports, I think.
> 
> and:
> >
> > pcib7@pci0:6:0:0:   class=0x060400 card=0x chip=0x10801b21
> > rev=0x04 hdr=0x01
> > vendor = 'ASMedia Technology Inc.'
> > device = 'ASM1083/1085 PCIe to PCI Bridge'
  
> > class  = bridge
> > subclass   = PCI-PCI
> >
> 
> This is something else.

I believe this is the PCI-PCI bridge that he clearly says
is on the board just a few lines below here.
> 
> 
> > The chips on the card are:
> >
> >   ASMedia asm1083 b0bk4911b3 1543 (?)
  
> >   SystemBase SB16C1058PCI 1624
> >
> > It only detects four (or six?) serials...
> >
> > So I think I found a 'somehow' working setup and have to add stuff to
> > sys/dev/puc/pucdata.c to match it. Thanks for the pointer!
> 
> 
> That's right. Ask me if you need help. There's several different ways that
> hardware vendors slice and dice the UARTs, and there's no standard. Clock
> rate may be an issue too, since newer cards have faster baud clocks to
> support higher rates, but this means to get the right right you have to
> use  a different divisor than the older 16550A typically needed. Luckily
> this is well supported.

I am also wondering if the reason he only saw 4 or 6 ports is that
some of them have been presented to the system in a way that they
look like standard uart0 and uart1, that is why I asked for the full
non verbose pciconf -lB output, it would clear some of that up.

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

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Rodney W. Grimes]

> On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > >
> > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org
> > (mailto:l...@freebsd.org)) wrote:
> > >
> > > > I have never seen such item in BIOS Setup. I've checked two MoBos now
> > (one is
> > > > Supermicro X9something and other is brand-new Goldmont-based Chinese
> > MiniPC
> > > > like Intel NUK): both have one knob in setup about boot type
> > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not
> > Chinese
> > > > one) could be booted to "UEFI Console" which is not documented
> > anywhere.
> > > >
> > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I
> > could
> > > > not find or understand anything in this home-rown UI with crazy-fast
> > mouse.
> > > >
> > >
> > > On ASUS systems you normally press F8 during POST to bring up the boot
> > menu, and F11 on Supermicro systems.
> >
> > ASUS should learn to put that stuff on screen... like everyone else.
> > I've been hitting the delete and going to the bios/boot tap which
> > also has a boot selection screen on one of my machines because I
> > did not know F8 existed.
> >
> 
> I've been generally reluctant to add old-style boot0 selection to UEFI
> stuff. The BIOS already does it, so we don't need to. I've not needed it at
> all.

The BIOS does NOT do what our boot0 does, I have seen no BIOS that
well allow me to select a partition on a drive, you can only select
the drive.

I think this is the feature that Lev is missing, and I am sure
others shall miss it to.

IIRC whistle used a version of this so you could install a new system
to partion 2, keeping your current system in partion 1, and changing the
active back and forth.  If we have lost that basic functionality with
the growth of GPT and UEFI that is a sad day.

> 
> However, we start the boot in lua. We already allow an interruption of
> loader.efi, so it would be super easy (assuming we got the lua bindings
> right) to implement something that would show you all the Boot envs and
> let you select one to boot instead. We already have the ability to
> interrupt the boot loader. It would also be trivial to implement a 'efiboot
> ' command to give that to you in cli mode. Both would set BootNext to
>  and exit. We already have a menu, we could just add it to that. This
> would solve the hassles people are having with their BIOS (either because
> it's incomplete or hides the functionality too well) and would obviate the
> need to make boot1.efi do the selection (which has issues of its own due to
> boot1's limited scope).

Loader and such is far too late... as part of what the boot0 mbr gets you
around is when your loader in the new partition is what is stopping you
from getting booted because it got screwed up.

> The only drawback here is that we'd not be able to create new boot envs in
> the loader, or you'd need to create a new one if you haven't yet run
> efibootmgr(8), but if that's really an issue, someone will write code to
> cope.
> 
> Warner

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

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Rodney W. Grimes]

> 
> On January 19, 2019 at 2:52:28 AM, Lev Serebryakov 
> (l...@freebsd.org(mailto:l...@freebsd.org)) wrote:
> 
> > I have never seen such item in BIOS Setup. I've checked two MoBos now (one 
> > is
> > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC
> > like Intel NUK): both have one knob in setup about boot type
> > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese
> > one) could be booted to "UEFI Console" which is not documented anywhere.
> >  
> > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could
> > not find or understand anything in this home-rown UI with crazy-fast mouse.
> >  
> 
> On ASUS systems you normally press F8 during POST to bring up the boot menu, 
> and F11 on Supermicro systems.

ASUS should learn to put that stuff on screen... like everyone else.
I've been hitting the delete and going to the bios/boot tap which
also has a boot selection screen on one of my machines because I
did not know F8 existed.

Thank you!
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Rodney W. Grimes]

> > On 18 Jan 2019, at 21:33, Rodney W. Grimes 
> >  wrote:
> > 
> >> 
> >> 
> >>> On 18 Jan 2019, at 19:57, Lev Serebryakov  wrote:
> >>> 
> >>> On 18.01.2019 20:13, Warner Losh wrote:
> >>> 
> >>>>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
> >>>>> legacy boot) :-(
> >>>>> 
> >>>> 
> >>>> What same problems? I don't think we've touched how gptboot has handed 
> >>>> off
> >>>> to /boot/loader in a long, long time. It there's an issue here, it's a
> >>>> different issue.
> >>> Ok, strictly speaking it is different issue with same "high-level"
> >>> description: pmbr/gptboot has less features than simplest oldest boot0.
> >>> 
> >>> pmbr/gptbood doesn't have any way to select partition to boot from, as
> >>> "boot0" has. No, setting "nextboot" from live system is not a solution.
> >>> I speak about NanoBSD situation when there is tow partitions, both
> >>> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> >>> completely broken and user need to boot from other one form very
> >>> beginning. This task is trivially solved by "boot0" in pure-MBR case.
> >>> What about GPT/Legacy and GPT/UEFI?
> >>> 
> >>> -- 
> >>> // Lev Serebryakov
> >>> 
> >> 
> >> errm.. you press a key and enter device and or loader path. if it is not 
> >> working - the code is there to be fixed.
> >> GPT does not have the concept of active partition.
> > 
> > It certainly does, it is called the attribute bootme,
> > and the above correctly states that.
> > 
> 
> Shall you give the reference to specification?:) 

You can bury yourself in that paradigm, but the fact is even the wiki documents
gpt attribute bit 2 as "legacy bootable, equivelant to active flag".

> 
> I am very well aware about the ?vendor? attributes, and I guess You can make 
> a difference about vendor extensions and specification?  
> 
> And regarding to GPT attributes, I personally would avoid writing partition 
> table from the boot loader?

I never advocated writing to anything from the loader.


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

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Rodney W. Grimes]

> On 18.01.2019 21:14, Toomas Soome wrote:
> 
> > errm.. you press a key and enter device and or loader path. if it is not 
> > working - the code is there to be fixed.
>  And loader looks to "bootme" attribute and try to boot from partition
> which has one, even if it is loaded from other partition itself.
> 
> > GPT does not have the concept of active partition.
>  It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have
> any tools to set these attributes, AFAIK. Same for UEFI boot code.

The gpart(8) command is used to set/unset these.


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

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

[Rodney W. Grimes]

> 
> 
> > On 18 Jan 2019, at 19:57, Lev Serebryakov  wrote:
> > 
> > On 18.01.2019 20:13, Warner Losh wrote:
> > 
> >>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
> >>> legacy boot) :-(
> >>> 
> >> 
> >> What same problems? I don't think we've touched how gptboot has handed off
> >> to /boot/loader in a long, long time. It there's an issue here, it's a
> >> different issue.
> > Ok, strictly speaking it is different issue with same "high-level"
> > description: pmbr/gptboot has less features than simplest oldest boot0.
> > 
> > pmbr/gptbood doesn't have any way to select partition to boot from, as
> > "boot0" has. No, setting "nextboot" from live system is not a solution.
> > I speak about NanoBSD situation when there is tow partitions, both
> > bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> > completely broken and user need to boot from other one form very
> > beginning. This task is trivially solved by "boot0" in pure-MBR case.
> > What about GPT/Legacy and GPT/UEFI?
> > 
> > -- 
> > // Lev Serebryakov
> > 
> 
> errm.. you press a key and enter device and or loader path. if it is not 
> working - the code is there to be fixed.
> GPT does not have the concept of active partition.

It certainly does, it is called the attribute bootme,
and the above correctly states that.

man gptboot

> 
> My suggestion would be to walk all those boot programs and document them, 
> then see what features are possible to bring to sync.

The gptboot use of bootme and bootonce are well documented.

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

Re: UEFI, loader.efi and /boot.config

[Rodney W. Grimes]

> On Fri, Jan 18, 2019, 12:49 AM Kurt Jaeger  
> > Hi!
> >
> > > With a recent change I made for UEFI, we now install loader.efi onto the
> > ESP and don???t run boot1. That means that /boot.config is no longer read,
> > and so console settings need to be put in /boot/loader.conf
> >
> > Which change is that ?
> >
> 
> Moving from boot1.efi to loader.efi. loader.efi never looked at it.
> loader.efi honors the uefi env vars to set the console which replaces the
> old way.
> 

So it sounds like what we need is some documentation that covers:

a)  If your using mbr/bios boot and /boot.config you need to move
your settings from /boot.config to /boot/loader.conf

or

b)  If your using uefi boot and /boot.config you need to migrate
your settings from /boot.config to uefi env vars foo bar and zep

Or did I get loss in the twisty maze of changes?


> Warner
> 
> > I was wondering if people will expect /boot.config to still be read and
> > so code should be added to loader to continue to parse it, or if
> > loader.conf can be considered the correct place and boot.config forgotten
> > about?
> >
> > I have quite a few systems using /boot.config, but can cope if I know
> > about this.
> >
> > --
> > p...@opsec.eu+49 171 3101372One year to go !

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

Re: openssl 1.1.1 utils mkerr.pl

[Rodney W. Grimes]

> Hi!
> 
> > Did you try to use the openssl port?
> 
> cd security/openssl111
> $ grep mkerr pkg-plist 
> $ 

cd secuirty/openssl111
make extract
find work | grep mkerr


> does not have it, either.
> 
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: building release images broken?

[Rodney W. Grimes]

> On 11/17/18 5:35 PM, Michael Butler wrote:
> > Any clues as to what's broken here? I'm trying to build a CD and/or DVD
> > image.
> > 
> > My tree is at SVN r340525.
> > 
> > --
>  Kernel build for GENERIC completed on Sat Nov 17 22:19:48 UTC 2018
> > --
> > make -C /usr/src/release  obj
> > make -C /usr/src/release  ftp cdrom dvdrom memstick.img mini-memstick.img
> > `ftp' is up to date.
> > sh /usr/src/release/amd64/mkisoimages.sh -b 13_0_CURRENT_amd64_CD
> > disc1.iso disc1
> > 200+0 records in
> > 200+0 records out
> > 819200 bytes transferred in 0.003692 secs (221856674 bytes/sec)
> > newfs_msdos: cannot get number of sectors per track: Operation not supported
> > newfs_msdos: cannot get number of heads: Operation not supported
> > /dev/md0: 1557 sectors in 1557 FAT12 clusters (512 bytes/cluster)
> > BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
> > Sectors=1600 Media=0xf8 FATsecs=5 SecPerTrack=63 Heads=1 HiddenSecs=0
> > mkdir: efi: File exists
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/src/release
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/src/release
> 
> Answering my own question .. seems there's one 'mkdir' without the '-p'
> option .. this fixes it ..
> 
> 
> *** release/amd64/mkisoimages.sh~   Mon Oct 22 16:41:26 2018
> --- release/amd64/mkisoimages.shSun Nov 18 11:42:09 2018
> ***
> *** 46,52 
> dd if=/dev/zero of=efiboot.img bs=4k count=200
> device=`mdconfig -a -t vnode -f efiboot.img`
> newfs_msdos -F 12 -m 0xf8 /dev/$device
> !   mkdir efi
> mount -t msdosfs /dev/$device efi
> mkdir -p efi/efi/boot
> cp -p "$BASEBITSDIR/boot/loader.efi" efi/efi/boot/bootx64.efi
> --- 46,52 
> dd if=/dev/zero of=efiboot.img bs=4k count=200
> device=`mdconfig -a -t vnode -f efiboot.img`
> newfs_msdos -F 12 -m 0xf8 /dev/$device
> !   mkdir -p efi

Though this does infact prevent the error the larger question
is what has gone wrong in the Makefile such that this directory
already exists when you get to this point in the Makefile,
as it appears from the lack of -p or other logic to detect
an already existing directory it is not expected to already
be present.

Traditionally -p is used when your creating a path
to a directory, not just a single directory, so it
appears very odd to me to even see a mkdir -p ,
which would probably be the same as @mkdir .

How did this directory get created?
Why is it existing when we get to this line?

> mount -t msdosfs /dev/$device efi
> mkdir -p efi/efi/boot
> cp -p "$BASEBITSDIR/boot/loader.efi" efi/efi/boot/bootx64.efi
> 
> 
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI GOP: screen goes blank during boot after loader is finished

[Rodney W. Grimes]

> On Wed, Nov 14, 2018 at 3:49 PM Kyle Evans  wrote:
> 
> > Good, good, so the loader <-> kernel transition would appear to be
> > intact and information appears good at first blush. If you don't have
> > time to dig into this, I'll try poking at it this weekend, but it
> > looks to be either kernel problem or VNC server.
> 
> FreeBSD 11.{1,2} and various Linux distros boot fine with UEFI GOP in
> the same time, the problem is only with FreeBSD 12-ALPHA+.
> Therefore it does not look like VNC server issue.

Lets make sure this is not the invalid instruction trap (CLFLUSH)
that has already been fixed by BETA3.  Is everyone infact using
BETA3 or later as a guest?   We know of and have fixed this other
bug and I want to make sure we are not chassing a red hearing.

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

Re: UEFI GOP: screen goes blank during boot after loader is finished

[Rodney W. Grimes]

> On Tue, Nov 13, 2018 at 5:15 PM Subbsd  wrote:
> >
> > Hi,
> >
> >
> >
> > On Tue, Nov 13, 2018 at 7:22 PM Rodney W. Grimes
> >  wrote:
> > >
> > > Uh oh, ok, thats not what I was thinking of then.  I do not have any
> > > bhyve capable hardware running on 12BETA at this time to test with.
> > >
> > > I wonder if we have a bad interaction between the loader and
> > > bhyve again, we have had a few of those.
> > >
> >
> > it's broken before 12-ALPHA1, my post from 14-Sep to current@
> >
> > https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071206.html
> >
> > probably the lua loader doesn't understand efifb/term very well
> 
> These things are basically completely unrelated- the interpreter
> included in loader(8) doesn't have to know anything about graphics and
> this stuff is handled before and after the interpreter is invoked.
> 
> However, because loader-land is funny in a not-ha-ha kind of way, can
> you try replacing loader.efi on your guest VM with the Forth-flavored
> version to rule that out or narrow it down, please?
> 
> Thanks,

Am I miss remebering or didn't we solve a similiar problem
earlier in the release cycle?   Perhaps that was with non
GOP console only.

Either way, we need to make sure this is resolved.  Sad state is
I do not have any access until after the holiday most likely to
any hardware that I can use to work on this problem.

Please keep me in the loop though, I am reading emails each morning,
and as times allow during the day.

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

Re: 12.0-beta3 base.txz missing complete dir tree

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> 
> 
> On 11/8/18 12:25 PM, Ernie Luzar wrote:
> > ftp.freebsd.org/pub/FreeBSD/releases/amd/amd/12.0-BETA3/base.txz
> >
> > /usr/local empty
> > /var/log? empty
> >
> > This is really making testing imposable!
> 
> shouldn't both of those directories be empty in the base.txz file? or is 
> their another error you are getting?

They should be empty.  Infact it would be very wrong for base to put
anything in either of these directories, /usr/local is for ports and
packages to install into.

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

Re: 12.0-BETA1 vnet with pf firewall

[Rodney W. Grimes]

> On 30 Oct 2018, at 14:14, Rodney W. Grimes wrote:
> 
> >> On 30 Oct 2018, at 14:29, Bjoern A. Zeeb wrote:
> >>> On 30 Oct 2018, at 12:23, Kristof Provost wrote:
> >>>> I?m not too familiar with this part of the vnet code, but it looks
> >>>> to me like we?ve got more per-vnet variables that was originally
> >>>> anticipated, so we may need to just increase the allocated space.
> >>>
> >>> Can you elfdump -a the two modules and see how big their set_vnet
> >>> section sizes are?  I see:
> >>>
> >>> pf.ko:  sh_size: 6664
> >>> ipl.ko: sh_size: 2992
> >>>
> >> I see exactly the same numbers.
> >>
> >>> VNET_MODMIN is two pages (8k).  So yes, that would exceed the module
> >>> space.
> >>> Having 6.6k global variable space is a bit excessive?  Where does 
> >>> that
> >>> come from?  multicast used to have a similar problem in the past 
> >>> that
> >>> it could not be loaded as a module as it had a massive array there 
> >>> and
> >>> we changed it to be malloced and that reduced it to a pointer.
> >>>
> >>> 0f38 l O set_vnet   0428
> >>> vnet_entry_pfr_nulltable
> >> That?s a default table. It?s large because it uses MAXPATHLEN for
> >> the pfrt_anchor string.
> >>
> >>> 0b10 l O set_vnet   03d0
> >>> vnet_entry_pf_default_rule
> >> Default rule. Rules potentially contain names, tag names, interface
> >> names, ? so it?s a large structure.
> >>
> >>> 1370 l O set_vnet   0690
> >>> vnet_entry_pf_main_anchor
> >> Anchors use MAXPATHLEN for the anchor path, so that?s 1024 bytes 
> >> right
> >> away.
> >>
> >>>  l O set_vnet   0120
> >>> vnet_entry_pf_status
> >>>
> >> pf status. Mostly counters.
> >>
> >> I?ll see about putting moving those into the heap on my todo list.
> >
> > Though that removes the current situation, it is a partial fix,
> > doesnt this static sized 2 page VNET_MODMIN needs to be fixed in the
> > longer term?
> 
> I think about it the other way round:  we might want to bump it to 4 
> pages in short term for 12.0 maybe?

81MB in your 1 vnet case, not horrible really as a quick and
slightly dirty fix.

> The problem is that whether or not you use modules these 2/4 pages will 
> be allocated per-vnet, so if you run 50 vnet jails that?s 100/200 
> pages.  And while people might say memory is cheap, I?ve run 10.000 
> vnet jails before on a single machine ? it adds up.  I wonder if we 
> could make it a tunable though..  Let me quickly think about it and come 
> up with a patch.

A boot time tunable that defaulted to 2 pages would be good too.

We are faced with similiar issues in bhyve, where each VM created
gets an allocation based on MAXCPU, I have wip in process to alter
this so that the 4th (and currently hidden) cpu topology option
controls the size of these allocations.

> 
> I?ll also go and see to get better error reporting into the 
> link_elf*.c files for this case.

Great!

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

Re: 12.0-BETA1 vnet with pf firewall

[Rodney W. Grimes]

> On 30 Oct 2018, at 14:29, Bjoern A. Zeeb wrote:
> > On 30 Oct 2018, at 12:23, Kristof Provost wrote:
> >> I?m not too familiar with this part of the vnet code, but it looks 
> >> to me like we?ve got more per-vnet variables that was originally 
> >> anticipated, so we may need to just increase the allocated space.
> >
> > Can you elfdump -a the two modules and see how big their set_vnet 
> > section sizes are?  I see:
> >
> > pf.ko:  sh_size: 6664
> > ipl.ko: sh_size: 2992
> >
> I see exactly the same numbers.
> 
> > VNET_MODMIN is two pages (8k).  So yes, that would exceed the module 
> > space.
> > Having 6.6k global variable space is a bit excessive?  Where does that 
> > come from?  multicast used to have a similar problem in the past that 
> > it could not be loaded as a module as it had a massive array there and 
> > we changed it to be malloced and that reduced it to a pointer.
> >
> > 0f38 l O set_vnet   0428 
> > vnet_entry_pfr_nulltable
> That?s a default table. It?s large because it uses MAXPATHLEN for 
> the pfrt_anchor string.
> 
> > 0b10 l O set_vnet   03d0 
> > vnet_entry_pf_default_rule
> Default rule. Rules potentially contain names, tag names, interface 
> names, ? so it?s a large structure.
> 
> > 1370 l O set_vnet   0690 
> > vnet_entry_pf_main_anchor
> Anchors use MAXPATHLEN for the anchor path, so that?s 1024 bytes right 
> away.
> 
> >  l O set_vnet   0120 
> > vnet_entry_pf_status
> >
> pf status. Mostly counters.
> 
> I?ll see about putting moving those into the heap on my todo list.

Though that removes the current situation, it is a partial fix,
doesnt this static sized 2 page VNET_MODMIN needs to be fixed in the
longer term?

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

Re: 12.0-BETA1 vnet with pf firewall

[Rodney W. Grimes]

> Bjoern A. Zeeb wrote:
> > On 28 Oct 2018, at 15:31, Ernie Luzar wrote:
> > 
> >> Tested with host running ipfilter and vnet running pf. Tried loading 
> >> pf from host console or from vnet console using kldload pf.ko command 
> >> and get this error message;
> >>
> >> linker_load_file: /boot/kernel/pf.ko-unsupported file type.
> >>
> >> Looks like the 12.0 version of pf which is suppose to work in vnet 
> >> independent of what firewall is running on the host is not working.
> > 
> > You cannot load pf from inside a jail (with or without vnet).  Kernel 
> > modules are global objects loaded from the base system or you compile 
> > the devices into the kernel;  it is their state which is virtualised.
> > 
> > If you load multiple firewalls they will all be available to the base 
> > system and all jails+vnet.  Whichever you configure in which one is up 
> > to you.  Just be careful as an unconfigured firewall might have a 
> > default action affecting the outcome of the overall decision.
> > 
> > For example you could have:
> > 
> > a base system using ipfilter and setting pf to default accept everything
> > and a jail+vnet using pf and setting ipfilter there to accept everything.
> > 
> > 
> > Hope that clarifies some things.
> > 
> > /bz
> > 
> 
> Hello Bjoern.
> 
> What you said is correct for 10.x & 11.x. But I an talking about 
> 12.0-beta1.  I have the ipfilter options enabled in rc.conf of the host 
> and on boot ipfilter starts just like it all ways does. Now to prep the 
> host for pf in a vnet jail, I issue from the host console the
> "kldload pf.ko" command and get this error message;
> 
> linker_load_file: /boot/kernel/pf.ko-unsupported file type.
> 
> Something is wrong here. This is not suppose to happen according to your 
> post above.
> 
> Remember that in 12.0 vimage is included in the base system kernel.

Confirmed, if I boot a clean install and issue:
kldload ipfilter.ko
kldload pf.ko
my dmesg has:
IP Filter: v5.1.2 initialized.  Default = pass all, Logging = enabled
linker_load_file: /boot/kernel/pf.ko - unsupported file type

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

Re: 12-BETA1 contains warning about non-PNP ISA device

[Rodney W. Grimes]

> On Thu, Oct 25, 2018 at 8:10 AM Eric van Gyzen  wrote:
> 
> > On 10/25/18 6:57 AM, Rodney W. Grimes wrote:
> > >>> I noticed a warning on a new AMD system running 12-BETA1:
> > >>>
> > >>> non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
> > >> Can you please reply with the specific device.
> > >> If you have seen one it may be an issue to removing it,
> > >> especially if this is on a "new AMD" system.
> > >
> > > Further investigation shows me that this comes from
> > > generic code in sys/isa/isa_common.c, and does not
> > > come from any specific driver markings.
> >
> > My new Ryzen says:
> >
> > atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12.
> >
> > Believe it or not, my motherboard has a PS/2 connector, so I could
> > actually use this driver someday.
> >
> 
> I'll look into this. Rest assured, we won't be removing this. In theory,
> all such devices should be attaching via ACPI.
> 
> Can you send me the output of 'devinfo -v' off list?

I suspect something funny happens when there is already a
USB keyboard plugged in that has been enumerated by ACPI,
I would be willing to speculate that it leaves the legacy
port visible as a legacy non PnP/Non ACPI device.

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

Re: 12-BETA1 contains warning about non-PNP ISA device

[Rodney W. Grimes]

> > I noticed a warning on a new AMD system running 12-BETA1:  
> > 
> > non-PNP ISA device will be removed from GENERIC in FreeBSD 12.  
> Can you please reply with the specific device.
> If you have seen one it may be an issue to removing it,
> especially if this is on a "new AMD" system.

Further investigation shows me that this comes from
generic code in sys/isa/isa_common.c, and does not
come from any specific driver markings.

> > It looks like it was introduced by Warner in r327120. Should those devices 
> > have been removed already?
> 
> Yes, and they well be removed from GENERIC in BETA2,
> as I just approved the RFA to merge that fix to stable/12.

That is an incorrect statement, what I approved does not
in any way effect this error that I can tell.

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

Re: 12-BETA1 contains warning about non-PNP ISA device

[Rodney W. Grimes]

> I noticed a warning on a new AMD system running 12-BETA1:  
> 
> non-PNP ISA device will be removed from GENERIC in FreeBSD 12.  
Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on a "new AMD" system.

> 
> It looks like it was introduced by Warner in r327120. Should those devices 
> have been removed already?

Yes, and they well be removed from GENERIC in BETA2,
as I just approved the RFA to merge that fix to stable/12.

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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> A cost(=time)/benefit look on moving ctm from src/ to ports/ :
> - No tangible architecture benefit (its not like purging an old driver
>   to makes kernel support simpler, or avoiding clashing libs etc)
> - FreeBSD would shrink 0.028 % of the size of src/
>   cd /pub/FreeBSD/branches/-current/src
>   du -s -k .  # 1223922
>   du -s -k `find . -type d -name \*ctm\*`
>   196 ./usr.sbin/ctm
>   74  ./usr.sbin/ctm/ctm
>   12  ./usr.sbin/ctm/ctm_dequeue
>   44  ./usr.sbin/ctm/ctm_rmail
>   18  ./usr.sbin/ctm/ctm_smail
>   dc 196 74 12 44 18 + + + + p 344
>   dc 3440 1223922 / p 281063  # then move 9 points
>   xcalc 344 / 1223922 # 0.0002810636
> 
> Those who would do the work might want to ponder if 0.028 % is best use of 
> their time, or if more fun & benefit to work on some other part of FreeBSD ?

At the most/least we should not go very far,
the only thing that needs done soon is a gonein(13) commited
to head and MFC'ed to stable/12 by thursday.

All the other details should wait until a depreication policy
revision is completed that includes how to deal with this.

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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen:
> > I have no problem turning ctm into a port.  But I would appreciate
> > advice on whether there is a standard or easy process for converting
> > software from the FreeBSD base to a port.  If not, I can muddle my way
> > through it.  But give me some time (a few months) to get it done,
> > because the rest of my life is making heavy demands on me right now.
> 
> Hi Stephen,
> 
> I could spend a few hours to perform the conversion to a port and to
> test it. I've a happy CTM user, many years ago, and I can understand
> that it still may be useful in special situations.
> 
> The source archive will need to be hosted somewhere. Do you have a
> preference (e.g., on a FreeBSD server, or on Github, Gitlab, ...)?

Doesnt the project have a place for doing this already?
Any commiters ~username/ would work, but is probably not optimal.

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

Re: careless commits disrupt

[Rodney W. Grimes]

> Am 22.10.18 um 23:09 schrieb Julian H. Stacey:
> > Hi, Reference:
> >> From:  Stefan Esser 
> >> Date:  Fri, 12 Oct 2018 11:44:59 +0200
> > 
> > Stefan Esser wrote:
> >> I might have mentioned, that I always preserve old shared libraries in
> >> /usr/lib/compat before running "make delete-old-libs". 
> > 
> > Good idea, are you doing that manually, or do you have a patch to share ?
> 
> I do it manually, but I have a script that checks for programs in the
> base system and packages that use any library moved to the lib/compat
> directory - see below.
> 
> The base system checks should never give any output (unless there are
> old and obsolete binaries).
> 
> I use the package list to identify packages that must be rebuilt to
> make the compat libraries obsolete. Since there may be shared library
> version conflicts, if some
> 
> Regards, STefan
> 
> 
> 
> #!/bin/sh
> 
> find_compat_depend () {
> local dir="$1"
> local pattern="$2"
> 
> find "$dir" -type f ${pattern:+-name "$pattern"} \
>   -exec sh -c "ldd {} 2>/dev/null | grep -lq /compat/ && echo {}" \;
> }
> 
> echo "Base system programs referencing compat libraries:"
> find_compat_depend /bin ""
> find_compat_depend /sbin ""
> find_compat_depend /libexec ""
> #find_compat_depend /lib "lib*.so.*"
> find_compat_depend /usr/bin ""
> find_compat_depend /usr/sbin ""
> find_compat_depend /usr/libexec ""
> #find_compat_depend /usr/lib "lib*.so.*"
> 
> echo
> echo "Installed packages referencing compat libraries:"
> {
> find_compat_depend /usr/local/bin ""
> find_compat_depend /usr/local/sbin ""
> find_compat_depend /usr/local/libexec ""
> find_compat_depend /usr/local/lib "lib*.so.*"
> } | xargs pkg which -q | sort -u


Could this be added in a more generic way to pkg?
pkg finddep $PATH $ALTLIBDIR
I see this as "Very Useful" (TM)

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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> > > The ctm(1) client remains in the FreeBSD base system, although
> > > FreeBSD-hosted ctm infrastructure was shut down some time ago. I
> > > suspect it is time to remove it from the base system (perhaps making a
> > > port).
> > > 
> > > How much use does ctm have these days?
> > 
> > I do not know that other than I do know that I have seen
> > one data point in the last 14 days of a user who was infact
> > using ctm though I can not associate a username/email address
> > with that memory.
> > 
> > A search of the last 30 days of @freebsd.org public mail
> > may yield a hit.
> 
> A fair guess, but it wouldn't indicate CTM usage well,
> as we only use the ctm@ list to discuss if something breaks,
> or to warn if a server will go out for maintenance.

The search was only to find YOU, as I knew my above 14
day reference to a user was a message on a mail list that
contained the word "ctm".

> more misleading still: the ctm-announce@ list
> https://lists.freebsd.org/mailman/listinfo/ctm-announce 
> hasnt been used in years, because Stephen doesnt have
> write access to it. I did write someone years back asking that
> Stephen be given write access, but it slipped between the cracks.
> If anyone fixes that to give Stephen Montgomery Smith write access to
> ctm-announce, it would be nice if you consider giving me write access too to
> ctm-announce@ as I occasionaly announce server outages eg
> https://lists.freebsd.org/pipermail/ctm-users/2018-September/000526.html

That should be possible, though I have no idea of where to even ask.


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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> 
> In message 
> 
> , Warner Losh writes:
> 
> >> > I think Julian Stacy is still running CTM generation ?
> >>
> >> Ah, yes, that brought back enough brain cells,
> >> confirmed that is who I saw with ctm usage.
> >
> >Do we need it in base? Or can we make it a port?
> 
> Absolutely make it a port!
> 

I concur, but please hold off on the svn rm until
Stephen Montgomery and Julian have acked that they
can quickly and easily transition to a port, then
I would even be fine with a MFC gone in(13) to
stable/12 and an immediate rm from head.


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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> 
> In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. 
> Gri
> mes" writes:
> 
> >I do not know that other than I do know that I have seen
> >one data point in the last 14 days of a user who was infact
> >using ctm though I can not associate a username/email address
> >with that memory.
> >
> >A search of the last 30 days of @freebsd.org public mail
> >may yield a hit.
> 
> I think Julian Stacy is still running CTM generation ?

Ah, yes, that brought back enough brain cells,
confirmed that is who I saw with ctm usage.


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

Re: ctm(1) deprecation in the FreeBSD base system?

[Rodney W. Grimes]

> The ctm(1) client remains in the FreeBSD base system, although
> FreeBSD-hosted ctm infrastructure was shut down some time ago. I
> suspect it is time to remove it from the base system (perhaps making a
> port).
> 
> How much use does ctm have these days?

I do not know that other than I do know that I have seen
one data point in the last 14 days of a user who was infact
using ctm though I can not associate a username/email address
with that memory.

A search of the last 30 days of @freebsd.org public mail
may yield a hit.

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

Re: A new stable/12 poudriere jail is inferior to its stable/12 host

[Rodney W. Grimes]

-- Start of PGP signed section.
> On Sun, Oct 21, 2018 at 02:14:16PM +0100, Graham Perrin wrote:
> > On 21/10/2018 13:31, David Wolfskill wrote:
> > > On Sun, Oct 21, 2018 at 09:41:46AM +0100, Graham Perrin wrote:
> > >> With the host already at r339438,
> > >> creation of a jail (method: svn (other methods failed)) resulted in
> > >> inferior version r339435.
> > >>
> > >> Is this normal?
> > >>
> > >> Re: 
> > >> 
> > >>  I want the version of the jail to match the version of the host before 
> > >> I use poudriere to build kernel modules, and so on.
> > >>
> > >> 
> > > r339438 is a revision in stable/11.  ?
> > 
> > That's weird, because I recently successfully ran:
> > 
> > svn switch '^/stable/12' /usr/src
> > 
> > ? prior to a successful update of the system.
> 
> Sure.  On my laptop (for example), I have a local private SVN mirror
> repo.  It is currently at r339530.
> 
> On each of 3 different slices, I have stable/11, stable/12, and
> head; the corresponding working directories (which have been updated
> since the repo was last updated) are currently at r339446, r339435,
> and r339530 (respectively).
> 
> FreeBSD's newvers.sh would put "r339530M" in the uname string for
> each of those.
> 
> My version places "r339446M/339530", "r339435M/339530", and
> "r339530M/339530" (respectively) in the uname string to try to help
> clarify which revision in each branch last affected that branch.

Yes please!
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Not sure if this is an important bug...

[Rodney W. Grimes]

> I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and
> it explodes because of an unemulated instruction:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081
> 
> I have no idea what importance this has in relation to releasing 12.0

Can you try an earlier alpha for me?  Specifically A3, I think this
may be some hand optimization of memmov stuff that included a new
instruction that we did not use before.


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

Re: Not sure if this is an important bug...

[Rodney W. Grimes]

> On Mon, Oct 08, 2018 at 07:12:59PM +, Poul-Henning Kamp wrote:
> > I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and
> > it explodes because of an unemulated instruction:
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081
> > 
> > I have no idea what importance this has in relation to releasing 12.0
> > 
> 
> I did see the PR when it was opened.  Hopefully the right people can
> take a look at this relatively soon.
> 
> Glen
> 
I saw the original posting by phk and was going to try and validate
it here on my x230, which might narrow this down to an AMD only issue,
or a "we starting using new instructions" issue.  But time has gotten
far away from me and was not able to do that.

I do know that I ran an earlier 12.0Alpha3 on my 11.1 x230 laptop
without issue.

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

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Rodney W. Grimes]

> On 10/2/18 6:27 PM, Rodney W. Grimes wrote:
> >> On 10/1/18 6:43 PM, Rodney W. Grimes wrote:
> >>>> Hi
> >>>>
> >>>> While sound work out of the box (with headphone switching) on the 1-2 
> >>>> year
> >>>> older Latitude 7270, it does not on my new machine.
> >>>>
> >>>> The internal speaker works fine. If I plug in external speakers in the
> >>>> headphone jack, sound still goes to the internal speaker while a very 
> >>>> load
> >>>> buzz comes from the external speakers.
> >>>>
> >>>> Do we have a solution for this?
> >>> I do not believe we have anything that detects stuff plugged into
> >>> and removed from the newer sound stuff that needs switching to
> >>> change from internal to external speakers.
> >>>
> >>> I think you need to do what I have to do when I plug in external
> >>> speakers on my thinkpad x230:
> >>> sysctl hw.snd.default_unit=1
> >>>
> >>> And when I unplug them I have to do:
> >>> sysctl hw.snd.default_unit=0
> >>>
> >>> to switch back to the internal speakers.
> >>
> >> Hi Rod,
> >>
> >>
> >> Can you post the output of 'sysctl dev.pcm' and 'sysctl dev.hdaa'
> > Sure:
> > @x230a:~ # sysctl dev.pcm
> > dev.pcm.4.bitperfect: 0
...
...
> 
> Thanks. So if you try this:
> 
> sysctl dev.hdaa.0.nid24_config="as=4 seq=15"
> sysctl dev.hdaa.0.nid21_config="as=1 seq=15"
> sysctl dev.hdaa.0.reconfig=1

Works, thank you!

> That should make pcm0 and pcm1 "merge" into pcm0 and enable 
> auto-switching when plugging something
> 
> in the headphones jack.
> 
> If it works you might want to put the following two lines in 
> /boot/loader.conf
> 
> hint.hdaa.0.nid24.config="as=4 seq=15"
> hint.hdaa.0.nid21.config="as=1 seq=15"


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

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Rodney W. Grimes]

> On 10/1/18 6:43 PM, Rodney W. Grimes wrote:
> >> Hi
> >>
> >> While sound work out of the box (with headphone switching) on the 1-2 year
> >> older Latitude 7270, it does not on my new machine.
> >>
> >> The internal speaker works fine. If I plug in external speakers in the
> >> headphone jack, sound still goes to the internal speaker while a very load
> >> buzz comes from the external speakers.
> >>
> >> Do we have a solution for this?
> > I do not believe we have anything that detects stuff plugged into
> > and removed from the newer sound stuff that needs switching to
> > change from internal to external speakers.
> >
> > I think you need to do what I have to do when I plug in external
> > speakers on my thinkpad x230:
> > sysctl hw.snd.default_unit=1
> >
> > And when I unplug them I have to do:
> > sysctl hw.snd.default_unit=0
> >
> > to switch back to the internal speakers.
> 
> 
> Hi Rod,
> 
> 
> Can you post the output of 'sysctl dev.pcm' and 'sysctl dev.hdaa'

Sure:
@x230a:~ # sysctl dev.pcm
dev.pcm.4.bitperfect: 0
dev.pcm.4.buffersize: 65536
dev.pcm.4.play.vchanformat: s16le:2.0
dev.pcm.4.play.vchanrate: 48000
dev.pcm.4.play.vchanmode: passthrough
dev.pcm.4.play.vchans: 1
dev.pcm.4.play.32bit: 24
dev.pcm.4.%parent: hdaa1
dev.pcm.4.%pnpinfo: 
dev.pcm.4.%location: nid=7
dev.pcm.4.%driver: pcm
dev.pcm.4.%desc: Intel Panther Point (HDMI/DP 8ch)
dev.pcm.3.bitperfect: 0
dev.pcm.3.buffersize: 65536
dev.pcm.3.play.vchanformat: s16le:2.0
dev.pcm.3.play.vchanrate: 48000
dev.pcm.3.play.vchanmode: passthrough
dev.pcm.3.play.vchans: 1
dev.pcm.3.play.32bit: 24
dev.pcm.3.%parent: hdaa1
dev.pcm.3.%pnpinfo: 
dev.pcm.3.%location: nid=6
dev.pcm.3.%driver: pcm
dev.pcm.3.%desc: Intel Panther Point (HDMI/DP 8ch)
dev.pcm.2.bitperfect: 0
dev.pcm.2.buffersize: 65536
dev.pcm.2.play.vchanformat: s16le:2.0
dev.pcm.2.play.vchanrate: 48000
dev.pcm.2.play.vchanmode: passthrough
dev.pcm.2.play.vchans: 1
dev.pcm.2.play.32bit: 24
dev.pcm.2.%parent: hdaa1
dev.pcm.2.%pnpinfo: 
dev.pcm.2.%location: nid=5
dev.pcm.2.%driver: pcm
dev.pcm.2.%desc: Intel Panther Point (HDMI/DP 8ch)
dev.pcm.1.bitperfect: 0
dev.pcm.1.buffersize: 65536
dev.pcm.1.rec.vchanformat: s16le:2.0
dev.pcm.1.rec.vchanrate: 48000
dev.pcm.1.rec.vchanmode: fixed
dev.pcm.1.rec.vchans: 1
dev.pcm.1.rec.autosrc: 2
dev.pcm.1.rec.32bit: 24
dev.pcm.1.play.vchanformat: s16le:2.0
dev.pcm.1.play.vchanrate: 48000
dev.pcm.1.play.vchanmode: fixed
dev.pcm.1.play.vchans: 9
dev.pcm.1.play.32bit: 24
dev.pcm.1.%parent: hdaa0
dev.pcm.1.%pnpinfo: 
dev.pcm.1.%location: nid=21,18
dev.pcm.1.%driver: pcm
dev.pcm.1.%desc: Realtek ALC269 (Analog)
dev.pcm.0.bitperfect: 0
dev.pcm.0.buffersize: 65536
dev.pcm.0.rec.vchanformat: s16le:2.0
dev.pcm.0.rec.vchanrate: 48000
dev.pcm.0.rec.vchanmode: fixed
dev.pcm.0.rec.vchans: 1
dev.pcm.0.rec.autosrc: 2
dev.pcm.0.rec.32bit: 24
dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.play.vchanrate: 48000
dev.pcm.0.play.vchanmode: fixed
dev.pcm.0.play.vchans: 1
dev.pcm.0.play.32bit: 24
dev.pcm.0.%parent: hdaa0
dev.pcm.0.%pnpinfo: 
dev.pcm.0.%location: nid=20,24
dev.pcm.0.%driver: pcm
dev.pcm.0.%desc: Realtek ALC269 (Analog)
dev.pcm.%parent: 


@x230a:~ # sysctl dev.hdaa
dev.hdaa.1.reconfig: 0
dev.hdaa.1.gpo_config: 
dev.hdaa.1.gpo_state: 
dev.hdaa.1.gpio_config: 
dev.hdaa.1.gpio_state: 
dev.hdaa.1.gpi_state: 
dev.hdaa.1.config: forcestereo,ivref50,ivref80,ivref100,ivref,vref
dev.hdaa.1.nid8: vendor widget [DISABLED]
 Widget cap: 0x00f0

dev.hdaa.1.nid7_original: 0x18560030 as=3 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid7_config: 0x18560030 as=3 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid7: pin: Digital-out (Jack)
 Widget cap: 0x0040778d PWR DIGITAL UNSOL 8CH
Association: 2 (0x0001)
Pin cap: 0x0994 PDC OUT HDMI DP HBR
 Pin config: 0x18560030 as=3 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
Pin control: 0x0040 OUT
 Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Connections: 1
  + <- nid=4 [audio output]

dev.hdaa.1.nid6_original: 0x18560020 as=2 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid6_config: 0x18560020 as=2 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid6: pin: Digital-out (Jack)
 Widget cap: 0x0040778d PWR DIGITAL UNSOL 8CH
Association: 1 (0x0001)
Pin cap: 0x0994 PDC OUT HDMI DP HBR
 Pin config: 0x18560020 as=2 seq=0 device=Digital-out conn=Jack 
ctype=Digital loc=0x18 color=Unknown misc=0
Pin control: 0x0040 OUT
 Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Connections: 1
  + <- nid=3 [au

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Rodney W. Grimes]

> Hi
> 
> While sound work out of the box (with headphone switching) on the 1-2 year
> older Latitude 7270, it does not on my new machine.
> 
> The internal speaker works fine. If I plug in external speakers in the
> headphone jack, sound still goes to the internal speaker while a very load
> buzz comes from the external speakers.
> 
> Do we have a solution for this?

I do not believe we have anything that detects stuff plugged into
and removed from the newer sound stuff that needs switching to
change from internal to external speakers.

I think you need to do what I have to do when I plug in external
speakers on my thinkpad x230:
sysctl hw.snd.default_unit=1

And when I unplug them I have to do:
sysctl hw.snd.default_unit=0

to switch back to the internal speakers.

> 
> # cat /dev/sndstat
> Installed devices:
> pcm0:  (play/rec) default
> pcm1:  (play)
> pcm2:  (play)
> No devices installed from userspace.
> 
> # sysctl hw.snd
> hw.snd.maxautovchans: 16
> hw.snd.default_unit: 0
> hw.snd.version: 2009061500/amd64
> hw.snd.default_auto: 1
> hw.snd.verbose: 0
> hw.snd.vpc_mixer_bypass: 1
> hw.snd.feeder_rate_quality: 1
> hw.snd.feeder_rate_round: 25
> hw.snd.feeder_rate_max: 2016000
> hw.snd.feeder_rate_min: 1
> hw.snd.feeder_rate_polyphase_max: 183040
> hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
> hw.snd.feeder_eq_exact_rate: 0
> hw.snd.feeder_eq_presets:
> PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
> hw.snd.basename_clone: 1
> hw.snd.compat_linux_mmap: 0
> hw.snd.syncdelay: -1
> hw.snd.usefrags: 0
> hw.snd.vpc_reset: 0
> hw.snd.vpc_0db: 45
> hw.snd.vpc_autoreset: 1
> hw.snd.timeout: 5
> hw.snd.latency_profile: 1
> hw.snd.latency: 5
> hw.snd.report_soft_matrix: 1
> hw.snd.report_soft_formats: 1
> 
> # sysctl dev.pcm
> dev.pcm.2.bitperfect: 0
> dev.pcm.2.buffersize: 65536
> dev.pcm.2.play.vchanformat: s16le:2.0
> dev.pcm.2.play.vchanrate: 48000
> dev.pcm.2.play.vchanmode: passthrough
> dev.pcm.2.play.vchans: 1
> dev.pcm.2.play.32bit: 24
> dev.pcm.2.%parent: hdaa1
> dev.pcm.2.%pnpinfo:
> dev.pcm.2.%location: nid=3
> dev.pcm.2.%driver: pcm
> dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
> dev.pcm.1.bitperfect: 0
> dev.pcm.1.buffersize: 65536
> dev.pcm.1.play.vchanformat: s16le:2.0
> dev.pcm.1.play.vchanrate: 48000
> dev.pcm.1.play.vchanmode: fixed
> dev.pcm.1.play.vchans: 1
> dev.pcm.1.play.32bit: 24
> dev.pcm.1.%parent: hdaa0
> dev.pcm.1.%pnpinfo:
> dev.pcm.1.%location: nid=33
> dev.pcm.1.%driver: pcm
> dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
> dev.pcm.0.bitperfect: 0
> dev.pcm.0.buffersize: 65536
> dev.pcm.0.rec.vchanformat: s16le:2.0
> dev.pcm.0.rec.vchanrate: 48000
> dev.pcm.0.rec.vchanmode: fixed
> dev.pcm.0.rec.vchans: 1
> dev.pcm.0.rec.autosrc: 2
> dev.pcm.0.rec.32bit: 24
> dev.pcm.0.play.vchanformat: s16le:2.0
> dev.pcm.0.play.vchanrate: 48000
> dev.pcm.0.play.vchanmode: fixed
> dev.pcm.0.play.vchans: 2
> dev.pcm.0.play.32bit: 24
> dev.pcm.0.%parent: hdaa0
> dev.pcm.0.%pnpinfo:
> dev.pcm.0.%location: nid=20,18
> dev.pcm.0.%driver: pcm
> dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
> dev.pcm.%parent:
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: devmatch sideeffec: No sound

[Rodney W. Grimes]

> HW: Thinkpad T480 with T3 Dock.
> 
> SW: -current, r338952
> 
> With devmatch enabled in /etc/rc.conf (the default0, snd_uaudio
> gets loaded automatically and finds the audio stuff in the dock,
> which is connected to a screen output(s) I do not use.
> 
> Firefox ends up with /dev/dsp2.0 which goes there, and as a result
> I get no sound through the laptops speakers where I expect it.
> 
> Obvious workaround: Disable devmatch.

I have just the opposite issue on my x230,
as I use external speakers plugged into the audio jack,
and to get them on I have to do a:

sysctl hw.snd.default_unit=1

Or it may need to be:
sysctl hw.snd.default_unit=0

> Yet to be discovered workaround:  Prioritize sound devices, when
> there are multiple.
> 
> This kind of thing may cause some support-work when 12 comes out...
> 

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