Beta Git repo for ports

[Graham Perrin]

Via 
: 





Please: where to file enhancement requests (or bugs) for development of 
this cgit service for ports?


Is there a GitHub repo where issues might be raised? Or, are group 
e-mails (all four of you) preferred?


TIA
Graham


___
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: git: a9fc14fbf445 - main - newvers.sh: add support for gitup(1) [the removal of git branch information]

[Mark Millard]

On 2021-Jan-21, at 09:24, Mark Millard  wrote:

> Ulrich Spörlein uqs at FreeBSD.org wrote on
> Wed Jan 20 09:49:49 UTC 2021 :
> 
>>While here, drop the redundant branch name from the git output and don't
>>count commits in shallow clones.
>> 
> 
> The branch name part of the patch breaks how I work with multiple
> branches and I will be locally "reverting" it in my branches
> unless FreeBSD itself reverts it. For my context it even breaks
> how I would work for main vs. stable/12 if I ever did something
> with stable/12 . (I'm not using shallow clones, it is the branch
> name removal that messes up my specific way of working.) In other
> words, for how I choose to work, the branch name is not redundant.
> 
> Going in another direction: mixing gitup/clone-counting and the
> branch name removal in the same commit and in the code structure
> means that I'm unable to just skip a commit to deal with the
> branch name issue.

I had an exchange with Michael Osipov and he reports that
he "advocated to have" the git branch information. So, for:

"While here, drop the redundant branch name from the git output"

do not take the content of the commit log as indicating that
Michael Osipov was asking for this part of the change.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: panic rtentry / hashdestroy /in6_purgeaddr related?

[Alexander V . Chernikov]

21.01.2021, 18:10, "Alexander Leidinger" :
> Hi,
>
> -current at d7fc908cffa as of 2021-01-20-154143.
>
> I've seen several failures to free an rtentry on the console shortly
> before the panic. May or may not be related..._
Sorry for the breakage, should be fixed by 130aebbab0d3.

> ---snip---
> in6_purgeaddr: err=65, destination address delete failed
> Freed UMA keg (rtentry) was not empty (1 items). Lost 1 pages of memory.
> j_gallery_hif: link state changed to DOWN
> j_gallery_jif: link state changed to DOWN
>   samba.leidinger.net
> in6_purgeaddr: err=65, destination address delete failed
> Freed UMA keg (rtentry) was not empty (1 items). Lost 1 pages of memory.
> j_samba_hif: link state changed to DOWN
> j_samba_jif: link state changed to DOWN
> ---snip---
>
> This is on shutdown with 22 vnet jails:
> ---snip---
> Unread portion of the kernel message buffer:
> <6>in6_purgeaddr: err=65, destination address delete failed
> panic: hashdestroy: hashtbl 0xf80be7108800 not empty (malloc type ifaddr)
> cpuid = 14
> time = 1611248408
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0064b55b10
> vpanic() at vpanic+0x181/frame 0xfe0064b55b60
> panic() at panic+0x43/frame 0xfe0064b55bc0
> hashdestroy() at hashdestroy+0x54/frame 0xfe0064b55bd0
> vnet_destroy() at vnet_destroy+0x146/frame 0xfe0064b55c00
> prison_deref() at prison_deref+0x28e/frame 0xfe0064b55c40
> taskqueue_run_locked() at taskqueue_run_locked+0xb0/frame 0xfe0064b55cc0
> taskqueue_thread_loop() at taskqueue_thread_loop+0x97/frame 0xfe0064b55cf0
> fork_exit() at fork_exit+0x85/frame 0xfe0064b55d30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0064b55d30
> ---snip---
>
> Full crashinfo output available on request. Kerneldump is also
> available if you want I peek into it at some specific place.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
___
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"

panic rtentry / hashdestroy /in6_purgeaddr related?

[Alexander Leidinger]

Hi,

-current at d7fc908cffa as of 2021-01-20-154143.

I've seen several failures to free an rtentry on the console shortly  
before the panic. May or may not be related..._

---snip---
in6_purgeaddr: err=65, destination address delete failed
Freed UMA keg (rtentry) was not empty (1 items).  Lost 1 pages of memory.
j_gallery_hif: link state changed to DOWN
j_gallery_jif: link state changed to DOWN
 samba.leidinger.net
in6_purgeaddr: err=65, destination address delete failed
Freed UMA keg (rtentry) was not empty (1 items).  Lost 1 pages of memory.
j_samba_hif: link state changed to DOWN
j_samba_jif: link state changed to DOWN
---snip---

This is on shutdown with 22 vnet jails:
---snip---
Unread portion of the kernel message buffer:
<6>in6_purgeaddr: err=65, destination address delete failed
panic: hashdestroy: hashtbl 0xf80be7108800 not empty (malloc type ifaddr)
cpuid = 14
time = 1611248408
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0064b55b10
vpanic() at vpanic+0x181/frame 0xfe0064b55b60
panic() at panic+0x43/frame 0xfe0064b55bc0
hashdestroy() at hashdestroy+0x54/frame 0xfe0064b55bd0
vnet_destroy() at vnet_destroy+0x146/frame 0xfe0064b55c00
prison_deref() at prison_deref+0x28e/frame 0xfe0064b55c40
taskqueue_run_locked() at taskqueue_run_locked+0xb0/frame 0xfe0064b55cc0
taskqueue_thread_loop() at taskqueue_thread_loop+0x97/frame 0xfe0064b55cf0
fork_exit() at fork_exit+0x85/frame 0xfe0064b55d30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0064b55d30
---snip---

Full crashinfo output available on request. Kerneldump is also  
available if you want I peek into it at some specific place.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpXhRFcbfDZO.pgp
Description: Digitale PGP-Signatur

Re: make buildkernel is broken (linuxkpi vs drm)

[Steve Kargl]

On Thu, Jan 21, 2021 at 11:50:15AM +0100, Emmanuel Vadot wrote:
> On Wed, 20 Jan 2021 22:21:09 -0800
> Steve Kargl  wrote:
> 
> > On Thu, Jan 21, 2021 at 07:18:07AM +0100, Hans Petter Selasky wrote:
> > > On 1/21/21 7:13 AM, Steve Kargl wrote:
> > > > It is 'make buildkernel' in /usr/src after a 'make buildworld'.
> > > > I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf.
> > > 
> > > Try to update the ports tree. I'm not aware of any current build issues in
> > > this area.
> > > 
> > 
> > I tried that.  I did not fix the problem.  Commenting
> > out the PORTS_MODULES line in /etc/make.conf allows
> > me to finish building the new kernel.  I re-install
> > the port after I install world/kernel.
> > 
> > -- 
> > Steve
> 
>  Does it works now ?

Haven't got to the point of re-installing drm-current-kmod.

For some reason, the newly built kernel is panicking, and
it panics either before or during keyboard probe so I have
no keyboard. 

Need to figure out to use git to back up to mid-december
source tree.

-- 
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: make buildkernel is broken (linuxkpi vs drm)

[Emmanuel Vadot]

On Wed, 20 Jan 2021 22:21:09 -0800
Steve Kargl  wrote:

> On Thu, Jan 21, 2021 at 07:18:07AM +0100, Hans Petter Selasky wrote:
> > On 1/21/21 7:13 AM, Steve Kargl wrote:
> > > It is 'make buildkernel' in /usr/src after a 'make buildworld'.
> > > I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf.
> > 
> > Try to update the ports tree. I'm not aware of any current build issues in
> > this area.
> > 
> 
> I tried that.  I did not fix the problem.  Commenting
> out the PORTS_MODULES line in /etc/make.conf allows
> me to finish building the new kernel.  I re-install
> the port after I install world/kernel.
> 
> -- 
> Steve

 Does it works now ?

 I think that PORTS_MODULES shouldn't be used for drm-current-kmod or
we should not install the source with it if PORTS_MODULES is the right
way.

 The problem is that drm-current-kmod install its sources
in /usr/local/sys and by default all modules there will be rebuild when
doing make buildkernel unless LOCAL_MODULES is defined.
 The problem with installing sources is that if something changed in
base that broke the build with a certain version of drm-current-kmod
you first need to upgrade the ports/package to have the new sources to
be able to make buildkernel correctly.
 I personally hate the fact that we install the sources as it only
causes problems for users but some people seems to like it.
 It seems that if we don't install the sources and one uses
PORTS_MODULES we just need to upgrade the ports tree before running
make buildkernel if there is a conflicting changes which seems saner to
me tbh.

 For now I've been focusing the rage that LOCAL_MODULES exists and
cause this kind of problems on migrating more stuff into base so that
one day we will finally have drm in base again. But I'm a bit
tired of dealing with all those problems and I've wondered a lot of
times about removing installing sources for drm-current-kmod.

 Adding jhb@ to cc as I know he uses LOCAL_MODULES so maybe he can
explain the advantage over PORTS_MODULES.

-- 
Emmanuel Vadot  
___
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: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

[Mark Millard]

On 2021-Jan-20, at 18:33, bob prohaska  wrote:

>> . . .
> A first OS build/install cycle on armv7 (RPI2) using meta mode 
> finished without trouble.  Sources were a day or two newer than 
> the kernel, -j4 buildworld took 157121 seconds. Peak swap use 
> was half again as much at 732932. No constraints on ld.lld 
> beyond defaults. I'm a little surprised at the extreme slowness,
> but this was a fully-debug'd-current kernel and sources were
> slightly newer than existing world.
> 
> In case there's interest I've put what log files I could gather at
> http://www.zefox.net/~fbsd/rpi2/buildworld/main-c950-gff1a307801/

The first META_MODE build has no META_MODE information
from the prior build.

You might want to have META_MODE do a build without
updating sources and leaving the existing build materials
in place. It would give you an idea of the lower bound on
how much time a minimal build would take in your context.
On the OPi+2E, for my context, for no linking-thread
constraint, an example was:

World built in 1468 seconds, ncpu: 4, make -j4
Kernel(s)  GENERIC-NODBG built in 116 seconds, ncpu: 4, make -j4

So, somewhat under 30 minutes total.

(There can be some things that do get some rebuild activity
in such a build. Lots of things can end up relinked, so .full
and .debug and such regenerated.)

I'll note that for META_MODE to work well, you need to keep
using it so that its records stay up to date as a description
of the build materials that are to be the basis for the next
update. Forgetting to supply WITH_META_MODE would not be
good for approximately minimizing the rebuild work done.

I've never tried to compare how much more memory is used
under a debug kernel than a non-debug one. My use of
non-debug vs. your use of debug could explain a lot for
both memory use and some part of the time difference
compared to my reports. I've only used a debug kernel
to buildworld or buildkernel when trying to get evidence
for a system problem that was occurring during build*
operation(s).

QUOTE (from UPDATING)
NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
FreeBSD 13.x has many debugging features turned on, in both the kernel
and userland.  These features attempt to detect incorrect use of
system primitives, and encourage loud failure through extra sanity
checking and fail stop semantics.  They also substantially impact
system performance.  If you want to do performance measurement,
benchmarking, and optimization, you'll want to turn them off.  This
includes various WITNESS- related kernel options, INVARIANTS, malloc
debugging flags in userland, and various verbose features in the
kernel.  Many developers choose to disable these features on build
machines to maximize performance.  (To completely disable malloc
debugging, define WITH_MALLOC_PRODUCTION in /etc/src.conf and rebuild
world, or to merely disable the most expensive debugging functionality
at runtime, run "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
END QUOTE

I was using a 1008 MHz clocked OPi+2E. You may well have
been using a 600 MHz clocked RPi2B. I do not know if there
are L1 or L2 RAM caching differences involved.

There are enough differences to not make the variations
in figures from our runs all that surprising.

I see that you kept the 2048 MiByte total swap space, so
still exceeding the documented recommended-maximum for
the context. Since it used under 800 MiBytes, it would
seem that it would fit to use more like <=1800 MiByte to
avoid what the documentation warns about for tradeoffs
for having too much swap space.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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