Re: svn commit: r336751 - head/usr.sbin/pw

[Ian Lepore]

On Fri, 2018-07-27 at 14:43 +, Li-Wen Hsu wrote:
> On Thu, Jul 26, 2018 at 20:03:11 +0000, Ian Lepore wrote:
> > 
> > Author: ian
> > Date: Thu Jul 26 20:03:11 2018
> > New Revision: 336751
> > URL: https://svnweb.freebsd.org/changeset/base/336751
> > 
> > Log:
> >   Re-apply r336625 which was reverted with r336638, now that the underlying
> >   pw_scan(3) has been fixed in a way that doesn't perturb other callers of
> >   it or the getpwnam(3) family.
> >   
> >   Make pw(8) showuser work the same with or without -R  for non-root
> >   users.  Without -R, pw(8) uses getpwnam(3), which will open master.passwd
> >   for the root user or passwd for non-root users.  With -R  pw(8) was
> >   always opening /master.passwd, which would fail for a non-root user,
> >   then falsely claim the userid you're trying to show doesn't exist.
> >   
> >   Now for a non-root user it opens /passwd, and populates the fields in
> >   the returned struct passwd which aren't present in that file with 
> > well-known
> >   canonical values, which duplicates the behavior of getpwnam(3).  The net
> >   effect is that the showuser output is identical whether using -R or not.
> > 
> > Modified:
> >   head/usr.sbin/pw/pw_vpw.c
> Hi Ian,
> 
> It seems usr.sbin.pw.* tests are failing after this commit:
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8367/testReport/
> 
> Can you help me check this is realted to the new pw code or there is
> anything we need to modify in the test VM setup or running environment.
> 
> The related artifacts are available here:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r336751/amd64/amd64/
> 
> You can use disk-test.img.xz which is a VM with setup testing
> environment.  The build script will start automatically but you can
> ctrl-c to interrupt anytime and run tests by hand:
> 
> cd /usr/tests/usr.sbin/pw
> kyua test

This was just an error on my part, the code was wrong and I fixed it in
r336762. This time I made sure the kyua tests pass first.

I had intended to run the kyua tests before and after re-applying my
changes to pw(8). Now that I look in my scrollback, it seems I ran the
"before" tests, then got distracted and forgot to run them again after
and just committed the changes. Sorry about the breakage.

-- 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: ntpd as ntpd user question

[Ian Lepore]

On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote:
> On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote:
> > 
> > 
> > Yes, first you press m. Then you will see differences of installed
> > file (left) and new file (right). Then you press either l or
> > r:
> > 
> > l | 1:  choose left diff
> > r | 2:  choose right diff
> > 
> > If the diff tries to remove/add to many lines you can:
> > 
> > el: edit left diff
> > er: edit right diff
> > 
> > And if done you can view the merged file (v) before installing (i)
> > it.
> > 
> > I am sure, someone can explain it better! :)
> > 
> Perhaps, but you've made the essential point. Your reply let me
> understand that 
> mergemaster does not really "master" the merge, it rather identifies
> files needing 
> to be merged and then starts sdiff to let me modify files. Never
> having even looked 
> at sdiff, the learning curve proved very steep. Too steep, in fact.
> 
> I'm going to try a more incremental approach. 
> 
> Thank you _very_ much!
> 
> bob prohaska

Your reaction to mergemaster is about the same as mine was when I first
encountered it very long ago, and re-discovered when I tried it a
couple years ago. It just seems like more trouble than it's worth, I
can usually figure out what's broken and fix it by hand faster than
messing with all the merge stuff.

But, someone told me that if you give mergemaster the right flags it
can potentially be intervention-free. Those apparently aren't the flag
or two that're suggested at the bottom of UPDATING. So I didn't really
dig into that any deeper, but I toss it out there in case someone can
expand on it.

It certainly makes some sense that it could be done intervention-free.
When doing other diff-based merges (like 'svn update') you only have to
intervene when there's an actual conflict between some local change
you've made and the incoming changes.

-- 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: ntpd as ntpd user question

[Ian Lepore]

On Sat, 2018-07-21 at 15:09 -0700, bob prohaska wrote:
> On Sat, Jul 21, 2018 at 12:14:10PM -0600, Ian Lepore wrote:
> > 
> > 
> > I can't see any way that installkernel would lead to the complaint
> > about the ntpd user not existing; that check is tied to the
> > installworld target.
> > 
> My mistake. I was sleepy and in a hurry. The error message was in
> installworld
> and my attempt to adduser ntpd concluded with an error:
> Locked : yes
> OK? (yes/no): yes
> pw: Bad id 'ntpd': invalid
> adduser: ERROR: There was an error adding user (ntpd).
> On reboot the old ntpd set the clock and I thought all was well.
> 
> The failure is a little surprising, is ntpd a reserved name?
> 
> The machine is re-running buildworld/installworld from a clean start,
> so presumably it'll halt over the same error again. When that
> happens, 
> what's the simplest way to recover? Mergemaster is a big hammer,
> something
> less comprehensive might suffice, even manual editing of files.  
> 
> There's minimal customization on the machine, basically /etc/fstab, 
> /etc/rc.conf and /etc/passwd. Nothing else of real value, so if I
> kill 
> it in the attempt it won't be a disaster.
> 
> 
> Thanks for waking me to my blunder...
> 
> bob prohaska
>  

The important changes that mergemaster would handle are:

  - add ntpd user, id 123
  - add ntpd group, id 123
  - set ntpd_flags="" in /etc/defaults/rc.conf
  - install the new /etc/rc.d/ntpd

You can add the user by doing vipw and pasting the ntpd line from
/usr/src/etc/master.passwd, IMO easier than doing adduser and answering
all the questions.

-- 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: ntpd as ntpd user question

[Ian Lepore]

On Sat, 2018-07-21 at 10:47 -0700, bob prohaska wrote:
> On Sat, Jul 21, 2018 at 11:14:45AM -0600, Ian Lepore wrote:
> > 
> > 
> > There's a "pre-world" stage of mergemaster (-Fp option I think) which
> > isn't needed often, but one of the times it is needed is apparently
> > when new user ids are added. ?(So I've been told, I've never much used
> > mergemaster myself). I think there are some words about it at the very
> > bottom of UPDATING.
> > 
> FWIW, installkernel stopped with the note about needing an ntpd user/group.
> Never having been successful with mergemaster (couldn't make heads nor tails
> of the "what to do" prompts) I just ran adduser, creating a locked ntpd user
> and group. Nothing else special done. The machine is up to r336567 on arm64.
> 
> Installkernel ran, I didn't touch anthing in /etc manually and reboot looked 
> normal.
> For now it seems ignorance is bliss
> 
> If there's something special I should do (beyond locking) to secure the ntpd 
> account please warn me.
> 
> Thanks for reading,
> 
> bob prohaska

I can't see any way that installkernel would lead to the complaint
about the ntpd user not existing; that check is tied to the
installworld target.

A quick way to check whether ntpd is running as ntpd user:

 procstat cred `pgrep ntpd`

 PID  COMM  EUID  RUID SVUID  EGID  RGID SVGID UMASK FLAGS GROUPS
 1176 ntpd   123   123   123   123   123   123   022 - 123

-- 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: ntpd as ntpd user question

[Ian Lepore]

On Sat, 2018-07-21 at 10:11 -0700, Pete Wright wrote:
> 
> On 07/21/2018 09:47, Ian Lepore wrote:
> > 
> > On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
> > > 
> > > hello - i am testing out the new ntpd that was committed
> > > yesterday and
> > > am attempting to run as non-root.  i've created a ntpd
> > > user/group, and
> > > verified permissions look good on pertinent directories.  i am
> > > running
> > > into an issue with the rc script tho - it's complaining about
> > > multiple
> > > pid files being specified?
> > > 
> > > $ sudo /etc/rc.d/ntpd start
> > > Starting ntpd.
> > > ntpd error:  only one pidfile option allowed
> > > ntpd - NTP daemon program - Ver. 4.2.8p11
> > > Usage:  ntpd [ - [] | --[{=| }] ]... \
> > >       [  ...  ]
> > > Try 'ntpd --help' for more information.
> > > /etc/rc.d/ntpd: WARNING: failed to start ntpd
> > > 
> > > 
> > > has anyone else seen this issue? not sure if this is an issue
> > > with my
> > > local config or not, i've read through the rc script and its not
> > > obvious
> > > to me yet why it may be getting multiple pid arguments passed. 
> > > the only
> > > relevant bit i have set in rc.conf is:
> > > 
> > > $ grep ntpd /etc/rc.conf
> > > ntpd_enable="YES"
> > > 
> > > 
> > > thanks!
> > > -pete
> > > 
> > You say you created an ntpd user/group, that seems to imply you
> > didn't
> > run mergemaster (which would have done that). If that's the case,
> > you
> > probably also didn't get /etc/defaults/rc.conf updated, so it still
> > has
> > the old ntpd_flags that includes the pidfile (which is now provided
> > by
> > the startup script and shouldn't be set in ntpd_flags).
> > 
> > If all of that is the wrong guess, let me know and we'll figure it
> > out.
> that's Ian - that's most likely it (defaults/rc.conf).  i did run 
> mergemaster but i suspect i didn't run it correctly b/c it didn't
> copy 
> over any files, nor create the ntpd uid/gid.  my buildworld script
> does 
> a "mergemaster -m $CHECKOUT -a".  i'll re-read the man page today
> and 
> update my scripts accordingly.
> 
> thanks again for the bread-crumb!
> -pete
> 

There's a "pre-world" stage of mergemaster (-Fp option I think) which
isn't needed often, but one of the times it is needed is apparently
when new user ids are added.  (So I've been told, I've never much used
mergemaster myself). I think there are some words about it at the very
bottom of UPDATING.

-- 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: ntpd as ntpd user question

[Ian Lepore]

On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
> hello - i am testing out the new ntpd that was committed yesterday and 
> am attempting to run as non-root.  i've created a ntpd user/group, and 
> verified permissions look good on pertinent directories.  i am running 
> into an issue with the rc script tho - it's complaining about multiple 
> pid files being specified?
> 
> $ sudo /etc/rc.d/ntpd start
> Starting ntpd.
> ntpd error:  only one pidfile option allowed
> ntpd - NTP daemon program - Ver. 4.2.8p11
> Usage:  ntpd [ - [] | --[{=| }] ]... \
>      [  ...  ]
> Try 'ntpd --help' for more information.
> /etc/rc.d/ntpd: WARNING: failed to start ntpd
> 
> 
> has anyone else seen this issue? not sure if this is an issue with my 
> local config or not, i've read through the rc script and its not obvious 
> to me yet why it may be getting multiple pid arguments passed.  the only 
> relevant bit i have set in rc.conf is:
> 
> $ grep ntpd /etc/rc.conf
> ntpd_enable="YES"
> 
> 
> thanks!
> -pete
> 

You say you created an ntpd user/group, that seems to imply you didn't
run mergemaster (which would have done that). If that's the case, you
probably also didn't get /etc/defaults/rc.conf updated, so it still has
the old ntpd_flags that includes the pidfile (which is now provided by
the startup script and shouldn't be set in ntpd_flags).

If all of that is the wrong guess, let me know and we'll figure it out.

-- 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: [PATCH] Recent libm additions

[Ian Lepore]

On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote:
> On Sun, Jul 15, 2018, 11:23 AM K. Macy  wrote:
> 
> > 
> > > 
> > > 
> > > Well, actually, the functions in polevll.c should have been
> > > copied
> > > into ld80/e_powl.c, and polevall.c should never have been
> > > committed.
> > > Unfortunately, the code was not reviewed for correctness.
> > That is not correct. Please stop repeating it. Bruce Evans and John
> > Baldwin were both looped in. Neither made this observation.
> > 
> Steve is the fp guy these days. And it wasn't reviewed by him. He's
> mad you
> cut him out of the loop. Arguing about pedantic points of process
> does no
> one any good.
> 
> Warner

On the other hand, what information is there for someone to know that
Steve should be involved in a review? There is nothing in MAINTAINERS.
The review was on phab for almost a month, and phab is supposedly the
preferred way to do reviews these days.

Steve is no longer a committer, but that doesn't preclude him having a
phab account and participating in reviews. If he doesn't like using
phab (and I can certainly understand that POV), an entry in MAINTAINERS
would still be helpful, unless we have a rule that only committers can
be listed in there.

-- 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: [PATCH] Recent libm additions

[Ian Lepore]

On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote:
> Apparently, the recents additions to libm were not
> subject to any code review.  The following patch 
> does two things.  First, it works around
> 
> https://bugs.llvm.org/show_bug.cgi?id=8532
> 
> Second, it removes the pollution of libm with the
> polevll.c functions.  Those functions are used 
> only in ld80/e_powl.c, and those functions should
> be inlined.
> 
> Index: Makefile
> ===
> --- Makefile  (revision 336304)
> +++ Makefile  (working copy)
> @@ -56,7 +56,6 @@
>   imprecise.c \
>   k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
>   k_tan.c k_tanf.c \
> - polevll.c \
>   s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c s_cargl.c \
>   s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
>   s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
> Index: ld80/e_powl.c
> ===
> --- ld80/e_powl.c (revision 336304)
> +++ ld80/e_powl.c (working copy)
> @@ -77,6 +77,7 @@
>  #include 
>  
>  #include "math_private.h"
> +#include "polevll.c"
>  
>  /* Table size */
>  #define NXT 32
> Index: src/math_private.h
> ===
> --- src/math_private.h(revision 336304)
> +++ src/math_private.h(working copy)
> @@ -828,7 +828,4 @@
>  long double __kernel_cosl(long double, long double);
>  long double __kernel_tanl(long double, long double, int);
>  
> -long double __p1evll(long double, void *, int);
> -long double __polevll(long double, void *, int);
> -
>  #endif /* !_MATH_PRIVATE_H_ */
> Index: src/polevll.c
> ===
> --- src/polevll.c (revision 336304)
> +++ src/polevll.c (working copy)
> @@ -69,7 +69,7 @@
>   * Polynomial evaluator:
>   *  P[0] x^n  +  P[1] x^(n-1)  +  ...  +  P[n]
>   */
> -long double
> +static inline long double
>  __polevll(long double x, void *PP, int n)
>  {
>   long double y;
> @@ -88,7 +88,7 @@
>   * Polynomial evaluator:
>   *  x^n  +  P[0] x^(n-1)  +  P[1] x^(n-2)  +  ...  +  P[n]
>   */
> -long double
> +static inline long double
>  __p1evll(long double x, void *PP, int n)
>  {
>   long double y;
> Index: src/s_cpow.c
> ===
> --- src/s_cpow.c  (revision 336304)
> +++ src/s_cpow.c  (working copy)
> @@ -60,7 +60,7 @@
>   y = cimag (z);
>   absa = cabs (a);
>   if (absa == 0.0) {
> - return (0.0 + 0.0 * I);
> + return (CMPLX(0.0, 0.0));
>   }
>   arga = carg (a);
>   r = pow (absa, x);
> @@ -69,6 +69,6 @@
>   r = r * exp (-y * arga);
>   theta = theta + y * log (absa);
>   }
> - w = r * cos (theta) + (r * sin (theta)) * I;
> + w = CMPLX(r * cos (theta),  r * sin (theta));
>   return (w);
>  }
> Index: src/s_cpowf.c
> ===
> --- src/s_cpowf.c (revision 336304)
> +++ src/s_cpowf.c (working copy)
> @@ -59,7 +59,7 @@
>   y = cimagf(z);
>   absa = cabsf (a);
>   if (absa == 0.0f) {
> - return (0.0f + 0.0f * I);
> + return (CMPLXF(0.0f, 0.0f));
>   }
>   arga = cargf (a);
>   r = powf (absa, x);
> @@ -68,6 +68,6 @@
>   r = r * expf (-y * arga);
>   theta = theta + y * logf (absa);
>   }
> - w = r * cosf (theta) + (r * sinf (theta)) * I;
> + w = CMPLXF(r * cosf (theta), r * sinf (theta));
>   return (w);
>  }
> Index: src/s_cpowl.c
> ===
> --- src/s_cpowl.c (revision 336304)
> +++ src/s_cpowl.c (working copy)
> @@ -59,7 +59,7 @@
>   y = cimagl(z);
>   absa = cabsl(a);
>   if (absa == 0.0L) {
> - return (0.0L + 0.0L * I);
> + return (CMPLXL(0.0L, 0.0L));
>   }
>   arga = cargl(a);
>   r = powl(absa, x);
> @@ -68,6 +68,6 @@
>   r = r * expl(-y * arga);
>   theta = theta + y * logl(absa);
>   }
> - w = r * cosl(theta) + (r * sinl(theta)) * I;
> + w = CMPLXL(r * cosl(theta), r * sinl(theta));
>   return (w);
>  }
> 

If a file contains inline function definitions and is intended only to
be included into another file and not compiled separately, shouldn't
its name be spelled polevll.h ?

-- 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: sys/Makefile .if defined(MODULES_WITH_WORLD)

[Ian Lepore]

On Mon, 2018-07-09 at 11:50 +0200, Julian H. Stacey wrote:
> Hi current@
> src/sys/dev/amdsbwd/amdsbwd.c broke src/sys/modules
> 
> Is it immediately intuitive & well known to developers working in
> sys/dev
> to enable MODULES_WITH_WORLD before a test make all before a commit ?
> 
> Or what should we do to increase the liklehood of commiters catching
> modules/ errors before a commit ?
> 
> With src/
>   .ctm_status src-cur 13573
>   .svn_revision 335362
> sys/Makefile has
>   .if defined(MODULES_WITH_WORLD)
>   SUBDIR+=modules
> & nothing from cd /usr/src; find . -name \*src.conf\*
> & no default /etc/src.conf with no
>   MODULES_WITH_WORLD=YES
> so make all does not build /sys/modules/ 
> so this not seen from /sys/modules/
> ===> amdsbwd (all)
> cc  -O2 -pipe -DBERKLIX=YES  -fno-strict-aliasing -Werror -D_KERNEL
> -DKLD_MODULE -nostdinc   -I. -I/data/release/s1/usr/src/sys
> -I/data/release/s1/usr/src/sys/contrib/ck/include -fno-common  -fno-
> omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  -
> MF.depend.amdsbwd.o -MTamdsbwd.o -mcmodel=kernel -mno-red-zone -mno-
> mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables
> -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-
> arith -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-
> tautological-compare -Wno-error-empty-body -Wno-error-parentheses-
> equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-
> error-shift-negative-value -Wno-address-of-packed-member  -mno-aes
> -mno-avx  -std=iso9899:1999 -c
> /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c -o amdsbwd.o
> /data/release/s1/usr/src/sys/dev/amdsbwd/amdsbwd.c:52:10: fatal
> error: 
>   'opt_amdsbwd.h' file not found
> #include "opt_amdsbwd.h"
> 
> 
> PS With 
>   .ctm_status src-cur 13601
>   .svn_revision   336117
> nothing from
>   find . -name opt_amdsbwd.h
> but this has
>   src/sys/dev/amdsbwd/amdsbwd.c
>   #include "opt_amdsbwd.h"
> I haven't yet upgraded my src/ yet to see if it still fails.
> 
> Cheers,
> Julian

Should be fixed in r336134.

-- 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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Ian Lepore]

On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> Hi!
> 
> Have you or Warner any update on this code?
> 
> On Thursday, April 12, 2018, Eric McCorkle 
> wrote:
> 

Are you aware of https://reviews.freebsd.org/D15743 ?

That's my changes to add geli support to loader(8) in an architecture-
agnostic way, so that "it just works" for all platforms and flavors of
loader. It has been succesfully tested on armv6/7 (ubldr) and on x86
using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The
only variations that aren't tested yet are the uefi flavors, because
the current rootgen.sh script for assembling test images is still using
boot1.efi and I don't know enough about efi myself to update the script
to make it assemble images the new way Warner envisions.

-- Ian

> > 
> > I'm in the middle of moving to a new apartment right now.  It's
> > going to
> > be a bit before I can get to this.
> > 
> > On 04/11/2018 20:31, Warner Losh wrote:
> > > 
> > > OK. I've pushed in the main part of it. The additional work I
> > > have
> > > shouldn't affect any of this stuff.  I was going to look at what
> > > part(s)
> > > of your open reviewed needed to be redone tomorrow and send you
> > > feedback, but if you wanted to get a start before then, I'm happy
> > > to
> > > answer questions. All the rest of my work is going to be
> > > selecting the
> > > root partition when we're told to us a specific partition, so
> > > will be
> > > very constrained.
> > > 
> > > Warner
> > > 
> > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > net
> > > > wrote:
> > > 
> > > I think the thing to do at this point is to wait for the
> > > current
> > work on
> > > 
> > > loader.efi to land, then adapt my patches to apply against
> > > that work.
> > > 
> > > On 04/11/2018 15:06, Warner Losh wrote:
> > > > Still reviewing the code. I'm worried it's too i386
> > > specific and it
> > > > conflicts with some work I'm doing. I'll have a list of
> > > actionable
> > > > critiques this week.
> > > >
> > > > Warner
> > > >
> > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > >  > > 
> > >  > > >>
> > > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > Is there any update regarding the rebase or the
> > > inclusion to
> > base
> > > 
> > > > system?
> > > > On 3/28/18, Eric McCorkle  > >  > e...@metricspace.net>
> > > 
> > > >  > > et>>>
> > wrote:
> > > 
> > > > > I'll do another rebase from head just to be sure
> > > > >
> > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh <
> > i...@bsdimp.com 
> > > 
> > > > >> wrote:
> > > > >>It's on my list for nexr, finally. I have an
> > > alternate patch
> > for
> > > 
> > > > >>loader.efi
> > > > >>from ESP, but i don't think it will affect the GELI
> > > stuff. I
> > have some
> > > 
> > > > >>time
> > > > >>slotted for integration issues though.
> > > > >>
> > > > >>I am quite mindful of the freeze dates I  have
> > > some uefi
> > boot
> > > 
> > > > >>loader
> > > > >>protocol changes that I need to get in.
> > > > >>
> > > > >>Warner
> > > > >>
> > > > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" <
> > tommi.pern...@iki.fi 
> > > 
> > > >  > > fi>>>
> > wrote:
> > > 
> > > > >>
> > > > >>> Awesome, thanks for the update and the work that
> > > you have
> > done!
> > > 
> > > > >>>
> > > > >>> Now we just need some more reviewers eyes on the
> > > code :)
> > > > >>>
> > > > >>> Br,
> > > > >>>
> > > > >>> Tommi
> > > > >>>
> > > > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <
> > e...@metricspace.net 
> > > 
> > > >  > > et>>>
> > > > >>wrote:
> > > > >>>
> > > >  FYI, I just IFC'ed everything, and the current
> > > patches
> > > are still
> > > > >>fine.
> > > > 
> > > >  Also, the full GELI + standalone loader has been
> > > deployed
> > > on one of
> > > > >>my
> > > >  laptops for some time now.
> > > > 
> > > >  On 02/21/2018 18:15, Eric McCorkle wrote:
> > > >  > The GELI work could be merged at this point,
> > > though it
> > > won't be
> > > > >>usable
> > > >  > without an additional patch to enable loader-
> > > only
> > > operation.  T

Re: TSC calibration in virtual machines

[Ian Lepore]

On Wed, 2018-06-27 at 10:05 -0700, Rodney W. Grimes wrote:
> > 
> > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim 
> > wrote:
> > 
> > > 
> > > On 06/27/2018 03:14, Andriy Gapon wrote:
> > > > 
> > > > 
> > > > It seems that TSC calibration in virtual machines sometimes can
> > > > do more
> > > harm
> > > > 
> > > > than good.  Should we default to trusting the information
> > > > provided by a
> > > hypervisor?
> > > > 
> > > > 
> > > > Specifically, I am observing a problem on GCE instances where
> > > > calibrated
> > > TSC
> > > > 
> > > > frequency is about 10% lower than advertised frequency.  And
> > > > apparently
> > > the
> > > > 
> > > > advertised frequency is the right one.
> > > > 
> > > > I found this thread with similar reports and a variety of
> > > > workarounds
> > > from
> > > > 
> > > > administratively disabling the calibration to switching to a
> > > > different
> > > timecounter:
> > > > 
> > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-
> > > January/80.html
> > > 
> > > We already do that for VMware hosts since r221214.
> > > 
> > > https://svnweb.freebsd.org/changeset/base/221214
> > > 
> > > We should do the same for each hypervisor.
> > > 
> > > Jung-uk Kim
> > > 
> > > 
> > We probably should.  But why does calibration fail in the first
> > place?  If
> > it can fail in a VM, then it can probably fail on bare metal
> > too.  It would
> > be worth investigating.
> No, the failure in a VM is unique to a VM, it has to do with the fact
> your have the hypervisor timeslicing a CPU that you believe to be
> 100%
> dedicated to you.
> 
> There are several white papers, including one from VMWare about what
> they have done to help with the time keeping problems.
> 
> What is suggested above would be a correct thing to do.
> Bhyve creates these issues as well, and use of certain timers
> in a bhyve guest can cause you nightmares with ntp.

Iirc, bhyve's arithmetic when doing timer emulation leads to roundoff
errors that accumulate to effectively make the emulated timer run off-
frequency. The hpet timer was trivial to fix by just redefining it to
run at a power-of-2 frequency to eliminate rounding errors. The other
timers have to run at fixed frequencies, so better arithmetic will be
the way to fix them. I vaguely remember that being harder to do than to
say because of the way the code is currently structured, which is why I
just did the easy fix to the hpet so that people would have at least
one usable timer that didn't give ntpd fits in guest OSes.

-- 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: GELI attach issue from r326073 -> r334996

[Ian Lepore]

On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote:
> Hi!
> 
> I just tried updating current from r326073 -> r334996 and when
> I try 'geli attach' I get the following error:
> 
> # geli attach -p -k mykey.key /dev/gpt/da14
> geli: Missing keyno argument
> #
> 
> If I boot the old kernel GELI attaches just fine.
> 
> I ran into this once before but can not find the thread.  I recall
> it being a bug... with no resolution.
> 
> I mount zfs partitions over GELI - my painful solution was to
> nuke each GPT partition in the zpool, resilver, repeat and
> rinse until everything was non-encrypted and repeat the cycle
> to re-encrypt.  NOT FUN.
> 
> Looking for suggestions to supply additional information to debug
> and resolve.
> 
> dmesg attached from working kernel.
> 
> Thanks!

r333439 added a '-n keyno' parameter to geli attach, but it's supposed
to default to trying all keys if you don't use -n. Is it possible
you're running a newer kernel (or geom_eli module) than your userland
or vice versa?

-- 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: serial console vs suspend

[Ian Lepore]

On Thu, 2018-05-17 at 10:54 +0300, Andriy Gapon wrote:
> 
> It seems that the serial console, or rather a UART used by it, may require
> re-initialization after waking up (from suspend to RAM).  At least one of my
> systems fails to wake up properly if I configure the serial console.  I've 
> done
> some experimenting with cu (and without the console) and the UART seems to be 
> in
> some weird state, it echoes back the input and does not send anything on the
> wire.  I guess that trying to print to the serial console while the UART is in
> that state results in a hang.
> 
> To test the theory I made this hack and it does help:
> Index: sys/dev/uart/uart_tty.c
> ===
> --- sys/dev/uart/uart_tty.c   (revision 333667)
> +++ sys/dev/uart/uart_tty.c   (working copy)
> @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp)
>   uart_init(di);
>  }
> 
> +void uart_resume(void);
> +void
> +uart_resume(void)
> +{
> + uart_init(&uart_console);
> +}
> +
>  static void
>  uart_cnterm(struct consdev *cp)
>  {
> Index: sys/x86/acpica/acpi_wakeup.c
> ===
> --- sys/x86/acpica/acpi_wakeup.c  (revision 333667)
> +++ sys/x86/acpica/acpi_wakeup.c  (working copy)
> @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc)
>  }
>  #endif
> 
> +extern void uart_resume(void);
> +
>  int
>  acpi_sleep_machdep(struct acpi_softc *sc, int state)
>  {
> @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat
>  #else
>   npxresume(susppcbs[0]->sp_fpususpend);
>  #endif
> + uart_resume();
>   }
> 
>   return (1); /* wakeup successfully */
> 
> 
> ===
> 
> This is quick and dirty, of course.
> I think that this should go through the console layer.
> And, obviously, not all consoles actually need such a reinit.
> 
> So, maybe:
> cnresume()
> {
>   for each console {
>   if cn->cn_ops->cn_resume != NULL
>   cn->cn_ops->cn_resume(cn)
>   }
> }
> 
> uart_resume(struct consdev *cp)
> {
>   uart_init(cp->cn_arg);
> }
> 
> What do you think?
> 
> Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method.
> So, will I have to add a dummy resume to all console drivers?

Why should it go through the console layer? If the uart hardware needs
some re-init on resume, won't that be true whether the uart is serving
as a console, a dial-in terminal, or the interface to wifi or bluetooth
chip?

-- 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: IGNORE_OSVERSION=yes -- can't install pkg

[Ian Lepore]

On Sat, 2018-05-05 at 08:26 -0700, Chris H wrote:
> On Fri, 04 May 2018 22:57:52 -0700  said
> 
> > 
> > I just setup a jail from a 12-CURRENT I built awhile ago. It has no
> > ports
> > tree. So I'm attempting
> > to install svnlite. issuing pkg search svnlite returns
> > The package management tool is not yet installed on your system.
> > Do you want to fetch and install it now? [y/N]: y
> > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/
> > latest,
> > please wait...
> > Verifying signature with trusted certificate
> > pkg.freebsd.org.2013102301...
> > done
> > [12current.localhost] Installing pkg-1.10.5...
> > Newer FreeBSD version for package pkg:
> > To ignore this error set IGNORE_OSVERSION=yes
> > - package: 1200062
> > - running kernel: 1200054
> > Allow missmatch now?[Y/n]:
> > 
> > Umm, what? Should I ignore this error? If so, why is there an error
> > at all?
> > I answered no. Guess I won't be able to use pkg(8) on this jail(8).
> > :-(
> > 
> > --Chris
> OK the only reference[1] I can find regarding this, indicates that
> answering "Y"
> to Allow missmatch now? resulted in an ABI mismatch that caused
> pkg(8) to be
> unusable.
> This is on an older version of 12, so I don't have anything that
> might have
> appeared in UPDATING. I really need this jail to resolve accumulating
> pr(1)'s
> on ports(7) I maintain.
> 
> Thank you.

The difference between 1200062 and 1200054 isn't going to affect
anything except modules which are intimate with kernel internals, such
as video drivers or virtualbox type stuff.

IMO, this new version checking done by pkg(8) is just bad Bad BAD. The
only control you get is a knob that tells you to ignore any version
mismatch. There appears to be no option to get the historical worked-
really-well behavior of ignoring mismatches of the minor version for
people who track -current.

-- 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: OSVERSION

[Ian Lepore]

On Fri, 2018-05-04 at 15:28 -0600, Alan Somers wrote:
> On Fri, May 4, 2018 at 2:46 PM, Jeffrey Bouquet 
> wrote:
> 
> > 
> > 12.0-CURRENT r332797 GENERIC amd64
> > ..
> > make: "/usr/ports/Mk/bsd.port.mk" line 1171: Unable to
> > determine OS version. Either define OSVERSION, or
> > install /usr/include/sys/param.h...
> > ..
> > then , with param.h in place
> > 
> > ..
> > port builds, pkgdb -u, and  portsdb -u all fail with:
> > ..
> > line 1200: UNAME_r (12.0-CURRENT) and OSVERSION (12.0-CURRENT) do not agree
> > on major version number.
> > ..
> > Can I set that in sh or tcsh or zsh?
> > .
> > 
> Looks like you're running ports in a jail.  The best way to do that is to
> set OSVERSION in /etc/make.conf.  Some jail managers will even do that for
> you.  It should look a little like this:
> 
>  > cat /etc/make.conf
> OSVERSION+=1100122
> UNAME_ENV+= OSVERSION=${OSVERSION}
> UNAME_ENV+= UNAME_s=FreeBSD
> UNAME_ENV+= UNAME_r=11.0-RELEASE
> UNAME_ENV+= UNAME_v="${UNAME_s} ${UNAME_r}"
> .MAKEFLAGS: ${UNAME_ENV}
> MAKE_ENV+=  ${UNAME_ENV}
> CONFIGURE_ENV+= ${UNAME_ENV}
> SCRIPTS_ENV+=   ${UNAME_ENV}

If you're running a freebsd 11 jail on a freebsd 12 host, the best
solution is to set osrelease and osreldate in your jail config to
reflect the 11.x userland you want the jail to implement. Then all the
values returned by uname and various sysctls will be consistently
correct within the jail. For example, on a 10.3 host I have a jail:

fb8 {
host.hostname = "${name}.hippie.lan";
ip4.addr = 172.22.42.241;
persist = true;
devfs_ruleset = 100;
osrelease="8.4-STABLE";
osreldate= 804507;
}

-- 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: clang manual page?

[Ian Lepore]

On Thu, 2018-04-05 at 15:38 -0700, Steve Kargl wrote:
> Is anyone working on fixing the clang manual to actually
> document the available options?
> 
> % man clang
> (search for -std=)
>    -std=
>   Specify the language standard to compile for.
> 
> OK, what does  mean?
> 

clang --help has more info than the manpage, but it's still light on
details.

-- 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: CURRENT r331284: crashing with USB

[Ian Lepore]

On Sat, 2018-03-24 at 10:39 -0700, bob prohaska wrote:
> On Wed, Mar 21, 2018 at 09:49:34PM -0700, bob prohaska wrote:
> > 
> > On Wed, Mar 21, 2018 at 12:07:18PM +0100, Hartmann, O. wrote:
> > > 
> > > 
> > > not the ZFS. I can plugin the USB and then unplug it and after
> > > two or
> > > three times doing this, the box goes down.
> > > 
> > > 
> > > Does anyone else observe this bug?
> > > 
> > An RPI2 running r331179 didn't crash, but it did complain about
> > setting
> > addresses. The same error crops up from time to time when pl2303
> > serial
> An RPI3 running r331146 reacted more drastically to the insertion of
> a
> USB 3.0 flash drive additional to the one holding /usr and /var; the
> console began to emit a flood of gibberish:
> 
> �`!���Qsb"J� ��Bdevices... ��m�o�TH��HU�m��**
> First descriptor���Oo]�sc��y���RRj�1 Storage Device(s) found
>    s�0�H�� *
>  "�R ���X�t Dev��ֹ.. 1 Ethernet Device(s) found
> Hit any key�}//_K�}?���
> 
> which persisted across shutdown -r and momentary power cutoff.
> Removing power 
> for a minute or two seems to have restored normal operation. Note the
> snippets
> of clear text; the serial link isn't the culprit, it's working fine.
> 
> The flash drive had been used as swap on a Raspbian system
> successfully,
> and had a vestigal partitioning scheme from a previous FreeBSD-
> current
> installation. However, it wasn't mounted in any way, just plugged in,
> to
> cause the upset seen above. I wanted to try using the flash drive as
> extra
> swap, per advice given elsewhere. Clearly that isn't going to work.
> 
> Thanks for reading, and any ideas.
> 
> bob prohaska

Those snippets are some of the first things uboot says when it starts.

-- 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: Speed up CD/DVD-based FreeBSD

[Ian Lepore]

On Mon, 2018-03-12 at 06:35 +0100, O. Hartmann wrote:
> We have a special case of running FreeBSD (actually a NanoBSD) from a CD/DVD.
> The reason behind using a CD/DVD is to prevent manipulations.
> 
> Now, after the GUI hass started, the system autologin a user and autostarts
> Firefox. But starting Firefox takes ~ 5 - 7 minutes, while the operating 
> system
> takes 2 - 3 minutes. As you can imagine, this isn't quite a useful time.
> 
> Is there a simple way, considering enough RAM in the box, to speed up the
> process? Loading Firefox makes the DVD drive moving the head very often - I
> assume this is the fact because I can hear the head scratiching around very
> intense.
> 
> Does FreeBSD bring tools/facilities onboard to achive what I'm requesting or 
> do
> I need an additional port/softwarepackage?
> 
> Any considerations are welcome.
> 
> Thanks in advance,
> 
> Oliver

You say you have "enough" ram... is it enough to fit your entire
filesystem image in memory and still be able to run apps?  If so you
can compile your entire filesystem into the kernel using an mdroot
image using options MD_ROOT and makeoptions MFS_IMAGE=.

-- 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: best settings for usb2 and attached disks, and sdcards

[Ian Lepore]

On Wed, 2018-03-07 at 06:15 +, John wrote:
> Hi,
> [cc'd to arm@ and fs@ where it's also relevant]
> 
> I have a number of rpi3 & rpi3 machines. Usually I want to attach a usb 
> keydrive to them so that the sdcard isn't thrashed. They're all running 
> -current. usr/src and usr/ports at least are mounted on the keydrive.
> 
> When initially updating eg the ports tree, svn will time out/crash because of 
> the poor write performance of these devices in a rpi2/3 context. The fs on 
> the usb keys is always ufs2. I have tried mounting these devices as -o async 
> and also in fstab but this parameter seems not to 'take' in that mount 
> doesn't report the async property set:
> 
> [...]
> /dev/da0p2 on /ext (ufs, local, noatime, soft-updates)
> [...]
> 
> was mounted with the command "mount -o async,noatime,rw /dev/da0s2 /ext"
> but I can't tell if async is on or just ignored, no error message. And I 
> still have to run svnlite cleanup /ext/ports until svnlite stops bailing out. 
> When newfs was written, I passed -t  to it to enable trim, which seems to 
> make a difference on this for deletes but not writes. Can anyone please 
> suggest anything I can so to speed up disk i/o? And is async being applied or 
> ignored?
> 
> thanks,

If your ufs2 filesystem is formatted with soft dependencies, the async
mount option does nothing (the ufs mount code forces it off when the
softdeps flag is on).  Basically, softdeps IS async for ufs.

If you have journaling enabled on the usb or sdcard filesystems, turn
it off.  It just amplifies the writes to devices that are already very
slow on writes, and the only benefit to journaling is that it speeds up
fsck recovery.  Since sdcard and thumb drive filesystems tend to be
very small already, the speed up from having journaling enabled amounts
to a few seconds at best, and even that benefit only comes after a
crash.

-- 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: top: sysctl(vfs.bufspace...) expected 8, got 4

[Ian Lepore]

On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote:
> Am Wed, 21 Feb 2018 20:05:24 +0100
> "O. Hartmann"  schrieb:
> 
> > 
> > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue
> > Feb 20 23:06:15 CET
> > 2018 amd64) I'm honored by this nice bug when calling top:
> > 
> > top: sysctl(vfs.bufspace...) expected 8, got 4
> > 
> > 
> > Regards,
> > 
> > oh
> I still can not use "top", it quits with the error mentioned above.
> Whats is wrong with
> my setup?
> 

It seems like the two big candidates must be mismatch between kernel
and userland, or maybe 32/64-bit mismatch between the kernel and top.

What's the output of

  uname -pmUK
  file `which top`
  ldd `which top`

-- 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: posix_fallocate on ZFS

[Ian Lepore]

On Sat, 2018-02-10 at 12:45 -0700, Alan Somers wrote:
> On Sat, Feb 10, 2018 at 12:43 PM, Ian Lepore  wrote:
> 
> > 
> > On Sat, 2018-02-10 at 11:24 -0700, Alan Somers wrote:
> > > 
> > > On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > This has been disabled on ZFS since last November.
> > > > And I do understand the rationale on this.
> > > > 
> > > > BUT
> > > > 
> > > > I've now upgraded some of my HEAD Ceph test systems and they now fail,
> > > > since Ceph uses posix_fallocate() to allocate space for the
> > > > FileStore-journal.
> > > > 
> > > > Is there any expectation that this is going to fixed in any near
> > future?
> > > 
> > > > 
> > > > 
> > > > --WjW
> > > > 
> > > No.  It's fundamentally impossible to support posix_fallocate on a COW
> > > filesystem like ZFS.  Ceph should be taught to ignore an EINVAL result,
> > > since the system call is merely advisory.
> > > 
> > > -Alan
> > Unfortunately, posix documents that the function returns EINVAL only
> > due to bad input parameters, so ignoring that seems like a bad idea.
> > 
> > Wouldn't it be better if we returned EOPNOTSUP if that's the actual
> > situation?  That could be safely ignored.
> > 
> I'm afraid you are mistaken.  Posix _should've_ required EOPNOTSUP in this,
> but it actually requires EINVAL.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html

Oops, I apparently was looking at the prior version of the spec.
 Nevermind. :)

-- 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: posix_fallocate on ZFS

[Ian Lepore]

On Sat, 2018-02-10 at 11:24 -0700, Alan Somers wrote:
> On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen 
> wrote:
> 
> > 
> > Hi,
> > 
> > This has been disabled on ZFS since last November.
> > And I do understand the rationale on this.
> > 
> > BUT
> > 
> > I've now upgraded some of my HEAD Ceph test systems and they now fail,
> > since Ceph uses posix_fallocate() to allocate space for the
> > FileStore-journal.
> > 
> > Is there any expectation that this is going to fixed in any near future?
> > 
> > --WjW
> > 
> No.  It's fundamentally impossible to support posix_fallocate on a COW
> filesystem like ZFS.  Ceph should be taught to ignore an EINVAL result,
> since the system call is merely advisory.
> 
> -Alan

Unfortunately, posix documents that the function returns EINVAL only
due to bad input parameters, so ignoring that seems like a bad idea.

Wouldn't it be better if we returned EOPNOTSUP if that's the actual
situation?  That could be safely ignored.

-- 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: openssl in base should install c_rehash

[Ian Lepore]

On Thu, 2018-02-08 at 19:35 -0500, Jung-uk Kim wrote:
> On 02/08/2018 18:51, Ian Lepore wrote:
> > 
> > On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote:
> > > 
> > > On 02/08/2018 17:31, Chris H wrote:
> > > > 
> > > > 
> > > > [...]
> > > > Couldn't this be in $base? I'd like to vote yes. :-)
> > > From OpenSSL 1.1.0, openssl(1) added "rehash" command.
> > > 
> > > https://www.openssl.org/docs/man1.1.0/apps/rehash.html
> > > 
> > > I don't think we need yet another implementation in the base.
> > But on a machine I just set up last weekend using -current I get:
> > 
> > ian@th > openssl rehash
> > openssl:Error: 'rehash' is an invalid command.
> > ian@th > openssl version
> > OpenSSL 1.0.2n-freebsd  7 Dec 2017
> > 
> > Are we going to update to 1.1.0 soon?
> When I find some free time.  I don't know how "soon", however.
> 
> > 
> > If not, how does it help that a version we don't use has rehash
> > built in?
> We will have the feature when we import OpenSSL 1.1.0.  Knowing that it
> is obsoleted by the upstream, I don't want to add an equivalent script
> in the base.
> 
> If it is really necessary, you can always install the c_rehash script
> (security/openssl), openssl with rehash command
> (security/openssl-devel), openssl with certhash command
> (security/libressl), etc. from the ports tree.
> 
> BTW, we never had it in the base and it was removed from head src tree
> more than 5 years ago.  Why is it so important now? :-(

When looking for info (because of this thread) I noticed that lots of
how-to writeups on the web tell you to use the c_rehash command, so if
we don't supply one that's bad (or if we supply an alternate-named
thing we should document that somehow).

If we're just a bit behind but we're going to catch up eventually, then
that's good enough I think. 

It's not clear if openssl 1.1.0 installs a link or wrapper for c_rehash
or not.  That manpage seems to imply that "openssl rehash" and
"c_rehash" are equivelent.

-- 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: openssl in base should install c_rehash

[Ian Lepore]

On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote:
> On 02/08/2018 17:31, Chris H wrote:
> > 
> > [...]
> > Couldn't this be in $base? I'd like to vote yes. :-)
> From OpenSSL 1.1.0, openssl(1) added "rehash" command.
> 
> https://www.openssl.org/docs/man1.1.0/apps/rehash.html
> 
> I don't think we need yet another implementation in the base.
> 
> Jung-uk Kim
> 

But on a machine I just set up last weekend using -current I get:

ian@th > openssl rehash
openssl:Error: 'rehash' is an invalid command.
ian@th > openssl version
OpenSSL 1.0.2n-freebsd  7 Dec 2017

Are we going to update to 1.1.0 soon?  If not, how does it help that a
version we don't use has rehash built in?

-- 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: openssl in base should install c_rehash

[Ian Lepore]

On Thu, 2018-02-08 at 21:15 +0100, Ulrich Spörlein wrote:
> 2018-02-08 21:00 GMT+01:00 Jung-uk Kim :
> 
> > 
> > On 02/08/2018 08:52, Jan Bramkamp wrote:
> > > 
> > > On 08.02.18 14:24, Ulrich Spörlein wrote:
> > > > 
> > > > Hey,
> > > > 
> > > > c_rehash has somehow disappeared from the base system. We still
> > > > install the
> > > > manpage it seems, but the tool itself is missing. Can we have
> > > > that back?
> > > > 
> > > > 
> > > > root@acme:/etc/ssl# locate c_rehash
> > > > ...
> > > > /usr/share/openssl/man/man1/c_rehash.1.gz
> > > > /usr/src/crypto/openssl/doc/apps/c_rehash.pod
> > > > /usr/src/secure/usr.bin/openssl/man/c_rehash.1
> > > > 
> > > > 
> > > > The port seems to install it just fine:
> > > > 
> > > > root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
> > > > /usr/ports/security/openssl/pkg-plist:bin/c_rehash
> > > > /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
> > > > 
> > > > It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
> > > > reading the
> > > > history with git pickaxe right).
> > > The LibreSSL port lacks a c_rehash script as well. Putting
> > > c_rehash back
> > > into base wouldn't solve the problem because it requires Perl 5.
> > Correct.  I just removed the manual page to not confuse users.
> > 
> > https://svnweb.freebsd.org/changeset/base/329024
> > 
> > Thanks for letting me know!
> > 
> > Jung-uk Kim
> > 
> > 
> I would rather that c_rehash is brought back. I can install perl just
> fine
> (or have it anyway installed), that's not the case with openssl from
> ports,
> as that will mess up many things.
> 
> Guess I'll download my own version ... :(
> 
> Uli


Maybe we should just replace ours in base with a non-perl version,
something like this one?

https://opensource.apple.com/source/OpenSSL/OpenSSL-5/openssl/tools/c_rehash.in.auto.html

-- 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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[Ian Lepore]

On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> > 
> > On Feb 6, 2018, at 10:54 AM, John Nielsen 
> > wrote:
> > 
> > > 
> > > 
> > > On Feb 4, 2018, at 2:50 AM, Maurizio Vairani  > > com> wrote:
> > > 
> > > 2018-01-29 18:38 GMT+01:00 John Nielsen :
> > > [ resending from correct email address ]
> > > 
> > > > 
> > > > On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  > > > il.com> wrote:
> > > > 
> > > > I am running
> > > > # uname
> > > > -a
> > > > 
> > > > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan
> > > > 25 04:48:52
> > > > UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd6
> > > > 4.amd64/sys/GENERIC
> > > > amd64
> > > > 
> > > > After compiling the kernel module as discussed in this thread :
> > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-Januar
> > > > y/068272.html
> > > > 
> > > > I can boot FreeBSD via iSCSI using iPXE. But when the isboot,
> > > > the iSCSI
> > > > boot driver version 0.2.13, starts I receive a panic:
> > > > https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdU
> > > > A1BorD4
> > > > 
> > > > Any idea?
> > > Bummer! 
> > > 
> > > Aoyama-san-
> > > 
> > > Are you still maintaining isboot? Can you help debug this issue
> > > on FreeBSD 12-CURRENT?
> > > 
> > > Once we get it working I will update the port with whatever is
> > > needed and send you the patches in case you'd like to cut a new
> > > release.
> > > 
> > > Thank you!
> > > 
> > > I have solved the issue changing the function isboot_ifup() in
> > > the source file isboot.c.
> > Here is a patch with some changes to minimize the diff. Except for
> > the printed error messages does that look functionally equivalent?
> > 
> > Now the question is why is this change needed and for what values
> > of __FreeBSD_version is it appropriate?
> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> since this commit in 2011:
> https://svnweb.freebsd.org/base?view=revision&revision=218757
> 
> So I'm going to add this patch to the port unconditionally once it
> works.
> 
> Unfortunately, I can't compile the port with either my patch below or
> your original replacement version of isboot_ifup(). :( Did you make
> other changes? Here's the error I'm getting:
> 
> --- isboot.o ---
> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_ucred, td);
>   ~~^
> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> thread'
> struct thread;
>    ^
> 1 error generated.
> 

Try adding #include  if it's not already in the list.  It
may be that that file got included via pollution from some other header
file in the past and maybe now that has changed.

If you're already including sys/proc.h then I'm clueless.

-- 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: Error compiling isboot-kmod

[Ian Lepore]

On Mon, 2018-01-29 at 10:29 -0700, John Nielsen wrote:
> > 
> > On Jan 27, 2018, at 9:20 AM, Ian Lepore  wrote:
> > 
> > On Fri, 2018-01-26 at 23:20 -0700, John Nielsen wrote:
> > > 
> > > > 
> > > > 
> > > > On Jan 26, 2018, at 9:42 PM, John Nielsen 
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > [...]
> > > > --- iscsi.o ---
> > > > iscsi.c:1146:3: error: incompatible pointer types passing 'void
> > > > (struct mbuf *, void *, void *)' to parameter of type
> > > > 'm_ext_free_t *' (aka 'void (*)(struct mbuf *)') [-Werror,-
> > > > Wincompatible-pointer-types]
> > > >    MEXTADD(md, (caddr_t)ds_dd, (ISCSI_ALIGN(pp-
> > > > >ds_len)
> > > >    ^~~~
> > > > 
> > > > /usr/src/sys/sys/mbuf.h:887:42: note: expanded from macro
> > > > 'MEXTADD'
> > > >    m_extadd((m), (char *)(buf), (size), (free), (arg1),
> > > > (arg2),\
> > > > ^~
> > > > /usr/src/sys/sys/mbuf.h:634:59: note: passing argument to
> > > > parameter here
> > > > void m_extadd(struct mbuf *, char *, u_int,
> > > > m_ext_free_t,
> > > Looks like iscsi.c needs to be fixed up following r324446
> > > (https://svnweb.freebsd.org/changeset/base/324446). Starting to
> > > be
> > > out of my depth unless there's a mechanical way to make the
> > > changes?
> > I'm not set up to test-compile this against -current right now, so
> > I'm
> > not sure if this is all that remains or just another breadcrumb on
> > the
> > trail, but... try the attached patch.
> > 
> > -- Ian
> > --- iscsi.c.orig2018-01-27 08:43:26.937858000 -0700
> > +++ iscsi.c 2018-01-27 09:15:39.631501000 -0700
> > @@ -1071,17 +1071,23 @@
> > }
> > 
> > 
> > -#if __FreeBSD_version >= 110
> > +#if __FreeBSD_version >= 1200051
> > +static void
> > +isboot_free_mbufext(struct mbuf *m)
> > +{
> > +   void *p = m->m_ext.ext_arg1;
> > +#elif __FreeBSD_version >= 110
> > static void
> > isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
> > #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
> > static int
> > isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
> > +{
> > #else
> > static void
> > isboot_free_mbufext(void *p, void *optarg)
> > -#endif
> > {
> > +#endif
> Thanks Ian. I think I ran in to a copy/paste issue on my end with the
> above but I can compile with this similar patch. Is it functionally
> equivalent to yours?
> 
> --- iscsi.c.orig  2015-11-05 09:50:51.0 -0700
> +++ iscsi.c   2018-01-29 10:20:00.586277000 -0700
> @@ -1070,9 +1070,11 @@
>   return (n);
>  }
>  
> -
> -#if __FreeBSD_version >= 110
> +#if __FreeBSD_version >= 1200051
>  static void
> +isboot_free_mbufext(struct mbuf *m)
> +#elif __FreeBSD_version >= 110
> +static void
>  isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
>  #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
>  static int
> @@ -1082,7 +1084,9 @@
>  isboot_free_mbufext(void *p, void *optarg)
>  #endif
>  {
> -
> +#if __FreeBSD_version >= 1200051
> + void *p = m->m_ext.ext_arg1;
> +#endif
>   ISBOOT_TRACE("isboot_free_mbufext\n");
>   if (p == NULL)
>  #if __FreeBSD_version >= 150 && __FreeBSD_version < 110

Yeah, that looks the same.  But someone else reported that once you get
it to compile, it crashes at runtime, not necessarily in a way that
involves this part of the code.  I probably can't help much with that,
I don't know anything about iscsi, and don't have a setup for testing.

-- 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: Error compiling isboot-kmod

[Ian Lepore]

On Fri, 2018-01-26 at 23:20 -0700, John Nielsen wrote:
> > 
> > On Jan 26, 2018, at 9:42 PM, John Nielsen  wrote:
> > 
> > > 
> > > [...]
> > --- iscsi.o ---
> > iscsi.c:1146:3: error: incompatible pointer types passing 'void (struct 
> > mbuf *, void *, void *)' to parameter of type 'm_ext_free_t *' (aka 'void 
> > (*)(struct mbuf *)') [-Werror,-Wincompatible-pointer-types]
> >    MEXTADD(md, (caddr_t)ds_dd, (ISCSI_ALIGN(pp->ds_len)
> >    ^~~~
> > /usr/src/sys/sys/mbuf.h:887:42: note: expanded from macro 'MEXTADD'
> >    m_extadd((m), (char *)(buf), (size), (free), (arg1), (arg2),\
> > ^~
> > /usr/src/sys/sys/mbuf.h:634:59: note: passing argument to parameter here
> > void m_extadd(struct mbuf *, char *, u_int, m_ext_free_t,
> Looks like iscsi.c needs to be fixed up following r324446
> (https://svnweb.freebsd.org/changeset/base/324446). Starting to be
> out of my depth unless there's a mechanical way to make the changes?
> 
> 

I'm not set up to test-compile this against -current right now, so I'm
not sure if this is all that remains or just another breadcrumb on the
trail, but... try the attached patch.

-- Ian
--- iscsi.c.orig	2018-01-27 08:43:26.937858000 -0700
+++ iscsi.c	2018-01-27 09:15:39.631501000 -0700
@@ -1071,17 +1071,23 @@
 }
 
 
-#if __FreeBSD_version >= 110
+#if __FreeBSD_version >= 1200051
+static void
+isboot_free_mbufext(struct mbuf *m)
+{
+	void *p = m->m_ext.ext_arg1;
+#elif __FreeBSD_version >= 110
 static void
 isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
 #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
 static int
 isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
+{
 #else
 static void
 isboot_free_mbufext(void *p, void *optarg)
-#endif
 {
+#endif
 
 	ISBOOT_TRACE("isboot_free_mbufext\n");
 	if (p == NULL)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Error compiling isboot-kmod

[Ian Lepore]

On Fri, 2018-01-26 at 10:00 -0700, John Nielsen wrote:
> > 
> > On Jan 26, 2018, at 3:37 AM, Maurizio Vairani  > om> wrote:
> > 
> > 2018-01-24 17:19 GMT+01:00 Warner Losh :
> > 
> > 
> > On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani  > il.com> wrote:
> > On this CURRENT snapshot
> > # uname -a
> > FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed
> > Jan 10
> > 22:55:40 UTC 2018
> > r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENER
> > IC
> > amd64
> > 
> > I can't compile the kernel module isboot-kmod:
> > # cd /usr/ports/net/isboot-kmod && make
> > ===>  License BSD2CLAUSE accepted by the
> > user
> > 
> > ===>   isboot-kmod-0.2.13_1 depends on file: /usr/local/sbin/pkg -
> > found
> > ===> Fetching all distfiles required by isboot-kmod-0.2.13_1 for
> > building
> > ===>  Extracting for isboot-kmod-0.2.13_1
> > => SHA256 Checksum OK for isboot-0.2.13.tar.gz.
> > ===>  Patching for isboot-kmod-0.2.13_1
> > ===>  Applying FreeBSD patches for isboot-kmod-0.2.13_1
> > ===>  Configuring for isboot-kmod-0.2.13_1
> > ===>  Building for isboot-kmod-0.2.13_1
> > --- machine ---
> > --- x86 ---
> > --- machine ---
> > machine -> /usr/src/sys/amd64/include
> > --- x86 ---
> > x86 -> /usr/src/sys/x86/include
> > --- objwarn ---
> > --- opt_cam.h ---
> > --- objwarn ---
> > Warning: Object directory not changed from original
> > /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
> > --- opt_cam.h ---
> > :> opt_cam.h
> > --- isboot.o ---
> > --- ibft.o ---
> > --- isboot.o ---
> > cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> > -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> > -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> > d.isboot.o -MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-
> > sse
> > -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
> > -fwrapv
> > -fstack-protector -Wall -Wredundant-dec$
> > s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith
> > -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs $
> > fdiagnostics-show-option -Wno-unknown-pragmas
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wno-error-unused-function
> > -Wno-error-pointer-s$
> > gn -Wno-error-shift-negative-value -Wno-error-address-of-packed-
> > member
> > -mno-aes -mno-avx  -std=iso9899:1999 -c isboot.c -o isboot.o
> > --- ibft.o ---
> > cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> > -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> > -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> > d.ibft.o -MTibft.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> > -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
> > -fwrapv
> > -fstack-protector -Wall -Wredundant-decls -$
> > nested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-
> > arith
> > -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi$
> > gnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-
> > compare
> > -Wno-error-empty-body -Wno-error-parentheses-equality
> > -Wno-error-unused-function -Wno-error-pointer-sign $
> > Wno-error-shift-negative-value -Wno-error-address-of-packed-member
> > -mno-aes -mno-avx  -std=iso9899:1999 -c ibft.c -o ibft.o
> > --- iscsi.o ---
> > cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> > -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> > -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> > d.iscsi.o -MTiscsi.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-
> > sse
> > -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
> > -fwrapv
> > -fstack-protector -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith
> > -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -f$
> > iagnostics-show-option -Wno-unknown-pragmas -Wno-error-
> > tautological-compare
> > -Wno-error-empty-body -Wno-error-parentheses-equality
> > -Wno-error-unused-function -Wno-error-pointer-sig$
> >  -Wno-error-shift-negative-value -Wno-error-address-of-packed-
> > member
> > -mno-aes -mno-avx  -std=iso9899:1999 -c iscsi.c -o iscsi.o
> > In file included from iscsi.c:62:
> > In file included from /usr/src/sys/cam/cam_ccb.h:1035:
> > In file included from /usr/src/sys/cam/mmc/mmc_bus.h:5:
> > In file included from /usr/src/sys/dev/mmc/bridge.h:59:
> > /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not
> > found
> > #include "device_if.h"
> >  ^
> > 
> > I think this was fixed in a newer -current.
> > 
> > Warner 
> > Thanks Warner, but I have the same error in :
> > # uname -a
> > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
> > 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src
> > /amd64.amd64/s

Re: microSDXC can't recognized

[Ian Lepore]

On Fri, 2018-01-26 at 23:09 +0900, KIRIYAMA Kazuhiko wrote:
> At Fri, 26 Jan 2018 16:31:08 +0900,
> 私 wrote:
> > 
> > 
> > Hi,
> > 
> > Builtin microSDXC card device can't recognized in may
> > machine[1]. Inserted it but nothing happened. Inserted card
> > is SanDisk SDSQAR-128G-GNMA[2]. But in may another machine,
> > it recognized da0:
> > 
> > [...]
> I've rebooted and then recognized by mmcsd1! dmesg shows:
> 
> mmcsd1: 128GB  at
> mmc1 50.0MHz/4bit/65535-block
> WARNING: WITNESS option enabled, expect reduced performance.
> 
> [...]
> 
> I supposed SD card to be a pnp device but this embedded
> micro sd port seems to be eMMC device. Actually it is teated
> same as internal eMMC device as HDD. That is micro SD card
> must not be pull out by umount on running isn't it?

You should be able to insert and remove the sdcard whenever you want,
as long as it has no mounted filesystems. Every time you insert or
remove it, you should see a notification on the console and in dmesg.
If that doesn't happen, then somehow the card-detect logic isn't
working right on your hardware.

-- 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: Periodical interrupt storm when playing game with USB keyboard

[Ian Lepore]

On Sun, 2018-01-21 at 22:07 +0100, Hans Petter Selasky wrote:
> On 01/21/18 21:45, Johannes Lundberg wrote:
> > 
> > What does kern.eventtimer.periodic do?  The sysctl description
> > wasn't
> > that elaborate...
> It turns off re-programming the timer every time there is a new
> callout 
> with earlier completion time.
> 
> --HPS

Well, it does more than that.  It makes the system run "the old way"
where there are periodic timer interrupts that happen whether they need
to or not (bad for power saving), and there's no way to schedule
anything to happen on intervals other than when the periodic ticks
occur (so if kern.hz = 1000 and you ask to sleep for a microsecond you
may actually sleep up to a millisecond).

-- 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: mounting UFS2 filesystem with access mode via fstab

[Ian Lepore]

On Sun, 2018-01-21 at 20:00 +0100, O. Hartmann wrote:
> Am Sun, 21 Jan 2018 18:15:11 +0100
> Gary Jennejohn  schrieb:
> 
> > 
> > On Sun, 21 Jan 2018 11:37:16 +0100
> > "O. Hartmann"  wrote:
> > 
> > > 
> > > Recently, I ran into the problem mounting a newly created /tmp,
> > > when I switched back
> > > from a tmpfs-backed /tmp to a UFS2/SSD/HDD backed /tmp. 
> > > 
> > > The convenience to set mode=01777 for the memory/tmpfs backed
> > > /tmp seems not to exist
> > > for UFS2 backed filesystems, since manpage mount(8) doesn't give
> > > me any option
> > > provided via -o which could accomplish what I can achieve with
> > > mode=, see man
> > > tmpfs(5).
> > > 
> > > Well, I guess I do miss something here or is this achievement
> > > reached on a different
> > > path I'm unaware of?
> > >   
> > chmod 1777 /tmp as root
> > 
> Well,
> that is the way we do it usually. But is there now way to perform the
> settings via fstab
> entry? Look at man  tmpfs, man mount_msdosfs, for instance, they
> provide options which
> can be put into the option column of fstab.
> 

You don't need to do it via the fstab, because the permissions are
persistent in the filesystem.  Just mount the filesystem on /tmp by
hand, then chmod  /tmp after mounting it and then it will
always have those permissions (wherever it is mounted).

With tmpfs there is no persistent storage to keep the permissions, so
there must be a way to set it from fstab.  With msdosfs there is no way
to store the unix-style permissions in the fs, so there must be a way
to set it from fstab.  For UFS, the mode is just stored in the fs.

-- 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: Building kernel with no sound

[Ian Lepore]

On Mon, 2018-01-15 at 19:14 +0100, Alexander Sieg wrote:
> Hey,
> i´m trying to build a custom kernel with no sound support build in.
> 
> This is my make.conf:
> MALLOC_PRODUCTION=true
> KERNCONF=MYKERNEL #GENERIC-NODEBUG
> DEVELOPER=yes
> 
> and this is my kernel configuration:
> include GENERIC-NODEBUG
> 
> ident   MYKERNEL
> 
> nodevice  sound   # Generic sound driver (required)
> nodevice  snd_es137x  # Ensoniq AUdioPCI ES137x
> nodevice  snd_hda # Intel High Definition Audio
> nodevice  snd_ich # Intel, Nvidia and other ICH AC'97 audio
> nodevice  snd_uaudio  # USB Audio
> nodevice  snd_via8233 # VIA VT823x Audio
> 
> 
> The problem is when i try to compile it with "make buildkernel" the
> build process starts, but it stop with the error that it can´t find the
> header file "channel_if.h".
> 
> /usr/src/sys/dev/sound/pcm/channel.h:256:10: fatal error: 'channel_if.h' file 
> not found
> #include "channel_if.h"
>  ^~
> 
> The intention behind the custom kernel is to try 'oss' form the
> ports tree.

I think your nodevice list isn't quite complete.  Grepping for snd_ in
i386 and amd64 GENERIC, I come up with this list:

 snd_cmi  # CMedia CMI8338/CMI8738
 snd_csa  # Crystal Semiconductor CS461x/428x
 snd_emu10kx  # Creative SoundBlaster Live! and Audigy
 snd_es137x   # Ensoniq AudioPCI ES137x
 snd_hda  # Intel High Definition Audio
 snd_ich  # Intel, NVidia and other ICH AC'97 Audio
 snd_via8233  # VIA VT8233x Audio

-- 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: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Ian Lepore]

On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote:
> On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote:
> > 
> > Hi All,
> > 
> > I use self built base packages. Seems that I have a problem with pkg.
> > Today I've got this:
> > ===
> > % sudo pkg update -f
> > Updating FreeBSD-base repository catalogue...
> > Fetching meta.txz: 100%268 B   0.3kB/s00:01
> > Fetching packagesite.txz: 100%   29 KiB  29.4kB/s00:01
> > Processing entries:   0%
> > pkg: Newer FreeBSD version for package FreeBSD-libulog:
> > - package: 1200055
> > - running kernel: 1200054
> > pkg: repository FreeBSD-base contains packages for wrong OS version:
> > FreeBSD:12:amd64
> > Processing entries: 100%
> > Unable to update repository FreeBSD-base
> > [...]
> > 
> > % uname -aKU
> > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan
> >  9 14:32:13 MSK 2018
> > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64
> > 1200054 1200054
> > 
> > % pkg -v
> > 1.10.4
> > 
> hum
> 
> pkg now has a mechanism to protect from installing too new package (aka 
> packages
> built on a more recent system than the system you are running on.
> 
> While this is great for ports this is a bit painful for upgrading base 
> packages
> when building on current
> 
> One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055
> to install on 1200054.
> 
> I need to figure out a mechanism to make this simpler to handle to upgrade of
> base system while keeping this safety belt for users.
> 
> Any idea is welcome
> 
> Best regards,
> Bapt

Is this new mechanism disabled if installing into something other than
the live system, such as when using -c or -r (and maybe -j)?

-- 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: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127

[Ian Lepore]

On Mon, 2018-01-08 at 20:43 +0100, Kurt Jaeger wrote:
> Hi!
> 
> If I understand correctly, in the past we decommissioned stuff from
> the base system in a few steps:
> 
> - announce intent
> - analyse/remove from use
> - disconnect from build
> - remove from tree
> 
> It seems dropping lint was done a bit hasty ?
> 

It was discovered that it had not been working for about 3 years and
nobody complained, so hasty removal seemed innocuous at the time.  I
don't think these subsequent build problems were anticipated, but they
should be fixable.

https://lists.freebsd.org/pipermail/freebsd-arch/2016-February/017658.html

-- 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: 11.1-jail on CURRENT: sh: lint: not found *** [llib-lposix.ln] Error code 127

[Ian Lepore]

On Sun, 2018-01-07 at 23:49 -0800, Don Lewis wrote:
> There doesn't appear to be a knob to disable building lint for FreeBSD
> 11.x.  Linking or copying /usr/bin/true to /usr/bin/lint works for cross
> building 11 on on a 12.0-CURRENT machine, but I was not able to get it
> to work when rebuilding a poudriere jail.
> 

Disabling the build of lint on 11-stable by default, but allowing users
to enable it, seems to me like the most sensible option, given how
little lint is used these days.  (The alternative would be to build it
as a bootstrap tool I guess.)  I've created a patchset to do that and
put it up for review...

https://reviews.freebsd.org/D13799

If this is an okay solution for everyone, I think it could be used with
10-stable too.

-- Ian


> On  8 Jan, Warner Losh wrote:
> > 
> > Does building -DWITHOUT_LINT work? Or linking lint to /bin/true
> > 
> > Warner
> > 
> > On Jan 7, 2018 11:58 PM, "O. Hartmann"  wrote:
> > 
> > > 
> > > We have a bunch of CURRENT boxes running poudriere jails providing
> > > packages for
> > > 11.1-RELENG. Since a couple of week sfor now, I face this error when I try
> > > to
> > > update the p3 and p4 to the recent p6:
> > > 
> > > [...]
> > > cc -O2 -pipe
> > > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../lint1
> > > -DPREFIX=\"\"
> > > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../arch/amd64
> > > -I/pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/../common
> > > -DNDEBUG
> > > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k
> > > -W
> > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> > > -Wpointer-arith
> > > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> > > -Wunused-parameter
> > > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> > > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
> > > -Wthread-safety -Wno-empty-body -Wno-string-plus-int
> > > -Wno-unused-const-variable
> > > -Qunused-arguments  -o xlint xlint.o mem.o --- lint.1.gz --- gzip
> > > -cn /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/xlint/lint.1 >
> > > lint.1.gz ===> usr.bin/xlint/llib (all) --- llib-lposix.ln --- lint
> > > -cghapbx
> > > -Cposix /pool/poudriere/jails/11amd64/usr/src/usr.bin/xlint/llib/
> > > llib-lposix
> > > sh: lint: not found *** [llib-lposix.ln] Error code 127
> > > [...]
> > > 
> > > 
> > > Please advice how this can be resolved.
> > > 
> > > 
> > > Kind regards,
> > > 
> > > Oliver
> > > ___
> > > 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"

Re: partitioning schemes: GPT <-> MBR

[Ian Lepore]

On Sun, 2018-01-07 at 18:58 +0100, Wolfram Schneider wrote:
> Hi guys,
> 
> I have 2 small virtual machines running in data center, on similar
> hardware. Both are running FreeBSD 12-current. The first one is based
> on a 10.3 image, upgraded to current. The second one is based on
> 11.1,
> upgraded to current.
> 
> I notice a difference in disk partitioning. 10.3 is using GPT, and
> 11.1 MBR.
> 
> [FreeBSD 10.3]
> $ gpart show
> =>  34  83886013  vtbd0  GPT  (40G)
>    34  1024  1  freebsd-boot  (512K)
>  1058   2097152  2  freebsd-swap  (1.0G)
>   2098210  81787836  3  freebsd-ufs  (39G)
>  83886046 1 - free -  (512B)
> 
> [FreeBSD 11.1]
> $ gpart show
> =>  63  83886017  vtbd0  MBR  (40G)
>    63 1 - free -  (512B)
>    64  79691776  1  freebsd  [active]  (38G)
>  79691840   4194240 - free -  (2.0G)
> 
> I thought that MBR is outdated. But the hosting company told me that
> FreeBSD 11.1 is using MBR by default. Is that correct?
> 
> My problem with the MBR machine is that I cannot add a swap device.
> There are 2GB free space, and I want add a 1GB swap device:
> 
> $ gpart add -s 1G -t freebsd-swap vtbd0
> gpart: Invalid argument
> 
> is this an MBR issue?
> 
> thanks, Wolfram
> 

You need to add a new freebsd slice, then add the freebsd swap
partition within it:

 gpart add -s 1g -t freebsd vtdb0
 gpart create -s bsd vtdb0s2
 gpart add -t freebsd-swap vtdb0s2

Now you should have a /dev/vtdb0s2b available for swap.  There will
also be ~1g still available to create another slice.

Another alternative is just create the vtdb0s2 slice, then don't
subdivide it into BSD partitions at all, just add /dev/vtdb0s2 to fstab
as a swap device.

-- 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: panic: invalid bcd 194

[Ian Lepore]

On Mon, 2018-01-01 at 09:54 +0100, Matthias Apitz wrote:
> El día domingo, diciembre 31, 2017 a las 10:19:50a. m. -0700, Ian Lepore 
> escribió:
> 
> > 
> > > 
> > > I will let the C720 over night under power while sitting in the boot menu,
> > > maybe this will fix the RTC battery issue.
> > > 
> > Last time I worked on RTC stuff, cleaning this up got put on my "to-do
> > some day" list.  I think maybe that day has arrived.
> > 
> > -- Ian
> For the moment we solved the issue by booting some older r28
> memstick, writing a correct date with ntpdate into the RTC and rebooted
> without poweroff. It seems that the RTC survives even some short
> powercyle.
> 
> The CMOS battery is soldered on the motherboard of the Acer C720, i.e.
> no chance to be replaced.
> 
> The issue must be fixed in FreeBSD, i.e. it should boot even with a
> broken RTC. Should I file a PR for this?
> 
> I'm happy to test any patch for this.
> 
>   matthias
> 

Okay, I've created a pair of patches for this.  The first adds some
common support routines usable by all RTC drivers with BCD hardware.
 The second one converts the atrtc driver to use those routines.  The
common code was tested using an i2c RTC chip, but I don't have an x86
testbed, so the atrtc patch is currently untested (it compiles).

The patches are available in a pair of phabricator reviews, plus I'll
attach them to this mail.  If the list scrubs the attachements, you can
download the patches from the phab urls below, just hit the Actions
button and look for Download Raw Diff.

https://reviews.freebsd.org/D13730
https://reviews.freebsd.org/D13731

-- Ian
Index: sys/kern/subr_clock.c
===
--- sys/kern/subr_clock.c	(revision 327438)
+++ sys/kern/subr_clock.c	(working copy)
@@ -199,6 +199,52 @@ clock_ct_to_ts(struct clocktime *ct, struct timesp
 	return (0);
 }
 
+int
+clock_bcd_to_ts(struct bcd_clocktime *bct, struct timespec *ts)
+{
+	struct clocktime ct;
+
+	/*
+	 * Year may come in as 2-digit or 4-digit.  clock_ct_to_ts() handles the
+	 * century for 2-digit, but we need to decode the century for 4-digit.
+	 */
+	if (validbcd(bct->year)) {
+		if (bct->year <= 0x99)
+			ct.year = FROMBCD(bct->year);
+		else
+			ct.year = FROMBCD(bct->year >> 8) * 100 +
+			FROMBCD(bct->year & 0xff);
+	} else
+		ct.year = -1;
+
+	/*
+	 * Ensure that all values are valid BCD numbers, to avoid assertions in
+	 * the BCD-to-binary conversion routines.  clock_ct_to_ts() will further
+	 * validate the field ranges (such as 0 <= min <= 59) during conversion.
+	 */
+	if (!validbcd(bct->sec)  || !validbcd(bct->min) ||
+	!validbcd(bct->hour) || !validbcd(bct->day) ||
+	!validbcd(bct->mon)  || ct.year == -1) {
+		if (ct_debug) {
+			printf("clock_bcd_to_ts: bad BCD: "
+			"[%04x-%02x-%02x %02x:%02x:%02x]\n",
+			bct->year, bct->mon, bct->day,
+			bct->hour, bct->min, bct->sec);
+		}
+		return (EINVAL);
+	}
+
+	ct.mon  = FROMBCD(bct->mon);
+	ct.day  = FROMBCD(bct->day);
+	ct.hour = FROMBCD(bct->hour);
+	ct.min  = FROMBCD(bct->min);
+	ct.sec  = FROMBCD(bct->sec);
+	ct.dow  = bct->dow;
+	ct.nsec = bct->nsec;
+
+	return (clock_ct_to_ts(&ct, ts));
+}
+
 void
 clock_ts_to_ct(struct timespec *ts, struct clocktime *ct)
 {
@@ -260,6 +306,23 @@ clock_ts_to_ct(struct timespec *ts, struct clockti
 	("seconds %d not in 0-60", ct->sec));
 }
 
+void
+clock_ts_to_bcd(struct timespec *ts, struct bcd_clocktime *bct)
+{
+	struct clocktime ct;
+
+	clock_ts_to_ct(ts, &ct);
+
+	bct->year = TOBCD(ct.year % 100) | (TOBCD(ct.year / 100) << 8);
+	bct->mon  = TOBCD(ct.mon);
+	bct->day  = TOBCD(ct.day);
+	bct->hour = TOBCD(ct.hour);
+	bct->min  = TOBCD(ct.min);
+	bct->sec  = TOBCD(ct.sec);
+	bct->dow  = ct.dow;
+	bct->nsec = ct.nsec;
+}
+
 int
 utc_offset(void)
 {
Index: sys/sys/clock.h
===
--- sys/sys/clock.h	(revision 327438)
+++ sys/sys/clock.h	(working copy)
@@ -60,9 +60,22 @@ extern int tz_dsttime;
 int utc_offset(void);
 
 /*
- * Structure to hold the values typically reported by time-of-day clocks.
- * This can be passed to the generic conversion functions to be converted
- * to a struct timespec.
+ * Structure to hold the values typically reported by time-of-day clocks,
+ * expressed as binary integers (see below for a BCD version).  This can be
+ * passed to the conversion functions to be converted to/from a struct timespec.
+ *
+ * On input, the year is interpreted as follows:
+ *   0 -   69 = 2000 - 2069
+ *  70 -   99 = 1970 - 1999
+ * 100 -  199 = 2000 - 2099 (Supports hardware "century bit".)
+ * 200 - 1969 = Invalid.
+ *  

Re: panic: invalid bcd 194

[Ian Lepore]

On Mon, 2018-01-01 at 10:12 +0100, Matthias Apitz wrote:
> El día lunes, enero 01, 2018 a las 09:57:23a. m. +0100, Kurt Jaeger escribió:
> 
> > 
> > Hi!
> > 
> > > 
> > > For the moment we solved the issue by booting some older r28
> > > memstick, writing a correct date with ntpdate into the RTC and rebooted
> > > without poweroff. It seems that the RTC survives even some short
> > > powercyle.
> > > 
> > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e.
> > > no chance to be replaced.
> > > 
> > > The issue must be fixed in FreeBSD, i.e. it should boot even with a
> > > broken RTC. Should I file a PR for this?
> > Yes, please file a PR.
> done.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224813
> 

FYI, I'm working on this, but I discovered yesterday afternoon that
Eric van Gyzen already added code in r314936 to the atrtc driver to
validate the data from the hardware before calling bcd2bin() .  The
code looks correct to me, so why is this error still happening?

I suspected a clang codegen bug, and the generated code does look a bit
suspicious to me (things like ANDing with 0x0e where the C code uses
0x0f), but my x86 asm skills are 25 years out of date.  It's also very
hard asm code to follow, because inlined functions that call other
inlined functions are involved.

I'm on the path of adding some new common routines that all RTC drivers
can use to validate the BCD coming from the hardware without panicking.
 But if I switch the atrtc code to use the new routines, that may
amount to sweeping a clang bug under the rug.

-- 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: Programmatically cache line

[Ian Lepore]

On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote:
> On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote:
> > 
> > On 1 Jan 2018, at 05:09, Adrian Chadd  wrote:
> > > 
> > > 
> > > On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> > > > 
> > > > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
> > > > > 
> > > > > Is there some way to programmatically get the CPU cache line sizes on
> > > > > FreeBSD?
> > > > There are, all of them are MD.
> > > > 
> > > > On x86, the CPUID instruction leaf 0x1 returns the information in
> > > > %ebx register.
> > > Hm, weird. Why don't we extend sysctl to include this info?
> For the same reason we do not provide a sysctl to add two integers.
> 
> > 
> > 
> > It would be nice to expose this kind of information via VDSO or similar.  
> > There are a lot of similar bits of info that people want to use for ifunc 
> > and, SVE is going to have a bunch of similar requirements.
> > 
> Is VDSO a new trendy word ?
> 
> ifunc resolvers in usermode on FreeBSD/x86 get four arguments which
> are essentially cpu_features / cpu_features2 / cpu_stdext_features /
> cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the
> ifunc support, in rtld and coming shortly in kernel.
> 
> Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3)
> interface exported from libc.
> 
> ARM* did not implemented yet the ifunc stubs in rtld. I believe this is
> considered a low priority because there is no ready to use toolchain
> which allow to utilize ifuncs on FreeBSD, except if you use recent bfd
> ld externally.

Linux exports this info using getauxval().  I think we should support
getauxval() and as many of the AT_* values that linux defines as makes
sense for us to do.

I think it was a mistake to give our version of the function a
different name and different semantics, but this is something that
affects mainly ports, and I don't yet have enough info to make the case
that being linux-compatible will ease porting rather than complicate it
(in some cases, patches will be needed either way).

-- 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: SVN r327444 breaks current build

[Ian Lepore]

On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote:
> Nathan Whitehorn (nwhiteh...@freebsd.org) wrote:
> > 
> > 
> > 
> > On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
> > > 
> > > Michael Butler (i...@protected-networks.net) wrote:
> > > > 
> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> > > > --- vt_termcolors.o ---
> > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> > > > arguments to function call, expected 4, have 5
> > > >  if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> > > > &g, &b) == 0) {
> > > >  
> > > >    ^~
> > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> > > > 'vt_parse_rgb_triplet' declared here
> > > > static int
> > > > ^
> > > > 1 error generated.
> > > > *** [vt_termcolors.o] Error code 1
> > > > 
> > > >  .. second time today a commit wasn't tested before commit :-(
> > > > 
> > > > imb
> > > Should be fixed in r327449. It was a sloppy job, I was making iterative
> > > improvements to the original patch following review feedback and used
> > > out-of-tree testcases for actual testing. I appologize for the breakage.
> > > 
> > Still broken with GCC.
> > 
> > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function 
> > declaration isn't a prototype [-Wstrict-prototypes]
> > *** [vt_termcolors.o] Error code 1
> *sigh* Should be fixed in r327454. Thanks for reporting
> 
> I wonder if we can get clang to be more strict about
> declarations/prototypes/etc to match gcc's expectations. I understand
> that it's developers' responsibility to make sure that kernel
> is GCC-buildable but if raising red flag for some of the cases
> when compiling with clang reduced number of these breakages
> that it'd be an improvement.
> 

I think we can get clang to do that with -Wstrict-prototypes, but I'm
not sure when that option appeared in terms of clang version, and the
clang site doesn't seem to provide documentation for anything other
than the current in-development version.

-- 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: SVN r327444 breaks current build

[Ian Lepore]

On Sun, 2017-12-31 at 16:32 -0500, Michael Butler wrote:
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> --- vt_termcolors.o ---
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> arguments to function call, expected 4, have 5
> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r,
> &g, &b) == 0) {
> 
>   ^~
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> 'vt_parse_rgb_triplet' declared here
> static int
> ^
> 1 error generated.
> *** [vt_termcolors.o] Error code 1
> 
>  .. second time today a commit wasn't tested before commit :-(
> 
>   imb

Fixed in r327449.

-- 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: panic: invalid bcd 194

[Ian Lepore]

On Sun, 2017-12-31 at 09:36 +0100, Matthias Apitz wrote:
> El día sábado, diciembre 30, 2017 a las 10:48:19p. m. +0100, Matthias Apitz 
> escribió:
> 
> > 
> > El día sábado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Konstantin 
> > Belousov escribió:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > static inline u_char
> > > > > > bcd2bin(int bcd)
> > > > > > {
> > > > > > 
> > > > > > KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> > > > > > ("invalid bcd %d", bcd));
> > > > > > return (bcd2bin_data[bcd]);
> > > > > > }
> > > > > > 
> > 
> > > 
> > > For an immediate relief, enter the BIOS setup and set up the date.  Try to
> > > change it even if the BIOS date looks fine.
> > > 
> > > artc(4) should do more validation of the date read from CMOS, but this is
> > > a known issue.
> > The problem with this hardware (Acer C720 Chromebook) is, there is no
> > BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older
> > CURRENT from an USB key r285885 boots fine.
> 
> I have got a hint about that the problem showed up already in March this
> year, even with some comment of mine in this thread:
> 
> http://freebsd.1045724.x6.nabble.com/panic-invalid-bcd-xxx-td6170480.html
> 
> In this tread is mentioned a patch as:
> 
> > 
> > cem@ posted this patch:
> > 
> > http://dpaste.com/1K2W05E
> > 
> > If someone can test it, I'll gladly commit it.  The real-time clock will
> > likely be wrong, but it won't panic with INVARIANTS.
> but the link is expired. Has got someone this patch? I checked the SVN
> for the file sys/sys/libkern.h there is no relevant change since March
> 2017. (cc'ed cem@)
> 
> I will let the C720 over night under power while sitting in the boot menu,
> maybe this will fix the RTC battery issue.
> 

Last time I worked on RTC stuff, cleaning this up got put on my "to-do
some day" list.  I think maybe that day has arrived.

-- 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: Onewire on BeagleBoneBlack example ?

[Ian Lepore]

On Wed, 2017-12-20 at 22:58 +, Poul-Henning Kamp wrote:
> 
> In message <97808.1513774...@critter.freebsd.dk>, Poul-Henning Kamp writes:
> 
> > 
> > Does anybody have a working example of getting onewire sensors
> > working on beagleboneblack ?
> Ok, with some hints from the usual IRC channel I managed to figure it out:
> 
>   cd /boot/dfb
>   mv am335x-boneblack.dtb _am335x-boneblack.dtb
>   dtc -I dtb -O dts -o am335x-boneblack.dts _am335x-boneblack.dtb
>   patch am335x-boneblack.dts (see below)
>   dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts
>   echo "owc_load=YES" >> /boot/loader.conf
>   echo "ow_load=YES" >> /boot/loader.conf
>   echo "ow_temp_load=YES" >> /boot/loader.conf
> 
> The patching of am335x-boneblack.dts is black magic, but this patch
> worked for me:
> 
>   root@beaglebone:/boot/dtb # diff -u *dts
>   --- _am335x-boneblack.dts   2017-07-21 11:24:18.229468000 +
>   +++ am335x-boneblack.dts2017-07-21 19:19:35.166447000 +
>   @@ -2149,6 +2149,14 @@
>   status = "disabled";
>   };
>    
>   +   // first number (0x36, 0x4b) refers to "phandle" of gpio#
>   +   // second number is bit on that *cpu* GPIO
>   +   // not sure if the third matter, but 1 works.
>   +   onewire0 { compatible = "w1-gpio"; gpios = <0x36 30 1>; }; // 
> P9::11
>   +   onewire1 { compatible = "w1-gpio"; gpios = <0x36 31 1>; }; // 
> P9::13
>   +   onewire2 { compatible = "w1-gpio"; gpios = <0x4b 16 1>; }; // 
> P9::15
>   +   onewire3 { compatible = "w1-gpio"; gpios = <0x36 3 1>; };  // 
> P9::21
>   +
>   __symbols__ {
>   l4_wkup = "/ocp/l4_wkup@44c0";
>   wkup_m3 = "/ocp/l4_wkup@44c0/wkup_m3@10";
> 
> Either device tree overlays just plain don't work, I can't figure out how to
> write them (p=0.5).
> 
> I sure get why getting people hooked on FreeBSD with RPi's and
> BeagleBones is not happening :-/
> 

That 3rd number in gpios= describes pin attributes:

/* Bit 0 express polarity */
#define GPIO_ACTIVE_HIGH 0
#define GPIO_ACTIVE_LOW 1

/* Bit 1 express single-endedness */
#define GPIO_PUSH_PULL 0
#define GPIO_SINGLE_ENDED 2


If you #include  in the dts source you can
just use the symbolic names.

For years, folks have been espousing the value of getting people hooked
on freebsd via rpi and beaglebone, but somehow those folks never end up
doing a lot of committing of arm code that advances that goal, they
just keep saying what a laudable goal it is.  The people who do work on
arm code mostly aren't all that interested in rpi or beaglebone, so we
fight the fires that are reported, and commit code contributed by
others, but don't do much optional work on them.

-- 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 to produce dtb from dts?

[Ian Lepore]

On Mon, 2017-12-04 at 19:06 +0200, Daniel Braniss wrote:
> Hi,
> what’s the current official procedure to compile/convert a dts file,
> I’m my case sun8i-h3-nanopi-neo.dts
> to its dtb?
> 
> thanks,
>   danny
> 

make builddtb FDT_DTS_FILE= DTBOUTPUTPATH=

-- 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: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

[Ian Lepore]

On Mon, 2017-11-06 at 12:49 -0500, Allan Jude wrote:
> On 2017-11-06 12:26, Ian Lepore wrote:
> > 
> > On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote:
> > > 
> > > From UPDATING:
> > > The naive and non-compliant support of posix_fallocate(2) in ZFS
> > > has been removed as of r325320.  The system call now returns EINVAL
> > > when used on a ZFS file.  Although the new behavior complies with the
> > > standard, some consumers are not prepared to cope with it.
> > > One known victim is lld prior to r325420.
> > > 
> > It just popped into my head... does this mean that kernels running
> > r325320+ on systems using ZFS will be unable to host build jails for
> > earlier versions / branches because lld will fail in the jail?
> > 
> > I think that will be a big problem for the ports team's package
> > building process, and for anyone using poudriere.
> > 
> > -- Ian
> > 
> lld is not the default on amd64 yet. So only people who have set the
> src.conf knob, or are building a platform like aarch64 that uses lld by
> default, would be impacted.
> 

Oh, right.  lld != ld.

-- 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: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

[Ian Lepore]

On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote:
> From UPDATING:
> The naive and non-compliant support of posix_fallocate(2) in ZFS
> has been removed as of r325320.  The system call now returns EINVAL
> when used on a ZFS file.  Although the new behavior complies with the
> standard, some consumers are not prepared to cope with it.
> One known victim is lld prior to r325420.
> 

It just popped into my head... does this mean that kernels running
r325320+ on systems using ZFS will be unable to host build jails for
earlier versions / branches because lld will fail in the jail?

I think that will be a big problem for the ports team's package
building process, and for anyone using poudriere.

-- 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: FreeBSD Documentation

[Ian Lepore]

On Sun, 2017-10-29 at 11:37 -0400, Allan Jude wrote:
> On 2017-10-29 11:00, Kurt Jaeger wrote:
> > 
> > Hi!
> > 
> > > 
> > > How can we suggest edits for the docs?
> > Checkout the docs repo:
> > 
> >   svn checkout https://svnweb.freebsd.org/doc/head/ .
> > 
> > Change the relevant files, create a new problem report on
> > 
> >   https://bugs.freebsd.org/
> > 
> > and attach the svn diff to that problem report.
> > 
> Since the document in question is a man page, it actually lives in
> the
> src tree.
> 
> svn checkout https://svn.freebsd.org/base/head/ .
> 
> cd usr.sbin/jail
> 
> vi jail.8
> 
> svn diff > jail_manpage.patch
> 
> And then attach that patch to a bugzilla, or upload it to
> reviews.freebsd.org
> 
> 

I hope I'm right in thinking that just submitting the proposed changes
as plain text would also be an option?  I suspect there are more people
with good ideas on improving manpages than there are people who've
decided they really want to learn the arcane skill of manpage markup
language.

-- 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: host, bhyve vm and ntpd

[Ian Lepore]

On Wed, 2017-10-25 at 00:43 +0300, Boris Samorodov wrote:
> Hi Ian, All!
> 
> 22.10.2017 01:15, Ian Lepore пишет:
> > 
> > On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
> > > 
> > > Ian Lepore writes:
> > > > 
> > > > 
> > > > Beyond that, I'm not sure what else to try.  It might be necessary to
> > > > get some bhyve developers involved (I know almost nothing about it).
> > > NTPD behaves more normally on uniprocessor VMs.
> > > 
> > > A FreeBSD bhyve-guest running on a freebsd host will select a
> > > different timecounter depending on whether it is a multiprocessor or a
> > > uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
> > > timecounter in a uniprocessor.  NTP functions there as expected.
> > > 
> > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
> > > dummy(-100)
> > > kern.timecounter.hardware: TSC-low
> > > 
> > > The very same VM, when given two total CPUs, selected HPET (if I
> > > recall) and the timekeeping with NTPD was unreliable, with many
> > > step-resets to the clock.
> > > 
> > Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
> > looks right.  I wonder if this is just a simple roundoff error in
> > converting between 10.0MHz and SBT units?  If so, that could be wished
> > away easily by using a power-of-2 frequency for the virtual HPET.  I
> > wonder if the attached patch is all that's needed?
> I suppose the answer is "yes", the patch helped. Here are two samples
> (host for bhyve VM without your patch and after patching):
> ---
> https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.1000.txt
> https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.16777216.txt
> ---
> 
> The command was:
> % for t in `jot 1000`; do ntpq -pn; sleep 64; done
> 
> The patch made the system to stabilize the process.
> Ian, thank you!
> 

Hmmm.  The startup behavior wasn't great, it took a long time and
several clock steps for it to figure out the frequency error and get
the clock under control.  But, as you say, it did eventually stabilize
this time.

Can you show the /var/db/ntpd.drift file contents of the host and
guest?  Ideally, now that it's stable, the two values should be very
close.  If they're not, maybe this isn't the right fix.

-- 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: host, bhyve vm and ntpd

[Ian Lepore]

On Sun, 2017-10-22 at 11:31 +0300, Boris Samorodov wrote:
> 22.10.2017 01:15, Ian Lepore пишет:
> > 
> > On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
> > > 
> > > Ian Lepore writes:
> > > > 
> > > > 
> > > > Beyond that, I'm not sure what else to try.  It might be necessary to
> > > > get some bhyve developers involved (I know almost nothing about it).
> > > NTPD behaves more normally on uniprocessor VMs.
> > > 
> > > A FreeBSD bhyve-guest running on a freebsd host will select a
> > > different timecounter depending on whether it is a multiprocessor or a
> > > uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
> > > timecounter in a uniprocessor.  NTP functions there as expected.
> > > 
> > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
> > > dummy(-100)
> > > kern.timecounter.hardware: TSC-low
> > > 
> > > The very same VM, when given two total CPUs, selected HPET (if I
> > > recall) and the timekeeping with NTPD was unreliable, with many
> > > step-resets to the clock.
> > > 
> > Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
> > looks right.  I wonder if this is just a simple roundoff error in
> > converting between 10.0MHz and SBT units?  If so, that could be wished
> > away easily by using a power-of-2 frequency for the virtual HPET.  I
> > wonder if the attached patch is all that's needed?
> I've tried the patch (at bhyve guest) and nothing has changed. Should
> the patched system be tested at bhyve guest or bhyve host?
> 

Oh, I'm sorry, I should have mentioned that's for the host side.

-- 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: host, bhyve vm and ntpd

[Ian Lepore]

On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
> Ian Lepore writes:
> > 
> > Beyond that, I'm not sure what else to try.  It might be necessary to
> > get some bhyve developers involved (I know almost nothing about it).
> NTPD behaves more normally on uniprocessor VMs.
> 
> A FreeBSD bhyve-guest running on a freebsd host will select a
> different timecounter depending on whether it is a multiprocessor or a
> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
> timecounter in a uniprocessor.  NTP functions there as expected.
> 
> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
> dummy(-100)
> kern.timecounter.hardware: TSC-low
> 
> The very same VM, when given two total CPUs, selected HPET (if I
> recall) and the timekeeping with NTPD was unreliable, with many
> step-resets to the clock.
> 

Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
looks right.  I wonder if this is just a simple roundoff error in
converting between 10.0MHz and SBT units?  If so, that could be wished
away easily by using a power-of-2 frequency for the virtual HPET.  I
wonder if the attached patch is all that's needed?

-- Ian
Index: sys/amd64/vmm/io/vhpet.c
===
--- sys/amd64/vmm/io/vhpet.c	(revision 324176)
+++ sys/amd64/vmm/io/vhpet.c	(working copy)
@@ -51,7 +51,7 @@ __FBSDID("$FreeBSD$");
 
 static MALLOC_DEFINE(M_VHPET, "vhpet", "bhyve virtual hpet");
 
-#define	HPET_FREQ	1000		/* 10.0 Mhz */
+#define	HPET_FREQ	16777216		/* 16.7 (2^24) Mhz */
 #define	FS_PER_S	1000ul
 
 /* Timer N Configuration and Capabilities Register */
___
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: host, bhyve vm and ntpd

[Ian Lepore]

On Fri, 2017-10-20 at 21:15 +0300, Boris Samorodov wrote:
> 20.10.2017 21:04, Ian Lepore пишет:
> > 
> > On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote:
> > > 
> > > (CC to freebsd-virtualization@)
> > > 
> > > 20.10.2017 19:32, Ian Lepore пишет:
> > > > 
> > > > 
> > > > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote:
> > > > > 
> > > > > 
> > > > > 20.10.2017 18:31, Boris Samorodov пишет:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 20.10.2017 18:12, Ian Lepore пишет:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi All,
> > > > > > > > 
> > > > > > > > I have got a host:
> > > > > > > > ---
> > > > > > > > bhyve-host% uname -a
> > > > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: 
> > > > > > > > Fri Aug
> > > > > > > > 25 05:25:26 MSK 2017
> > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 
> > > > > > > > amd64
> > > > > > > > ---
> > > > > > > > 
> > > > > > > > And a bhyve vm:
> > > > > > > > ---
> > > > > > > > bhyve-vm: uname -a
> > > > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 
> > > > > > > > r324782: Fri
> > > > > > > > Oct 20 05:12:17 MSK 2017
> > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
> > > > > > > > ---
> > > > > > > > 
> > > > > > > > The only difference at kernel configs is a colored console. :-)
> > > > > > > > 
> > > > > > > > And here I get some weird (is it?) result at the VM (I expect 
> > > > > > > > ntpd to be
> > > > > > > > more stable):
> > > > > > > > ---
> > > > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
> > > > > > > >  remote   refid  st t when poll reach   delay   
> > > > > > > > offset
> > > > > > > > jitter
> > > > > > > > ==
> > > > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   
> > > > > > > > -1.202
> > > > > > > > 316.407
> > > > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   
> > > > > > > > -1.202
> > > > > > > > 358.395
> > > > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  
> > > > > > > > -328.42
> > > > > > > > 181.405
> > > > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  
> > > > > > > > -328.42
> > > > > > > > 214.868
> > > > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  
> > > > > > > > -328.42
> > > > > > > > 214.868
> > > > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  
> > > > > > > > -328.42
> > > > > > > > 268.618
> > > > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  
> > > > > > > > -328.42
> > > > > > > > 333.175
> > > > > > > >  XX.XX.XX.1  .STEP.  16 u 1910   6400.000   
> > > > > > > >  0.000
> > > > > > > > 0.000
> > > > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  
> > > > > > > > -262.63
> > > > > > > > 0.004
> > > > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   

Re: host, bhyve vm and ntpd

[Ian Lepore]

On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote:
> (CC to freebsd-virtualization@)
> 
> 20.10.2017 19:32, Ian Lepore пишет:
> > 
> > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote:
> > > 
> > > 20.10.2017 18:31, Boris Samorodov пишет:
> > > > 
> > > > 
> > > > 20.10.2017 18:12, Ian Lepore пишет:
> > > > > 
> > > > > 
> > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
> > > > > > 
> > > > > > 
> > > > > > Hi All,
> > > > > > 
> > > > > > I have got a host:
> > > > > > ---
> > > > > > bhyve-host% uname -a
> > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri 
> > > > > > Aug
> > > > > > 25 05:25:26 MSK 2017
> > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
> > > > > > ---
> > > > > > 
> > > > > > And a bhyve vm:
> > > > > > ---
> > > > > > bhyve-vm: uname -a
> > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 
> > > > > > r324782: Fri
> > > > > > Oct 20 05:12:17 MSK 2017
> > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
> > > > > > ---
> > > > > > 
> > > > > > The only difference at kernel configs is a colored console. :-)
> > > > > > 
> > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd 
> > > > > > to be
> > > > > > more stable):
> > > > > > ---
> > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
> > > > > >  remote   refid  st t when poll reach   delay   
> > > > > > offset
> > > > > > jitter
> > > > > > ==
> > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   
> > > > > > -1.202
> > > > > > 316.407
> > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   
> > > > > > -1.202
> > > > > > 358.395
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  
> > > > > > -328.42
> > > > > > 181.405
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  
> > > > > > -328.42
> > > > > > 214.868
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  
> > > > > > -328.42
> > > > > > 214.868
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  
> > > > > > -328.42
> > > > > > 268.618
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  
> > > > > > -328.42
> > > > > > 333.175
> > > > > >  XX.XX.XX.1  .STEP.  16 u 1910   6400.000
> > > > > > 0.000
> > > > > > 0.000
> > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  
> > > > > > -262.63
> > > > > > 0.004
> > > > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  
> > > > > > -331.43
> > > > > > 68.800
> > > > > > ---
> > > > > > 
> > > > > > At the same time host's results are very stable:
> > > > > > ---
> > > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
> > > > > >  remote   refid  st t when poll reach   delay   
> > > > > > offset
> > > > > > jitter
> > > > > > ==
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.401
> > > > > > 0.176
> > > > > > 0.106
> > > > > > *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.401
> > > > > > 0.176
> > > > > > 0.459
> > >

Re: host, bhyve vm and ntpd

[Ian Lepore]

On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote:
> 20.10.2017 18:31, Boris Samorodov пишет:
> > 
> > 20.10.2017 18:12, Ian Lepore пишет:
> > > 
> > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
> > > > 
> > > > Hi All,
> > > > 
> > > > I have got a host:
> > > > ---
> > > > bhyve-host% uname -a
> > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
> > > > 25 05:25:26 MSK 2017
> > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
> > > > ---
> > > > 
> > > > And a bhyve vm:
> > > > ---
> > > > bhyve-vm: uname -a
> > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
> > > > Oct 20 05:12:17 MSK 2017
> > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
> > > > ---
> > > > 
> > > > The only difference at kernel configs is a colored console. :-)
> > > > 
> > > > And here I get some weird (is it?) result at the VM (I expect ntpd to be
> > > > more stable):
> > > > ---
> > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
> > > >  remote   refid  st t when poll reach   delay   offset
> > > > jitter
> > > > ==
> > > >  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
> > > > 316.407
> > > >  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
> > > > 358.395
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
> > > > 181.405
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
> > > > 214.868
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
> > > > 214.868
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
> > > > 268.618
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
> > > > 333.175
> > > >  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
> > > > 0.000
> > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
> > > > 0.004
> > > >  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
> > > > 68.800
> > > > ---
> > > > 
> > > > At the same time host's results are very stable:
> > > > ---
> > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
> > > >  remote   refid  st t when poll reach   delay   offset
> > > > jitter
> > > > ==
> > > > 
> > > > 
> > > > 
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
> > > > 0.106
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
> > > > 0.459
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
> > > > 0.940
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
> > > > 0.940
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
> > > > 1.566
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
> > > > 1.739
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
> > > > 2.365
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
> > > > 3.110
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
> > > > 3.929
> > > > *XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
> > > > 4.722
> > > > ---
> > > > 
> > > > The network is organized via bridge -- host igb and vm tap interfaces
> > > > are members of one bridge.
> > > > 
> > > > Are those results expected? Does it smell like a bug? Should I dig
> > > > furter?
> > > > 
> > > So it is repeatedly stepping the clock in the VM? (Set
> > > kern.timecounter.stepwarnings=1 to log steps).
> > No kernel/ntpd messages for 20 minute

Re: host, bhyve vm and ntpd

[Ian Lepore]

On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
> Hi All,
> 
> I have got a host:
> ---
> bhyve-host% uname -a
> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
> 25 05:25:26 MSK 2017
> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
> ---
> 
> And a bhyve vm:
> ---
> bhyve-vm: uname -a
> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
> Oct 20 05:12:17 MSK 2017
> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
> ---
> 
> The only difference at kernel configs is a colored console. :-)
> 
> And here I get some weird (is it?) result at the VM (I expect ntpd to be
> more stable):
> ---
> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
>  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
> 316.407
>  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
> 358.395
> *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
> 181.405
> *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
> 214.868
> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
> 214.868
> *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
> 268.618
> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
> 333.175
>  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
> 0.000
>  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
> 0.004
>  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
> 68.800
> ---
> 
> At the same time host's results are very stable:
> ---
> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> 
> 
> 
> *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
> 0.106
> *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
> 0.459
> *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
> 0.940
> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
> 0.940
> *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
> 1.566
> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
> 1.739
> *XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
> 2.365
> *XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
> 3.110
> *XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
> 3.929
> *XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
> 4.722
> ---
> 
> The network is organized via bridge -- host igb and vm tap interfaces
> are members of one bridge.
> 
> Are those results expected? Does it smell like a bug? Should I dig
> furter?
> 

So it is repeatedly stepping the clock in the VM? (Set
kern.timecounter.stepwarnings=1 to log steps).  That is usually a sign
that the chosen timecounter is running at a different frequency than it
claimed to be when it registered itself -- the host may not be
emulating the timer hardware properly in the guest.  What is the output
of sysctl kern.timecounter in the vm?

Also, what is the output of ntptime(8) in the vm?

-- 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: pfind_locked(pid) fails when in a jail?

[Ian Lepore]

On Tue, 2017-10-17 at 21:26 +, Rick Macklem wrote:
> Mateusz Guzik wrote:
> [lots of stuff snipped]
> > 
> > I proposed registration of per-process callbacks, not filtering.
> > The code would just walk the list/table/whatever and call everything on
> > it - they asked for it.
> Yep, this would work for the NFSv4 client.
> Way back when, all I did in OpenBSD was add a function pointer to "struct 
> proc"
> that was normally NULL, but set to a function in the NFS client when an NFSv4
> Open was done for the process.
> 
> I suspect you'd want something like a linked list, so that multiple "users" 
> could register callback functions upon exit or ...
> 
> rick

FYI, I'm dropping out of this conversation, not because I'm out of
opinions, but for some reason I'm not getting the emails from Mateusz
that you're replying to, and now so much context is snipped that I
don't know what's being said by whom.

-- 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: pfind_locked(pid) fails when in a jail?

[Ian Lepore]

On Tue, 2017-10-17 at 00:08 +, Rick Macklem wrote:
> [stuff snipped]
> > 
> > > 
> > > > 
> > > > 
> > > pfind* does not do any filtering.
> > > 
> Hmm, well I have no idea why the jailed mounts get looping in here then.
> 
> > 
> > > 
> > > The real question though is why are you calling it in the first place. The
> > > calls
> > > I grepped in nfscl_procdoesntexist are highly suspicious - there is no
> > > guarantee
> > > the process you found here is the same you had at the time you were saving
> > > the pid.
> > > 
> Long long ago (about 2002) this code was written for OpenBSD2.6. I added
> a call from the kernel exit() code to do this. When I ported it to FreeBSD
> around 2005, I didn't find any way for a process exit notification to be done,
> so I created the first version of this code. (This way of doing it was first
> coded for Mac OS X 10.3, if I recall correctly.)
> 
> Since it does check that the time of process creation is the same, it doesn't
> seem likely that it would find a different process (ie. two processes with the
> same pid that were created at the same time within the clock resolution of
> that creation time seems highly unlikely in practice?).
> 
> > 
> > > 
> > > There is no usable process exit notification right now, but it can be 
> > > added
> > > if necessary.
> > > 
> If there was a way for the NFS client to register to get a notification that a
> given process is terminating (exit'ng), that could certainly be used instead
> of this code.
> 
> I wouldn't want a call for every exit(), but only the ones that have NFSv4 
> opens.
> 
> > 
> > > 
> > > 
> > > Does that mean there is something wrong with the existing eventhandler
> > > notifications related to proc fork/exec/exit?
> > > 
> > I already noted in the other mail that the current mechanism has
> > avoidable global locking, lists traversals etc. But even with these
> > issues fixed it calls everything for everyone.
> > 

All of that locking-and-lookup overhead in the event notification
system is already happening on every process exit, whether anyone has
registered an event handler or not.  If you want to actually avoid the
avoidable overheads, the answer is to fix the existing code, not create
another new mechanism that adds more overhead without addressing the
existing problem.  I suspect the worst of the existing overhead can be
eliminated with some fairly small changes, and I hope to find time to
look at it later this week.

On the issue of filtering the callbacks to just the exits you're
interested in... it doesn't seem any better to me to do the filtering
at the source unless there are multiple registered handlers at once
that all need the same filtering.  How many different things in the
kernel would want process-exit filtering based on "have NFSv4 opens"?
 That seems like a single-consumer kind of filter.

-- Ian

> > What's needed is a mechanism to register per-process callbacks. Details
> > can be flamed over (e.g. should it require allocating a buffer per
> > process or perhaps just one and then point to it from a resizable
> > per-proc table when registered), but calling something which has nothing
> > to do in almost all cases and from in a super inefficient way at that is
> > definitely something we need to start cleaning up.
> Yes, I would agree, although it doesn't explain what this CPU hog case is
> caused by.
> 
> Thanks for the comments and if you create/commit the above, let me know
> and I'll change the NFS client code to use it (if your patch doesn't do that).
> 
> rick
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@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: pfind_locked(pid) fails when in a jail?

[Ian Lepore]

On Tue, 2017-10-17 at 00:38 +0200, Mateusz Guzik wrote:
> On Tue, Oct 17, 2017 at 12:24 AM, Rick Macklem  wrote:
> 
> > 
> > Hi,
> > 
> > A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot
> > of CPU
> > when the NFSv4 mount is in a jail has been reported to the freebsd-stable@
> > mailing list.
> > 
> > I know nothing about jails, but when looking at the code, the most obvious
> > cause of this would be "pfind_locked(pid)" failing to find a process.
> > - Will a jail affect how pfind_locked() behaves?
> > - If the answer is "yes", then I need to know how to either...
> >    1 - Make pfind_locked() work the same as when no jail exists.
> >    OR
> >    2 - A way for the Renew thread can determine that a jail will affect
> > pfind_locked()
> >  behaviour, so it can avoid this problem.
> > #1 is preferred, since #2 may not be 100% correct, although #2 would allow
> > the
> > code to behave well for most cases. (The exception is a case where a file
> > remains
> > open for a long period of time, with different processes doing byte range
> > locks on
> > the file.)
> > 
> pfind* does not do any filtering.
> 
> The real question though is why are you calling it in the first place. The
> calls
> I grepped in nfscl_procdoesntexist are highly suspicious - there is no
> guarantee
> the process you found here is the same you had at the time you were saving
> the pid.
> 
> There is no usable process exit notification right now, but it can be added
> if necessary.
> 

Does that mean there is something wrong with the existing eventhandler
notifications related to proc fork/exec/exit?

-- 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: r324353: boot failure: failed with error 19

[Ian Lepore]

On Fri, 2017-10-06 at 22:33 +0200, O. Hartmann wrote:
> First of all, I think something has changed, since /dev/ufs doesn't get 
> populated anymore
> by usage of "gpart label" command. Second, there is a high chance that I 
> messed up
> NanoBSD a bit, a couple of days ago I tried to sync with the code base 
> changes and I made
> most changes effectively what is now "legacy.sh".

Here is the crucial error...  Labels created with glabel are in
/dev/label, they have never been in /dev/ufs.

/dev/ufs is populated by the contents of ufs filesystem labels, which
are created using "newfs -L" or "tunefs -L".  To see what label (if
any) is on your root filesystem, use:

  # dumpfs / | grep vol
  volname   roots1  swuid   0   providersize262135

If nothing appears between "volname" and "swuid" it has no label.

I'm not disputing something may have changed that is causing you
problems, I'm just trying to point out that you are chasing the wrong
cause based on some kind of misunderstanding of the symptoms.

-- 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: RFC how to use kernel procs/threads efficiently

[Ian Lepore]

On Fri, 2017-10-06 at 19:02 +, Rick Macklem wrote:
> Hi,
> 
> I have now dropped the client side of Flexible File Layout for pNFS into head
> and I believe it is basically working.
> Currently when talking to mirrored DS servers, it does the Write and Commit
> RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed 
> to to
> completion.
> 
> To do them concurrently, I need separate kernel processes/threads to do them.
> I can think of two ways to do this:
> 1 - The code that I have running in projects/pnfs-planb-server for the pNFS 
> server
>   side does a kproc_create() to create a kernel process that does the RPC 
> and
>   then krpc_exit()s.
>   - This was easy to code and works. However, I am concerned that there is
> going to be excessive overheads from doing all the kproc_create()s and
> kproc_exit()s?
>    Anyone know if these calls will result in large overheads?
> 2 - I haven't coded this, but the other way I can think of to do this is to
>   create a pool of threads (kthread_create() is sufficient in this case, I
>   think?) and then hand each RPC to an available thread so it can do the 
> RPC.
>   - Other than a little more complex coding, the main issue I see with 
> this one
> is "How many threads and when to create more/less of them.".
> 
> Anyhow, any comments w.r.t. the merits of either of the above approaches
> (or a suggestion of other ways to do this) would be appreciated, rick

taskqueue(9) is an existing mechanism to enqueue functions to execute
asynch using a pool of threads, but it doesn't answer the scalability
questions.  In fact it may make them harder, inasmuch as I don't think
there's a mechanism to dynamically adjust the number of threads after
first calling taskqueue_start_threads().

-- 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: C++ in jemalloc

[Ian Lepore]

On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote:
> On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard 
> wrote:
> > 
> > Luckily most kernel and world code that I actively use
> > does not throw C++ exceptions in my use.
> > 
> > But devel/kyua is majorly broken by the C++ exception
> > issue: It makes extensive use of C++ exceptions. In my
> > view that disqualifies clang as being "close": I view
> > my activity as a hack until devel/kyua is generally
> > operable and so available for use in testing.
> I don't think that is a major roadblock; a broken port is a broken
> port.  Kyua is a relatively unimportant one for most users.  In this
> particular case, maybe kyua (a leaf binary) could be built with GCC
> instead of Clang on any platform with broken C++ exceptions.
> 
> Best,
> Conrad

It isn't about "a broken port".  All C++ code is broken if exceptions
don't work.  That means devd is broken.  Not to mention clang itself.
 It may be that neither of those relies on exceptions for routine
operation and uses them only for error handling, and errors mostly
don't happen.  There is plenty of C++ code in the world where
exceptions are used in non-fatal-error cases and where the applications
just don't work at all without them.

-- 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: C++ in jemalloc

[Ian Lepore]

On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt 
> wrote:
> 
> > 
> >  Hi all,
> > 
> > The jemalloc developers have wanted to start using C++ for a while, to
> > enable some targeted refactorings of code we have trouble maintaining due
> > to brittleness or complexity (e.g. moving thousand line macro definitions
> > to templates, changing the build->extract symbols->rebuild mangling scheme
> > for internal symbols to one using C++ namespaces). We'd been holding off
> > because we thought that FreeBSD base all had to compile on GCC 4.2, in
> > order to support some esoteric architectures[1].
> > 
> > The other day though, I noticed that there is some C++ shipping with
> > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING
> > document that C++11 is a minimum for FreeBSD 11). This, combined with the
> > fact that ports now points to a modern gcc, makes me think we were
> > incorrect, and can turn on C++ without breaking FreeBSD builds.
> > 
> > Am I right? Will anything break if jemalloc needs a C++ compiler to build?
> > We will of course not use exceptions, RTTI, global constructors, the C++
> > stdlib, or anything else that might affect C source or link compatibility.
> > 
> > Thanks,
> > David (on behalf of the jemalloc developers
> > 
> > [1] That being said, we don't compile or test on those architectures, and
> > so probably don't work there in the first place if I'm being honest. But
> > we'd also like to avoid making that a permanent state of affairs that can't
> > be changed.
> > 
> For FreeBSD 10 and earlier, this would likely break all architectures that
> aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by clang,
> but not super well. For FreeBSD 12, we're getting close for everything
> except sparc64 (whose fate has not yet been finally decided).
> 
> So for the popular architectures, this arrangement might work. For building
> with external toolchains, it might also work. Some of the less popular
> architectures may be a problem.
> 
> Does that help? It isn't completely cut and dried, but it should be helpful
> for you making a decision.
> 
> Warner

Wait a sec... we've been compiling C++ code with gcc 4.2 since like
2006.  What am I missing here that keeps this answer from being a
simple "go for it"?

Just stay away from C++11 features and gcc 4.2 should work fine.  (DTC
may require C++11, but that was likely the author's choice given that
there was no requirement for it to work on pre-clang versions of
freebsd).

-- 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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Ian Lepore]

On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:
> Our 10.4 system is using gcc (for now).
> 
> when we compile the devel/binutils port, we get a failure with a
> bunch 
> of these errors:
> 
> 
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb1EEE]' 
> of aarch64.o
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb0EEE]' 
> of aarch64.o
> 
> 
> I managed to defeat these one before but I forget how.
> 
> possibly the answer is to use clang/clang++ for this item but I
> tried 
> defining CC and CXX  to clang/clang++ in the Makefile but that
> didn't 
> seem to help
> 
> there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.  

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
 Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

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

[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: Pre-filled RAM disk.

[Ian Lepore]

On Wed, 2017-09-20 at 22:47 -0500, Jon Brawn wrote:
> On Sep 20, 2017, at 10:35 PM, Ian Lepore  wrote:
> > 
> > 
> > On Wed, 2017-09-20 at 21:23 -0600, Warner Losh wrote:
> > > 
> > > On Wed, Sep 20, 2017 at 9:16 PM, Warner Losh 
> > > wrote:
> > > 
> > > > 
> > > > On Wed, Sep 20, 2017 at 8:50 PM, Jon Brawn 
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Wotcha!
> > > > > 
> > > > > 
> > > > > So, what does FreeBSD have to offer in the way of ramdisk
> > > > > functionality?
> > > > > 
> > > > Yes.
> > > > 
> > > > See MD_ROOT and friends.
> > > > 
> > > The MFS_IMAGE kernel option has replaced this.
> > > 
> > > Warner
> > And the documentation (such as it is) for MFS_IMAGE is in the md(4)
> > manpage.  In a nutshell, it's a mechanism that lets you compile an
> > existing filesystem image directly into the kernel and it is
> > mounted as
> > a memory filesystem at boot time.  Hopefully being contained within
> > the
> > kernel will make the problem of loading it at a fixed physical
> > address
> > go away for you.
> > 
> > -- Ian
> > 
> I really need to bring more of my work problems to this list,
> obviously. Thanks folks!
> 
> Jon.
> ___

Another good place for help with freebsd on arm is the #bsdmips channel
on efnet, if you're an irc-using kind of person.  Don't let the 'mips'
in the name throw you, it's the channel where the arm, powerpc, and
mips developers hang out.

Oh, and of course, there is also the freebsd-arm@ mailing list.

-- 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: Pre-filled RAM disk.

[Ian Lepore]

On Wed, 2017-09-20 at 21:23 -0600, Warner Losh wrote:
> On Wed, Sep 20, 2017 at 9:16 PM, Warner Losh  wrote:
> 
> > 
> > 
> > 
> > On Wed, Sep 20, 2017 at 8:50 PM, Jon Brawn  wrote:
> > 
> > > 
> > > Wotcha!
> > > 
> > > I work for Arm for my sins, and in my spare time I’ve been
> > > playing with
> > > FreeBSD. In my day job I work with the CPU core validation team,
> > > and one of
> > > the things we do is take the hardware design of a new core and
> > > run it on a
> > > machine called an emulator. This emulator isn’t the same thing as
> > > QEMU, nor
> > > is it just an FPGA, it’s something in the middle - you compile
> > > the hardware
> > > design and download it to the emulator, and it can then run
> > > programs on
> > > your design at about 1MHz. Which is lovely. Our main bread and
> > > butter is to
> > > take such a design and get it to boot Arm Linux, a very cut down
> > > version,
> > > and then run some tests hosted in the Linux environment. These
> > > tests would
> > > typically thrash the snot out of some particular aspect of the
> > > architecture, such as memory sharing amongst multiple processor
> > > cores. Now,
> > > we would like to use other operating systems that behave
> > > differently to
> > > Linux, there are some obvious candidates that I’m not going to
> > > talk about
> > > for legal reasons, but one that was suggested was using FreeBSD
> > > under
> > > emulation.
> > > 
> > > So, what is needed is someway of telling the operating system
> > > that it is
> > > going to use a ram disk for its root filesystem, and that the ram
> > > disk is
> > > going to be at a fixed physical address in the memory map. That
> > > way we can
> > > pre-load root from a file in the emulation environment. In the
> > > Linux
> > > environment we would package the kernel, it’s DRB and the root
> > > filesystem
> > > memory image inside a light-weight bootloader wrapper, load that
> > > at the
> > > right offset into the emulator’s memory map, and twang the
> > > virtual reset
> > > line of the emulated processor. There’s some magic jiggery pokery
> > > to get
> > > console output from what the OS thinks is an AMBA UART, but
> > > that’s about
> > > size of it.
> > > 
> > > So, what does FreeBSD have to offer in the way of ramdisk
> > > functionality?
> > > 
> > Yes.
> > 
> > See MD_ROOT and friends.
> > 
> The MFS_IMAGE kernel option has replaced this.
> 
> Warner

And the documentation (such as it is) for MFS_IMAGE is in the md(4)
manpage.  In a nutshell, it's a mechanism that lets you compile an
existing filesystem image directly into the kernel and it is mounted as
a memory filesystem at boot time.  Hopefully being contained within the
kernel will make the problem of loading it at a fixed physical address
go away for you.

-- 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: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

[Ian Lepore]

On Sat, 2017-09-09 at 15:31 -0700, Simon J. Gerraty wrote:
> Mark Millard  wrote:
> > 
> > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko
> > lrwxr-xr-x  1 root  wheel  25 Sep  8 22:47:36 2017
> > /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko
> > lrwxr-xr-x  1 root  wheel  68 Sep  6 20:27:20 2017
> > /media/boot/kernel/if_igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53-
> > installkernel/boot/kernel/if_em.ko
> > 
> > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes
> > would not exist for booting the PINE64 that the USB SSD is for:
> > so file not found if a usage attempt is made.
> Yes, when making symlinks in presence of DESTDIR, the src should have
> $DESTDIR removed - the following should usually be safe:
> 
> ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR}
> 

I think the modern fix for this would be "install -l rs $src $DESTDIR",
that should result in if_igb.ko -> if_em.ko without any dir nodes in
the link.

-- 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: Custom Kernel Fail

[Ian Lepore]

On Tue, 2017-08-29 at 19:54 -0400, Monty Chaney-Geib wrote:
> I'm getting a failure building a custom kernel on arm64.
> 
> "/usr/src/sys/dev/mii/smcphy.c:49:10: fatal error: 'miidevs.h' file
> not
> found"
> 
> Let me know what you guys recommend.
> -Monty

Add "device mii" to your config.

-- 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: src/libexec/Makefile damaged fails to build rshd

[Ian Lepore]

On Mon, 2017-08-07 at 00:05 +0200, Julian H. Stacey wrote:
> Ian Lepore wrote:
> > 
> > On Sun, 2017-08-06 at 22:47 +0200, Julian H. Stacey wrote:
> > > 
> > > Hi, Reference:
> > > > 
> > > > 
> > > > From:   "Julian H. Stacey" 
> > > > Date:   Sun, 06 Aug 2017 22:25:02 +0200
> > > "Julian H. Stacey" wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The half baked mod. to src/libexec/Makefile could be
> > > > > > > backed
> > > > > > > out
> > > > I was wrong, sorry, code is not half baked, cos further down I
> > > > spotted :
> > > > .if ${MK_RCMDS} != "no"
> > > > _rlogind=rlogind
> > > > _rshd=rshd
> > > > .endif
> > > > 
> > > > cd /usr/src; find . -type f | xargs grep MK_RCMDS | grep -v
> > > > Makefile:
> > > > ./tools/build/mk/OptionalObsoleteFiles.inc:.if
> > > > ${MK_RCMDS} ==
> > > > no
> > > > 
> > > > I'm reading that while make world continues.
> > > Finaly found it, after guessing some shell might roll MK_RCMDS
> > > from
> > > a list including RCMDS, & finding man src.conf with WITH_RCMDS
> > > Took me a while to find.Thanks Ngie for your time.
> > > 
> > The thanks seem appropriate enough, given the tone and content of
> > your
> > previous emails. What's missing is the very-much-required appology.
> > 
> > -- Ian
> As said & to quote Ian L. quoting me: "I was wrong, sorry"
> Ngie, my apologies for consuming your time, & thanks for looking at
> this.

What was worthy of appology was not any "waste of time" but the totally
insulting condescending tone aimed at pretty much the entire freebsd
community. Here's a little hint for you: people who work for you for
free are probably not strongly motivated by being mocked as incompetent
fools for the work they do.

-- 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: src/libexec/Makefile damaged fails to build rshd

[Ian Lepore]

On Sun, 2017-08-06 at 22:47 +0200, Julian H. Stacey wrote:
> Hi, Reference:
> > 
> > From:   "Julian H. Stacey" 
> > Date:   Sun, 06 Aug 2017 22:25:02 +0200
> "Julian H. Stacey" wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > The half baked mod. to src/libexec/Makefile could be backed
> > > > > out
> > I was wrong, sorry, code is not half baked, cos further down I
> > spotted :
> > .if ${MK_RCMDS} != "no"
> > _rlogind=   rlogind
> > _rshd=  rshd
> > .endif
> > 
> > cd /usr/src; find . -type f | xargs grep MK_RCMDS | grep -v
> > Makefile:
> > ./tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_RCMDS} ==
> > no
> > 
> > I'm reading that while make world continues.
> Finaly found it, after guessing some shell might roll MK_RCMDS from
> a list including RCMDS, & finding man src.conf with WITH_RCMDS
> Took me a while to find.  Thanks Ngie for your time.
> 

The thanks seem appropriate enough, given the tone and content of your
previous emails.  What's missing is the very-much-required appology.

-- 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: order of executing MOD_LOAD and registering module sysctl-s

[Ian Lepore]

On Wed, 2017-08-02 at 08:49 -0700, John Baldwin wrote:
> On Wednesday, August 02, 2017 12:39:36 PM Hans Petter Selasky wrote:
> > 
> > On 08/02/17 12:13, Andriy Gapon wrote:
> > > 
> > > 
> > > As far as I understand a module initialization routine is
> > > executed via the
> > > sysinit mechanism.  Specifically, module_register_init is set up
> > > as the sysinit
> > > function for every module and it calls MOD_EVENT(mod, MOD_LOAD)
> > > to invoke the
> > > module event handler.
> > > 
> > > In linker_load_file() I see the following code:
> > >  linker_file_register_sysctls(lf);
> > >  linker_file_sysinit(lf);
> > > 
> > > I think that this means that any statically declared sysctl-s in
> > > the module
> > > would be registered before the module receives the MOD_LOAD
> > > event.
> > > It's possible that some of the sysctl-s could have procedures as
> > > handlers and
> > > they might access data that is supposed to be initialized by the
> > > module event
> > > handler.
> > > 
> > > So, for example, running sysctl -a at just the right moment
> > > during the loading
> > > of a module might end up in an expected behavior (including a
> > > crash).
> > > 
> > > Is my interpretation of how the code works correct?
> > > Can the order of linker_file_sysinit and
> > > linker_file_register_sysctls be changed
> > > without a great risk?
> > > 
> > > Thank you!
> > > 
> > > P.S.
> > > The same applies to:
> > >  linker_file_sysuninit(file);
> > >  linker_file_unregister_sysctls(file);
> > > 
> > Hi,
> > 
> > Not sure if this answers your question.
> > 
> > If a SYSCTL() is TUNABLE, it's procedure can be called when the
> > sysctl 
> > is created. Else the SYSCTL() procedure callback might be called
> > right 
> > after it's registered. I think there is an own subsystem in
> > sys/kernel.h 
> > which takes care of the actual SYSCTL() creation/destruction -
> > after the 
> > linker is involved.
> sysctl nodes are created explicitly via linker_file_register_sysctls,
> not via
> SYSINITs, so you can't order them with respect to other init
> functions.
> 
> I think Andriy's suggestion of doing sysctls "inside" sysinits (so
> they are
> registered last and unregistered first) is probably better than the
> current
> state and is a simpler fix than changing all sysctls to use SYSINITs.
> 

But if module sysctls are registered last then the ones flagged as
CTLFLAG_TUN won't have their tunable values populated before the
MOD_LOAD handler runs, is that going to cause trouble?  It would suck
to have to handle things differently in a driver depending on whether
you're compiled into the kernel or kldload'd interactively.

-- 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: netgraph: documentation issue? What kernel options? Where to find?

[Ian Lepore]

On Sun, 2017-07-16 at 22:48 +0200, O. Hartmann wrote:
> For a small SoC based system, I use a highly customised static kernel
> and build the
> system via NanoBSD with no kernel modules.
> 
> Tyring to track down some network issues with recent CURRENT I
> figured out, that when
> using the ppp client to connect via modem to the ISP and there is no 
> 
> options   NETGRAPH_ETHER
> options   NETGRAPH_PPPOE
> 
> in the kernel configuration, the resulting system fails to establish
> a ppp session. The
> man page states, that a netgraph node is established, but as hard as
> I look, I can not
> find any(!) information in the man pages what options are
> necessary/optional to provide
> the correct module statically.
> 
> The same is for many other NETGRAPH_XXX features. Starting from man
> page "man 4
> netgraph", section "SEE ALSO", I started tweaking the kernel with
> NETGRAPH_XXX, i.e.
> ng_vlan -> NETGRAPH_VLAN until the compiler bails out with an error,
> for instance
> ng_car -> NETGRAPH_CAR.
> 
> I tried to find out what options cover which netgraph module but
> there is - right,
> nothing I can find on a direct route.
> 
> Since netgraph isn't so brand new (I guess ~ 2000 from the PDFs I
> found on the network),
> there must be some documentation other than "reading the source
> code".
> 
> Please give me some hints where to find the entry point for the
> appropriate documented
> options for netgraph modules.
> 
> Obviously, some ng_xxx modules are prerequisite for some services to
> work properly, as
> ppp - but I can't find any hints for "options NETGRAPH_ETHER" or
> "options NETGRAPH_PPPOE"
> in the manpages (looked at ppp, pppoed). 
> 
> Thanks in advance,
> kind regards
> 
> Oliver
> 

I can't help with anything specific to netgraph or its [lack of] docs.

For the general question "How do I know what undocumented device or
option statement to put in my kernel config to get x" a good place
to start is /usr/src/sys/conf/NOTES.  It's supposed to contain all the
options and devices (except some machine/arch-specific stuff).  If you
don't find it in NOTES, try "grep -i x *" in that dir, you may find
the thing you're looking for in 'options' or 'files' and get some clues
that way.

For the netgraph stuff, I see that in NOTES it tells you how to find
the manpages for netgraph things, so I guess I accidentally did answer
that part too.  :)

-- 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: about history:)

[Ian Lepore]

On Fri, 2017-06-30 at 21:19 +0300, Toomas Soome wrote:
> hi!
> 
> there is an question about the tty line (canonical) mode — the
> internal implementation is using 2k buffer, but the related (public)
> constants are claiming buffer size about 255 chars. Why it is so -
> any hints about the background there?
> 
> #define MAX_CANON 255   /* max bytes in term canon
> input line */
> #define MAX_INPUT 255   /* max bytes in terminal
> input */
> 
> rgds,
> toomas

I don't have a direct answer to the question, but I do remember even
before the rewrite that gave us the current kern/tty.c and friends, the
old tty code had a #undef MAX_INPUT and then redefined it to 8K, with a
comment that the value in limits.h was "wrong".  From that I might
surmise that people over the years were afraid of changing values in
public header files that were handed down from the depths of unix
history and that might break something if changed.

I'm not sure MAX_CANON has a separate meaning from MAX_INPUT with the
current code.  I think both raw and canonical input use the same
buffering scheme that's based on a linked list of 128-byte chunks.  The
total size of all the chunks on the list isn't compile-time constant,
it's choosen at device open time to provide a buffer that is the
smaller of 64K or 2 seconds of incoming data.  (The code comment for
years said 0.2 seconds of data, and perhaps that was the intent, but I
corrected the comment rather than the code because .2s just isn't
enough for slow embedded systems).

You mention a 2k buffer... at the default input speed of 9600 baud the
2-seconds-size buffer is 1920 bytes.  Pseudo-ttys and video consoles
all seem to get this size.  I just noticed there's nothing in the
current code to prevent a pathologic buffer size of 0 if the input line
speed is set to 0 but the CREAD flag is set (I think maybe a
/dev/.init or .lock file could set the speed to 0).

-- 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: cpp behavior?

[Ian Lepore]

On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote:
> % which cpp
> /usr/bin/cpp
> troutmask:kargl[408] cpp --version
> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
> LLVM 4.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> troutmask:kargl[409] cpp --help |grep trad
>   -traditional-cppEnable some traditional CPP emulation
> troutmask:kargl[410] cpp -traditional-cpp boxmuller.F90 
> cpp: error: unable to execute command: Executable "gcc" doesn't
> exist!
> 
> OK, so what is the preprocessor for clang?
> 

It looks like the problem is that it sees the .F90 and wants to "do the
right thing" for fortran sources, which is "invoke gcc".  I got a clue
by adding '-###' (quotes required) to see what cpp was trying to do
internally.

You might get the effect you want by either adding something like -x
assembler-with-cpp, or maybe by hiding the filetype from cpp:

 cat boxmuller.F90 | cpp -traditional-cpp

-- 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: https://reviews.freebsd.org/D10232

[Ian Lepore]

On Tue, 2017-04-18 at 23:15 +0300, Toomas Soome wrote:
> Hi!
> 
> The network code rework still needs good people to test out the work,
> especially the non-x86 platforms:)  the url is still: https://reviews
> .freebsd.org/D10232
> 
> Once it checks out, we can go for next phase and get some boost for
> network loading.
> 
> thanks,
> toomas

I use netbooting in loader(8) extensively for armv6, and in fact that's
what I'm knee-deep in for $work today too, so I'll give D10232 a look
tonight or tomorrow at the latest.

-- 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: r316958: booting a server takes >10 minutes!

[Ian Lepore]

On Sun, 2017-04-16 at 21:53 -0700, Maxim Sobolev wrote:
> Well, all this suggests to me that there must be some issue with the client
> syslog code in the libc, so that if syslog daemon hangs or has some
> internal issue that would basically render system mostly unusable. I think
> that might be an interesting project for somebody who has some spare time
> on hands to take syslogd as of (r317033 - 1) and see what can be done to
> improve resilience of the system against such a failure mode.
> 
> -Max
> 

On the sending side, the libc code tries very hard to deliver messages
to the unpriveleged /var/run/log socket; if the datagram send fails due
to buffer space (i.e., due to syslogd not keeping up on the read side),
it will endlessly loop to sleep for 1us then try again until it
succeeds.

On the other hand, for /var/run/logpriv apparently the theory is that
hanging a process with enough privs to use that connection would be
bad.  So it retries just once for errors that are not related to buffer
space, and doesn't retry at all if the error was buffer space (which is
a case of the code not quite matching the nearby comments) then gives
up on syslogd and writes the message directly to the console before
returning.

So yeah, there may be some room for improvement in that logic. :)  I
think it could eventually give up in the non-priv case and maybe try an
extra time or two in the priveleged case.

When we ran into this at $work years ago we just wrote our own work-
alike function to use instead of syslog(3); it retries any kind of
failure no more than 3 times, with a millisecond sleep between each
try.  (Losing logging is bad, but losing the functionality of our app
that's trying to do the logging is even worse.)

-- Ian

> On Sun, Apr 16, 2017 at 5:50 PM, Ben Woods 
> wrote:
> 
> > 
> > On 16 April 2017 at 03:24, Larry Rosenman  wrote:
> > 
> > > 
> > > Current SVN seems to have fixed it (via sobomax@ syslogd commit).
> > > 
> > 
> > I experienced this issue too, and can confirm that it existing on
> > r316952,
> > but is resolve on r317033.
> > 
> > It was extremely strange. The symptoms I was experiencing were:
> > - lightdm display manager would fail to start
> > - slim display manager would start, but then fail to login to xfce
> > - "service hald restart" and "service dbus restart" would fail
> > - "pkg upgrade hal" would fail
> > 
> > Regards,
> > Ben
> > 
> > --
> > From: Benjamin Woods
> > woods...@gmail.com
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb
> > sd.org"
> > 
> > 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd
> .org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ntpd dies nightly on a server with jails

[Ian Lepore]

On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote:
> On 17 Mar, O. Hartmann wrote:
> 
> > 
> > Just some strange news:
> > 
> > I left the server the whole day with ntpd disabled and I didn't
> > watch
> > a gain of the RTC by one second, even stressing the machine.
> > 
> > But soon after restarting ntpd, I realised immediately a 30 minutes
> > off! This morning, the discrapancy was almost 5 hours - it looked
> > more
> > like a weird ajustment to another time base than UTC.
> > 
> > Over the weekend I'll leave the server with ntpd disabled and only
> > RTC
> > running. I've the strange feeling that something is intentionally
> > readjusting the ntpd time due to a misconfiguration or a rogue ntp
> > server in the X.CC.pool.ntp.org
> A ntp should recognize a single bad server and ignore it in favor of 
> the other servers that are sane.
> 
> It sounds like something is going off the rails once ntpd starts
> calling
> adjtime().  What is the output of:
>   sysctl kern.clockrate
> 
> I'd suggest starting ntpd and running "ntpq -c pe" a few times a
> minute
> and capturing its output to monitor the status of ntpd as it starts
> up
> and try to capture things going wrong.   You should probably disable
> iburst in ntp.conf to give more visibility in the early startup.
> 
> For the first few minutes ntpd should just be getting reliable
> timestamp
> info and won't start trying to adjust the clock until it has captured
> endough samples and figured out which servers are best.  Then the
> behaviour of the offset is the thing to watch.  If the iniital offset
> is
> large enough, ntpd will step the clock once to get it close to zero,
> otherwise it will just use adjtime to slowy push the offset towards
> zero.  I think though that you will see the offset start gyrating
> madly.
> 
> You might want to set /var/db/ntpd.drift to zero beforehand if there
> is
> an insane value in there.  If the initial drift value is bogus, will
> try
> to use it which will push the time offset away from zero so fast that
> it
> will decide to keep stepping the clock back to zero before it can
> capture enough samples from the external servers to determine the
> true
> local clock drift rate.

Do not set ntpd.drift contents to zero.  Delete the file.  There's a
huge difference between a file that says the clock is perfect and a
missing file which triggers ntpd to do a 15-minute frequency
measurement to come up with the initial drift correction.

-- 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: ntpd dies nightly on a server with jails

[Ian Lepore]

On Fri, 2017-03-17 at 18:05 +0100, O. Hartmann wrote:
> Am Wed, 15 Mar 2017 13:12:37 -0700
> Cy Schubert  schrieb:
> 
> > 
> > Hi O.Hartmann,
> > 
> > I'll try to answer as much as I can in the noon hour I have left.
> > 
> > In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilie
> > n.de>, 
> > "O. H
> > artmann" writes:
> > > 
> > > Running a host with several jails on recent CURRENT (12.0-CURRENT 
> > > #8 r315187:
> > > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily
> > > basis.
> > > 
> > > The box is an older two-socket Fujitsu server equipted with two
> > > four-core
> > > Intel(R) Xeon(R) CPU L5420  @ 2.50GHz.
> > > 
> > > The box has several jails, each jail does NOT run service ntpd.
> > > Each jail has
> > > its dedicated loopback, lo1 throughout lo5 (for the moment) with
> > > dedicated IP
> > > :
> > > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not).
> > > 
> > > The host itself has two main NICs, broadcom based. bcm0 is
> > > dedicated to the
> > > host, bcm1 is shared amongst the jails: each jail has an IP bound
> > > to bcm1 via
> > > whihc the jails communicate with the network.
> > > 
> > > I try to capture log informations via syslog, but FreeBSD's ntpd
> > > seems to be
> > > very, very sparse with such informations, coverging to null - I
> > > can't see
> > > anything suiatble in the logs why NTPD dies almost every night
> > > leaving the
> > > system with a wild reset of time. Sometimes it is a gain of 6
> > > hours, sometime
> > > s
> > > it is only half an hour. I leave the box at 16:00 local time
> > > usually and take
> > > care again at ~ 7 o'clock in the morning local time.  
> > We will need to turn on debugging. Unfortunately debug code is not
> > compiled 
> > into the binary. We have two options. You can either update 
> > src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's
> > the exact 
> > same ntp) with the DEBUG option -- this is probably simpler. Then
> > enable 
> > debug with -d and -D. -D increases verbosity. I just committed a
> > debug 
> > option to both ntp ports to assist here.
> > 
> > Next question: Do you see any indication of a core dump? I'd be
> > interested 
> > in looking at it if possible.
> > 
> > > 
> > > 
> > > When the clock is floating that wild, in all cases ntpd isn't
> > > running any mor
> > > e.
> > > I try to restart with options -g and -G to adjust the time
> > > quickly at the
> > > beginning, which works fine.  
> > This is disconcerting. If your clock is floating wildly without
> > ntpd 
> > running there are other issues that might be at play here. At most
> > the 
> > clock might drift a little, maybe a minute or two a day but not by
> > a lot. 
> > Does the drift cause your clocks to run fast or slow?
> > 
> > > 
> > > 
> > > Apart from possible misconfigurations of the jails (I'm quite new
> > > to jails an
> > > d
> > > their pitfalls), I was wondering what causes ntpd to die. i can't
> > > determine
> > > exactly the time of its death, so it might be related to
> > > diurnal/periodic
> > > processes (I use only the most vanilla configurations on
> > > periodic, except for
> > > checking ZFS's scrubbing enabled).  
> > As I'm a little rushed for time, I didn't catch whether the jails 
> > themselves were also running ntpd... just thought I'd ask. I don't
> > see how 
> > zfs scrubbing or any other periodic scripts could cause this.
> > 
> > > 
> > > 
> > > I'ven't had the chance to check whether the hardware is
> > > completely all right,
> > > but from a superficial point of view there is no issue with high
> > > gain of the
> > > internal clock or other hardware issues.  
> > It's probably a good idea to check. I don't think that would cause
> > ntpd any 
> > gas. I've seen RTC battery messages on my gear which haven't caused
> > ntpd 
> > any problem. I have two machines which complain about RTC battery
> > being 
> > dead, where in fact I have replaced the batteries and the messages
> > still 
> > are displayed at boot. I'm not sure if it's possible for a kernel
> > to damage 
> > the RTC. In my case that doesn't cause ntpd any problems. It's
> > probably 
> > good to check anyway.
> > 
> > > 
> > > 
> > > If there are known issues with jails (the problem occurs since I
> > > use those),
> > > advice is appreciated.  
> > Not that I know of.
> > 
> > 
> Just some strange news:
> 
> I left the server the whole day with ntpd disabled and I didn't watch
> a gain of the RTC
> by one second, even stressing the machine.
> 
> But soon after restarting ntpd, I realised immediately a 30 minutes
> off! This morning,
> the discrapancy was almost 5 hours - it looked more like a weird
> ajustment to another
> time base than UTC.
> 
> Over the weekend I'll leave the server with ntpd disabled and only
> RTC running. I've the
> strange feeling that something is intentionally readjusting the ntpd
> time due to a
> misconfiguration or a rogue ntp server in the X.CC.pool.ntp.org
> 

The rogue serve

Re: process killed: text file modification

[Ian Lepore]

On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote:
> 
> On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
> > 
> > 
> > 
> > On 2017. 03. 09. 19:44, John Baldwin wrote:
> > > 
> > > On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
> > > > 
> > > > [+freebsd-fs]
> > > > 
> > > > 
> > > > On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
> > > > > 
> > > > > On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I'm trying to build a few things from ports on an rpi3, the
> > > > > > ports
> > > > > > collection is mounted over NFS from another machine. When
> > > > > > it's trying
> > > > > > to build pkg i'm getting the error message in syslog:
> > > > > > 
> > > > > > rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file
> > > > > > modification
> > > > > > 
> > > > > > The report to pkg@:
> > > > > > https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/
> > > > > > 002048.html 
> > > > > > 
> > > > > > 
> > > > > > In ports-mgmt/pkg's config.log It fails at the following
> > > > > > entry:
> > > > > > configure:3726: checking whether we are cross compiling
> > > > > > configure:3734: cc -o conftest -O2 -pipe  -Wno-error
> > > > > > -fno-strict-aliasing   conftest.c  >&5
> > > > > > configure:3738: $? = 0
> > > > > > configure:3745: ./conftest
> > > > > > configure:3749: $? = 137
> > > > > > configure:3756: error: in 
> > > > > > `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
> > > > > > configure:3760: error: cannot run C compiled programs.
> > > > > > If you meant to cross compile, use `--host'.
> > > > > > See `config.log' for more details
> > > > > > 
> > > > > > # uname -a
> > > > > > FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949:
> > > > > > Thu Mar 9
> > > > > > 08:58:46 CET 2017
> > > > > > ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.
> > > > > > aarch64/tank/rpi3/src/sys/AEGIR 
> > > > > > 
> > > > > > arm64
> > > > > So far, a few additions:
> > > > > Time is synced between the NFS server and the client.
> > > > > it's an open() call which is getting the kill, and it's not
> > > > > the file
> > > > > what's being opened, but the process executing it.
> > > > > Here's a simple code that reproduces it:
> > > > > #include 
> > > > > 
> > > > > int main() {
> > > > > 
> > > > >    FILE *f = fopen ("/bar", "w");
> > > > > 
> > > > >    fclose(f);
> > > > >    return 0;
> > > > > }
> > > > > 
> > > > > Conditions to reproduce it:
> > > > >   - The resulting binary must be executed from the nfs mount
> > > > >   - The binary must be built after mounting the NFS share.
> > > > > 
> > > > > I haven't tried building it on a different host, I don't have
> > > > > access
> > > > > to multiple RPis. Also, if I build the binary, umount/remount
> > > > > the NFS
> > > > > mount point, which has the binary, execute it, then it works.
> > > > > 
> > > > > I've also tried this with the raspbsd.org's image, I could
> > > > > reproduce
> > > > > it as well.
> > > > > 
> > > > > Another interesting thing is, when I first booted the RPi up,
> > > > > the NFS
> > > > > server was a 10.2-STABLE, and later got updated to 11-STABLE. 
> > > > > While it
> > > > > was 10.2 I've tried to build some port, and I don't remember
> > > > > having
> > > > > this issue.
> > > > > 
> > > > > So, could someone please help me figure this out and fix it?
> > > > > This
> > > > > stuff should work pretty much.
> > > > > 
> > > > So, this error message comes from here:
> > > > https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio
> > > > .c?revision=314436&view=markup#l1674 
> > > > 
> > > > 
> > > > It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np-
> > > > >n_vattr.na_mtime)
> > > > comparision that fails, np should be the NFS node structure,
> > > > from the
> > > > vnode's v_data, and n_vattr is the attribute cache. As I've
> > > > seen these
> > > > two are being updated together, so I don't really see by the
> > > > code why
> > > > they might differ. Could someone please take a look at it, with
> > > > more
> > > > experience in the NFS code? -czg
> > > Can you print out the two mtimes?  I wonder if what's happening
> > > is that
> > > your server uses different granularity (for example just seconds)
> > > than
> > > your client, so on the client we generate a timestamp with a non-
> > > zero
> > > nanoseconds but when the server receives that timestamp it
> > > "truncates"
> > > it.  During open() we forcefully re-fetch the timestamp (for CTO
> > > consistency) and then notice it doesn't match.  For now I would
> > > start
> > > with comparing the timestamps and maybe the
> > > vfs.timestamp_precision
> > > sysctls on client and server (if server is a FreeBSD box).
> > Here are the time values:
> > Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 + 
> > -3298114786336  &np->n_vattr.na_mtime: -3298114786616 +
> > -3298114786608
> > Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed:
> > text 
> > file modificati

Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX

[Ian Lepore]

On Sun, 2017-03-12 at 13:27 +1100, Lawrence Stewart wrote:
> Hi Ian,
> 
> On 12/03/2017 10:29, Ian Lepore wrote:
> > 
> > On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote:
> > > 
> > > Hi all,
> > > 
> > > I'm unable to complete buildworld with 2 recent svn revs I've
> > > tried
> > > (r314838 and r315059). I'm building for a slightly resource
> > > constrained
> > > production system so am specifying custom settings and a
> > > different
> > > obj
> > > tree location so I can copy it to the target system. The error
> > > persists
> > > after an "rm -rf /usr/obj/*", and if parallel building is
> > > disabled.
> > > 
> > > The underlying build system built from r314838 via simple "make
> > > -C
> > > /usr/src -s -j6 buildworld buildkernel" built and installed fine,
> > > so
> > > the
> > > problem seems to be around the use of the build customisations.
> > > 
> > > Any clues?
> > > 
> > > Cheers,
> > > Lawrence
> > > 
> > > 
> > > root@builder-head-amd64:/usr/src # cat cust_make.conf
> > > KERNCONF=GENERIC-NODEBUG
> > > MALLOC_PRODUCTION=YES
> > > 
> > > root@builder-head-amd64:/usr/src # cat cust_src.conf
> > > WITHOUT_PROFILE=1
> > > 
> > > root@builder-head-amd64:/usr/src # make
> > > __MAKE_CONF=/usr/src/cust_make.conf
> > > SRCCONF=/usr/src/cust_src.conf
> > > MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel
> > > [...]
> > > MK_AUTO_OBJ=no
> > > MK_TESTS=no  UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
> > > CC="cc -target x86_64-unknown-freebsd12.0
> > > --sysroot=/usr/obj/cust/usr/src/tmp
> > > -B/usr/obj/cust/usr/src/tmp/usr/bin
> > > -O2 -pipe   -std=gnu99-Qunused-arguments  "  CXX="c++  -
> > > target
> > > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp
> > > -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments
> > > -Wno-c++11-extensions  "  make .MAKE.MODE="normal curdirOk=yes"
> > > .MAKE.META.IGNORE_PATHS=""  -f rescue.mk exe
> > > cc -target x86_64-unknown-freebsd12.0
> > > --sysroot=/usr/obj/cust/usr/src/tmp
> > > -B/usr/obj/cust/usr/src/tmp/usr/bin
> > > -O2 -pipe   -std=gnu99-Qunused-arguments   -nostdlib -Wl,-dc
> > > -r
> > > -o
> > > cat.lo cat_stub.o
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o
> > > cc: error: no such file or directory:
> > > '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o'
> > > *** Error code 1
> > > 
> > > There appear to be a lot of missing .o files under the rescue obj
> > > tree:
> > > 
> > > root@builder-head-amd64:/usr/src # find
> > > /usr/obj/cust/usr/src/rescue/rescue//usr -type f
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h
> > > /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost
> > > 
> > > compared with an obj tree on a different head system:
> > > 
> > > find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l
> > > 1552
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre
> > > ebsd
> > > .org"
> > The MAKEOBJDIRPREFIX variable must be set in the environment, not
> > in
> > make.conf or on the make command line (documented in build(7)).
> Your assertion seems at odds with my past experience and my reading
> of
> the man page... from build(7):
> 
>   The build may be controlled by defining make(1) variables
>   described in the ENVIRONMENT section below, and by the
>   variables documented in make.conf(5).
> 
> ... which indicates they are make variables, not environment
> variables
> specifically. As a concrete example, TARGET and DESTDIR are listed
> under
> the "ENVIRONME

Re: Deterministic rescue buildworld error with custom make.conf/src.conf/MAKEOBJDIRPREFIX

[Ian Lepore]

On Sun, 2017-03-12 at 10:22 +1100, Lawrence Stewart wrote:
> Hi all,
> 
> I'm unable to complete buildworld with 2 recent svn revs I've tried
> (r314838 and r315059). I'm building for a slightly resource
> constrained
> production system so am specifying custom settings and a different
> obj
> tree location so I can copy it to the target system. The error
> persists
> after an "rm -rf /usr/obj/*", and if parallel building is disabled.
> 
> The underlying build system built from r314838 via simple "make -C
> /usr/src -s -j6 buildworld buildkernel" built and installed fine, so
> the
> problem seems to be around the use of the build customisations.
> 
> Any clues?
> 
> Cheers,
> Lawrence
> 
> 
> root@builder-head-amd64:/usr/src # cat cust_make.conf
> KERNCONF=GENERIC-NODEBUG
> MALLOC_PRODUCTION=YES
> 
> root@builder-head-amd64:/usr/src # cat cust_src.conf
> WITHOUT_PROFILE=1
> 
> root@builder-head-amd64:/usr/src # make
> __MAKE_CONF=/usr/src/cust_make.conf SRCCONF=/usr/src/cust_src.conf
> MAKEOBJDIRPREFIX=/usr/obj/cust buildworld buildkernel
> [...]
> MK_AUTO_OBJ=no MK_TESTS=no  UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
> CC="cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/cust/usr/src/tmp
> -B/usr/obj/cust/usr/src/tmp/usr/bin
> -O2 -pipe   -std=gnu99-Qunused-arguments  "  CXX="c++  -target
> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/cust/usr/src/tmp
> -B/usr/obj/cust/usr/src/tmp/usr/bin -O2 -pipe -Qunused-arguments
> -Wno-c++11-extensions  "  make .MAKE.MODE="normal curdirOk=yes"
> .MAKE.META.IGNORE_PATHS=""  -f rescue.mk exe
> cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/cust/usr/src/tmp
> -B/usr/obj/cust/usr/src/tmp/usr/bin
> -O2 -pipe   -std=gnu99-Qunused-arguments   -nostdlib -Wl,-dc -r
> -o
> cat.lo cat_stub.o
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o
> cc: error: no such file or directory:
> '/usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/cat/cat.o'
> *** Error code 1
> 
> There appear to be a lot of missing .o files under the rescue obj
> tree:
> 
> root@builder-head-amd64:/usr/src # find
> /usr/obj/cust/usr/src/rescue/rescue//usr -type f
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax.o
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mksyntax
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes.o
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/sh/mknodes
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/sh.err.h
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/tc.const.h
> /usr/obj/cust/usr/src/rescue/rescue//usr/src/bin/csh/gethost
> 
> compared with an obj tree on a different head system:
> 
> find /usr/obj/usr/src/rescue/rescue/usr/ -type f | wc -l
> 1552
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd
> .org"

The MAKEOBJDIRPREFIX variable must be set in the environment, not in
make.conf or on the make command line (documented in build(7)).

-- 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: Strange issue after early AP startup

[Ian Lepore]

On Tue, 2017-01-17 at 11:00 -0800, John Baldwin wrote:
> >  > You could
> >  > do that by setting it to 'cc_firstevent' of the associated CPU, but in
> >  > practice 'state->nextcall' should already be set to that (it is 
> > initalized
> >  > to SBT_MAX in cpu_initclocks_bsp() and is then only set to other 
> > values due
> >  > to cpu_new_callout()).  Keep in mind that configtimer() is not just 
> > called
> >  > from boot, but is also invoked when starting/stopping the profiling 
> > timer.
> >  >
> > 
> >  > However, when setting 'nextevent' (which is used to schedule the next 
> > timer
> >  > interrupt), we should be honoring the existing 'nextcall' if it is sooner
> >  > than the next hardclock.
> > 
> > Does this matter for the first tick? How often is configtimer() called?
> 
> As I said, it is called at runtime when profclock is started / stopped, not
> just at boot.  Those changes at runtime probably have existing callouts
> active and your change will not process any callouts until the next hardclock
> tick fires (but only because you are setting nextcallopt to the bogus
> 'next' value).

On some platforms, configtimer() can be called quite often.  Power
saving modes can change the frequency of the timer, and systems that
suppport such dynamic frequency scaling call configtimer()
(via cpu_et_frequency()) to handle the changes.

-- 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: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

[Ian Lepore]

On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote:
> Hello,
> 
> Since the commit in the subject /etc/rc.d/ntpdate does not work
> anymore.
> # /etc/rc.d/ntpdate restart
> Setting date via ntp.
> 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting
> 
> This diff fixes it for me:
> # diff -u /tmp/ntpdate /etc/rc.d/ntpdate
> --- /tmp/ntpdate  2017-01-11 00:41:58.736138000 +0100
> +++ /etc/rc.d/ntpdate 2017-01-11 00:42:15.522986000 +0100
> @@ -20,7 +20,7 @@
>   if [ -z "$ntpdate_hosts" -a -f "$ntpdate_config" ]; then
>   ntpdate_hosts=`awk '
>   /^server[ \t]*127.127/  {next}
> - /^(server|peer)/{
> + /^(server|peer|pool)/{
>   if ($2 ~/^-/)   {print $3}
>   else{print $2}}
>   ' < "$ntpdate_config"`
> 
> 
> Regards,
> 
> Ronald.

Ooops, my bad, I'll get it fixed asap.

-- 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: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[Ian Lepore]

On Thu, 2016-12-29 at 21:17 +0100, O. Hartmann wrote:
> Am Thu, 29 Dec 2016 20:26:32 +0100
> Dimitry Andric  schrieb:
> 
> > 
> > On 29 Dec 2016, at 17:29, O. Hartmann 
> > wrote:
> > > 
> > > 
> > > Am Wed, 7 Dec 2016 23:31:01 +0100
> > > Dimitry Andric  schrieb:
> > >   
> > > > 
> > > > On 07 Dec 2016, at 10:42, O. Hartmann 
> > > > wrote:  
> > > > > 
> > > > > 
> > > > > I try my first steps in cross compiling ports with poudriere
> > > > > and therefore I try to
> > > > > setup an appropriate jail and QEMU environment.
> > > > > 
> > > > > Well, I'm failing at the jail setup due to the non-exitence
> > > > > of any suitable QEMU
> > > > > environment and for that I tried to figure out to find some
> > > > > proper HOWTO.
> > > > > Searching via google ave some hints, but in questions which
> > > > > QEMU from ports should
> > > > > be used, all leave me alone, so I tried
> > > > > 
> > > > > emulators/qemu
> > > > > emulators/qemu-devel
> > > > > emulators/qemu-static
> > > > > 
> > > > > emulators/qemu is known for me to fail since months and the
> > > > > days of 11-CURRENT,
> > > > > there is a compiler error spit out with clang 3.8 and now
> > > > > 3.9. The very same for
> > > > > qemu-devel (both ports used with standard options, no
> > > > > extras). See also Bug 214873
> > > > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873)
> > > > > and Bug 215100
> > > > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).  
> > > > I couldn't reproduce the compilation errors, it builds fine for
> > > > me until
> > > > the link phase.  
> > > Well, I face this in poudriere on the most recent 12-CURRENT, too
> > > as well as
> > > 12-CURRENT buildworld today.
> > > 
> > > On the host I'd like to run qemu for testing aarch64 binaries for
> > > a Odroid-C2
> > > project, I use a customized /etc/src.conf - but on poudriere,
> > > there is no such
> > > customisation but the failing is identical.  
> > Looking at your errors, it seems that the port has decided to
> > enable
> > rdma support.  This is normally enabled using --enable-rdma with
> > the
> > configure script, but I don't see that at all in the port Makefile.
> > 
> > On my systems, it runs a test to check for rdma support, but this
> > fails.
> > Quoting from config.log:
> > 
> > cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> > -D_LARGEFILE_SOURCE
> > -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
> > -Wmissing-prototypes -fno-strict-aliasing -fno-common
> > -I/usr/work/share/dim/ports/emulators/qemu/work/qemu-2.6.1
> > -I/usr/local/include
> > -DPREFIX=\""/usr/local\"" -Wno-string-plus-int -Wno-initializer-
> > overrides
> > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs 
> > -Wformat-security
> > -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-
> > definition -Wtype-limits
> > -fstack-protector-strong -I/usr/local/include
> > -I/usr/local/include/p11-kit-1
> > -I/usr/local/include -o config-temp/qemu-conf.exe config-temp/qemu-
> > conf.c -m64 -g
> > -fstack-protector -L"/usr/local/lib" -lrdmacm -libverbs config-
> > temp/qemu-conf.c:1:10:
> > fatal error: 'rdma/rdma_cma.h' file not found #include
> >  ^
> > 
> > The minimal test program it tries to compile here is just this:
> > 
> > #include 
> > int main(void) { return 0; }
> > 
> > and it attempts to link it with -lrdmacm -libverbs.  If this
> > somehow
> > succeeds on your system, then it will think rdma support is
> > available,
> > while apparently the support is not complete, if it misses the
> > rdma_getaddrinfo() function.
> > 
> > Do you have some Linux rdma or infiniband headers or libraries
> > installed
> > into /usr or /usr/local?  This might be the cause of the problems.
> No Linux, but I found these files on all of the boxes in question:
> 
> locate rdma
> 
> [...]
> /usr/include/rdma
> /usr/include/rdma/rdma_cma.h
> /usr/include/rdma/rdma_cma_abi.h
> /usr/lib/librdmacm.a
> /usr/lib/librdmacm.so
> /usr/lib/librdmacm.so.1
> 
> ll usr/include/rdma discovers:
> 
> total 44
> 322075 drwxr-xr-x   2 root  wheel  -  512B Oct  7 13:52 ./
> 240768 drwxr-xr-x  55 root  wheel  -  6.5K Dec 29 19:14 ../
> 324275 -r--r--r--   1 root  wheel  -   21K Oct  7 13:52 rdma_cma.h
> 324276 -r--r--r--   1 root  wheel  -  4.7K Oct  7 13:52
> rdma_cma_abi.h
> 
> and
> 
> ll /usr/lib/librdma*
> 804463 -r--r--r--  1 root  wheel  -   28K Dec 18 16:34
> /usr/lib/librdmacm.a
> 804127 lrwxr-xr-x  1 root  wheel  -   14B Dec 29 19:15
> /usr/lib/librdmacm.so@ ->
> librdmacm.so.1 804128 -r--r--r--  1 root  wheel  -   24K Dec 29
> 19:15 /usr/lib/librdmacm.so.1
> 
> 
> As you can see, the libraries are of the date of the last full
> install of the system,
> while the headers seem to be remains from October?
> 
> In my jail for poudriere, I was surprised, based on your analysis,
> that I found this:
> 
> ll /pool/poudriere/jails/head-amd64/usr/include/rdma
> total 43
> 77923 drwxr-xr-x   2 root  wheel  uarch4B Jul 13 07:09 ./
> 770

Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized.

[Ian Lepore]

On Mon, 2016-08-01 at 13:55 -0500, Matthew Grooms wrote:
> On 8/1/2016 12:40 PM, Randy Westlund wrote:
> > On Mon, Aug 01, 2016 at 11:05:54AM +0200, O. Hartmann wrote:
> > > On every(!) USB drive which worked well with 11-CURRENT up to 11
> > > -BETA, I fail
> > > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14
> > > r303475: Fri
> > > Jul 29 11:59:11 CEST 2016) with the error shown below.
> > > 
> > > On USB flash drives I created myself, the suggested gpart command
> > > solved the
> > > problem, but I can not do this with drives I was given by a
> > > vendor or supplier.
> > > 
> > > What is wrong?
> > > 
> > > Kind regards and thank you very much in advance,
> > > 
> > > O. Hartmann
> > > 
> > > 
> > > On console, I get the report:
> > > 
> > > [...]
> > > GEOM_PART: da4 was automatically resized.
> > >   Use `gpart commit da4` to save changes or `gpart undo da4` to
> > > revert them.
> > 
> > I noticed something similar when I was trying to dd a more recent
> > memstick installer to a USB drive on 12-CURRENT.  When I plugged in
> > the
> > flash drive I couldn't dd to it until I noticed that message in
> > syslog
> > and ran 'gpart undo da0'.  Looks like something is unhelpfully
> > auto-resizing partitions.
> > 
> 
> Do you have growfs_enable in your rc.conf file? I think this is added
> to 
> certain flash images by default so it will automatically grow to your
> device capacity. See ...
> 
> /etc/rc.d/growfs
> 
> ... and ...
> 
> https://lists.freebsd.org/pipermail/freebsd-rc/2014-May/003497.html
> 
> -Matthew

I think rather than being related to growfs, this is fallout from
r303019 [*] which automatically resizes the device geom based on what
the device reports.  I suspect the intent was to make gpt backup
partition data appear at the right place on the device even when the
original image is created on a device of a different size.

Unfortunately, leaving an uncommited geom change lurking in the system
is going to lead to a fair amount of confusion, since it makes other
attempts to work with the device fail, usually with no clue about why
it's failing.  Uncommitted geom changes are a bit like an invisible
time bomb in your system; it wouldn't be so bad if they weren't so
invisible, and weren't so hard to figure out how to properly get out of
the situation.

Something like a "gpart undo -r " to recursively undo all
uncommitted changes would go a long way towards fixing the "what to do"
part.  I'm not sure how to make pending changes more visible.  Maybe it
would work to have gpart show flag uncommitted changes somehow.

* https://svnweb.freebsd.org/base/head/sys/geom/geom_disk.c?view=log

-- 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: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sun, 2016-07-24 at 12:52 -0600, Warner Losh wrote:
> On Sun, Jul 24, 2016 at 12:42 PM, Kevin Oberman 
> wrote:
> > There are several different USB serial drivers. Off-hand I see
> > ubser, ubsa,
> > uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom,
> > usb_serial, uslcom, and uvscom. Whether any of these will support
> > the TI
> > chip, I can't say. Most have man pages, but a few, as has been
> > noted, are
> > lacking one.
> 
> I tried to automate discovery of these things. However, the only way
> you can really know for sure about the TI chip is to read it's
> datasheet
> and compare that with extant drivers. It's actually easier than it
> sounds.
> 
> I've often thought of unification of the TTY USB drivers, since they
> are
> most (but not all) based on the standard plus extra bits.
> 
> Warner

To reiterate:  we do not have a driver for TI 5052 chips.

It's not much like other usb-serial chips.  In fact it's not strictly a
usb-serial chip, it's a multifunction chip that includes a software
-controllable usb hub, 2 serial ports, gpio, an i2c bus master, an MCU
interface, a multichannel DMA controller, and apparently even has the
ability to download your own 8052-compatible microcontroller code into
the 5052 and have it take over from the built-in rom code.

It would be reasonable enough to write a driver that initially
supported only the uart part of the chip.

-- 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: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sun, 2016-07-24 at 10:51 +0200, O. Hartmann wrote:
> Am Sun, 24 Jul 2016 08:38:59 +0200
> Gary Jennejohn  schrieb:
> 
> > On Sun, 24 Jul 2016 08:03:30 +0200
> > "O. Hartmann"  wrote:
> > 
> > > Am Sat, 23 Jul 2016 14:49:11 -0600
> > > Ian Lepore  schrieb:
> > >   
> > > > On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> > > > > Am Fri, 22 Jul 2016 10:52:54 -0600
> > > > > Ian Lepore  schrieb:
> > > > >   
> > > > > > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:  
> > > > > > > For temperature monitoring, we have a bunch of Digi
> > > > > > > Watchport/T
> > > > > > > sensors: 
> > > > > > > 
> > > > > > > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > > > > > > 
> > > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > I think the attached patch will make it show up as a
> > > > > > ttyU*/cuaU*
> > > > > > device
> > > > > > for you.  (You should probably use the /dev/cuaU* flavor,
> > > > > > to avoid
> > > > > > problems with tty layer and modem control signals).
> > > > > > 
> > > > > > I keep wishing we had a mechanism, like a sysctl that could
> > > > > > be set
> > > > > > or
> > > > > > something, that would let you supply a vendor/product pair
> > > > > > and have
> > > > > > the
> > > > > > ugensa driver attach to that device, for quick testing of
> > > > > > this sort
> > > > > > of
> > > > > > thing.
> > > > > > 
> > > > > > -- Ian  
> > > > > 
> > > > > No, it doesn't change anything. I applied the patch to most
> > > > > recent
> > > > > CURRENT and it is
> > > > > still the same. But thanks anyway.
> > > > > 
> > > > > Kind regards,
> > > > > 
> > > > > oh  
> > > > 
> > > > Oh, my bad, I forgot to mention:  You'll have to manually
> > > > "kldload
> > > > ugensa" before plugging in the device (or load it from your
> > > > loader.conf).
> > > > 
> > > > When the change gets committed (assuming it works), the devd
> > > > usb
> > > > scripts will get regenerated, and that's what handles the auto
> > > > -load of
> > > > the driver.
> > > > 
> > > > -- Ian
> > > man ugensa doesn't exist! As I wrote earlier, I tried everything
> > > to load what I could
> > > find. It seems, the patch and the hint about ugensa.ko did the
> > > magic ;-) Thank you
> > > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > > 
> > > And also important: where is the man page for ugensa? Can the the
> > > module be compiled
> > > staitcally into the kernel or are there pitfalls?
> > >   
> > 
> > Even the most complete man page found in the internet, the one from
> > Dragonfly, doesn't list your Digi International device as being one
> > of those supported.
> 
> Yes. That is a pity. But Linux seems to operate this serial device. I
> have to check next
> time I get hands on a Linux box, what driver is attached to the
> sensor.
> 
> > 
> > Still, having the man page under FreeBSD would at least provide a
> > hint
> > that the driver even exists.
> 
> Agreed.
> 
> > 
> > I added device ugensa to my config file and the kernel was
> > generated
> > without an error.
> 
> Me, too.
> 
> > 
> > > root@localhost: [src] kldload ugensa
> > > 
> > > ugen2.7:  at usbus2
> > > ugensa0: 
> > > on usbus2
> > > ugensa0: Found 1 interfaces.
> > > root@thor: [src] man ugensa
> > > No manual entry for ugensa
> > > root@localhost: [src] ll /dev/cuaU0*
> > > 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > > 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51
> > > /dev/cuaU0.init
> > > 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51
> > > /dev/cuaU0.lock
> > > 
> > > 
> > > I'll try now to get informa

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> Am Fri, 22 Jul 2016 10:52:54 -0600
> Ian Lepore  schrieb:
> 
> > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> > > For temperature monitoring, we have a bunch of Digi Watchport/T
> > > sensors: 
> > > 
> > > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > > 
> > >   
> > [...]
> > 
> > I think the attached patch will make it show up as a ttyU*/cuaU*
> > device
> > for you.  (You should probably use the /dev/cuaU* flavor, to avoid
> > problems with tty layer and modem control signals).
> > 
> > I keep wishing we had a mechanism, like a sysctl that could be set
> > or
> > something, that would let you supply a vendor/product pair and have
> > the
> > ugensa driver attach to that device, for quick testing of this sort
> > of
> > thing.
> > 
> > -- Ian
> 
> No, it doesn't change anything. I applied the patch to most recent
> CURRENT and it is
> still the same. But thanks anyway.
> 
> Kind regards,
> 
> oh

Oh, my bad, I forgot to mention:  You'll have to manually "kldload
ugensa" before plugging in the device (or load it from your
loader.conf).

When the change gets committed (assuming it works), the devd usb
scripts will get regenerated, and that's what handles the auto-load of
the driver.

-- 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: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> For temperature monitoring, we have a bunch of Digi Watchport/T
> sensors: 
> 
> http://ftp1.digi.com/support/documentation/9406_H.pdf
> 
> 
[...]

I think the attached patch will make it show up as a ttyU*/cuaU* device
for you.  (You should probably use the /dev/cuaU* flavor, to avoid
problems with tty layer and modem control signals).

I keep wishing we had a mechanism, like a sysctl that could be set or
something, that would let you supply a vendor/product pair and have the
ugensa driver attach to that device, for quick testing of this sort of
thing.

-- Ian
Index: sys/dev/usb/serial/ugensa.c
===
--- sys/dev/usb/serial/ugensa.c	(revision 302505)
+++ sys/dev/usb/serial/ugensa.c	(working copy)
@@ -158,6 +158,7 @@ static const STRUCT_USB_HOST_ID ugensa_devs[] = {
 	{USB_VPI(USB_VENDOR_KYOCERA2, USB_PRODUCT_KYOCERA2_CDMA_MSM_K, 0)},
 	{USB_VPI(USB_VENDOR_HP, USB_PRODUCT_HP_49GPLUS, 0)},
 	{USB_VPI(USB_VENDOR_NOVATEL2, USB_PRODUCT_NOVATEL2_FLEXPACKGPS, 0)},
+	{USB_VPI(USB_VENDOR_INSIDEOUT, USB_PRODUCT_INSIDEOUT_WATCHPORTT, 0)},
 };
 
 DRIVER_MODULE(ugensa, uhub, ugensa_driver, ugensa_devclass, NULL, 0);
Index: sys/dev/usb/usbdevs
===
--- sys/dev/usb/usbdevs	(revision 302505)
+++ sys/dev/usb/usbdevs	(working copy)
@@ -2456,6 +2456,7 @@ product INITIO INIC_1610P	0x1e40	USB to SATA Bridg
 
 /* Inside Out Networks products */
 product INSIDEOUT EDGEPORT4	0x0001	EdgePort/4 serial ports
+product INSIDEOUT WATCHPORTT	0x0304	WatchPort/T 
 
 /* In-System products */
 product INSYSTEM F5U002		0x0002	Parallel printer
___
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: [PATCH] microoptimize locking primitives by introducing randomized delay between atomic ops

[Ian Lepore]

On Sun, 2016-07-10 at 13:13 +0200, Mateusz Guzik wrote:
> If the lock is contended, primitives like __mtx_lock_sleep will spin
> checking if the owner is running or the lock was freed. The problem
> is
> that once it is discovered that the lock is free, multiple CPUs are
> likely to try to do the atomic op which will make it more costly for
> everyone and throughput suffers.
> 
> The standard thing to do is to have some sort of a randomized delay
> so
> that this kind of behaviour is reduced.
> 
> As such, below is a trivial hack which takes cpu_ticks() into account
> and performs % 2048, which in my testing gives reasonbly good
> results.
> 
> Please note there is definitely way more room for improvement in
> general.
> 
> In terms of results, there was no statistically significant change in
> -j 40 buildworld nor buildkernel.
> 
> However, a 40-way find on a ports tree placed on tmpfs yielded the
> following:
> 
> x vanilla
> + patched
> +
> +
> > + x
> >  x x x  |
> > + ++++  +  + ++   +   + x   x 
> >  x   x x x|
> >|_MA__| 
> >  |AM__| |
> +
> +
> N   Min   MaxMedian   Avg   
>  Stddev
> x  2012.43115.95214.897   14.7444   
>  0.74241657
> +  20 8.10311.8639.0135   9.44565
>  1.0059484
> Difference at 95.0% confidence
>   -5.29875 +/- 0.565836
>   -35.9374% +/- 3.83764%
>   (Student's t, pooled s = 0.884057)
> 
> The patch:
[...]

What about platforms that don't have a useful implementation of
cpu_ticks()?

What about platforms that don't suffer the large expense for atomic ops
that x86 apparently does?

-- 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

[Ian Lepore]

On Tue, 2016-06-21 at 15:30 -0700, Mark Millard wrote:
> Ian Lepore ian at freebsd.org  wrote on Tue Jun 21 17:55:28 UTC 2016
> :
> 
> > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote:
> > > Em 21/06/2016 07:33, Keith White escreveu:
> > > > In an earlier message Ian said that he thought he knew what the
> > > > problem was... 
> > > 
> > > Here the problem occurs  when using wifi. I do not have tested
> > > wired 
> > > because I don't have a cable here.
> > > 
> > > 
> > > []'s
> > > 
> > > -Otacilio
> > 
> > The wifi alignment fault should be fixed as of r302064.  Sorry it
> > took
> > so long.
> > 
> > -- Ian
> > 
> 
> FYI: I've not had any -r301975 problems with WiFi on my rpi2.
> 
> But I cross build for TARGET_ARCH=armv6 with:
> 
> > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
> > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> 
> (And similarly for self-hosted.) It may be that the -march and/or 
> -mcpu matter to the code generation and explain my lack of problems.
> 
> The builds also have INVARIANTS and WITNESS off.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

INVARIANTS being on was one of the things required to trigger the
alignment fault.

-- 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

[Ian Lepore]

On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote:
> Em 21/06/2016 07:33, Keith White escreveu:
> > In an earlier message Ian said that he thought he knew what the
> > problem was... 
> 
> Here the problem occurs  when using wifi. I do not have tested wired 
> because I don't have a cable here.
> 
> 
> []'s
> 
> -Otacilio

The wifi alignment fault should be fixed as of r302064.  Sorry it took
so long.

-- 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: Intel Atom I2C

[Ian Lepore]

On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote:
> Hi
> 
> I am trying to figure out how to get I2C support on Intel Atom x5
> (Cherryview), which should be same for Baytrail platforms.
> 
> On the Serial I/O device (PCI device 24) there are 8 devices.
> #0 is DMA controller
> #1-7 are I2C controllers (1 & 2 available on GPIO pins).
> 
> I assume that all traffic to/from the I2C controllers must go via the
> DMA
> controller although I'm not 100% sure.
> 
> In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of
> the
> PCI configuration space.
> 
> On Linux they have
> i2c/busses/i2c-designware-*
> and
> dma/dw/*
> that takes care of the I2C and DMA parts.
> 
> The ichiic (ig4) driver seems to be working on this platform and
> looking
> through the registers it seems to be basically the same as i2c
> -designware
> driver, but it doesn't not detect any devices on the I2C bus
> (/dev/smbx).
> (I have confirmed that the devices are recognized on Linux on the
> same
> device.)
> 

There is no way to automatically detect devices on an i2c bus.  You
can, with some incomplete success, detect which addresses are in use. 
 Even when you can detect there is a device at a given address, there
is no way to figure out what that device is (and in some rare cases,
even probing for the address being in use can perturb the device).

So, in the linux case, something must be telling the OS which drivers
to attach to which addresses.  I have no idea what that mechanism might
be, if it's not FDT.

In freebsd, you can specify i2c devices using FDT data, or hints.

-- Ian

> We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so
> I
> have already ported this.
> 
> What is left to do I guess would be to implement a DMA driver that
> works
> with ig4 or create a new ig4 driver that is extended to use the DMA
> controller, and implement the DMA controller driver.
> 
> Implementing from scratch would be quite the undertaking. Can we
> leverage
> any existing DMA infrastructure for this?
> 
> Any one interested in helping?
> 
> I have a board called "UP" which is very similar to Raspberry Pi but
> Intel
> SoC. It has IC20 and IC21 available on the 40-pin connector.
> Since it's Intel most stuff just works. Thanks to mmacy accelerated
> graphics is also working (on separate branch).
> It really is a great board for anyone who likes to tinker :)
> 
> 
> References:
> http://www.up-board.org/
> http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses
> http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw
> http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> asheet-vol-1.html
> http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> asheet-vol-2.html
> 
> Other TODO stuff:
> Port Imer's GPIO driver from DragonFly
> Add support for S0ix sleep states (would be useful for all new Intel
> low
> power laptops since Haswell)
> And more...
> 
> Thanks!
> /Johannes
> 
___
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: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]

[Ian Lepore]

On Fri, 2016-06-17 at 12:28 -0400, Keith White wrote:
> On Fri, 17 Jun 2016, Ian Lepore wrote:
> 
> > On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
> > > Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
> > > 
> > > See if it's that.
> > > 
> > > 
> > > 
> > > -adrian
> > > 
> > 
> > You can see from the crash info that it's an alignment fault:
> > 
> >  r6 =c21a4876
> >  ldmib   r6,{r1-r2}
> > 
> > An ldm instruction requires 4-byte alignment.  Now the question is
> > why
> > undefining __NO_STRICT_ALIGNMENT didn't fix the problem.  Maybe the
> > wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other
> > network
> > drivers do?
> > 
> > Unfortunately the pasted info lists the nearby symbol as
> > $a.17+0x38,
> > which doesn't help find the actual code.  A stack backtrace might
> > help.
> > 
> > -- Ian
> > ...
> 
> What do I need to type at the "db> " prompt that would be useful?
> I should be able to access the RPI-B in 5 hours.
> 
> Here's the result of a "where" taken from an earlier logged session
> (different r6 value):
> 

"where" is a synonym for getting a stack backtrace, that's just what I
needed.  Now I know what's wrong, but not yet how to fix it.

-- 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: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]

[Ian Lepore]

On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
> Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
> 
> See if it's that.
> 
> 
> 
> -adrian
> 

You can see from the crash info that it's an alignment fault:

  r6 =c21a4876
  ldmib   r6,{r1-r2}

An ldm instruction requires 4-byte alignment.  Now the question is why
undefining __NO_STRICT_ALIGNMENT didn't fix the problem.  Maybe the
wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network
drivers do?

Unfortunately the pasted info lists the nearby symbol as $a.17+0x38,
which doesn't help find the actual code.  A stack backtrace might help.

-- Ian

> 
> On 17 June 2016 at 04:19, Keith White  wrote:
> > On Thu, 16 Jun 2016, Keith White wrote:
> > 
> > > On Wed, 15 Jun 2016, Mark Millard wrote:
> > > 
> > > > https://lists.freebsd.org/pipermail/freebsd-current/2016-June/0
> > > > 61904.html
> > > > reports an RPI-B alignment fault for -r301815 (the snapshot)
> > > > "when
> > > > connecting via WiFi".
> > > > 
> > > > -r301872 (
> > > > https://lists.freebsd.org/pipermail/svn-src-head/2016-June/0883
> > > > 39.html ) has
> > > > a fix for networking vs. alignment handling for armv6 contexts
> > > > that might be
> > > > needed. Quoting:
> > > > 
> > > > > Author: ian
> > > > > Date: Mon Jun 13 16:48:27 2016
> > > > > New Revision: 301872
> > > > > URL:
> > > > > https://svnweb.freebsd.org/changeset/base/301872
> > > > 
> > > > ...
> > > 
> > > 
> > > Thanks for pointing this out!  I'll see if a (complete) rebuild
> > > at
> > > that rev fixes the problem.
> > > 
> > 
> > Tried that.  I still get a panic.
> > 
> > I cross built on an amd64 at r301840, I'll try upgrading that
> > machine too.
> > 
> > In the meantime, other suggestions?
> > 
> > FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
> > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based
> > on LLVM
> > 3.8.0)
> > VT: init without driver.
> > ...
> > Starting devd.
> > urtwn0:  > addr 4> on
> > usbus0
> > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> > urtwn0: enabling 11n
> > wlan0: Ethernet address: 00:13:ef:74:07:a8
> > Created wlan(4) interfaces: wlan0.
> > ...
> > 
> > [ nc rpi-b 22 ]
> > Fatal kernel mode data abort: 'Alignment Fault' on read
> > trapframe: 0xc18f28c0
> > FSR=0001, FAR=c21a487a, spsr=6013
> > r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
> > r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
> > r8 =c1ccd240, r9 =c21a4Stopped at  $a.17+0x38: ldmib   r6,
> > {r1-r2}
> > db>
> > 
> > 
> > ...keith
> > ___
> > 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: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Ian Lepore]

On Mon, 2016-06-13 at 11:04 -0700, Conrad Meyer wrote:
> I expect it's because:
> 
> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
> unsigned long))

This might result in allocating too-few bytes, but that's something
you'd only notice if you have something like valgrind watching out for
accesses beyond the allocated size.

> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
> 'unsigned long' sized or aligned).
> 3. Various bit_* functions access the result as if it's an array of
> 'unsigned long', when it was allocated as a single-byte array (no
> ulong alignment or size).

malloc and related functions (including calloc) always return memory
"...suitably aligned for storage of any type of object."  Last time I
checked that basically meant all allocations, even a single byte, are
aligned on a 16-byte boundary on arm.

> 4. ARM isn't as happy about unaligned accesses as x86.
> 

That's mostly not the case anymore.  Using load/store-doubleword or
load/store-multiple instructions requires 4-byte-aligned values (not a
typo: doubleword access requires word alignment).  Everything smaller
than doubleword access in userland these days can be unaligned.  The
optimizer can combine adjacent 32-bit accesses into doubleword
-instruction accesses, leading to alignment faults with unaligned data,
but that shouldn't be the case here because malloc'd memory is aligned.

-- Ian

> I'd make the following change (needs sys/param.h, not compile tested)
> and see if it fixes it:
> 
> --- sys/bitstring.h (revision 301805)
> +++ sys/bitstring.h (working copy)
> @@ -119,7 +119,8 @@
>  static inline bitstr_t *
>  bit_alloc(int _nbits)
>  {
> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
> +   return (calloc(howmany(bitstr_size(_nbits),
> sizeof(bitstr_t)),
> +   sizeof(bitstr_t)));
>  }
>  #endif
> 
> 
> 
> 
> 
> 
> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers 
> wrote:
> > Please open a bug for the bitstring test failures and assign it to
> > me.
> > Also, since I don't have any arm hardware, please provide
> > instructions
> > on how to run this code in a VM, or where I can get access to the
> > hardware.
> > 
> > -Alan
> > 
> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard  > > wrote:
> > > With the newly less strict alignment requirements "kyua test -k
> > > /usr/tests/Kyuafile" runs to completion, unlike before.
> > > 
> > > > ===> Summary
> > > > Results read from /root/.kyua/store/results.usr_tests.20160613
> > > > -080302-120731.db
> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24
> > > > broken, 59 failed
> > > > Total time: 8723.243s
> > > 
> > > 
> > > I only list the one line summaries below. Then I list various
> > > context details.
> > > 
> > > > ===> Broken tests
> > > > lib/msun/cexp_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/ctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.074s]
> > > > lib/msun/exponential_test:main  ->  broken: Received signal 6 
> > > >  [1.045s]
> > > > lib/msun/fenv_test:main  ->  broken: Received signal 6 
> > > >  [1.048s]
> > > > lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
> > > > lib/msun/invctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.091s]
> > > > lib/msun/invtrig_test:main  ->  broken: Received signal 6 
> > > >  [1.086s]
> > > > lib/msun/logarithm_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/lrint_test:main  ->  broken: Received signal 6 
> > > >  [1.069s]
> > > > lib/msun/nearbyint_test:main  ->  broken: Received signal 6 
> > > >  [1.066s]
> > > > lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
> > > > lib/msun/trig_test:main  ->  broken: Received signal 6 
> > > >  [1.070s]
> > > > sbin/growfs/legacy_test:main  ->  broken: Reported plan differs
> > > > from actual executed tests  [0.459s]
> > > > sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test
> > > > case timed out  [1200.082s]
> > > > sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test
> > > > case timed out  [600.138s]
> > > > sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case
> > > > timed out  [600.044s]
> > > > sys/sys/bitstring_test:bit_clear  ->  broken: Test case body
> > > > timed out  [300.032s]
> > > > sys/sys/bitstring_test:bit_count  ->  broken: Premature exit;
> > > > test case received signal 11 (core dumped)  [1.080s]
> > > > sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit;
> > > > test case received signal 11 (core dumped)  [1.077s]
> > > > sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit;
> > > > test case received signal 11 (core dumped)  [1.081s]
> > > > sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit;
> > > > test case received signal 11 (core dumped)  [1.082s]
> > > > sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit;
> > > > test case re

Re: GPIO driver for Intel Atom SoC

[Ian Lepore]

On Sun, 2016-06-12 at 10:48 -0700, Lundberg, Johannes wrote:
> Thanks Adrian
> 
> Looks like this is something I can base the new driver on.
> Hopefully with this we can get eMMC support for Intel SDHCI
> controller.
> 

Why do we need gpio support for emmc/sdhci?  Is there a power-enable
pin that has to be asserted or something?  I don't think we have an API
that lets an arbitrary driver which is not a child of the gpiobus
manipulate pins, outside of the FDT world.

-- 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: GPIO driver for Intel Atom SoC

[Ian Lepore]

On Sat, 2016-06-11 at 21:59 -0700, Lundberg, Johannes wrote:
> Hi
> 
> I want to port the pinctrl-cherryview driver from Linux.
> 
> I've seen there is the gpiobus and a controller gpioc, can any of
> these be
> leverage when porting pinctrl?
> 
> What is the recommend way to proceed?
> 
> Thanks!
> 

The term 'pinctrl' has a very specific meaning in the FDT/devicetree
world which is prevelant in linux these days.  A pinctrl driver is not
just a gpio controller driver.  If the linux driver you're talking
about is in fact an FDT pinctrl driver, then you'll essentially be
embracing the entire FDT world (it's an alternative to ACPI and hints
and other types of metadata for describing hardware).  You'll also be
breaking new ground in freebsd by being the first to try to use
freebsd's FDT support framework on an x86 platform.

-- 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: libarchive update SVN r299529 breaks "ezjail update"

[Ian Lepore]

On Sun, 2016-05-15 at 01:57 +0200, Martin Matuska wrote:
> That switch is "--insecure" and is supported in all libarchive
> versions
> freebsd ever used.
> 

Oh, well that will make handling the new version easier.  It doesn't
change the fact that the new libarchive stuff will break long-working
existing software, but at least it'll be easy to fix.

-- Ian

> 
> On 15.05.2016 01:36, Ngie Cooper (yaneurabeya) wrote:
> > > On May 14, 2016, at 16:29, Martin Matuska  wrote:
> > > 
> > > Ian, we are here talking about cpio, not libarchive. The flag in
> > > libarchive is not active by default.
> > > 
> > > On 14.05.2016 22:08, Ian Lepore wrote:
> > > > The real damage will happen to out-of-tree users.  I think this
> > > > will
> > > > impact our software updater for $work for example, and it has
> > > > to work
> > > > with both old and new versions of libarchive, and now the new
> > > > version
> > > > will require a flag that the old version will reject as
> > > > unknown.
> > > > 
> > > > Ick.
> > Ian’s comment was valid.. cpio doesn’t recognize the new switch on
> > older versions, so something like cpio `cpio --help | grep --
> > switch && echo switch` would need to be employed everywhere for
> > backwards compatibility — ew.
> > Thanks,
> > -Ngie
> 
> ___
> 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: libarchive update SVN r299529 breaks "ezjail update"

[Ian Lepore]

On Sun, 2016-05-15 at 01:29 +0200, Martin Matuska wrote:
> Ian, we are here talking about cpio, not libarchive. The flag in
> libarchive is not active by default.
> 

Yes.  We use cpio for filesystem images, for historical reasons (such
as cpio's ability to encode device major/minor node numbers and other
stuff that doesn't really matter anymore, but the format is kinda cast
in stone now).

-- Ian

> 
> On 14.05.2016 22:08, Ian Lepore wrote:
> > On Sat, 2016-05-14 at 15:51 -0400, michael butler wrote:
> > >  From the looks of this, I think it's likely better to have the
> > > default 
> > > be "secure" and ezjail-admin use the "--insecure" flag as an
> > > explicit
> > > override. That's the only place I've noticed the need for it
> > > although
> > > I've not done an extensive search for any other instances in
> > > which it
> > > might be required,
> > > 
> > >   imb
> > > 
> > The real damage will happen to out-of-tree users.  I think this
> > will
> > impact our software updater for $work for example, and it has to
> > work
> > with both old and new versions of libarchive, and now the new
> > version
> > will require a flag that the old version will reject as unknown.
> > 
> > Ick.
> > 
> > -- Ian
> > 
> > > On 5/14/2016 3:46 PM, Tim Kientzle wrote:
> > > > A little history about this issue:
> > > > 
> > > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304
> > > > 
> > > > 
> > > > > On May 14, 2016, at 12:17 PM, Tim Kientzle 
> > > > > wrote:
> > > > > 
> > > > > Many people consider the traditional behavior to be a
> > > > > security
> > > > > risk, which is why this was changed.
> > > > > 
> > > > > FreeBSD is welcome to make --insecure the default on FreeBSD,
> > > > > but
> > > > > I'm reluctant to do that in the upstream libarchive project.
> > > > > 
> > > > > Tim
> > > > > 
> > > > > 
> > > > > > On May 12, 2016, at 8:54 AM, Martin Matuska  > > > > > >
> > > > > > wrote:
> > > > > > 
> > > > > > Looks like we have to remove line #174 from cpio/cpio.c:
> > > > > > cpio->extract_flags |=
> > > > > > ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
> > > > > > 
> > > > > > This breaks traditional cpio behavior.
> > > > > > 
> > > > > > Quoting Martin Matuska :
> > > > > > 
> > > > > > > Hi Michael, I have looked at the source and this is an
> > > > > > > intended change in 3.2.0.
> > > > > > > 
> > > > > > > An absolute path security check was added, cpio refuses
> > > > > > > to
> > > > > > > extract or copy over absolute paths. To do this anyway
> > > > > > > the "-
> > > > > > > -insecure" flag must be used.
> > > > > > > 
> > > > > > > Here is the commit:
> > > > > > > https://github.com/libarchive/libarchive/commit/593571577
> > > > > > > 06d4
> > > > > > > 7c365b2227739e17daba3607526
> > > > > > > 
> > > > > > > Quoting Michael Butler :
> > > > > > > 
> > > > > > > > It seems that today's libarchive update breaks cpio's
> > > > > > > > behaviour:
> > > > > > > > 
> > > > > > > > sudo ezjail-admin update -i -s /usr/src
> > > > > > > > 
> > > > > > > > [ .. ]
> > > > > > > > 
> > > > > > > > cd /usr/src/etc/..; install -o root -g wheel -m 444 
> > > > > > > >  COPYRIGHT
> > > > > > > > /usr/local/jails/fulljail/
> > > > > > > > install -o root -g wheel -m 444
> > > > > > > > /usr/src/etc/../sys/i386/conf/GENERIC.hints
> > > > > > > > /usr/local/jails/fulljail/boot/device.hints
> > > > > > > > /usr/local/jails/basejail/bincpio: bin: Path is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> >