Re: How do GEOM_PART_* options configure geom_part_* modules??

[Kevin Oberman]

On Thu, Sep 28, 2017 at 6:09 PM, Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Thu, Sep 28, 2017 at 11:12 AM, Kevin Oberman 
> wrote:
> >
> > > On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:
> > >
> > >> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
> > >> wrote:
> > >>
> > >> > I created a new kernel config file from scratch, wondered what the
> > >> > GEOM_PART_MBR option and friends were doing, search for them, didn't
> > >> find
> > >> > them in the tree, and deleted them from my config. But... de
> resulting
> > >> disk
> > >> > image didn't boot, because of the fact that it didn't recognise the
> MBR
> > >> > partitions (it only had a single diskid entry on the mount-root
> prompt).
> > >> >
> > >> > Can anyone explain to me how these kernel options work, as in: they
> are
> > >> > defined in kernel configs and as a consequence in opt_geom.h, but
> how
> > >> are
> > >> > they actually used to select which geom_part_* modules/kernel parts
> to
> > >> > build? I thought these options were translated to stuff that cpp
> would
> > >> use,
> > >> > but there are not uses of for example GEOM_PART_MBR anywhere for
> > >> example!
> > >> >
> > >> >
> > >> > The module always build them because they are listed in the module's
> > >> > Makefile.
> > >> >
> > >> > The kernel only sometimes does. Here's the key lines from
> conf/files:
> > >> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> > >> > files:geom/part/g_part_apm.c optional geom_part_apm
> > >> > files:geom/part/g_part_bsd.c optional geom_part_bsd
> > >> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> > >> > files:geom/part/g_part_ebr.c optional geom_part_ebr
> > >> > files:geom/part/g_part_gpt.c optional geom_part_gpt
> > >> > files:geom/part/g_part_ldm.c optional geom_part_ldm
> > >> > files:geom/part/g_part_mbr.c optional geom_part_mbr
> > >> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> > >> >
> > >> > which turn on/off which files get included. config "helpfully"
> converts
> > >> the
> > >> > upper case options to lower case for this.
> > >> >
> > >> > Warner
> > >> >
> > >> >
> > >> > *slaps forehead* Goose chase!
> > >> >
> > >> > I actually knew that... and, at the time, thought it was weird
> > >> behaviour.
> > >> > ''grep" would not have failed me if those options would be uppercase
> > >> there
> > >> > ...
> > >> >
> > >>
> > >> I've been nibbled to death by these geese often enough to have a
> PTSD-like
> > >> reaction when someone mentions it and habitually add -i to my greps...
> > >>
> > >> Warner
> > >
> > >
> > > This horrid POLA violation seems to have been in FreeBSD configuration
> > > since at least 3.0 and probably goes back to the creation of the
> > > configuration process.
> > >
> > > Any idea why such a horrible POLA was ever introduced? Seems like an
> > > obviously bad idea in an OS that is ALMOST always case sensitive.
> > >
> >
> > It's received code from the old 4.3 BSD config program (or maybe the
> net-2
> > config program).
>
> We had best not have any code direct from 4.3 or net-2, it should be from
> 4.4BSDLite, any code prior to that is subject of the lawsuit.
>
>
> --
> Rod Grimes
> rgri...@freebsd.org
>

I believe any code in 4.3 BSD that was developed by CSRG was not subject of
the suit. Copyright on that code by the Regents of UC, not AT (So was
any code I wrote.) Many utilities were from v8 or descended from AT code,
but a great deal was not. It was what UC was getting paid for.

My first Unix experience was with 4.2 BSD and I was not concerned with
copyrights as I was working for  UC (at least my paychecks said so) and we
had an AT license for Unix, so it was simply not an issue. The system was
a VAX-11/750 at the UC-Davis Department of Applied Science located at
Lawrence Livermore Lab.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: How do GEOM_PART_* options configure geom_part_* modules??

[Rodney W. Grimes]

> On Thu, Sep 28, 2017 at 11:12 AM, Kevin Oberman  wrote:
> 
> > On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:
> >
> >> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
> >> wrote:
> >>
> >> > I created a new kernel config file from scratch, wondered what the
> >> > GEOM_PART_MBR option and friends were doing, search for them, didn't
> >> find
> >> > them in the tree, and deleted them from my config. But... de resulting
> >> disk
> >> > image didn't boot, because of the fact that it didn't recognise the MBR
> >> > partitions (it only had a single diskid entry on the mount-root prompt).
> >> >
> >> > Can anyone explain to me how these kernel options work, as in: they are
> >> > defined in kernel configs and as a consequence in opt_geom.h, but how
> >> are
> >> > they actually used to select which geom_part_* modules/kernel parts to
> >> > build? I thought these options were translated to stuff that cpp would
> >> use,
> >> > but there are not uses of for example GEOM_PART_MBR anywhere for
> >> example!
> >> >
> >> >
> >> > The module always build them because they are listed in the module's
> >> > Makefile.
> >> >
> >> > The kernel only sometimes does. Here's the key lines from conf/files:
> >> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> >> > files:geom/part/g_part_apm.c optional geom_part_apm
> >> > files:geom/part/g_part_bsd.c optional geom_part_bsd
> >> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> >> > files:geom/part/g_part_ebr.c optional geom_part_ebr
> >> > files:geom/part/g_part_gpt.c optional geom_part_gpt
> >> > files:geom/part/g_part_ldm.c optional geom_part_ldm
> >> > files:geom/part/g_part_mbr.c optional geom_part_mbr
> >> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> >> >
> >> > which turn on/off which files get included. config "helpfully" converts
> >> the
> >> > upper case options to lower case for this.
> >> >
> >> > Warner
> >> >
> >> >
> >> > *slaps forehead* Goose chase!
> >> >
> >> > I actually knew that... and, at the time, thought it was weird
> >> behaviour.
> >> > ''grep" would not have failed me if those options would be uppercase
> >> there
> >> > ...
> >> >
> >>
> >> I've been nibbled to death by these geese often enough to have a PTSD-like
> >> reaction when someone mentions it and habitually add -i to my greps...
> >>
> >> Warner
> >
> >
> > This horrid POLA violation seems to have been in FreeBSD configuration
> > since at least 3.0 and probably goes back to the creation of the
> > configuration process.
> >
> > Any idea why such a horrible POLA was ever introduced? Seems like an
> > obviously bad idea in an OS that is ALMOST always case sensitive.
> >
> 
> It's received code from the old 4.3 BSD config program (or maybe the net-2
> config program).

We had best not have any code direct from 4.3 or net-2, it should be from
4.4BSDLite, any code prior to that is subject of the lawsuit.


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

Re: How do GEOM_PART_* options configure geom_part_* modules??

[Warner Losh]

On Sep 28, 2017 7:09 PM, "Rodney W. Grimes" <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> On Thu, Sep 28, 2017 at 11:12 AM, Kevin Oberman 
wrote:
>
> > On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:
> >
> >> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
> >> wrote:
> >>
> >> > I created a new kernel config file from scratch, wondered what the
> >> > GEOM_PART_MBR option and friends were doing, search for them, didn't
> >> find
> >> > them in the tree, and deleted them from my config. But... de
resulting
> >> disk
> >> > image didn't boot, because of the fact that it didn't recognise the
MBR
> >> > partitions (it only had a single diskid entry on the mount-root
prompt).
> >> >
> >> > Can anyone explain to me how these kernel options work, as in: they
are
> >> > defined in kernel configs and as a consequence in opt_geom.h, but how
> >> are
> >> > they actually used to select which geom_part_* modules/kernel parts
to
> >> > build? I thought these options were translated to stuff that cpp
would
> >> use,
> >> > but there are not uses of for example GEOM_PART_MBR anywhere for
> >> example!
> >> >
> >> >
> >> > The module always build them because they are listed in the module's
> >> > Makefile.
> >> >
> >> > The kernel only sometimes does. Here's the key lines from conf/files:
> >> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> >> > files:geom/part/g_part_apm.c optional geom_part_apm
> >> > files:geom/part/g_part_bsd.c optional geom_part_bsd
> >> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> >> > files:geom/part/g_part_ebr.c optional geom_part_ebr
> >> > files:geom/part/g_part_gpt.c optional geom_part_gpt
> >> > files:geom/part/g_part_ldm.c optional geom_part_ldm
> >> > files:geom/part/g_part_mbr.c optional geom_part_mbr
> >> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> >> >
> >> > which turn on/off which files get included. config "helpfully"
converts
> >> the
> >> > upper case options to lower case for this.
> >> >
> >> > Warner
> >> >
> >> >
> >> > *slaps forehead* Goose chase!
> >> >
> >> > I actually knew that... and, at the time, thought it was weird
> >> behaviour.
> >> > ''grep" would not have failed me if those options would be uppercase
> >> there
> >> > ...
> >> >
> >>
> >> I've been nibbled to death by these geese often enough to have a
PTSD-like
> >> reaction when someone mentions it and habitually add -i to my greps...
> >>
> >> Warner
> >
> >
> > This horrid POLA violation seems to have been in FreeBSD configuration
> > since at least 3.0 and probably goes back to the creation of the
> > configuration process.
> >
> > Any idea why such a horrible POLA was ever introduced? Seems like an
> > obviously bad idea in an OS that is ALMOST always case sensitive.
> >
>
> It's received code from the old 4.3 BSD config program (or maybe the net-2
> config program).

We had best not have any code direct from 4.3 or net-2, it should be from
4.4BSDLite, any code prior to that is subject of the lawsuit.


The code is idental in both. There is also a newconfig in 4.4 we didn't
adopt...

Warner



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

Re: FreeBSD, IPFW and the SIP/VoIP NAT problem

[O. Hartmann]

Am Wed, 27 Sep 2017 14:17:14 +0200
Damjan Jovanovic  schrieb:

> On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann 
> wrote:
> 
> > On Tue, 26 Sep 2017 16:26:51 +0200
> > Damjan Jovanovic  wrote:
> >  
> > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann 
> > > wrote:
> > >  
> > > > On Tue, 26 Sep 2017 11:00:45 +0200
> > > > Damjan Jovanovic  wrote:
> > > >  
> > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <  
> > ohartm...@walstatt.org>  
> > > > > wrote:
> > > > >  
> > > > > > Hello,
> > > > > >
> > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13)  
> > appliance, I  
> > > > ran  
> > > > > > into
> > > > > > several problems. My questions might have a "noobish" character,  
> > so my  
> > > > > > apology,
> > > > > > my experiences with IPFW are not as thorough as they should be.
> > > > > >
> > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64:
> > > > > >
> > > > > > - port net/asterisk13 is supposed to build only on armv6, is  
> > aarch64  
> > > > about  
> > > > > >   coming soon also supported?
> > > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX  
> > platform  
> > > > > > (assumed
> > > > > >   having 2 GB of RAM)?
> > > > > >
> > > > > > My main concern is about IPFW (we do not use PF for some reasons, I 
> > > > > >  
> > > > have to  
> > > > > > stay with IPFW).
> > > > > >
> > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and  
> > not  
> > > > yet  
> > > > > > IPv6.
> > > > > > The FreeBSD system acting as a router is supposed to have a jail  
> > soon  
> > > > > > containing the Asterisk 13 IP PBX (at the moment running on the  
> > main  
> > > > > > system).
> > > > > > To provide access to the VoIP infrastructure inside/behind the  
> > > > router/NAT  
> > > > > > system, the in-kernel NAT facility of FreeBSD is forwarding the  
> > > > relevant  
> > > > > > UPD/TCP ports for VoIP to its destination network, and here I have  
> > a  
> > > > > > problem to
> > > > > > solve.
> > > > > >
> > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other 
> > > > > >  
> > > > ports,  
> > > > > > it
> > > > > > is a mess and pain in the arse to forward a whole range, say  
> > 11000/udp  
> > > > -  
> > > > > > 35000/udp, which is a range one of my providers is sending RTP on.  
> > A  
> > > > second  
> > > > > > provider uses another range for RTP, starting at 5000/udp. So, the  
> > > > logical  
> > > > > > consequence would be a union set up UDP range to forward, which  
> > exapnds  
> > > > > > then
> > > > > > form 5000/udp to 45000/udp - which is much more a pain ...
> > > > > >
> > > > > > One of the most disturbing and well known problems is that due to  
> > the  
> > > > > > stateful
> > > > > > firewall the RTP session very often is half duplex - it seems one  
> > > > direction  
> > > > > > of the RTP connection doesn't make it through IPFW/NAT. As often I  
> > > > search  
> > > > > > the
> > > > > > net, I always get informed this is a typical problem and solutions  
> > are  
> > > > > > provided by so called ALGs - since SIP protocol's SDP indicates  
> > within  
> > > > the  
> > > > > > payload of the packets on which UDP ports both ends wish to  
> > establish  
> > > > their  
> > > > > > RTP session, it would be "easy" to pinhole the IPFW on exactly  
> > those  
> > > > ports  
> > > > > > for
> > > > > > a theoretical large number of sessions, if IPFW could "divert"  
> > those  
> > > > > > packets
> > > > > > to an instance inspecting SDP (or whatever is used for the RTP port
> > > > > > indication, I'm new to that, sorry for the terminology) and then  
> > > > pinholing  
> > > > > > the
> > > > > > NAT/IPFW for exactly this purpose without the forwarding mess. I  
> > came  
> > > > along  
> > > > > > netgraph() while searching for hints and hooks, but it seems a  
> > complete  
> > > > > > Linux
> > > > > > domain, when it somes to appliances like VoIP/IP PBX.
> > > > > >
> > > > > > Either, the problem is that trivial on FreeBSD, so no further  
> > > > mentioning is  
> > > > > > necessary (which would explain the vast emptyness of explanations,  
> > > > hints  
> > > > > > and
> > > > > > so on) or FreeBSD is a complete wasteland on this subject - which I 
> > > > > >  
> > > > also  
> > > > > > suspect, since pfSense and OPNsense must have come along with such  
> > > > problems  
> > > > > > and I simply do not know or recognise the software used for those  
> > > > purposes.  
> > > > > >
> > > > > > So, if someone enlightened in this matter stumbles over my  
> > question and  
> > > > > > could
> > > > > > delegate me onto the right way (ports, ng_XXX netgraph ficilities  
> > to  
> > > > look  
> > > > > > at,
> > > > > > some ipfw techniques relevant to the problem apart from the stupid  
> > > > simple  
> > > > > > 

Re: panic: softdep_deallocate_dependencies: dangling deps

[John Baldwin]

On Wednesday, September 27, 2017 03:13:21 PM Steve Kargl wrote:
> Just got this panic on 
> 
> FreeBSD troutmask.apl.washington.edu 12.0-CURRENT FreeBSD 12.0-CURRENT
> #0 r321800: Mon Jul 31 13:48:43 PDT 2017
> kargl@:/data/obj/usr/src/sys/SPEW  amd64
> 
> core.txt.0 contains
> 
> panic: softdep_deallocate_dependencies: dangling deps
> cpuid = 7
> time = 1506549566
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe023a281710
> vpanic() at vpanic+0x19c/frame 0xfe023a281790
> panic() at panic+0x43/frame 0xfe023a2817f0
> softdep_deallocate_dependencies() at 
> softdep_deallocate_dependencies+0x76/frame 0xfe023a281810
> brelse() at brelse+0x149/frame 0xfe023a281870
> bufwrite() at bufwrite+0x65/frame 0xfe023a2818b0
> softdep_process_journal() at softdep_process_journal+0x7a8/frame 
> 0xfe023a281950
> softdep_process_worklist() at softdep_process_worklist+0x80/frame 
> 0xfe023a2819b0
> softdep_flush() at softdep_flush+0xff/frame 0xfe023a2819f0
> fork_exit() at fork_exit+0x75/frame 0xfe023a281a30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe023a281a30
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> 
> __curthread () at ./machine/pcpu.h:232
> 232   __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:232
> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318
> #2  0x805879eb in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:386
> #3  0x80587e66 in vpanic (fmt=, ap=0xfe023a2817d0)
> at /usr/src/sys/kern/kern_shutdown.c:779
> #4  0x80587c83 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:710
> #5  0x80787f56 in softdep_deallocate_dependencies (
> bp=0xfe01f008d8b8) at /usr/src/sys/ufs/ffs/ffs_softdep.c:14304
> #6  0x8061dd69 in buf_deallocate (bp=0xfe01f008d8b8)
> at /usr/src/sys/sys/buf.h:429
> #7  brelse (bp=0xfe01f008d8b8) at /usr/src/sys/kern/vfs_bio.c:2348
> #8  0x8061b9e5 in bufwrite (bp=0xfe01f008d8b8)
> at /usr/src/sys/kern/vfs_bio.c:1914
> #9  0x8079bec8 in softdep_process_journal (mp=, 
> needwk=0x0, flags=)
> at /usr/src/sys/ufs/ffs/ffs_softdep.c:3559
> #10 0x80785dc0 in softdep_process_worklist (mp=0xf80007eef000, 
> full=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1592
> #11 0x807894ff in softdep_flush (addr=0xf80007eef000)
> at /usr/src/sys/ufs/ffs/ffs_softdep.c:1397
> #12 0x80555075 in fork_exit (
> callout=0x80789400 , arg=0xf80007eef000, 
> frame=0xfe023a281a40) at /usr/src/sys/kern/kern_fork.c:1038
> #13 
> (kgdb) 
> 
> Hmmm,
> 
> %  kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.0
> GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done.
> ABI doesn't support a vmcore target
> 
> OK, so debugging is broken :-/

Run the debugger on the binary, not the debug symbols:

kgdb /boot/kernel/kernel vmcore.0

-- 
John Baldwin
___
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: How do GEOM_PART_* options configure geom_part_* modules??

[Cy Schubert]

Changing grep to default to -i would be the POLA violation. Rather than mess 
with grep like RHEL has I suggest installing textproc/the_silver_searcher 
pkg/port. It does everything grep does and more. I've switched to ag (which by 
default does recursive case insensitive searches) while using grep in scripts 
and at times I need simply grep.


---
Sent using a tiny phone keyboard. Apologies for any typos and autocorrect.

Cy Schubert
 or 

-Original Message-
From: Kevin Oberman
Sent: 28/09/2017 10:13
To: Warner Losh
Cc: Nick Hibma; FreeBSD Current Mailing List
Subject: Re: How do GEOM_PART_* options configure geom_part_* modules??

On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:

> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
> wrote:
>
> > I created a new kernel config file from scratch, wondered what the
> > GEOM_PART_MBR option and friends were doing, search for them, didn't find
> > them in the tree, and deleted them from my config. But... de resulting
> disk
> > image didn't boot, because of the fact that it didn't recognise the MBR
> > partitions (it only had a single diskid entry on the mount-root prompt).
> >
> > Can anyone explain to me how these kernel options work, as in: they are
> > defined in kernel configs and as a consequence in opt_geom.h, but how are
> > they actually used to select which geom_part_* modules/kernel parts to
> > build? I thought these options were translated to stuff that cpp would
> use,
> > but there are not uses of for example GEOM_PART_MBR anywhere for example!
> >
> >
> > The module always build them because they are listed in the module's
> > Makefile.
> >
> > The kernel only sometimes does. Here's the key lines from conf/files:
> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> > files:geom/part/g_part_apm.c optional geom_part_apm
> > files:geom/part/g_part_bsd.c optional geom_part_bsd
> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> > files:geom/part/g_part_ebr.c optional geom_part_ebr
> > files:geom/part/g_part_gpt.c optional geom_part_gpt
> > files:geom/part/g_part_ldm.c optional geom_part_ldm
> > files:geom/part/g_part_mbr.c optional geom_part_mbr
> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> >
> > which turn on/off which files get included. config "helpfully" converts
> the
> > upper case options to lower case for this.
> >
> > Warner
> >
> >
> > *slaps forehead* Goose chase!
> >
> > I actually knew that... and, at the time, thought it was weird behaviour.
> > ''grep" would not have failed me if those options would be uppercase
> there
> > ...
> >
>
> I've been nibbled to death by these geese often enough to have a PTSD-like
> reaction when someone mentions it and habitually add -i to my greps...
>
> Warner


This horrid POLA violation seems to have been in FreeBSD configuration
since at least 3.0 and probably goes back to the creation of the
configuration process.

Any idea why such a horrible POLA was ever introduced? Seems like an
obviously bad idea in an OS that is ALMOST always case sensitive.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: How do GEOM_PART_* options configure geom_part_* modules??

[Warner Losh]

On Thu, Sep 28, 2017 at 11:12 AM, Kevin Oberman  wrote:

> On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:
>
>> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
>> wrote:
>>
>> > I created a new kernel config file from scratch, wondered what the
>> > GEOM_PART_MBR option and friends were doing, search for them, didn't
>> find
>> > them in the tree, and deleted them from my config. But... de resulting
>> disk
>> > image didn't boot, because of the fact that it didn't recognise the MBR
>> > partitions (it only had a single diskid entry on the mount-root prompt).
>> >
>> > Can anyone explain to me how these kernel options work, as in: they are
>> > defined in kernel configs and as a consequence in opt_geom.h, but how
>> are
>> > they actually used to select which geom_part_* modules/kernel parts to
>> > build? I thought these options were translated to stuff that cpp would
>> use,
>> > but there are not uses of for example GEOM_PART_MBR anywhere for
>> example!
>> >
>> >
>> > The module always build them because they are listed in the module's
>> > Makefile.
>> >
>> > The kernel only sometimes does. Here's the key lines from conf/files:
>> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
>> > files:geom/part/g_part_apm.c optional geom_part_apm
>> > files:geom/part/g_part_bsd.c optional geom_part_bsd
>> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
>> > files:geom/part/g_part_ebr.c optional geom_part_ebr
>> > files:geom/part/g_part_gpt.c optional geom_part_gpt
>> > files:geom/part/g_part_ldm.c optional geom_part_ldm
>> > files:geom/part/g_part_mbr.c optional geom_part_mbr
>> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
>> >
>> > which turn on/off which files get included. config "helpfully" converts
>> the
>> > upper case options to lower case for this.
>> >
>> > Warner
>> >
>> >
>> > *slaps forehead* Goose chase!
>> >
>> > I actually knew that... and, at the time, thought it was weird
>> behaviour.
>> > ''grep" would not have failed me if those options would be uppercase
>> there
>> > ...
>> >
>>
>> I've been nibbled to death by these geese often enough to have a PTSD-like
>> reaction when someone mentions it and habitually add -i to my greps...
>>
>> Warner
>
>
> This horrid POLA violation seems to have been in FreeBSD configuration
> since at least 3.0 and probably goes back to the creation of the
> configuration process.
>
> Any idea why such a horrible POLA was ever introduced? Seems like an
> obviously bad idea in an OS that is ALMOST always case sensitive.
>

It's received code from the old 4.3 BSD config program (or maybe the net-2
config program).

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: How do GEOM_PART_* options configure geom_part_* modules??

[Kevin Oberman]

On Thu, Sep 28, 2017 at 9:13 AM, Warner Losh  wrote:

> On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma 
> wrote:
>
> > I created a new kernel config file from scratch, wondered what the
> > GEOM_PART_MBR option and friends were doing, search for them, didn't find
> > them in the tree, and deleted them from my config. But... de resulting
> disk
> > image didn't boot, because of the fact that it didn't recognise the MBR
> > partitions (it only had a single diskid entry on the mount-root prompt).
> >
> > Can anyone explain to me how these kernel options work, as in: they are
> > defined in kernel configs and as a consequence in opt_geom.h, but how are
> > they actually used to select which geom_part_* modules/kernel parts to
> > build? I thought these options were translated to stuff that cpp would
> use,
> > but there are not uses of for example GEOM_PART_MBR anywhere for example!
> >
> >
> > The module always build them because they are listed in the module's
> > Makefile.
> >
> > The kernel only sometimes does. Here's the key lines from conf/files:
> > files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> > files:geom/part/g_part_apm.c optional geom_part_apm
> > files:geom/part/g_part_bsd.c optional geom_part_bsd
> > files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> > files:geom/part/g_part_ebr.c optional geom_part_ebr
> > files:geom/part/g_part_gpt.c optional geom_part_gpt
> > files:geom/part/g_part_ldm.c optional geom_part_ldm
> > files:geom/part/g_part_mbr.c optional geom_part_mbr
> > files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> >
> > which turn on/off which files get included. config "helpfully" converts
> the
> > upper case options to lower case for this.
> >
> > Warner
> >
> >
> > *slaps forehead* Goose chase!
> >
> > I actually knew that... and, at the time, thought it was weird behaviour.
> > ''grep" would not have failed me if those options would be uppercase
> there
> > ...
> >
>
> I've been nibbled to death by these geese often enough to have a PTSD-like
> reaction when someone mentions it and habitually add -i to my greps...
>
> Warner


This horrid POLA violation seems to have been in FreeBSD configuration
since at least 3.0 and probably goes back to the creation of the
configuration process.

Any idea why such a horrible POLA was ever introduced? Seems like an
obviously bad idea in an OS that is ALMOST always case sensitive.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: How do GEOM_PART_* options configure geom_part_* modules??

[Ian Lepore]

On Thu, 2017-09-28 at 17:31 +0200, Nick Hibma wrote:
> I created a new kernel config file from scratch, wondered what the
> GEOM_PART_MBR option and friends were doing, search for them, didn't
> find them in the tree, and deleted them from my config. But... de
> resulting disk image didn't boot, because of the fact that it didn't
> recognise the MBR partitions (it only had a single diskid entry on
> the mount-root prompt).
> 
> Can anyone explain to me how these kernel options work, as in: they
> are defined in kernel configs and as a consequence in opt_geom.h, but
> how are they actually used to select which geom_part_* modules/kernel
> parts to build? I thought these options were translated to stuff that
> cpp would use, but there are not uses of for example GEOM_PART_MBR
> anywhere for example!
> 
> The only thing I was able to come up with, but could not figure out,
> was FEATURE() doing some magic.
> 
> Thanks in advance for any pointers!
> 
> Nick Hibma
> n...@van-laarhoven.org 
> 
> -- Open Source: We stand on the shoulders of giants.
> 
> 
> % grep -r GEOM_PART_ /usr/src/sys/ | grep -Ev '/conf/.*options'
> /usr/src/sys/geom/part/g_part_mbr.c:"GEOM_PART_MBR Master Boot
> Record");
> /usr/src/sys/geom/part/g_part_ldm.c:"GEOM_PART_LDM Logical Disk
> Manager");
> /usr/src/sys/geom/part/g_part_ldm.c:   * XXX: We use some
> knowledge about GEOM_PART_GPT internal
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part.h:#ifndef _GEOM_PART_H_
> /usr/src/sys/geom/part/g_part.h:#define   _GEOM_PART_H_
> /usr/src/sys/geom/part/g_part.h:#endif /* !_GEOM_PART_H_ */

If you had added '-i' to your grep command you would have found the
missing piece in sys/conf/files.  config(8) turns uppercase OPTION_NAME
into lowercase option_name for purposes of configuring which files to
compile.

-- Ian

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

Re: How do GEOM_PART_* options configure geom_part_* modules??

[Warner Losh]

On Thu, Sep 28, 2017 at 10:00 AM, Nick Hibma  wrote:

> I created a new kernel config file from scratch, wondered what the
> GEOM_PART_MBR option and friends were doing, search for them, didn't find
> them in the tree, and deleted them from my config. But... de resulting disk
> image didn't boot, because of the fact that it didn't recognise the MBR
> partitions (it only had a single diskid entry on the mount-root prompt).
>
> Can anyone explain to me how these kernel options work, as in: they are
> defined in kernel configs and as a consequence in opt_geom.h, but how are
> they actually used to select which geom_part_* modules/kernel parts to
> build? I thought these options were translated to stuff that cpp would use,
> but there are not uses of for example GEOM_PART_MBR anywhere for example!
>
>
> The module always build them because they are listed in the module's
> Makefile.
>
> The kernel only sometimes does. Here's the key lines from conf/files:
> files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> files:geom/part/g_part_apm.c optional geom_part_apm
> files:geom/part/g_part_bsd.c optional geom_part_bsd
> files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> files:geom/part/g_part_ebr.c optional geom_part_ebr
> files:geom/part/g_part_gpt.c optional geom_part_gpt
> files:geom/part/g_part_ldm.c optional geom_part_ldm
> files:geom/part/g_part_mbr.c optional geom_part_mbr
> files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
>
> which turn on/off which files get included. config "helpfully" converts the
> upper case options to lower case for this.
>
> Warner
>
>
> *slaps forehead* Goose chase!
>
> I actually knew that... and, at the time, thought it was weird behaviour.
> ''grep" would not have failed me if those options would be uppercase there
> ...
>

I've been nibbled to death by these geese often enough to have a PTSD-like
reaction when someone mentions it and habitually add -i to my greps...

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: How do GEOM_PART_* options configure geom_part_* modules??

[Nick Hibma]

>> I created a new kernel config file from scratch, wondered what the
>> GEOM_PART_MBR option and friends were doing, search for them, didn't find
>> them in the tree, and deleted them from my config. But... de resulting disk
>> image didn't boot, because of the fact that it didn't recognise the MBR
>> partitions (it only had a single diskid entry on the mount-root prompt).
>> 
>> Can anyone explain to me how these kernel options work, as in: they are
>> defined in kernel configs and as a consequence in opt_geom.h, but how are
>> they actually used to select which geom_part_* modules/kernel parts to
>> build? I thought these options were translated to stuff that cpp would use,
>> but there are not uses of for example GEOM_PART_MBR anywhere for example!
>> 
> 
> The module always build them because they are listed in the module's
> Makefile.
> 
> The kernel only sometimes does. Here's the key lines from conf/files:
> files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
> files:geom/part/g_part_apm.c optional geom_part_apm
> files:geom/part/g_part_bsd.c optional geom_part_bsd
> files:geom/part/g_part_bsd64.c optional geom_part_bsd64
> files:geom/part/g_part_ebr.c optional geom_part_ebr
> files:geom/part/g_part_gpt.c optional geom_part_gpt
> files:geom/part/g_part_ldm.c optional geom_part_ldm
> files:geom/part/g_part_mbr.c optional geom_part_mbr
> files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8
> 
> which turn on/off which files get included. config "helpfully" converts the
> upper case options to lower case for this.
> 
> Warner

*slaps forehead* Goose chase!

I actually knew that... and, at the time, thought it was weird behaviour. 
''grep" would not have failed me if those options would be uppercase there ...

Thanks, Warner.

Nick


signature.asc
Description: Message signed with OpenPGP

Re: How do GEOM_PART_* options configure geom_part_* modules??

[Warner Losh]

On Thu, Sep 28, 2017 at 9:31 AM, Nick Hibma  wrote:

> I created a new kernel config file from scratch, wondered what the
> GEOM_PART_MBR option and friends were doing, search for them, didn't find
> them in the tree, and deleted them from my config. But... de resulting disk
> image didn't boot, because of the fact that it didn't recognise the MBR
> partitions (it only had a single diskid entry on the mount-root prompt).
>
> Can anyone explain to me how these kernel options work, as in: they are
> defined in kernel configs and as a consequence in opt_geom.h, but how are
> they actually used to select which geom_part_* modules/kernel parts to
> build? I thought these options were translated to stuff that cpp would use,
> but there are not uses of for example GEOM_PART_MBR anywhere for example!
>

The module always build them because they are listed in the module's
Makefile.

The kernel only sometimes does. Here's the key lines from conf/files:
files:geom/geom_bsd_enc.c optional geom_bsd | geom_part_bsd
files:geom/part/g_part_apm.c optional geom_part_apm
files:geom/part/g_part_bsd.c optional geom_part_bsd
files:geom/part/g_part_bsd64.c optional geom_part_bsd64
files:geom/part/g_part_ebr.c optional geom_part_ebr
files:geom/part/g_part_gpt.c optional geom_part_gpt
files:geom/part/g_part_ldm.c optional geom_part_ldm
files:geom/part/g_part_mbr.c optional geom_part_mbr
files:geom/part/g_part_vtoc8.c optional geom_part_vtoc8

which turn on/off which files get included. config "helpfully" convers the
upper case options to lower case for this.

Warner

Warner


> The only thing I was able to come up with, but could not figure out, was
> FEATURE() doing some magic.
>
> Thanks in advance for any pointers!
>
> Nick Hibma
> n...@van-laarhoven.org 
>
> -- Open Source: We stand on the shoulders of giants.
>
>
> % grep -r GEOM_PART_ /usr/src/sys/ | grep -Ev '/conf/.*options'
> /usr/src/sys/geom/part/g_part_mbr.c:"GEOM_PART_MBR Master Boot
> Record");
> /usr/src/sys/geom/part/g_part_ldm.c:"GEOM_PART_LDM Logical Disk
> Manager");
> /usr/src/sys/geom/part/g_part_ldm.c: * XXX: We use some knowledge
> about GEOM_PART_GPT internal
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
> /usr/src/sys/geom/part/g_part.h:#ifndef _GEOM_PART_H_
> /usr/src/sys/geom/part/g_part.h:#define _GEOM_PART_H_
> /usr/src/sys/geom/part/g_part.h:#endif /* !_GEOM_PART_H_ */
>
___
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"

How do GEOM_PART_* options configure geom_part_* modules??

[Nick Hibma]

I created a new kernel config file from scratch, wondered what the 
GEOM_PART_MBR option and friends were doing, search for them, didn't find them 
in the tree, and deleted them from my config. But... de resulting disk image 
didn't boot, because of the fact that it didn't recognise the MBR partitions 
(it only had a single diskid entry on the mount-root prompt).

Can anyone explain to me how these kernel options work, as in: they are defined 
in kernel configs and as a consequence in opt_geom.h, but how are they actually 
used to select which geom_part_* modules/kernel parts to build? I thought these 
options were translated to stuff that cpp would use, but there are not uses of 
for example GEOM_PART_MBR anywhere for example!

The only thing I was able to come up with, but could not figure out, was 
FEATURE() doing some magic.

Thanks in advance for any pointers!

Nick Hibma
n...@van-laarhoven.org 

-- Open Source: We stand on the shoulders of giants.


% grep -r GEOM_PART_ /usr/src/sys/ | grep -Ev '/conf/.*options'
/usr/src/sys/geom/part/g_part_mbr.c:"GEOM_PART_MBR Master Boot Record");
/usr/src/sys/geom/part/g_part_ldm.c:"GEOM_PART_LDM Logical Disk Manager");
/usr/src/sys/geom/part/g_part_ldm.c: * XXX: We use some knowledge about 
GEOM_PART_GPT internal
/usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
/usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
/usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
/usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
/usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
/usr/src/sys/geom/part/g_part_ebr.c:#if defined(GEOM_PART_EBR_COMPAT)
/usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
/usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
/usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
/usr/src/sys/geom/part/g_part_ebr.c:#ifndef GEOM_PART_EBR_COMPAT
/usr/src/sys/geom/part/g_part.h:#ifndef _GEOM_PART_H_
/usr/src/sys/geom/part/g_part.h:#define _GEOM_PART_H_
/usr/src/sys/geom/part/g_part.h:#endif /* !_GEOM_PART_H_ */


signature.asc
Description: Message signed with OpenPGP

Call for 2017Q3 quarterly status reports

[Benjamin Kaduk]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is October 21,
2017, for work done in July through September.

Status report submissions do not need to be very long.  They may be about
anything happening in the FreeBSD project and community, and provide a great
way to inform FreeBSD users and developers about work that is underway and
completed.  Submission of reports is not restricted to committers; anyone
doing anything interesting and FreeBSD related can -- and should -- write one!

The preferred and easiest submission method is to use the XML generator [1]
with the results emailed to the status report team at mont...@freebsd.org .
(Do be sure, though, to save the form output and not the form itself!  In
particular, the Google Chrome "save as" function does not save the generated
output for some reason.)  There is also an XML template [2] that can be
filled out manually and attached if preferred.  For the expected content
and style, please study our guidelines on how to write a good status
report [3].  You can also review previous issues [4][5] for ideas on the
style and format.

We look forward to seeing your 2017Q3 reports!

Thanks,

Ben (on behalf of monthly@)

[1] https://www.FreeBSD.org/cgi/monthly.cgi
[2] https://www.FreeBSD.org/news/status/report-sample.xml
[3] https://www.FreeBSD.org/news/status/howto.html
[4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html
[5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html


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

Re: panic: softdep_deallocate_dependencies: dangling deps

[Gary Jennejohn]

On Wed, 27 Sep 2017 15:19:59 -0700
Steve Kargl  wrote:

> On Wed, Sep 27, 2017 at 03:13:21PM -0700, Steve Kargl wrote:
> > 
> > Hmmm,
> > 
> > %  kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.0
> > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done.
> > ABI doesn't support a vmcore target
> > 
> > OK, so debugging is broken :-/
> >   
> 
> It seems the devel/gdb80 port installs a kgdb symlink
> to kgdb80.  So, I'm not getting the correct kgdb due to 
> my path.  Ugh.
> 

Yeah.  I think the idea is to delete the old base-system kgdb when
you install the port.

-- 
Gary Jennejohn
___
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: net/asterisk13: memory leak under 12-CURRENT?

[Guido Falsi]

On 09/28/2017 09:38, Guido Falsi wrote:

> I'm not understanding what you are expecting us to do based on
> circumstantial and partial data.
> 

I'm clarifying myself here:

I mean that I don't know what to do about this based on the data and the
details you give. What you are seeing looks normal to me.

To understand better what is happening is more data.

You say you have data that shows something but in a non scientific way.
But this translates to me to you having a feeling, which I don't share
based on that data. So if you want help or a better explanation your
only way is to give more and more detailed data.

At a minimum the while memory line from top not only the "free memory:"
column, which by itself gives completely incomplete information.

It would be better if you could give the time evolution of that line.
before launching asterisk, some samples while it is running and you are
doing some tests, and after closing it.

Other tools like vmstat can give more detailed information, but I'm not
very good at deciphering that data, but it could be very useful anyway
for people more expert about the VM system to give you an explanation or
be convinced that there is actually something strange going on.

In other words I'm sorry to say you need to give more scientific proof
of your feeling. There's nothing personal in this.

-- 
Guido Falsi 
___
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: net/asterisk13: memory leak under 12-CURRENT?

[Guido Falsi]

On 09/28/2017 08:11, O. Hartmann wrote:
> On Wed, 27 Sep 2017 09:05:42 +0200
> Guido Falsi  wrote:
> 
>> On 09/26/2017 15:41, O. Hartmann wrote:
>>> On Tue, 26 Sep 2017 15:06:23 +0200
>>> Guido Falsi  wrote:  
>>
>>> Since I run net/asterisk with automatic module loading (I'm new to
>>> asterisk), this is very likely and might cause the problem somehow.
>>>   
>>
>> You can exclude single modules from autoloading via modules.conf.
>>
 Not sure, restarting the daemon should free any leaked memory the daemon 
 has. If a killed process leaves memory locked at the system level there 
 should be some other cause.  
>>>
>>> Even with no runnidng asterisk, memory level drops after the last shutdown
>>> of asterisk and keeps that low. Even for weeks! My router never shows that
>>> high memory consumption, even under load.  
>>
>> But while asterisk is running does the memory usage increase unbounded
>> till filling all available memory or does it stabilize at some point?
> 
> While Asterisk is running, it doesn't consume much memory, but stopping
> Asterisk, I would expect that the claimed memory is freed again. It isn't, not
> all memory is freed. Starting Asterisk then again from this reduced memory
> level, it claims its memory, "stabilzes" at a certain point while running and
> again, stopping Asterisk leaves the free memory now at a much lower level 
> never
> been leveld out - as I said.
> 
> I played this game last night ~ 20 times until the free memory dropped beneath
> 3 GB after asterisk has been shut down. This morning, the level was at the 
> same
> low level as I left it. The router has nothing special to do, the workload is
> not memory consuming even for weeks! And if there is load, after the load went
> away, the memory consumption always leveld out and freed memory.
>>
>> Asterisk is relatively memory hungry, especially with all modules
>> enabled. It also caches and logs various information in RAM, even doing
>> "nothing" it will cache and log that "nothing" activity. If memory does
>> stabilize after some point it's not really a leak but it's standard
>> memory usage. To reduce it you should disable all unused modules.
> 
> I don't understand here. Even if Asterisk is memory hungry - it has ~ 3 GB to
> use. But after stopping it, it should free the memory. BUT the system is then
> after the stop with less memory! that is the point. Not the running asterisk's
> memory consumption bothers me, but the fact, that after 20 start and stops and
> waiting for days the memory once gone is never put back.

VM system is not composed only of "free" and "used" ram, there ar3e
other categories. Depending on how a program allocates and uses memory
it's not automatically sent to the "free" pool after being reclaimed.

Allocated memory can be dirty buffers which are reclaimed after time, or
other types of buffered data which is never reclaimed until there is
memor7y pressure. How do you know the game you were playing has a
similar memory usage as asterisk, which, I assure you, has some complex
memory usage patterns in it's source.

Also asterisk leverages many parts of the kernel which a game does not
leverage. I'm quite sure after quitting asterisk you have an higher
"wired" memory than before starting it. That memory was not allocated by
asterisk itself, but by the kernel while "serving" asterisk requests.
The kernel keeps running and does not free that memory right away. in
fact will not free it until forced by VM pressure AFAIK.

But this is quite a complicated matter and not being a VM expert I can't
explain it in detail. What you must understand is that many things are
going on at a given time in a memory subsystem and looking at it through
a single value is not indicative.

> 
> At the moment, I have mpg123 suspect doing nasty things, because the
> vanishing memory is more prominent and indicated when voicemail system has
> been used and mpg123 started. Not touching VM subsystem seems to free the
> whole memory claimed by asterisk after stopping asterisk, apart from maybe
> buffers claimed by the OS released later (I did no thourough investigations on
> that).

Please note that when I use the "VM" Acronym I mean "Virtual Memory".

there is a new version of mpg123 also, and I'm quite sure that mpg123
causes caching of the audio data it reads. Adsterisk Voicemail system
also causes caching. Those cached are not going to be freed after
program exit because other programs could take advantage of the cached data.

I'm not understanding what you are expecting us to do based on
circumstantial and partial data.

-- 
Guido Falsi 
___
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: net/asterisk13: memory leak under 12-CURRENT?

[Guido Falsi]

On 09/28/2017 08:01, O. Hartmann wrote:

>> These numbers really don't tell us anything. The system has anyway been
>> running for days, depending on configuration daemons like cron and ntp
>> are running and performing tasks, things are being cached and so on, so
>> that difference after three days could be perfectly normal overhead.
> 
> I think they do, but not in a scientific way.

I am unable to work with such data anyway.

> 
> The system in question has to do always the same task and is running for 
> months
> with never dropping below a certain memory boundary.
> 
> Then, when asterisk started/stopped/started, memory begins to fade away and is
> never getting back to "free", even with asterisk off for days, twoo weeks. 
> Does
> this really tell me nothing?
> 

It tells you the OS is caching some data. Which is normal. You should
discover what the OS is doing with that memory. The fact that it is in
some way allocated does not indicate anything. Maybe the memory used by
asterisk is simply going in the inactive pool and never reclaimed by the
OS because it's not required, having still lots of Free memory.

There are many possibilities, and exact data is needed to investigate.
I'm also not an expert about VM systems.

Asterisk, even with few modules tends to use a big chunk of memory and
after stopping a software which uses much RAM it's normal for the OS to
not immediately reclaim that to the Free pool. In fact such reclaiming
happens only if there actually is memory pressure. There are so many
factors playing into this that just looking at Free RAM answers no question.

What problem are you trying to solve? Are you running out of memory?

>> Whatever you prefer, but trying a few days uptime with all modules
>> enabled is zero cost and east to do. Also you started this report with
>> THIS configuration, changing configuration would prevent from comparing
>> results. Let's test one thing at a time.
>>
> 
> I will.
> Now as we have a indication that there is porbably something, I'll go for
> deeper investiagtions with a static config.
> 
I disagree with the indication buyt to investigate such a problem you
need to use better tools than just looking at the free ram reported in
top. Please at least give us the other ram numbers (Used, inactive,
laundry, wired, buffers...)



-- 
Guido Falsi 
___
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: net/asterisk13: memory leak under 12-CURRENT?

[O. Hartmann]

On Wed, 27 Sep 2017 09:05:42 +0200
Guido Falsi  wrote:

> On 09/26/2017 15:41, O. Hartmann wrote:
> > On Tue, 26 Sep 2017 15:06:23 +0200
> > Guido Falsi  wrote:  
> 
> > Since I run net/asterisk with automatic module loading (I'm new to
> > asterisk), this is very likely and might cause the problem somehow.
> >   
> 
> You can exclude single modules from autoloading via modules.conf.
> 
> >> Not sure, restarting the daemon should free any leaked memory the daemon 
> >> has. If a killed process leaves memory locked at the system level there 
> >> should be some other cause.  
> > 
> > Even with no runnidng asterisk, memory level drops after the last shutdown
> > of asterisk and keeps that low. Even for weeks! My router never shows that
> > high memory consumption, even under load.  
> 
> But while asterisk is running does the memory usage increase unbounded
> till filling all available memory or does it stabilize at some point?

While Asterisk is running, it doesn't consume much memory, but stopping
Asterisk, I would expect that the claimed memory is freed again. It isn't, not
all memory is freed. Starting Asterisk then again from this reduced memory
level, it claims its memory, "stabilzes" at a certain point while running and
again, stopping Asterisk leaves the free memory now at a much lower level never
been leveld out - as I said.

I played this game last night ~ 20 times until the free memory dropped beneath
3 GB after asterisk has been shut down. This morning, the level was at the same
low level as I left it. The router has nothing special to do, the workload is
not memory consuming even for weeks! And if there is load, after the load went
away, the memory consumption always leveld out and freed memory.
> 
> Asterisk is relatively memory hungry, especially with all modules
> enabled. It also caches and logs various information in RAM, even doing
> "nothing" it will cache and log that "nothing" activity. If memory does
> stabilize after some point it's not really a leak but it's standard
> memory usage. To reduce it you should disable all unused modules.

I don't understand here. Even if Asterisk is memory hungry - it has ~ 3 GB to
use. But after stopping it, it should free the memory. BUT the system is then
after the stop with less memory! that is the point. Not the running asterisk's
memory consumption bothers me, but the fact, that after 20 start and stops and
waiting for days the memory once gone is never put back.

At the moment, I have mpg123 suspect doing nasty things, because the
vanishing memory is more prominent and indicated when voicemail system has
been used and mpg123 started. Not touching VM subsystem seems to free the
whole memory claimed by asterisk after stopping asterisk, apart from maybe
buffers claimed by the OS released later (I did no thourough investigations on
that).
 
> 
> > 
> > The question would be: how to use vmstat to give hints for those familiar
> > with memory subsystems to indicate a real bug?
> > 
> > I tried to find some advices, but maybe my English isn't good enough to make
> > google help.  
> 
> I'm not able to give you a correct indication, but if the memory usage
> is not increasing indefinitely but is stabilizing I'd say it's not
> really a leak.
> 

___
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: net/asterisk13: memory leak under 12-CURRENT?

[O. Hartmann]

On Wed, 27 Sep 2017 12:23:20 +0200
Guido Falsi  wrote:

> On 09/27/2017 11:27, O. Hartmann wrote:
> > On Wed, 27 Sep 2017 09:05:42 +0200
> > Guido Falsi  wrote:  
> >> But while asterisk is running does the memory usage increase unbounded
> >> till filling all available memory or does it stabilize at some point?  
> > 
> > As far as I could observe, a three day test run of the
> > router/firewall/asterisk box drained around 500 MB of memory: starting at
> > boot time with ~3700 MB, asterisk leaves the box with ~3640 MB after bein
> > started and after three days the system reached ~3150 MB. Stopping asterisk
> > gave back some memory, so ~3300 MB then was for days the final result - not
> > recovering anything further. I use TEMPFS, if it matters, but I
> > checked /tmp and /var/, there were no remnant files so far. TMPVAR is only
> > allowed to have 256 MB. 
> 
> These numbers really don't tell us anything. The system has anyway been
> running for days, depending on configuration daemons like cron and ntp
> are running and performing tasks, things are being cached and so on, so
> that difference after three days could be perfectly normal overhead.

I think they do, but not in a scientific way.

The system in question has to do always the same task and is running for months
with never dropping below a certain memory boundary.

Then, when asterisk started/stopped/started, memory begins to fade away and is
never getting back to "free", even with asterisk off for days, twoo weeks. Does
this really tell me nothing?

> 
> You need to investigate the amount of memory allocated to asterisk with
> ps and top and check if that stabilizes. A few days, at most a week
> would be enough. After that, if it's not stabilizing you can start
> thinking on a leak, but still can't assume where the leak is happening.
> 
> 
> > Can't say whether it is stabilising or not - I think the runtime is too
> > short. I'll check first to disable some modules in the first place and then
> > try to perform a test with several days of asterisk enabled.
> >   
> 
> Whatever you prefer, but trying a few days uptime with all modules
> enabled is zero cost and east to do. Also you started this report with
> THIS configuration, changing configuration would prevent from comparing
> results. Let's test one thing at a time.
> 

I will.
Now as we have a indication that there is porbably something, I'll go for
deeper investiagtions with a static config.

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