Re: mips32 + gcc9 -- still broken

[Adrian Chadd]

So, the big list of unknown symbols was my fault! Whoops.

i've gotten further using gcc-6.4 by fixing some of the warnings/issues
that have crept up.

Here's a review for one of them:

https://reviews.freebsd.org/D26504

However, now I've hit:

/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1:
undefined reference to `__atomic_fetch_sub_8'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1:
undefined reference to `__atomic_load_8'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1:
undefined reference to `__atomic_fetch_add_8'

.. looks like we need some 64 bit atomics now in mips32 for libc++ / devd.



-adrian
___
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: iflib/bridge kernel panic

[Conrad Meyer]

Hi Shawn,

Is it possible to reproduce the issue on FreeBSD?  The excerpt you've
linked to is not on FreeBSD.

Conrad

On Sun, Sep 20, 2020 at 5:53 PM Shawn Webb  wrote:
>
> From latest HEAD on a Dell Precision 7550 laptop:
>
> https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2
>
> The last working boot environment was 14 Aug 2020. If I get some time to
> bisect commits, I'll try to figure out the culprit.
>
> Thanks,
>
> Shawn Webb
>
> (Sorry for the brevity. Only partially working system due to above
> breakage.)
> ___
> 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"

iflib/bridge kernel panic

[Shawn Webb]

>From latest HEAD on a Dell Precision 7550 laptop:

https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2

The last working boot environment was 14 Aug 2020. If I get some time to
bisect commits, I'll try to figure out the culprit.

Thanks,

Shawn Webb

(Sorry for the brevity. Only partially working system due to above
breakage.)
___
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: Plans for git

[Adrian Chadd]

On Sun, 20 Sep 2020 at 15:37, Rick Macklem  wrote:

> Christian Weisgerber wrote:
> > On 2020-09-19, Zaphod Beeblebrox  wrote:
> >
> > > Hrm.  Maybe what I hear others saying, tho, and not entirely being
> replied
> > > to is just a nice concise document of the why.  What I hear you saying
> is
> > > that GIT has momentum and that it's popular... (and I accept that ---
> it is
> > > evidently true), but then I hear handwaving about features, but no
> list of
> > > features that are a clear win/loose.
> >
> > How about the very basics (that Warner appears to have lost sight
> > of)?
> >
> > Git is a distributed version control system.  You clone a repository
> > and apart from pulling and pushing changes to another repository,
> > all your work happens with the local repository.  Subversion has a
> > central repository and needs to talk to the server all the time.
> > Laptop on a plane?  No change of workflow with Git.
> Well, I (mostly lurk) on the linux-...@vger.kernels.org mailing list,
> where the Linux NFS work gets done.
> What I see is the following, when someone has an enhancement/change
> for the Linux NFS code.
> Do I see one diff with all the changes in it...No.
> I see anywhere from a few to over 50 email messages, each with
> one little piece of the pie, out of git.
>
> I have no idea how they review this stuff.
>

It's done in patchwork.kernel.org. This takes the contents of very
specifically correctly formatted git-email contents and wraps up the series
as something that can be assigned to patchwork users for review/feedback.
All of it goes in and out of email.

It's basically using the public Linux email lists as part discussion and
part RPC between everyones' git repositories.

I think this stuff predates github, where there's a much nicer web flow for
doing stuff like this.

The linux model works great in a world where you're /truely/ decentralised.
I bet that 99% of git users use some web frontend that's integrated into CI
and patch review.

HTH,



-adrian
___
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: Plans for git

[Rick Macklem]

Christian Weisgerber wrote:
> On 2020-09-19, Zaphod Beeblebrox  wrote:
> 
> > Hrm.  Maybe what I hear others saying, tho, and not entirely being replied
> > to is just a nice concise document of the why.  What I hear you saying is
> > that GIT has momentum and that it's popular... (and I accept that --- it is
> > evidently true), but then I hear handwaving about features, but no list of
> > features that are a clear win/loose.
>
> How about the very basics (that Warner appears to have lost sight
> of)?
>
> Git is a distributed version control system.  You clone a repository
> and apart from pulling and pushing changes to another repository,
> all your work happens with the local repository.  Subversion has a
> central repository and needs to talk to the server all the time.
> Laptop on a plane?  No change of workflow with Git.
Well, I (mostly lurk) on the linux-...@vger.kernels.org mailing list,
where the Linux NFS work gets done.
What I see is the following, when someone has an enhancement/change
for the Linux NFS code.
Do I see one diff with all the changes in it...No.
I see anywhere from a few to over 50 email messages, each with
one little piece of the pie, out of git.

I have no idea how they review this stuff.
If I were stuck doing it, I'd end up creating an unpatched tree, copying it
and applying all the patches to the copy and then creating a single diff
to look at in phabricator, which does display the changes very nicely.

So, I hope that a transition to git does not encourage "lots of small
loosely related commits" to the FreeBSD repository.

Also, I find svnweb useful, mostly to look at the commits done to a
file in temporal (most recent first) order. The global serial revision
number is very nice, but so long as it is easy to see the temporal
ordering of changes, I can live with that.

> And since it's your repository, you can cheaply create your own
> branches, where you can commit your work and have a versioned history
> of it instead of just a flat diff.  I can't overstate the value of
> that.  Whether you work on something that will be pushed back
> upstream or just your private changes, it has a full commit history.
I, on the other hand, will have no use for this. I can easily keep track of
changes I do by naming file.sav, file.sav2,...
I like to carefully merge changes into the repository checkout after I've
tested them, taking a careful look at the changes as I go.
I find most of the subtle bugs (that wouldn't be detected during normal
testing) during this "code inspection".
--> I think anything that encourages another look at the change before
  commit is a good thing.
  Put another way, slow and careful is better than quick and easy, imho.

I've live with the transition, but to be honest, I know it won't make my
work better or easier, rick

You can easily revert commits, you can upstream it one by one, you
can upstream it with history.

When FreeBSD switched from CVS to SVN, there was hope or promise
of lightweight branches, but that never materialized.  Developers
still can't have private branches in the FreeBSD repository.  For
a while, a lot of development happened in a Perforce repository--a
commerical version control system, whose company had donated a
license--which offered this feature.  Nowadays, everybody who does
any but the most trivial development does so in a private Git
repository anyway.  It only makes sense to interface this directly
with the FreeBSD repository instead of going through a SVN<>Git
media break.

> Certainly the only clear things a quick search turns up that seem relevant
> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
> GCC and the repository is a core function, but I suppose not a necessary
> function for forked projects that can't abide, so...

There is a bit of historical precedent: The original BSD work at
Berkeley was kept in a SCCS repository, a proprietary version control
system at the time.

And of course the fact that significant FreeBSD development has
effectively happened in Perforce, then in Git for a long time and
is just merged back into the Subversion repository.  To put it
bluntly, the people doing the work have voted with their feet years
ago.

--
Christian "naddy" Weisgerber  na...@mips.inka.de
___
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"

mips32 + gcc9 -- still broken

[Adrian Chadd]

hi!

So mips32 and gcc9 is broken, and things have been broken with mips32+gcc
for months now.

I've been poking slowly at the various build failures and they're getting
slowly fixed, but this one deep in linker fun is stumping me:

===

/usr/local/bin/mips-unknown-freebsd13.0-gcc9
--sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp
-B/usr/local/mips-unknown-freebsd13.0/bin/ -O -pipe -fno-common
-DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\"
-DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DDAEMON_UID=1
-DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\"/var/at/\"
-I/usr/home/adrian/work/freebsd/head-embedded/src/usr.bin/at
-I/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun -DLOGIN_CAP
-DPAM -G0 -EB -mabi=32 -msoft-float -march=mips32 -g -std=gnu99
-Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -Wno-pointer-sign -Wno-error=address
-Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare
-Wno-error=cast-align -Wno-error=clobbered
-Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra
-Wno-error=inline -Wno-error=logical-not-parentheses
-Wno-error=strict-aliasing -Wno-error=uninitialized
-Wno-error=unused-but-set-variable -Wno-error=unused-function
-Wno-error=unused-value -Wno-error=empty-body
-Wno-error=maybe-uninitialized -Wno-error=nonnull-compare
-Wno-error=redundant-decls -Wno-error=shift-negative-value
-Wno-error=tautological-compare -Wno-error=unused-const-variable
-Wno-error=bool-operation -Wno-error=deprecated
-Wno-error=expansion-to-defined -Wno-error=format-overflow
-Wno-error=format-truncation -Wno-error=implicit-fallthrough
-Wno-error=int-in-bool-context -Wno-error=memset-elt-size
-Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare
-Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations
-Wno-error=cast-function-type -Wno-error=catch-value
-Wno-error=multistatement-macros -Wno-error=restrict
-Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation
-Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member
 -EB -mabi=32   -o atrun.full atrun.o gloadavg.o   -lpam  -lutil
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/crt1.o:
in function `__start':
/usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76:
undefined reference to `_init_tls'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/lib/csu/mips/crt1_c.c:76:
undefined reference to `_init_tls'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perr':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417:
undefined reference to `vsyslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:417:
undefined reference to `vsyslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `perrx':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433:
undefined reference to `vsyslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:433:
undefined reference to `vsyslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `run_file':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348:
undefined reference to `waitpid'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:348:
undefined reference to `waitpid'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478:
undefined reference to `openlog'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:478:
undefined reference to `openlog'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `usage':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590:
undefined reference to `syslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:590:
undefined reference to `syslog'
/usr/local/bin/mips-unknown-freebsd13.0-ld: atrun.o: in function `main':
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532:
undefined reference to `time'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:532:
undefined reference to `time'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec/atrun/atrun.c:510:
undefined reference to `sysctlbyname'
/usr/local/bin/mips-unknown-freebsd13.0-ld:
/usr/home/adrian/work/freebsd/head-embedded/src/libexec

Re: objcopy "text file busy" build failure with populated /usr/obj

[Michael Butler]

On 9/20/20 10:58 AM, Mark Murray wrote:

Hi *

I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin 
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then 
the build works, but takes a few hours. If I do a no-clean build with /obj/obj populated with he 
contents of a previous build, and /usr/src with updated ("svn update") sources, then the 
below nearly always happens early in the rebuild. It is in "stage 4.4: building 
everything" that this happens. The build is parallel (-j8), and I have manually de-threaded 
the output.

The generated command-line from the logfile is:

cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm 
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/

legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  
SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all


Anyone else seeing this?

objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1

make[4]: stopped in /usr/src/usr.bin/objcopy


Yes, although simply restarting the build seems to avoid the problem on 
the second attempt.


However, I'm building on a dual quad-core amd64 platform (8 cores total) 
so it's not just ARM being affected,


imb


___
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 commit: r364936 - in head: lib lib/libnetmap share/mk

[Adrian Chadd]

hi!

This code fails compilation on mips32 + gcc, as it assumes uint64_t and
pointer casts are the same underlying size.

===

/usr/local/bin/mips-unknown-freebsd13.0-gcc9
--sysroot=/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp
-B/usr/local/mips-unknown-freebsd13.0/bin/  -O -pipe -fno-common -G0 -EB
-mabi=32 -msoft-float -march=mips32
 -I/usr/home/adrian/work/freebsd/head-embedded/src/sys/net
-I/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap -g -MD
 -MF.depend.nmport.o -MTnmport.o -std=gnu99 -Wno-format-zero-length
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds
-Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align
-Wno-error=clobbered -Wno-error=deprecated-declarations
-Wno-error=enum-compare -Wno-error=extra -Wno-error=inline
-Wno-error=logical-not-parentheses -Wno-error=strict-aliasing
-Wno-error=uninitialized -Wno-error=unused-but-set-variable
-Wno-error=unused-function -Wno-error=unused-value -Wno-error=empty-body
-Wno-error=maybe-uninitialized -Wno-error=nonnull-compare
-Wno-error=redundant-decls -Wno-error=shift-negative-value
-Wno-error=tautological-compare -Wno-error=unused-const-variable
-Wno-error=bool-operation -Wno-error=deprecated
-Wno-error=expansion-to-defined -Wno-error=format-overflow
-Wno-error=format-truncation -Wno-error=implicit-fallthrough
-Wno-error=int-in-bool-context -Wno-error=memset-elt-size
-Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare
-Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations
-Wno-error=cast-function-type -Wno-error=catch-value
-Wno-error=multistatement-macros -Wno-error=restrict
-Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation
-Wno-error=empty-body -Wno-error=overflow -Wno-address-of-packed-member
 -c /usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c
-o nmport.o
In file included from
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:46:
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In
function 'nmport_register':
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:557:14:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
  557 |  for ((o_) = (struct nmreq_option *)((h_)->nr_options);\
  |  ^
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3:
note: in expansion of macro 'nmreq_foreach_option'
  547 |   nmreq_foreach_option(&d->hdr, o) {
  |   ^~~~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/libnetmap.h:559:14:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
  559 |   (o_) = (struct nmreq_option *)((o_)->nro_next))
  |  ^
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:547:3:
note: in expansion of macro 'nmreq_foreach_option'
  547 |   nmreq_foreach_option(&d->hdr, o) {
  |   ^~~~
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c: In
function 'nmport_mmap':
/usr/home/adrian/work/freebsd/head-embedded/src/lib/libnetmap/nmport.c:617:13:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
  617 |m->mem = (void *)d->extmem->nro_usrptr;
  | ^
cc1: all warnings being treated as errors
*** [nmport.o] Error code 1

===


Are you able to fix this? pretty please? :)



-adrian


On Fri, 28 Aug 2020 at 13:04, Vincenzo Maffione 
wrote:

> Author: vmaffione
> Date: Fri Aug 28 20:03:54 2020
> New Revision: 364936
> URL: https://svnweb.freebsd.org/changeset/base/364936
>
> Log:
>   lib: add libnetmap
>
>   This changeset introduces the new libnetmap library for writing
>   netmap applications.
>   Before libnetmap, applications could either use the kernel API
>   directly (e.g. NIOCREGIF/NIOCCTRL) or the simple header-only-library
>   netmap_user.h (e.g. nm_open(), nm_close(), nm_mmap() etc.)
>
>   The new library offers more functionalities than netmap_user.h:
> - Support for complex netmap options, such as external memory
>   allocators or per-buffer offsets. This opens the way to future
>   extensions.
> - More flexibility in the netmap port bind options, such as
>   non-numeric names for pipes, or the ability to specify the netmap
>   allocator that must be used for a given port.
> - Automatic tracking of the netmap memory regions in use across the
>   open ports.
>
>   At the moment there is no man page, but the libnetmap.h header file
>   has in-depth documentation.
>
>   Reviewed by:  hrs
>   MFC after:2 weeks
>   Differential Revision:https://reviews.freebsd.org/D26171
>
> Added:
>   head/lib/libnetmap/
>   head/lib/libnetmap/Makefile   (contents, props changed)
>   head/lib/libnetmap/libnetmap.h   (contents, props changed)
>   

Re: Plans for git

[Russell L. Carter]

On 2020-09-20 12:28, Andriy Gapon wrote:
> Just my +100500 to this.
>
> On 20/09/2020 18:03, Christian Weisgerber wrote:
>> On 2020-09-19, Zaphod Beeblebrox  wrote:
>>
>>> Hrm.  Maybe what I hear others saying, tho, and not entirely being 
replied
>>> to is just a nice concise document of the why.  What I hear you 
saying is
>>> that GIT has momentum and that it's popular... (and I accept that 
--- it is
>>> evidently true), but then I hear handwaving about features, but no 
list of

>>> features that are a clear win/loose.
>>
>> How about the very basics (that Warner appears to have lost sight
>> of)?
>>
>> Git is a distributed version control system.  You clone a repository
>> and apart from pulling and pushing changes to another repository,
>> all your work happens with the local repository.  Subversion has a
>> central repository and needs to talk to the server all the time.
>> Laptop on a plane?  No change of workflow with Git.
>>
>> And since it's your repository, you can cheaply create your own
>> branches, where you can commit your work and have a versioned history
>> of it instead of just a flat diff.  I can't overstate the value of
>> that.  Whether you work on something that will be pushed back
>> upstream or just your private changes, it has a full commit history.
>> You can easily revert commits, you can upstream it one by one, you
>> can upstream it with history.

Back in 2009 I had my small dev group using git-svn to allow us all to
work remotely with at least *some* flexibility against the $JOB svn
repo.  The svn interactive response was dreadful over our DSL
connections.  I flew to SF to the $JOB hq and purposely made a few
offline commits on the plane.  Then at the office I merged them,
trivially.  None of the devs there had any experience with git.  It
blew their minds.  (obvs any other DVCS can do that too)

git can seem to have bottomless command line complexity from the point
of view of a casual user.  I look at the answers to edge case problems
posted on SO and just laugh.  People have careers being git
specialists.  However you don't need to know much to get very
productive.  And if you use emacs, there is no debate that magit is a
stellar interface to git, maybe the very best.  I believe I've heard
noises about its functionality being replicated into vim.  Once you
use something like magit even complex operations have very little
cognitive overhead.  For example, picking the exact changes you want
to commit together from an already coded larger set of changes is
easy.  I'm always fixing eg. doc nits when I see them, when working on
code/bugs and then later group those into their own commit.  Maybe you
can do that now in svn but it is a pleasure with magit.

just my 2¢

Russell

>>
>> When FreeBSD switched from CVS to SVN, there was hope or promise
>> of lightweight branches, but that never materialized.  Developers
>> still can't have private branches in the FreeBSD repository.  For
>> a while, a lot of development happened in a Perforce repository--a
>> commerical version control system, whose company had donated a
>> license--which offered this feature.  Nowadays, everybody who does
>> any but the most trivial development does so in a private Git
>> repository anyway.  It only makes sense to interface this directly
>> with the FreeBSD repository instead of going through a SVN<>Git
>> media break.
>>
>>> Certainly the only clear things a quick search turns up that seem 
relevant
>>> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for 
LLVM vs
>>> GCC and the repository is a core function, but I suppose not a 
necessary

>>> function for forked projects that can't abide, so...
>>
>> There is a bit of historical precedent: The original BSD work at
>> Berkeley was kept in a SCCS repository, a proprietary version control
>> system at the time.
>>
>> And of course the fact that significant FreeBSD development has
>> effectively happened in Perforce, then in Git for a long time and
>> is just merged back into the Subversion repository.  To put it
>> bluntly, the people doing the work have voted with their feet years
>> ago.
>>
>
>


___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 20.09.20 22:07, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
 On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>> Hi monochrome,
>>>
>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>> with newest sources the error occurs.
>>>
>>> After looking around somewhat more, I found some hints about Virtualbox
>>> kernel module having problems with r365488. Unfortunately, I am not able
>>> to find the thread again :(
>>>
>>> What seems to help as a workaround is to disable the loading of
>>> VirtualBox in /boot/loader.conf
>>>
>>> #vboxdrv_load="YES"
>>>
>>> and in /etc/rc.conf
>>>
>>> #vboxnet_enable="YES"
>>> #vboxguest_enable="YES"
>>>
>>>
>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>
>>
>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>> version was not bumped correctly.
>>
>> --HPS
>>
>
> Thanks for the hint. But I did rebuild all kernel modules before
> rebooting, in my case vbox*.ko, nvidia*.ko.

 Provide backtrace of the panic.

>>>
>>> Hi Konstantin,
>>>
>>> Thanks for your response.
>>>
>>> After trying several ways to produce a core dump or a working kdb prompt
>>> without success, all I can offer is the following screen contents. I
>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
>>> via /boot/loader.conf and /etc/rc.conf as described above:
>>>
>>>
>>> [..snip..]
>>> procfs registered
>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
>>> 0x82520a70) error 17
>>> Timecounters tick every 1.000 msec
>>> lo0: bpf attached
>>> vlan: initialized, using hash tables with chaining
>>>
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x0
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80ea889b
>>> stack pointer   = 0x20:0x826017e0
>>> frame pointer   = 0x20:0x826017e0
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 0 (swapper)
>>> trap number = 12
>>> panic: page fault
>>> cpuid = 31
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0x82601490
>>> vpanic() at vpanic+0x182/frame 0x826014e0
>>> panic() at panic+0x43/frame 0x82601540
>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600
>>> calltrap() at calltrap+0x8/frame 0x82601710
>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
>>> 0x826017e0 ---
>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
>>> vm_fault() at vm_fault+0x5d6/frame 0x82601940
>>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
>>> vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
>>> rtR0MemObjFreeBSDAllocHelper() at
>>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>> 0x82601ac0
>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
>>> 0x82601bf0
>>> module_register_init() at module_register_init+0xbd/frame 0x82601c20
>>> mi_startup() at mi_startup+0xec/frame 0x82601c70
>>> btext() at btext+0x2c
>>> KDB: enter: panic
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
>>> db>
>>>
>>>
>>> The system freezes at this point, no core dump is generated ;)  This
>>> does not happen without loading VBoxDrv.
>>>
>>> At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
>>> this is of some help.
>>>
>> Yes it seems to be enough for me to see where the possible issue is.
>> Try this patch, I did not even compiled it.  Probably you need to put
>> it into ports/emulators/virtualbox-ose-kmod/files with the name ending
>> with .patch.
> This seems to be wrong, name should _start_ with the prefix 'patch-'.

Many thanks for the patch!

Putting it into emulators/virtualbox-ose-kmod/files/ as
patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Konstantin Belousov]

On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
> > Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> > >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> > >>> On 2020-09-20 10:05, Rainer Hurling wrote:
> >  Hi monochrome,
> > 
> >  back to keyboard, it tried newest CURRENT (r365920) on my box and even
> >  with newest sources the error occurs.
> > 
> >  After looking around somewhat more, I found some hints about Virtualbox
> >  kernel module having problems with r365488. Unfortunately, I am not 
> >  able
> >  to find the thread again :(
> > 
> >  What seems to help as a workaround is to disable the loading of
> >  VirtualBox in /boot/loader.conf
> > 
> >  #vboxdrv_load="YES"
> > 
> >  and in /etc/rc.conf
> > 
> >  #vboxnet_enable="YES"
> >  #vboxguest_enable="YES"
> > 
> > 
> >  So probably, this page fault is not restricted to AMD Ryzen?
> > 
> > >>>
> > >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> > >>> version was not bumped correctly.
> > >>>
> > >>> --HPS
> > >>>
> > >>
> > >> Thanks for the hint. But I did rebuild all kernel modules before
> > >> rebooting, in my case vbox*.ko, nvidia*.ko.
> > > 
> > > Provide backtrace of the panic.
> > > 
> > 
> > Hi Konstantin,
> > 
> > Thanks for your response.
> > 
> > After trying several ways to produce a core dump or a working kdb prompt
> > without success, all I can offer is the following screen contents. I
> > built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
> > via /boot/loader.conf and /etc/rc.conf as described above:
> > 
> > 
> > [..snip..]
> > procfs registered
> > modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
> > 0x82520a70) error 17
> > Timecounters tick every 1.000 msec
> > lo0: bpf attached
> > vlan: initialized, using hash tables with chaining
> > 
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 31; apic id = 1f
> > fault virtual address   = 0x0
> > fault code  = supervisor read data, page not present
> > instruction pointer = 0x20:0x80ea889b
> > stack pointer   = 0x20:0x826017e0
> > frame pointer   = 0x20:0x826017e0
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 0 (swapper)
> > trap number = 12
> > panic: page fault
> > cpuid = 31
> > time = 1
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0x82601490
> > vpanic() at vpanic+0x182/frame 0x826014e0
> > panic() at panic+0x43/frame 0x82601540
> > trap_fatal() at trap_fatal+0x387/frame 0x826015a0
> > trap_pfault() at trap_pfault+0x97/frame 0x82601600
> > calltrap() at calltrap+0x8/frame 0x82601710
> > --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
> > 0x826017e0 ---
> > phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
> > vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
> > vm_fault() at vm_fault+0x5d6/frame 0x82601940
> > vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
> > vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
> > rtR0MemObjFreeBSDAllocHelper() at
> > rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
> > rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
> > 0x82601ac0
> > supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
> > supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
> > VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
> > 0x82601bf0
> > module_register_init() at module_register_init+0xbd/frame 0x82601c20
> > mi_startup() at mi_startup+0xec/frame 0x82601c70
> > btext() at btext+0x2c
> > KDB: enter: panic
> > [ thread pid 0 tid 10 ]
> > Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
> > db>
> > 
> > 
> > The system freezes at this point, no core dump is generated ;)  This
> > does not happen without loading VBoxDrv.
> > 
> > At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
> > this is of some help.
> > 
> Yes it seems to be enough for me to see where the possible issue is.
> Try this patch, I did not even compiled it.  Probably you need to put
> it into ports/emulators/virtualbox-ose-kmod/files with the name ending
> with .patch.
This seems to be wrong, name should _start_ with the prefix 'patch-'.
> 
> --- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx 2020-09-20 
> 19:40:07.471956776 +
> +++ src/VBox/Runtime/r

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Konstantin Belousov]

On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> >>> On 2020-09-20 10:05, Rainer Hurling wrote:
>  Hi monochrome,
> 
>  back to keyboard, it tried newest CURRENT (r365920) on my box and even
>  with newest sources the error occurs.
> 
>  After looking around somewhat more, I found some hints about Virtualbox
>  kernel module having problems with r365488. Unfortunately, I am not able
>  to find the thread again :(
> 
>  What seems to help as a workaround is to disable the loading of
>  VirtualBox in /boot/loader.conf
> 
>  #vboxdrv_load="YES"
> 
>  and in /etc/rc.conf
> 
>  #vboxnet_enable="YES"
>  #vboxguest_enable="YES"
> 
> 
>  So probably, this page fault is not restricted to AMD Ryzen?
> 
> >>>
> >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> >>> version was not bumped correctly.
> >>>
> >>> --HPS
> >>>
> >>
> >> Thanks for the hint. But I did rebuild all kernel modules before
> >> rebooting, in my case vbox*.ko, nvidia*.ko.
> > 
> > Provide backtrace of the panic.
> > 
> 
> Hi Konstantin,
> 
> Thanks for your response.
> 
> After trying several ways to produce a core dump or a working kdb prompt
> without success, all I can offer is the following screen contents. I
> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
> via /boot/loader.conf and /etc/rc.conf as described above:
> 
> 
> [..snip..]
> procfs registered
> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
> 0x82520a70) error 17
> Timecounters tick every 1.000 msec
> lo0: bpf attached
> vlan: initialized, using hash tables with chaining
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 31; apic id = 1f
> fault virtual address   = 0x0
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80ea889b
> stack pointer   = 0x20:0x826017e0
> frame pointer   = 0x20:0x826017e0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 0 (swapper)
> trap number = 12
> panic: page fault
> cpuid = 31
> time = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0x82601490
> vpanic() at vpanic+0x182/frame 0x826014e0
> panic() at panic+0x43/frame 0x82601540
> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
> trap_pfault() at trap_pfault+0x97/frame 0x82601600
> calltrap() at calltrap+0x8/frame 0x82601710
> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
> 0x826017e0 ---
> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
> vm_fault() at vm_fault+0x5d6/frame 0x82601940
> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
> vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
> rtR0MemObjFreeBSDAllocHelper() at
> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
> 0x82601ac0
> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
> 0x82601bf0
> module_register_init() at module_register_init+0xbd/frame 0x82601c20
> mi_startup() at mi_startup+0xec/frame 0x82601c70
> btext() at btext+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
> db>
> 
> 
> The system freezes at this point, no core dump is generated ;)  This
> does not happen without loading VBoxDrv.
> 
> At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
> this is of some help.
> 
Yes it seems to be enough for me to see where the possible issue is.
Try this patch, I did not even compiled it.  Probably you need to put
it into ports/emulators/virtualbox-ose-kmod/files with the name ending
with .patch.

--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.xxx   2020-09-20 
19:40:07.471956776 +
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c   2020-09-20 
19:46:03.606966773 +
@@ -323,7 +323,8 @@
 size_t  cPages = atop(pMemFreeBSD->Core.cb);
 int rc;
 
-pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages);
+pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
+  pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
 
 /* No a

Re: Plans for git

[Andriy Gapon]

Just my +100500 to this.

On 20/09/2020 18:03, Christian Weisgerber wrote:
> On 2020-09-19, Zaphod Beeblebrox  wrote:
> 
>> Hrm.  Maybe what I hear others saying, tho, and not entirely being replied
>> to is just a nice concise document of the why.  What I hear you saying is
>> that GIT has momentum and that it's popular... (and I accept that --- it is
>> evidently true), but then I hear handwaving about features, but no list of
>> features that are a clear win/loose.
> 
> How about the very basics (that Warner appears to have lost sight
> of)?
> 
> Git is a distributed version control system.  You clone a repository
> and apart from pulling and pushing changes to another repository,
> all your work happens with the local repository.  Subversion has a
> central repository and needs to talk to the server all the time.
> Laptop on a plane?  No change of workflow with Git.
> 
> And since it's your repository, you can cheaply create your own
> branches, where you can commit your work and have a versioned history
> of it instead of just a flat diff.  I can't overstate the value of
> that.  Whether you work on something that will be pushed back
> upstream or just your private changes, it has a full commit history.
> You can easily revert commits, you can upstream it one by one, you
> can upstream it with history.
> 
> When FreeBSD switched from CVS to SVN, there was hope or promise
> of lightweight branches, but that never materialized.  Developers
> still can't have private branches in the FreeBSD repository.  For
> a while, a lot of development happened in a Perforce repository--a
> commerical version control system, whose company had donated a
> license--which offered this feature.  Nowadays, everybody who does
> any but the most trivial development does so in a private Git
> repository anyway.  It only makes sense to interface this directly
> with the FreeBSD repository instead of going through a SVN<>Git
> media break.
> 
>> Certainly the only clear things a quick search turns up that seem relevant
>> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
>> GCC and the repository is a core function, but I suppose not a necessary
>> function for forked projects that can't abide, so...
> 
> There is a bit of historical precedent: The original BSD work at
> Berkeley was kept in a SCCS repository, a proprietary version control
> system at the time.
> 
> And of course the fact that significant FreeBSD development has
> effectively happened in Perforce, then in Git for a long time and
> is just merged back into the Subversion repository.  To put it
> bluntly, the people doing the work have voted with their feet years
> ago.
> 


-- 
Andriy Gapon
___
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: Plans for git

[Lev Serebryakov]

On 19.09.2020 19:05, Bakul Shah wrote:

>> These are the main ones. The three down sides are lack of $FreeBSD$ support
>> and tags in general.
> 
> Can a git hook be used for this?

git filters could be used for that, problem is it should be local 
configuration. You could not configure filters in clones automatically :-(


-- 
// Lev Serebryakov
___
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"

bin/cp/utils.c:517:14: error: member reference base type 'void' is not a structure or union (RESCUE)

[Hartmann, O.]

A couple of weeks for now it is impossible to compile nanoBSD (based on
12-STABLE, most recent r365925), compiled on a host running recent
CURRENT (FreeBSD 13.0-CURRENT #0 r365487: Fri Sep 18 16:31:04 CEST 2020
amd64). Since the introduction of LLVM 10 to 12-STABLE and LLVM 11 to
CURRENT, the (cross) compilation of nanoBSD fails on the building host
with the error shown below. Although option "WITHOUT_RESCU" is set when
either building or building/installing the sources, the shown error
popps up.

The curious thing is, that I also build 12-STABLE jails on the same
CURRENT system the "tradiotional way" (means: building the 12-STABLE
and then installing the jail via ezjail-admin without interaction of
any foreign/network sources except the source repository. No error of
the shown kind ever occurs.

Can someon please explain this problem? It looks like a bug in a make
file.

Regards,

Oliver

[...]
cc -target x86_64-unknown-freebsd12.2
--sysroot=/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd64.amd64/tmp
-B/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd64.amd64/tmp/usr/bin
-pg  -O2 -pipe -O3 -pipe -fno-common
-I/pool/sources/12-STABLE/src/lib/msun/x86
-I/pool/sources/12-STABLE/src/lib/msun/ld80
-I/pool/sources/12-STABLE/src/lib/msun/amd64
-I/pool/sources/12-STABLE/src/lib/msun/src
-I/pool/sources/12-STABLE/src/lib/libc/include
-I/pool/sources/12-STABLE/src/lib/libc/amd64   -DNDEBUG -mretpoline -MD
 -MF.depend.e_j1f.po -MTe_j1f.po -std=gnu99 -fstack-protector-strong
-Wsystem-headers -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c
/pool/sources/12-STABLE/src/lib/msun/src/e_j1f.c -o e_j1f.po ---
all_subdir_rescue ---
/pool/sources/12-STABLE/src/bin/cp/utils.c:517:14: error: member
reference base type 'void' is not a structure or union aclp =
&acl->ats_acl; ~~~^ ~~~
/pool/sources/12-STABLE/src/bin/cp/utils.c:518:11: error: incomplete
definition of type 'struct acl' if (aclp->acl_cnt != 0 &&
aclsetf(dest_dir, ^
/pool/sources/12-STABLE/src/bin/cp/utils.c:468:9: note: forward
declaration of 'struct acl' struct acl *aclp; ^ 2 errors generated. ***
[/pool/sources/12-STABLE/src/bin/cp/utils.o] Error code 1

make[6]: stopped in
/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd64.amd64/rescue/rescue
1 error

make[6]: stopped in
/pool/nanobsd/amd64/ALERICH_12-STABLE_amd64/pool/sources/12-STABLE/src/amd64.amd64/rescue/rescue
*** [rescue] Error code 2

make[5]: stopped in /pool/sources/12-STABLE/src/rescue/rescue
1 error

make[5]: stopped in /pool/sources/12-STABLE/src/rescue/rescue


pgpuXTAGP6uKp.pgp
Description: OpenPGP digital signature

Re: Plans for git

[Warner Losh]

On Sun, Sep 20, 2020 at 9:41 AM Pete Wright  wrote:

>
> >> making quarterly reports about this for almost a years as well. We put
> out
> >> calls for people to help with the efforts about the same time. We have
> >> tried at every step of the way to be open and honest that this was
> going to
> >> happen.
> > All developer centric communications
>
> I would argue that quarterly reports are actually one of the few methods
> of getting accurate information about the state of the project as a
> non-insider.  i've been following the progress of this work via the
> quarterly status reports for years now, and as someone who is merely a
> freebsd operator felt like i was more or less kept up to date on this
> eventuality.
>

Plus the git list also gave status updates and it was public and mentioned
in the reports.


> honestly there has to be *some* responsibility of operators to at least
> make an effort to keep up to date on the status of the various efforts
> in such a large project.  and as an outsider the idea that comms can
> only happen on the mailing list isn't the greatest - how am i to know
> that the idea of one person on the ML carries more weight than another,
> or one persons opinion is the "official" stated opinion of the core group?
>

And to be honest, we'd planned on a final PR push once we had a confirmed
date with enough lead time for people to adjust.

Be all that as it may, I've finished up the first of a series of videos.
This one talks about the fundamental differences between the two in 4
minutes. Future videos will delve into details of how it affects different
segments of our community: users, developers, integrators, etc.
https://youtu.be/Lx9lKr_M-DI if you want to take a look. The next one will
be one on why (though it largely rehashes this thread and the blog post I
made, again in about 4 minutes).

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"

Re: Plans for git

[Steve Kargl]

On Sun, Sep 20, 2020 at 08:41:13AM -0700, Pete Wright wrote:
> 
> > > making quarterly reports about this for almost a years as well. We put out
> > > calls for people to help with the efforts about the same time. We have
> > > tried at every step of the way to be open and honest that this was going 
> > > to
> > > happen.
> > All developer centric communications
> 
> I would argue that quarterly reports are actually one of the few methods of
> getting accurate information about the state of the project as a
> non-insider.  i've been following the progress of this work via the
> quarterly status reports for years now, and as someone who is merely a
> freebsd operator felt like i was more or less kept up to date on this
> eventuality.
> 
> honestly there has to be *some* responsibility of operators to at least make
> an effort to keep up to date on the status of the various efforts in such a
> large project.  and as an outsider the idea that comms can only happen on
> the mailing list isn't the greatest - how am i to know that the idea of one
> person on the ML carries more weight than another, or one persons opinion is
> the "official" stated opinion of the core group?
> 

Traditionally, this has been done through the freebsd-hackers and
freebsd-current mailing lists.  Admittedly, the freebsd-current
mailing list has never recovered from the jenkins debacle.  Making
an announcement or seeking input about a conversion from subversion
to git on the freebsd-git mailing list is self-fulfilling.  People
interested in git on FreeBSD will subscribe to that list.  People
not interested in git, oh well, they'll find out eventually.

Of course, not seeking input on the mailing lists avoids the
inevitable bikeshed.  A discussion about a conversion from
subversion to git would devolve rather quickly.

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

Re: Plans for git

[Pete Wright]

making quarterly reports about this for almost a years as well. We put out
calls for people to help with the efforts about the same time. We have
tried at every step of the way to be open and honest that this was going to
happen.

All developer centric communications


I would argue that quarterly reports are actually one of the few methods 
of getting accurate information about the state of the project as a 
non-insider.  i've been following the progress of this work via the 
quarterly status reports for years now, and as someone who is merely a 
freebsd operator felt like i was more or less kept up to date on this 
eventuality.



honestly there has to be *some* responsibility of operators to at least 
make an effort to keep up to date on the status of the various efforts 
in such a large project.  and as an outsider the idea that comms can 
only happen on the mailing list isn't the greatest - how am i to know 
that the idea of one person on the ML carries more weight than another, 
or one persons opinion is the "official" stated opinion of the core group?



-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: Plans for git

[Christian Weisgerber]

On 2020-09-19, Zaphod Beeblebrox  wrote:

> Hrm.  Maybe what I hear others saying, tho, and not entirely being replied
> to is just a nice concise document of the why.  What I hear you saying is
> that GIT has momentum and that it's popular... (and I accept that --- it is
> evidently true), but then I hear handwaving about features, but no list of
> features that are a clear win/loose.

How about the very basics (that Warner appears to have lost sight
of)?

Git is a distributed version control system.  You clone a repository
and apart from pulling and pushing changes to another repository,
all your work happens with the local repository.  Subversion has a
central repository and needs to talk to the server all the time.
Laptop on a plane?  No change of workflow with Git.

And since it's your repository, you can cheaply create your own
branches, where you can commit your work and have a versioned history
of it instead of just a flat diff.  I can't overstate the value of
that.  Whether you work on something that will be pushed back
upstream or just your private changes, it has a full commit history.
You can easily revert commits, you can upstream it one by one, you
can upstream it with history.

When FreeBSD switched from CVS to SVN, there was hope or promise
of lightweight branches, but that never materialized.  Developers
still can't have private branches in the FreeBSD repository.  For
a while, a lot of development happened in a Perforce repository--a
commerical version control system, whose company had donated a
license--which offered this feature.  Nowadays, everybody who does
any but the most trivial development does so in a private Git
repository anyway.  It only makes sense to interface this directly
with the FreeBSD repository instead of going through a SVN<>Git
media break.

> Certainly the only clear things a quick search turns up that seem relevant
> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
> GCC and the repository is a core function, but I suppose not a necessary
> function for forked projects that can't abide, so...

There is a bit of historical precedent: The original BSD work at
Berkeley was kept in a SCCS repository, a proprietary version control
system at the time.

And of course the fact that significant FreeBSD development has
effectively happened in Perforce, then in Git for a long time and
is just merged back into the Subversion repository.  To put it
bluntly, the people doing the work have voted with their feet years
ago.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
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"

objcopy "text file busy" build failure with populated /usr/obj

[Mark Murray]

Hi *

I've been getting these build failures for a while (weeks/months). The machine 
is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and zfs 
filesystem. If I empty out /usr/obj, then the build works, but takes a few 
hours. If I do a no-clean build with /obj/obj populated with he contents of a 
previous build, and /usr/src with updated ("svn update") sources, then the 
below nearly always happens early in the rebuild. It is in "stage 4.4: building 
everything" that this happens. The build is parallel (-j8), and I have manually 
de-threaded the output.

The generated command-line from the logfile is:

cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  
CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target 
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target 
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" 
LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" 
STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
  SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all

Anyone else seeing this?

objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1

make[4]: stopped in /usr/src/usr.bin/objcopy

M
--




signature.asc
Description: Message signed with OpenPGP

Re: Plans for git

[Rodney W. Grimes]

> On Sat, Sep 19, 2020, 2:44 PM Lucas Nali de Magalh?es 
> wrote:
> 
> > Just My 2??
> >
> > On Sep 3, 2020, at 5:19 PM, Warner Losh  wrote:
> >
> > ?On Thu, Sep 3, 2020 at 1:32 PM Chris  wrote:
> >
> > On 2020-09-03 11:33, Kristof Provost wrote:
> >
> > On 3 Sep 2020, at 19:56, Chris wrote:
> >
> > Why was the intention to switch NOT announced as such MUCH sooner?
> >
> >
> > There was discussion about a possible switch to git on the freebsd-git
> >
> > mailing
> >
> > list as early as February 2017:
> >
> >
> > https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html
> >
> >
> > Ed gave a talk about FreeBSD and git back in 2018:
> >
> > https://www.youtube.com/watch?v=G8wQ88d85s4
> >
> >
> > The Git Transition Working group was mentioned in the quarterly status
> >
> > reports a
> >
> > year ago:
> >
> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html
> >
> > and
> >
> > https://www.freebsd.org/news/status/report-2019-04-2019-06.html
> >
> > It appears to me that the references you make here all allude to
> >
> > _investigation_
> >
> > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_.
> >
> > IMHO a change as significant as this, which will require tossing years of
> >
> > tooling
> >
> > out the window, and an untold amount of _re_tooling. Should have created an
> >
> > announcement at _least_ as significant as a new release gets on the mailing
> >
> > lists.
> >
> >
> >
> > Yes. We've been working on this for years. We've been working on the
> > retooling in earnest for the last 6 months. We didn't make an announcement
> > because we wanted to have most of the pieces in place before we did that.
> > We've been doing the multi-year process for multiple years now. I'll also
> > point out that only the 'git' people showed. A number of other ideas were
> > suggested, but nothing else was stood up in a serious way (hg came the
> > closest to setting up an exporter). Since there was really no alternatives
> > being proposed to git, the process was less visible than if we'd had to
> > have had a hg vs git bake off. One step has lead to the next, with much
> > status reporting done for years.
> >
> > Subversion, btw, is not viable in the long run. The Apache foundation has
> > moved all its projects from svn to git. The velocity of features with svn
> > has diminished, and the number of CI/CT/etc tool sets that supported svn
> > well has been dropping over time. It's also been identified as a barrier to
> > entry for the project. Sure, some people climb the learning curve to learn
> > and understand it, but our survey data has shown that for every one that
> > did take the time, many others did not and simply didn't contribute.
> >
> > All of these issues have been discussed at length at conferences for the
> > last 5 years at least, with increasing levels of sophistication. Had there
> > been a BSDcan this year, I'd hoped to do a talk / BOF on this to help
> > socialize the ideas and to get people's feedback in real time (rather than
> > the slow and difficult process of getting it just in email).
> >
> > We've also talked about this in the BSD office hours and core election
> > forums over the past year.
> >
> > We've been rolling out the beta git repo now for 3 months. People have
> > found issues and we've been correcting them. We've heard from people that
> > their automated tooling needs a bit of transition time, so we'll be
> > exporting the stable/11 and stable/12 branches back into subversion (and
> > the release branches) after the conversion for the life of those
> > branches, though we don't plan on doing it for the current nor stable/13
> > branches (due to the inefficiencies of git-svn, we need separate trees for
> > each, and each tree takes over a day to setup). We know we need some better
> > docs (we have some decent preliminary ones, but there's some missing bits
> > in them, and they are too long for more casual users). We need to spell out
> > different commit policies, how we're going to have to shift our "MFC"
> > terminology because that's very CVS/SVN centric (in git a merge means a
> > more specific thing than it does in svn. A cherry-pick in git is also
> > called a merge in svn, for example). We need to document to the developers
> > how to make the shift (this doc is mostly complete and was posted earlier,
> > though it could use some TLC). We'd hoped to have the documents done, the
> > policies written and vetted and have a good test system before making an
> > announcement. The last thing I wanted was to make a big announcement, only
> > to fail to deliver. And since each step of the process followed naturally,
> > there wasn't a clear A/B decision point where an announcement could have
> > been generated. We were getting close to publishing the final schedule when
> > this thread popped up, though, since it is finally feeling like it will be
> > real soon. I also had hoped to refine things so that existing developers
> > and u

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>> On 2020-09-20 10:05, Rainer Hurling wrote:
 Hi monochrome,

 back to keyboard, it tried newest CURRENT (r365920) on my box and even
 with newest sources the error occurs.

 After looking around somewhat more, I found some hints about Virtualbox
 kernel module having problems with r365488. Unfortunately, I am not able
 to find the thread again :(

 What seems to help as a workaround is to disable the loading of
 VirtualBox in /boot/loader.conf

 #vboxdrv_load="YES"

 and in /etc/rc.conf

 #vboxnet_enable="YES"
 #vboxguest_enable="YES"


 So probably, this page fault is not restricted to AMD Ryzen?

>>>
>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>> version was not bumped correctly.
>>>
>>> --HPS
>>>
>>
>> Thanks for the hint. But I did rebuild all kernel modules before
>> rebooting, in my case vbox*.ko, nvidia*.ko.
> 
> Provide backtrace of the panic.
> 

Hi Konstantin,

Thanks for your response.

After trying several ways to produce a core dump or a working kdb prompt
without success, all I can offer is the following screen contents. I
built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
via /boot/loader.conf and /etc/rc.conf as described above:


[..snip..]
procfs registered
modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
0x82520a70) error 17
Timecounters tick every 1.000 msec
lo0: bpf attached
vlan: initialized, using hash tables with chaining


Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ea889b
stack pointer   = 0x20:0x826017e0
frame pointer   = 0x20:0x826017e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x82601490
vpanic() at vpanic+0x182/frame 0x826014e0
panic() at panic+0x43/frame 0x82601540
trap_fatal() at trap_fatal+0x387/frame 0x826015a0
trap_pfault() at trap_pfault+0x97/frame 0x82601600
calltrap() at calltrap+0x8/frame 0x82601710
--- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
0x826017e0 ---
phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
vm_fault() at vm_fault+0x5d6/frame 0x82601940
vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
rtR0MemObjFreeBSDAllocHelper() at
rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
0x82601ac0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
0x82601bf0
module_register_init() at module_register_init+0xbd/frame 0x82601c20
mi_startup() at mi_startup+0xec/frame 0x82601c70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
db>


The system freezes at this point, no core dump is generated ;)  This
does not happen without loading VBoxDrv.

At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
this is of some help.

Best regards,
Rainer
___
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: Fatal trap 18 on boot after OpenZFS import

[Tomoaki AOKI]

Forgot to mention here.

As I already mentioned on bugzilla, this problem is fixed at r365894.

Thanks again, Ryan and Matthew!


On Sun, 6 Sep 2020 18:02:40 +0900
Tomoaki AOKI  wrote:

> Filed PR.
> Bug 249147 - [ZFS][Panic]Fatal trap 18 on boot after OpenZFS import
> 
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249147
> 
> 
> On Fri, 4 Sep 2020 22:03:01 +0900
> Tomoaki AOKI  wrote:
> 
> > Hi.
> > 
> > Encountering boot failure with fatal trap 18 on boot,
> > happening at (maybe) just before init() starts. Possibly on
> > root remount by kernel or zpool import by rc.d script.
> > The last revision tried is r365316 (r364788 is the last tried
> > clean rebuild).
> > 
> > The last health revision is r364744, just before actual switch
> > to OpenZFS. amd64 on ThinkPad P52 (Core i7-8750H) w/descrete nvidia GPU.
> > 
> > r364751 with diff of r364777 and r364788 (to successfully built
> > Without unrelated-to-OpenZFS changes) fails.
> > 
> > Any suggestions and fixes are appreciated.
> > 
> > 
> > Trap screen is something like below (text attached),
> > typed up from relatively clear photo, so could be some typo.
> > 
> > This is shown just after usual kernel startup outputs.
> > boot1.efi (as EFI/bootx64.efi on ESP) starts /boot/loader.efi
> > properly, and loader.efi seems to boot kernel properly.
> > 
> > As even single user shell selection doesn't appear, loader.efi
> > is of r364744. But they works even if I proceeded irregular
> > process,
> > 
> >   1)Update src tree
> >   2)Clean obj tree
> >   3)buildworld
> >   4)etcupdate -p
> >   5)buildkernel
> >   6)installkernel
> >   7)shutdown to single user WITHOUT reboot  <- Irregular!
> >   8)installworld
> >   9)etcupdate
> >  10)rebuild src/sys-dependent ports (kmods, nvidia-driver, ...)
> >  11)reboot
> > 
> > loader.efi looks doing its job and panics after kernel startup ends.
> > Needless to say, rolling back to r364744 state from stable/12 on nvd0
> > Fixes the issue.
> > 
> > Regards.
> > 
> > =
> > 
> > Fatal trap 18: integer divide fault while in kernel mode
> > cpuid = 2; apic id = 02
> > instruction pointer = 0x20:0x82bfa320
> > stack pointer   = 0x28:0xfe00e20c6900
> > frame pointer   = 0x28:0xfe00e20c6960
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 27 (vdev_open)
> > trap number = 18
> > panic: integer divide fault
> > cpuid = 2
> > time = 16
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe00e20c6610 vpanic() at vpanic+0x182/frame fe00e20c6660
> > panic() at panic+0x43/frame fe00e20c66c0
> > trap_fatal() at trap_fatal+0x387/frame fe00e20c6720
> > trap() at trap+0x8e/frame fe00e20c6830
> > calltrap() at calltrap+0x8/frame fe00e20c6830
> > --- trap 0x12, rip = 0x82bfa320, rsp = 0xfe00e20c6900, rbp
> > = 0xfe00e20c6960 --- zio_wait() at zio_wait+0x60/frame
> > 0xfe00e20c6960 vdev_open() at vdev_open+0x74d/frame
> > 0xfe00e20c69c0 vdev_open_child() at vdev_open_child+0x1e/frame
> > 0xfe00e20c69e0 taskq_run() at taskq_run+0x1f/frame
> > 0xfe00e20c6a00 taskqueue_run_locked() at
> > taskqueue_run_locked+0x181/frame 0xfe00e20c6a80
> > taskqueue_thread_loop() at taskqueue_thread_loop+0x118/frame
> > 0xfe00e20c6ab0 fork_exit() at fork_exit+0x7d/frame
> > 0xfe00e20c6af0 fork_trampoline() at fork_trampoline+0xe/frame
> > 0xfe00e20c6af0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > KDB: enter: panic
> > [ thread pid 27 tid 100570 ]
> > Stopped at  kdb_enter+0x37: movq$0,0x1091556(%rip)
> > db> 
> > 
> > =
> > 
> > Additional info:
> >  *Clean build with killing CPUTYPE from command line and
> >   make.conf (so should be equivalent with nocona) didn't help.
> > 
> >  *Clean build with commenting out WITH_KERNEL_RETPOLINE line
> >   and WITH_RETPOLINE line in src.conf didn't help.
> > 
> >  *Combination of the above two didn't help, too (at r364788).
> > 
> >  *There are two root pools in different physical drive.
> >   stable/12 on nvd0 (primary) and head on ada0 (secondary).
> > 
> >  *GENERIC-NODEBUG based (added options CAM_IOSCHED_DYNAMIC)
> >   kernel.
> > 
> > -- 
> > Tomoaki AOKI
> 
> 
> -- 
> Tomoaki AOKI
> ___
> 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"


-- 
Tomoaki AOKI
___
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: Deprecating ftpd in the FreeBSD base system?

[Tomoaki AOKI]

On Thu, 17 Sep 2020 08:55:26 -0700
Cy Schubert  wrote:

> In message <451538de-9427-4584-987b-8e4aa26c2...@freebsd.org>, Daniel 
> Eischen w
> rites:
> > 
> >
> > > On Sep 17, 2020, at 11:20 AM, Maxim Sobolev  wrote:
> > > 
> > > 〓〓〓Re: removing HTTP client please no!!! The current drive to "outlaw" 
> > > HTTP
> > > coming from companies who see all world via web browser. Totally ignoring
> > > the fact that HTTP != HTTPS in particular in cases where reliability and
> > > lower complexity of the system takes precedence over on-the-wire protocol
> > > security. For example, many internal APIs of AWS EC2 are HTTP.
> >
> > Agree.  And remember the mantra: tools, not policy.
> 
> Since there are so many I'll pick this email to reply to.
> 
> libfetch should be designed to call plugins. An https plugin, http plugin, 
> ftp plugin, sftp plugin, and so on. New protocols are added as needed, 
> preferably to ports before they are mainstream. Old protocols are removed 
> and moved to ports. People who still need to use old protocols can install 
> the port which plugs into libfetch. When a protocol becomes stale it's 
> forgotten, no longer maintained and simply disappears into the ether.

Looks reasonable for me, if all plugin to fetch base distribution
and pkgbase is guaranteed to be incorporated in base and install images.

No objection about removing ftpd and ftp client from base, if drop-in
(at least having enough compatibility with configuration files/envs)
alternatives are in ports.


Regards.


> Given that pkgbase will become a reality at some point the line between 
> base and ports will blur. I expect at some point some of what we see in 
> base to simply become ports. As a developer of both base and ports, ports 
> are much easier to maintain than importing into base.
> 
> That's my vision.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
> 
>   The need of the many outweighs the greed of the few.
> 
> 
> ___
> 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"
> 


-- 
Tomoaki AOKI
___
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: Plans for git

[Tomoaki AOKI]

Hi!
Thanks for clarification, Warner.

Focusing on downsides, I feel the second is fundamental.
Running (incremental) count is important especially for non-developers
like me (or developers not having commit bit) to report problems via ML.

It clarifies revision ranges in shorter and clearer form.
And if specfying it to use back and forth revisions is possible,
like `svnlite -r (any revision No.)`, bisecting should be
much easier than using git hash, which is not incremental.


For the third, merging acceptably-licensed tool, such as got,
into base seems reasonable to me.
IIUC, got uses git-compatible repository. So anyone who hesitates
incompatible command line can use devel/git or anything else from ports.


Regards.


On Sat, 19 Sep 2020 09:57:38 -0600
Warner Losh  wrote:

> I've taken the time to clean up this email (which I wrote on my phone last
> thing yesterday) and expand it a little.
> 
> https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
> 
> is the result. I'm planning on doing a number of videos about this, as well
> as blog posts, FreeBSD Journal articles and handbook updates.
> 
> Hopefully that will help explain why we're headed that way, as well as
> provide resources for what to do after the cut-over, what users can expect,
> etc.
> 
> Warner
> 
> On Sat, Sep 19, 2020 at 12:21 AM Warner Losh  wrote:
> 
> >
> >
> > On Fri, Sep 18, 2020, 11:31 PM Zaphod Beeblebrox 
> > wrote:
> >
> >> Hrm.  Maybe what I hear others saying, tho, and not entirely being
> >> replied to is just a nice concise document of the why.  What I hear you
> >> saying is that GIT has momentum and that it's popular... (and I accept that
> >> --- it is evidently true), but then I hear handwaving about features, but
> >> no list of features that are a clear win/loose.
> >>
> >
> > Apache has switched to git from subversion. They are the current
> > caretakers of subversion so it's future is very much in doubt.
> >
> > Git have more support for newer CI tools than subversion. This will allow
> > us, once things are fully phased in, to increase the quality of the code
> > going into the tree, as well as greatly reduce build breakages and
> > accidental regressions.
> >
> > Gits merging facilities are much better than subversion. You can more
> > easily curate patches as well since git supports a rebase workflow. This
> > allows cleaner patches that are logical bits for larger submissions.
> > Subversion can't do this.
> >
> > Git can easily and robustly be mirrored. Subversion can be mirrored, but
> > that mirroring is far from robust. One of the snags in the git migration is
> > that different svn mirrors have different data than the main repo or each
> > other. Git can cryptographically sign tags and commits. Subversion cannot.
> >
> > Mirroring also opens up more 3rd party plug ins. Gitlab can do some
> > things, Github others, in terms of automated testing and continuous
> > integration. Tests can be run when branches are pushed. Both these
> > platforms have significant collaboration tools as well, which will support
> > groups going off and creating new features for FreeBSD.  While one can use
> > these things to a limited degree, with subversion mirrored to github, the
> > full power of these tools isn't fully realized without a conversion to git.
> >
> > All of this is before the skillset arguments are made about kids today
> > just knowing git, but needing to learn subversion and how that has had
> > increasing been a source of friction.  This argument is the closest one to
> > being handwavy since I've not voted the data showing the growing proportion
> > of projects using git (iirc, it's 85% or 90%).
> >
> > These are the main ones. The three down sides are lack of $FreeBSD$
> > support and tags in general. Git has a weaker count of commits than
> > subversion. And the BSDL git clients are less mature than the GPL'd ones.
> >
> > Certainly the only clear things a quick search turns up that seem relevant
> >> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
> >> GCC and the repository is a core function, but I suppose not a necessary
> >> function for forked projects that can't abide, so...
> >>
> >
> > OPENBSD has got, which is being ported in earnest. It has an agreeable
> > license.
> >
> > Anyways... some concise record of thoughts might calm the gnawing
> >> sensation in my gut...
> >>
> >
> > Yes. I've started doing a series of short videos explaining the change,
> > why we are doing it and what to do in the new world order. I'll be doing
> > blog entries as well as turning that material into handbook entries. I have
> > some of those written.
> >
> > Does this help?
> >
> > Warner
> >
> > On Thu, Sep 3, 2020 at 4:19 PM Warner Losh  wrote:
> >>
> >>> On Thu, Sep 3, 2020 at 1:32 PM Chris  wrote:
> >>>
> >>> > On 2020-09-03 11:33, Kristof Provost wrote:
> >>> > > On 3 Sep 2020, at 19:56, Chris wrote:
> >>> > >> Why was the intention to switch NOT announced as suc

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Konstantin Belousov]

On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> > On 2020-09-20 10:05, Rainer Hurling wrote:
> >> Hi monochrome,
> >>
> >> back to keyboard, it tried newest CURRENT (r365920) on my box and even
> >> with newest sources the error occurs.
> >>
> >> After looking around somewhat more, I found some hints about Virtualbox
> >> kernel module having problems with r365488. Unfortunately, I am not able
> >> to find the thread again :(
> >>
> >> What seems to help as a workaround is to disable the loading of
> >> VirtualBox in /boot/loader.conf
> >>
> >> #vboxdrv_load="YES"
> >>
> >> and in /etc/rc.conf
> >>
> >> #vboxnet_enable="YES"
> >> #vboxguest_enable="YES"
> >>
> >>
> >> So probably, this page fault is not restricted to AMD Ryzen?
> >>
> > 
> > Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> > version was not bumped correctly.
> > 
> > --HPS
> > 
> 
> Thanks for the hint. But I did rebuild all kernel modules before
> rebooting, in my case vbox*.ko, nvidia*.ko.

Provide backtrace of the panic.
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> On 2020-09-20 10:05, Rainer Hurling wrote:
>> Hi monochrome,
>>
>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>> with newest sources the error occurs.
>>
>> After looking around somewhat more, I found some hints about Virtualbox
>> kernel module having problems with r365488. Unfortunately, I am not able
>> to find the thread again :(
>>
>> What seems to help as a workaround is to disable the loading of
>> VirtualBox in /boot/loader.conf
>>
>> #vboxdrv_load="YES"
>>
>> and in /etc/rc.conf
>>
>> #vboxnet_enable="YES"
>> #vboxguest_enable="YES"
>>
>>
>> So probably, this page fault is not restricted to AMD Ryzen?
>>
> 
> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> version was not bumped correctly.
> 
> --HPS
> 

Thanks for the hint. But I did rebuild all kernel modules before
rebooting, in my case vbox*.ko, nvidia*.ko.

Best wishes,
Rainer
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Hans Petter Selasky]

On 2020-09-20 10:05, Rainer Hurling wrote:

Hi monochrome,

back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.

After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(

What seems to help as a workaround is to disable the loading of
VirtualBox in /boot/loader.conf

#vboxdrv_load="YES"

and in /etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"


So probably, this page fault is not restricted to AMD Ryzen?



Possibly you need to rebuild that kernel module. Maybe the FreeBSD 
version was not bumped correctly.


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

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Hi monochrome,

back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.

After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(

What seems to help as a workaround is to disable the loading of
VirtualBox in /boot/loader.conf

#vboxdrv_load="YES"

and in /etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"


So probably, this page fault is not restricted to AMD Ryzen?

HTH,
Rainer


Am 20.09.20 um 08:04 schrieb monochrome:
> I have confirmed that r365487 is the last kernel that will boot on my
> 2400G. These are the files changed between r365487 and r365488:
> 
> U    sys/vm/phys_pager.c
> U    sys/vm/vm_object.c
> U    sys/vm/vm_object.h
> U    sys/vm/vm_pager.h
> 
> 
> 
> On 9/18/20 8:57 AM, Rainer Hurling wrote:
>> Hi,
>> I am AFK until Sunday, so can't investigate ATM.
>> And no, I haven't solved it until now. Thanks for your report.
>> Rainer
>>
>> Am 18. September 2020 00:38:31 MESZ schrieb monochrome
>> :
>>>
>>> forgot you
>>>
>>>  Forwarded Message 
>>> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
>>> Date: Thu, 17 Sep 2020 17:03:49 -0400
>>> From: monochrome 
>>> To: freebsd-current@freebsd.org
>>>
>>> I am also having this problem. Have you resolved it? Mine is a Ryzen
>>> 5 2400G
>>>
>>> On 9/12/20 5:22 AM, Rainer Hurling wrote:
 Since r365488 (and above until recent) my box breaks with the following
 error when starting:

 Fatal trap 12: page fault while in kernel mode
 cpuid = 31; apic id = 1f
 fault virtual address   = 0x0
 fault code  = supervisor read data, page not present
 instruction pointer = 0x20:0x808f452b
 stack pointer   = 0x28:0x81711800
 frame pointer   = 0x28:0x81711800
 code segment    = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags    = interrupt enabled, resume, IOPL = 0
 current process = 0 (swapper)
 trap number = 12
 panic: page fault
 cpuid = 31
 time = 1



 Some infos about the system, the page fault occurs:

 CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
 K8-class CPU)
     Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71 
 Stepping=0
 Features=0x178bfbff

 Features2=0x7ed8320b

     AMD Features=0x2e500800
     AMD
 Features2=0x75c237ff

     Structured Extended
 Features=0x219c91a9

     Structured Extended Features2=0x44
     XSAVE Features=0xf
     AMD Extended Feature Extensions ID
 EBX=0x108b657
     SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
     TSC: P-state invariant, performance statistics
 real memory  = 68717379584 (65534 MB)
 avail memory = 66756149248 (63663 MB)
 Event timer "LAPIC" quality 600


 #cat /etc/sysctl.conf
 security.bsd.map_at_zero=1
 kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
 kern.evdev.rcpt_mask=6
 kern.maxfiles=49312
 kern.ipc.shm_allow_removed=1
 kern.ipc.maxsockbuf=16777216
 vfs.usermount=1
 net.inet.tcp.rfc1323=1
 net.inet.tcp.sack.enable=1
 net.inet.tcp.sendbuf_auto=1
 net.inet.tcp.recvbuf_auto=1
 net.inet.tcp.sendbuf_max=16777216
 net.inet.tcp.recvbuf_max=16777216
 net.inet6.ip6.use_tempaddr=1
 net.inet6.ip6.prefer_tempaddr=1
 net.local.stream.recvspace=65536
 net.local.stream.sendspace=65536


 Please let me know, if I should provide more info or test something.
 Thanks in advance,
 Rainer
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 "freebsd-current-unsubscr...@freebsd.org"

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

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

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Jack L.]

I also have the exact same panic on a Dell motherboard with a Haswell processor.

On Sat, Sep 19, 2020 at 11:05 PM monochrome  wrote:
>
> I have confirmed that r365487 is the last kernel that will boot on my
> 2400G. These are the files changed between r365487 and r365488:
>
> Usys/vm/phys_pager.c
> Usys/vm/vm_object.c
> Usys/vm/vm_object.h
> Usys/vm/vm_pager.h
>
>
>
> On 9/18/20 8:57 AM, Rainer Hurling wrote:
> > Hi,
> > I am AFK until Sunday, so can't investigate ATM.
> > And no, I haven't solved it until now. Thanks for your report.
> > Rainer
> >
> > Am 18. September 2020 00:38:31 MESZ schrieb monochrome 
> > :
> >>
> >> forgot you
> >>
> >>  Forwarded Message 
> >> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
> >> Date: Thu, 17 Sep 2020 17:03:49 -0400
> >> From: monochrome 
> >> To: freebsd-current@freebsd.org
> >>
> >> I am also having this problem. Have you resolved it? Mine is a Ryzen 5 
> >> 2400G
> >>
> >> On 9/12/20 5:22 AM, Rainer Hurling wrote:
> >>> Since r365488 (and above until recent) my box breaks with the following
> >>> error when starting:
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 31; apic id = 1f
> >>> fault virtual address   = 0x0
> >>> fault code  = supervisor read data, page not present
> >>> instruction pointer = 0x20:0x808f452b
> >>> stack pointer   = 0x28:0x81711800
> >>> frame pointer   = 0x28:0x81711800
> >>> code segment= base 0x0, limit 0xf, type 0x1b
> >>>   = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> processor eflags= interrupt enabled, resume, IOPL = 0
> >>> current process = 0 (swapper)
> >>> trap number = 12
> >>> panic: page fault
> >>> cpuid = 31
> >>> time = 1
> >>>
> >>>
> >>>
> >>> Some infos about the system, the page fault occurs:
> >>>
> >>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
> >>> K8-class CPU)
> >>> Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  
> >>> Stepping=0
> >>> Features=0x178bfbff
> >>> Features2=0x7ed8320b
> >>> AMD Features=0x2e500800
> >>> AMD
> >>> Features2=0x75c237ff
> >>> Structured Extended
> >>> Features=0x219c91a9
> >>> Structured Extended Features2=0x44
> >>> XSAVE Features=0xf
> >>> AMD Extended Feature Extensions ID
> >>> EBX=0x108b657
> >>> SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
> >>> TSC: P-state invariant, performance statistics
> >>> real memory  = 68717379584 (65534 MB)
> >>> avail memory = 66756149248 (63663 MB)
> >>> Event timer "LAPIC" quality 600
> >>>
> >>>
> >>> #cat /etc/sysctl.conf
> >>> security.bsd.map_at_zero=1
> >>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
> >>> kern.evdev.rcpt_mask=6
> >>> kern.maxfiles=49312
> >>> kern.ipc.shm_allow_removed=1
> >>> kern.ipc.maxsockbuf=16777216
> >>> vfs.usermount=1
> >>> net.inet.tcp.rfc1323=1
> >>> net.inet.tcp.sack.enable=1
> >>> net.inet.tcp.sendbuf_auto=1
> >>> net.inet.tcp.recvbuf_auto=1
> >>> net.inet.tcp.sendbuf_max=16777216
> >>> net.inet.tcp.recvbuf_max=16777216
> >>> net.inet6.ip6.use_tempaddr=1
> >>> net.inet6.ip6.prefer_tempaddr=1
> >>> net.local.stream.recvspace=65536
> >>> net.local.stream.sendspace=65536
> >>>
> >>>
> >>> Please let me know, if I should provide more info or test something.
> >>> Thanks in advance,
> >>> Rainer
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >>>
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
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"