Re: FreeBSD Documentation

2017-10-29 Thread Ngie Cooper

> On Oct 29, 2017, at 13:53, Rodney W. Grimes 
>  wrote:
> 
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
>>> 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
> 
> Lets make this MUCH easier on a user.
> cp /usr/share/man/man8/jail.8.gz /tmp
> cd /tmp
> gzip -d jail.8.gz
> cp -p jail.8 jail.8.orig
> vi jail.8
> diff -u jail.8.orig jail.8 >jail.8.patch
> 
> And then attach that patch to a bugzilla
> 
> More commands, but much shorter amount of time.
> 
> (Of cource broken if your system is not -current or close to it)

No. Just do a sparse checkout of share/man/man8 ... less error prone and one 
has a usable diff instead of a diff that might contain local modifications, or 
be a few revisions behind.

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

2017-10-29 Thread Rodney W. Grimes
-- Start of PGP signed section.
[ Charset UTF-8 unsupported, converting... ]
> 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

Lets make this MUCH easier on a user.
cp /usr/share/man/man8/jail.8.gz /tmp
cd /tmp
gzip -d jail.8.gz
cp -p jail.8 jail.8.orig
vi jail.8
diff -u jail.8.orig jail.8 >jail.8.patch

And then attach that patch to a bugzilla

More commands, but much shorter amount of time.

(Of cource broken if your system is not -current or close to it)
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Segfault in _Unwind_* code called from pthread_exit

2017-10-29 Thread Andreas Tobler

On 29.10.17 20:13, Konstantin Belousov wrote:

On Sun, Oct 29, 2017 at 06:23:51PM +0100, Tijl Coosemans wrote:

On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov  
wrote:

On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:

I did consider using
a CFI directive (see patch below) and it works, but it's architecture
specific and it's inserted after the function prologue so there's still
a window of a few instructions where a stack unwinder will try to use
the return address.

Index: lib/libthr/thread/thr_create.c
===
--- lib/libthr/thread/thr_create.c  (revision 322802)
+++ lib/libthr/thread/thr_create.c  (working copy)
@@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
  static void
  thread_start(struct pthread *curthread)
  {
+   __asm(".cfi_undefined %rip");
 sigset_t set;
  
 if (curthread->attr.suspend == THR_CREATE_SUSPENDED)


I like this approach much more than the previous patch.  What can be
done is to provide asm trampoline which calls thread_start().  There you
can add the .cfi_undefined right at the entry.

It is somewhat more work than just setting the return address on the
kernel-constructed pseudo stack frame, but I believe this is ultimately
correct way.  You still can do it only on some arches, if you do not
have incentive to code asm for all of them.


Ok, but then there are two ways to implement the trampoline:

1)
movq $0,(%rsp)
jmp thread_start
2)
subq $8,%rsp
call thread_start
/* NOTREACHED */

With 1) you're setting the return address to zero anyway, so you might
as well do that in the kernel like my first patch.  With 2) you're
setting up a new call frame, basically redoing what the kernel already
did and on i386 this also means copying the function argument.

I do not quite understand the second variant, because the stack is not
guaranteed to be zeroed, and it is often not if reused after the previously
exited thread.

The first variant is what I like, but perhaps we need to emulate the
frame as well, i.e. push two zero longs.

Currently kernel does not access the usermode stack for the new thread
unless dictated by ABI (i.e. it does not touch it for 64bit process
on amd64, but have to for 32bit).  I like this property.  Also, the
previous paragraph is indicative: we do not really know in kernel
what ABI the userspace follows.  It might want frame, may be it does
not need it.  It could use other register than %rbp as the frame base,
etc.



Do you have any preference (or better alternatives), because I think I
still prefer my first patch.  It's the caller's job to set up the call
frame, in this case the kernel.  And if the kernel handles it then it
also works with (hypothetical) implementations other than libthr.


Also crt1 probably should get the same treatment, despite we already set
%rbp to zero AFAIR.


I haven't checked but I imagine the return address of the process entry
point is always zero because the stack is all zeros.

Stack is not zero. The environment and argument strings and auxv are copied
at top, and at the bottom the ps_strings structure is located, so it
is not.

If you commit your existing patch as is, I will not resent.  But I do think
that stuff that can be done in usermode, should be done in usermode, esp.
when the amount of efforts is same.


Attached what I have for libgcc. It can be applied to gcc5-8, should 
give no issues. The mentioned tc from this thread and mine, 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.


What do you think?

Andreas

Index: libgcc/config/i386/freebsd-unwind.h
===
--- libgcc/config/i386/freebsd-unwind.h (revision 254205)
+++ libgcc/config/i386/freebsd-unwind.h (working copy)
@@ -28,7 +28,10 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 #define REG_NAME(reg)  sf_uc.uc_mcontext.mc_## reg
@@ -36,38 +39,46 @@
 #ifdef __x86_64__
 #define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state
 
+static int
+x86_64_outside_sigtramp_range (unsigned char *pc)
+{
+  static int sigtramp_range_determined = 0;
+  static unsigned char *sigtramp_start, *sigtramp_end;
+
+  if (sigtramp_range_determined == 0)
+{
+  struct kinfo_sigtramp kst = {0};
+  size_t len = sizeof (kst);
+  int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_SIGTRAMP, getpid() };
+
+  sigtramp_range_determined = 1;
+  if (sysctl (mib, 4, , , NULL, 0) == 0)
+  {
+sigtramp_range_determined = 2;
+sigtramp_start = kst.ksigtramp_start;
+sigtramp_end   = kst.ksigtramp_end;
+  }
+}
+  if (sigtramp_range_determined < 2)  /* sysctl failed if < 2 */
+return 1;
+
+  return (pc < sigtramp_start || pc >= sigtramp_end);
+}
+
 static _Unwind_Reason_Code
 x86_64_freebsd_fallback_frame_state
 (struct _Unwind_Context *context, 

Re: Segfault in _Unwind_* code called from pthread_exit

2017-10-29 Thread Konstantin Belousov
On Sun, Oct 29, 2017 at 06:23:51PM +0100, Tijl Coosemans wrote:
> On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov  
> wrote:
> > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:
> >> I did consider using
> >> a CFI directive (see patch below) and it works, but it's architecture
> >> specific and it's inserted after the function prologue so there's still
> >> a window of a few instructions where a stack unwinder will try to use
> >> the return address.
> >> 
> >> Index: lib/libthr/thread/thr_create.c
> >> ===
> >> --- lib/libthr/thread/thr_create.c  (revision 322802)
> >> +++ lib/libthr/thread/thr_create.c  (working copy)
> >> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
> >>  static void
> >>  thread_start(struct pthread *curthread)
> >>  {
> >> +   __asm(".cfi_undefined %rip");
> >> sigset_t set;
> >>  
> >> if (curthread->attr.suspend == THR_CREATE_SUSPENDED)  
> > 
> > I like this approach much more than the previous patch.  What can be
> > done is to provide asm trampoline which calls thread_start().  There you
> > can add the .cfi_undefined right at the entry.
> >
> > It is somewhat more work than just setting the return address on the
> > kernel-constructed pseudo stack frame, but I believe this is ultimately
> > correct way.  You still can do it only on some arches, if you do not
> > have incentive to code asm for all of them.
> 
> Ok, but then there are two ways to implement the trampoline:
> 
> 1)
>   movq $0,(%rsp)
>   jmp thread_start
> 2)
>   subq $8,%rsp
>   call thread_start
>   /* NOTREACHED */
> 
> With 1) you're setting the return address to zero anyway, so you might
> as well do that in the kernel like my first patch.  With 2) you're
> setting up a new call frame, basically redoing what the kernel already
> did and on i386 this also means copying the function argument.
I do not quite understand the second variant, because the stack is not
guaranteed to be zeroed, and it is often not if reused after the previously
exited thread.

The first variant is what I like, but perhaps we need to emulate the
frame as well, i.e. push two zero longs.

Currently kernel does not access the usermode stack for the new thread
unless dictated by ABI (i.e. it does not touch it for 64bit process
on amd64, but have to for 32bit).  I like this property.  Also, the
previous paragraph is indicative: we do not really know in kernel
what ABI the userspace follows.  It might want frame, may be it does
not need it.  It could use other register than %rbp as the frame base,
etc.

> 
> Do you have any preference (or better alternatives), because I think I
> still prefer my first patch.  It's the caller's job to set up the call
> frame, in this case the kernel.  And if the kernel handles it then it
> also works with (hypothetical) implementations other than libthr.
> 
> > Also crt1 probably should get the same treatment, despite we already set
> > %rbp to zero AFAIR.
> 
> I haven't checked but I imagine the return address of the process entry
> point is always zero because the stack is all zeros.
Stack is not zero. The environment and argument strings and auxv are copied
at top, and at the bottom the ps_strings structure is located, so it
is not.

If you commit your existing patch as is, I will not resent.  But I do think
that stuff that can be done in usermode, should be done in usermode, esp.
when the amount of efforts is same.
___
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: iwm not in GENERIC kernel

2017-10-29 Thread Warner Losh
On Sun, Oct 29, 2017 at 11:29 AM, Ngie Cooper (yaneurabeya) <
yaneurab...@gmail.com> wrote:

>
> > On Oct 29, 2017, at 10:26, Kevin Oberman  wrote:
>
> …
>
> > But I thought that all modern wireless interfaces and many others load
> blobs. Is the source for the firmware blob for iwn (which is in GENERIC)
> available?
>
> There’s a piece that’s open sourced that a BSD developer has
> written, but there’s also a binary payload that we have no insight into.
> Cheers,
> -Ngie
>
> $ file sys/contrib/dev/iwm/*.uu
> sys/contrib/dev/iwm/iwm-3160-16.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-3160-17.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-3160-9.fw.uu:   empty
> sys/contrib/dev/iwm/iwm-7260-16.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-7260-17.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-7260-9.fw.uu:   empty
> sys/contrib/dev/iwm/iwm-7265-16.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-7265-17.fw.uu:  uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-7265-9.fw.uu:   empty
> sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text
> sys/contrib/dev/iwm/iwm-8265-22.fw.uu:  uuencoded or xxencoded, ASCII text
>

The blobs run on the actual card itself, not on the host. This is the
firmware for the wireless SoC that's on the card. We have allowed those in
the kernel since the very early days of the project when scsi controllers
like isp(4) downloaded firmware.

This is somewhat different than the recently discussed HBAs that have
binary blobs that run on the host, which have no business in GENERIC...

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

Re: iwm not in GENERIC kernel

2017-10-29 Thread Ngie Cooper (yaneurabeya)

> On Oct 29, 2017, at 10:26, Kevin Oberman  wrote:

…

> But I thought that all modern wireless interfaces and many others load blobs. 
> Is the source for the firmware blob for iwn (which is in GENERIC)  available?

There’s a piece that’s open sourced that a BSD developer has written, 
but there’s also a binary payload that we have no insight into.
Cheers,
-Ngie

$ file sys/contrib/dev/iwm/*.uu
sys/contrib/dev/iwm/iwm-3160-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-3160-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7260-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7260-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265-16.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-17.fw.uu:  uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265-9.fw.uu:   empty
sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text
sys/contrib/dev/iwm/iwm-8265-22.fw.uu:  uuencoded or xxencoded, ASCII text


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: iwm not in GENERIC kernel

2017-10-29 Thread Kevin Oberman
On Sun, Oct 29, 2017 at 9:49 AM, Ngie Cooper (yaneurabeya) <
yaneurab...@gmail.com> wrote:

>
> > On Oct 29, 2017, at 02:46, Thomas Mueller  wrote:
>
> …
>
> > Is that binary blob the reason why rsu is not in GENERIC?
> >
> > I use rsu for Hiro H50191 USB wireless adapter.
>
> Yup.
>

But I thought that all modern wireless interfaces and many others load
blobs. Is the source for the firmware blob for iwn (which is in GENERIC)
available?
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

2017-10-29 Thread Tijl Coosemans
On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov  
wrote:
> On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:
>> I did consider using
>> a CFI directive (see patch below) and it works, but it's architecture
>> specific and it's inserted after the function prologue so there's still
>> a window of a few instructions where a stack unwinder will try to use
>> the return address.
>> 
>> Index: lib/libthr/thread/thr_create.c
>> ===
>> --- lib/libthr/thread/thr_create.c  (revision 322802)
>> +++ lib/libthr/thread/thr_create.c  (working copy)
>> @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
>>  static void
>>  thread_start(struct pthread *curthread)
>>  {
>> +   __asm(".cfi_undefined %rip");
>> sigset_t set;
>>  
>> if (curthread->attr.suspend == THR_CREATE_SUSPENDED)  
> 
> I like this approach much more than the previous patch.  What can be
> done is to provide asm trampoline which calls thread_start().  There you
> can add the .cfi_undefined right at the entry.
>
> It is somewhat more work than just setting the return address on the
> kernel-constructed pseudo stack frame, but I believe this is ultimately
> correct way.  You still can do it only on some arches, if you do not
> have incentive to code asm for all of them.

Ok, but then there are two ways to implement the trampoline:

1)
movq $0,(%rsp)
jmp thread_start
2)
subq $8,%rsp
call thread_start
/* NOTREACHED */

With 1) you're setting the return address to zero anyway, so you might
as well do that in the kernel like my first patch.  With 2) you're
setting up a new call frame, basically redoing what the kernel already
did and on i386 this also means copying the function argument.

Do you have any preference (or better alternatives), because I think I
still prefer my first patch.  It's the caller's job to set up the call
frame, in this case the kernel.  And if the kernel handles it then it
also works with (hypothetical) implementations other than libthr.

> Also crt1 probably should get the same treatment, despite we already set
> %rbp to zero AFAIR.

I haven't checked but I imagine the return address of the process entry
point is always zero because the stack is all zeros.
___
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

2017-10-29 Thread Benjamin Kaduk
On Sun, Oct 29, 2017 at 07:47:33PM +0300, Yuri Pankov wrote:
> On Sun, 29 Oct 2017 22:13:16 +0800, Blubee Blubeeme wrote:
> > How can we suggest edits for the docs?
> > 
> > The docs still reference using sysinstall to setup a jail when it hasn't
> > been that since at least 2011
> > https://www.freebsd.org/cgi/man.cgi?query=jail=8=freebsd-release-ports
> > 
> >   Start a shell in the jail:
> > 
> >jail -c path=/data/jail/testjail mount.devfs \
> >host.hostname=testhostname ip4.addr=192.0.2.100 \
> >command=/bin/sh
> > 
> >   Assuming no errors, you will end up with ashell prompt within the 
> > jail.
> >   You can now run */usr/sbin/sysinstall* and do the post-install 
> > configura-
> >   tion to set various configuration options,or perform these 
> > actions manu-
> >   ally by editing */etc/rc.conf*, etc.
> 
> While you were already given a lot of correct replies, exactly the 
> change you want is already in HEAD (though as noted in followup, it 
> could really say bsdconfig instead of bsdinstall):
> 
> Author: bjk (doc committer)
> Date: Wed Oct 18 22:56:46 2017
> New Revision: 324732
> URL: https://svnweb.freebsd.org/changeset/base/324732
> 
> Log:
>Adopt jail.8 to our brave new bsdinstall world

Indeed.  I have the MFC reminder sitting in my inbox, since the original
commit received such feedback about bsdconfig being a better replacement,
but I haven't had a chance to go review the best change to make in master
(and then MFC).

I would not object if someone beat me to coming up with better text! :)

-Ben
___
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: iwm not in GENERIC kernel

2017-10-29 Thread Ngie Cooper (yaneurabeya)

> On Oct 29, 2017, at 02:46, Thomas Mueller  wrote:

…

> Is that binary blob the reason why rsu is not in GENERIC?
> 
> I use rsu for Hiro H50191 USB wireless adapter.

Yup.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: FreeBSD Documentation

2017-10-29 Thread Yuri Pankov

On Sun, 29 Oct 2017 22:13:16 +0800, Blubee Blubeeme wrote:

How can we suggest edits for the docs?

The docs still reference using sysinstall to setup a jail when it hasn't
been that since at least 2011
https://www.freebsd.org/cgi/man.cgi?query=jail=8=freebsd-release-ports

  Start a shell in the jail:

   jail -c path=/data/jail/testjail mount.devfs \
   host.hostname=testhostname ip4.addr=192.0.2.100 \
   command=/bin/sh

  Assuming no errors, you will end up with ashell prompt within the 
jail.
  You can now run */usr/sbin/sysinstall* and do the post-install configura-
  tion to set various configuration options,or perform these 
actions manu-
  ally by editing */etc/rc.conf*, etc.


While you were already given a lot of correct replies, exactly the 
change you want is already in HEAD (though as noted in followup, it 
could really say bsdconfig instead of bsdinstall):


Author: bjk (doc committer)
Date: Wed Oct 18 22:56:46 2017
New Revision: 324732
URL: https://svnweb.freebsd.org/changeset/base/324732

Log:
  Adopt jail.8 to our brave new bsdinstall world

  Submitted by: Steve Kargl
  MFC after:3 days


___
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

2017-10-29 Thread Cy Schubert
In message <1509293832.21609.7.ca...@freebsd.org>, Ian Lepore writes:
> 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.

That's a useful skill too. Not just here but in Solaris, AIX and Linux. IMO 
every sysadmin should have a rudimentary nroff markup skill.

But if the markup is indeed an impediment, just sending in text will work 
too.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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


Re: FreeBSD Documentation

2017-10-29 Thread Cy Schubert
In message , Allan Jude 
write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --aGGixulc9uAFLFA2k9VWxk7NcN6fQBdFP
> Content-Type: multipart/mixed; boundary="T6pjExsFmnQlcvXFRkfkRKJem0LXImVKi";
>  protected-headers="v1"
> From: Allan Jude 
> To: freebsd-current@freebsd.org
> Message-ID: 
> Subject: Re: FreeBSD Documentation
> References:  om>
>  <20171029150039.gl34...@home.opsec.eu>
> In-Reply-To: <20171029150039.gl34...@home.opsec.eu>
> 
> --T6pjExsFmnQlcvXFRkfkRKJem0LXImVKi
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
> 
> On 2017-10-29 11:00, Kurt Jaeger wrote:
> > Hi!
> >=20
> >> How can we suggest edits for the docs?
> >=20
> > Checkout the docs repo:
> >=20
> >   svn checkout https://svnweb.freebsd.org/doc/head/ .
> >=20
> > Change the relevant files, create a new problem report on
> >=20
> >   https://bugs.freebsd.org/
> >=20
> > and attach the svn diff to that problem report.
> >=20
> 
> 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

Yes, and that's the first step to becoming a committer. I recall sending 
multiple patches because I didn't want to patch brand new FreeBSD systems 
after installing the ISO (they were plastic discs then). (We used FreeBSD 
for infrastructure servers at $JOB at the time.) Then one day there was an 
email from nectar@ in my inbox offering the keys to the farm.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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


Re: FreeBSD Documentation

2017-10-29 Thread 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: FreeBSD Documentation

2017-10-29 Thread Allan Jude
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


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: NFSv3 issues with latest -current

2017-10-29 Thread Yuri Pankov

On Sun, 29 Oct 2017 18:11:41 +0300, Yuri Pankov wrote:

On Sun, 29 Oct 2017 13:13:31 +, Rick Macklem wrote:

Yuri Pankov wrote:

All file operations (e.g. copying the file over NFSv3 for me) seem to be
stuck running the latest -current (r325100).  Reverting just the kernel
to r323779 (arbitrary chosen) seems to help.  I noticed the "Stale file
handle when mounting nfs" message but I don't get the "stale file
handle" messages from mount, probably as I'm not running any linux clients.

These kinds of problems are usually related to your net interface device
driver or the TCP stack.

A couple of things to try:
- Disable TSO (look for a sysctl with "tso" in it).
- Try using mount options rsize=32768,waize=32768 to reduce the I/O
size. Some device drivers don't handle long chains of mbufs well,
especially when the size is near 64K.
(These issues have been fixed in current, but if a bug slips into a net driver
   update or ???)
- Look at recent changes to the net device driver you are using and try 
reverting
those changes if you can do so.
- Capture packets and look at them in wireshark (which knows NFS) and see
what is going on the wire.

There hasn't been any recent changes to NFS that should affect NFSv3 mounts
or to the kernel rpc, so I doubt the NFSv4.1 changes would be involved.


Thanks for the hints, Rick!

Indeed, it was one of the changes to sys/dev/e1000, reverting just the
commit made everything look normal again (CC'ing the author).


One thing I forgot to mention here, the problem is visible only if the 
client side has MTU of 1500 configured; when both sides have MTU 9000, 
everything looks to be normal -- noticed this when my XenServer (having 
MTU of 1500 on management interface) wasn't able to read the ISO from 
NFS datastore.



The NIC is:

igb0@pci0:2:0:0:class=0x02 card=0x10c915d9 chip=0x10c98086
rev=0x01 hdr=0x00
  vendor = 'Intel Corporation'
  device = '82576 Gigabit Network Connection'
  class  = network
  subclass   = ethernet

Interface configuration (note the MTU):

igb0: flags=8843 metric 0 mtu 9000
options=e525bb
  ether 00:25:90:72:54:22
  inet6 fe80::225:90ff:fe72:5422%igb0 prefixlen 64 scopeid 0x1
  inet 192.168.1.4 netmask 0xff00 broadcast 192.168.1.255
  nd6 options=23
  media: Ethernet autoselect (1000baseT )
  status: active

And the commit itself:

commit f81cb8df32ae96299b8bbc2e948c17ad3aab59ca
Author: shurd 
Date:   Sat Sep 23 01:33:20 2017 +

  Some small packet performance improvements

  If the packet is smaller than MTU, disable the TSO flags.
  Move TCP header parsing inside the IS_TSO?() test.
  Add a new IFLIB_NEED_ZERO_CSUM flag to indicate the checksums need
to be zeroed before TX.

  Reviewed by:sbruno
  Approved by:sbruno (mentor)
  Sponsored by:   Limelight Networks
  Differential Revision:  https://reviews.freebsd.org/D12442

Notes:
  svn path=/head/; revision=323941




___
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: NFSv3 issues with latest -current

2017-10-29 Thread Cy Schubert
In message , Rick Macklem writes:
> Yuri Pankov wrote:
> > All file operations (e.g. copying the file over NFSv3 for me) seem to be
> > stuck running the latest -current (r325100).  Reverting just the kernel
> > to r323779 (arbitrary chosen) seems to help.  I noticed the "Stale file
> > handle when mounting nfs" message but I don't get the "stale file
> > handle" messages from mount, probably as I'm not running any linux clients.
> These kinds of problems are usually related to your net interface device
> driver or the TCP stack.
> 
> A couple of things to try:
> - Disable TSO (look for a sysctl with "tso" in it).

The sysctl is net.inet.tcp.tso. You can also disable tso through ifconfig 
for an interface.

Additionally, though not directly related to this, TSO is not generally 
firewall friendly either. Our friends at pfsense document it be disabled. 
It can cause issues with our ipfilter firewall on some interfaces (e.g. 
fxp). I also recall reading a Juniper KB about path MTU discovery and TSO 
not playing well together.

Not that TSO is bad but disabling it is something to try when diagnosing 
network problems.



-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.



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


Re: NFSv3 issues with latest -current

2017-10-29 Thread Yuri Pankov

On Sun, 29 Oct 2017 13:13:31 +, Rick Macklem wrote:

Yuri Pankov wrote:

All file operations (e.g. copying the file over NFSv3 for me) seem to be
stuck running the latest -current (r325100).  Reverting just the kernel
to r323779 (arbitrary chosen) seems to help.  I noticed the "Stale file
handle when mounting nfs" message but I don't get the "stale file
handle" messages from mount, probably as I'm not running any linux clients.

These kinds of problems are usually related to your net interface device
driver or the TCP stack.

A couple of things to try:
- Disable TSO (look for a sysctl with "tso" in it).
- Try using mount options rsize=32768,waize=32768 to reduce the I/O
   size. Some device drivers don't handle long chains of mbufs well,
   especially when the size is near 64K.
(These issues have been fixed in current, but if a bug slips into a net driver
  update or ???)
- Look at recent changes to the net device driver you are using and try 
reverting
   those changes if you can do so.
- Capture packets and look at them in wireshark (which knows NFS) and see
   what is going on the wire.

There hasn't been any recent changes to NFS that should affect NFSv3 mounts
or to the kernel rpc, so I doubt the NFSv4.1 changes would be involved.


Thanks for the hints, Rick!

Indeed, it was one of the changes to sys/dev/e1000, reverting just the 
commit made everything look normal again (CC'ing the author).


The NIC is:

igb0@pci0:2:0:0:class=0x02 card=0x10c915d9 chip=0x10c98086 
rev=0x01 hdr=0x00

vendor = 'Intel Corporation'
device = '82576 Gigabit Network Connection'
class  = network
subclass   = ethernet

Interface configuration (note the MTU):

igb0: flags=8843 metric 0 mtu 9000
options=e525bb
ether 00:25:90:72:54:22
inet6 fe80::225:90ff:fe72:5422%igb0 prefixlen 64 scopeid 0x1
inet 192.168.1.4 netmask 0xff00 broadcast 192.168.1.255
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active

And the commit itself:

commit f81cb8df32ae96299b8bbc2e948c17ad3aab59ca
Author: shurd 
Date:   Sat Sep 23 01:33:20 2017 +

Some small packet performance improvements

If the packet is smaller than MTU, disable the TSO flags.
Move TCP header parsing inside the IS_TSO?() test.
Add a new IFLIB_NEED_ZERO_CSUM flag to indicate the checksums need 
to be zeroed before TX.


Reviewed by:sbruno
Approved by:sbruno (mentor)
Sponsored by:   Limelight Networks
Differential Revision:  https://reviews.freebsd.org/D12442

Notes:
svn path=/head/; revision=323941
___
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

2017-10-29 Thread Kurt Jaeger
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.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
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 Documentation

2017-10-29 Thread blubee blubeeme
How can we suggest edits for the docs?

The docs still reference using sysinstall to setup a jail when it hasn't
been that since at least 2011
https://www.freebsd.org/cgi/man.cgi?query=jail=8=freebsd-release-ports

 Start a shell in the jail:

   jail -c path=/data/jail/testjail mount.devfs \
   host.hostname=testhostname ip4.addr=192.0.2.100 \
   command=/bin/sh

 Assuming no errors, you will end up with a shell prompt within the jail.
 You can now run */usr/sbin/sysinstall* and do the post-install configura-
 tion to set various configuration options, or perform these actions manu-
 ally by editing */etc/rc.conf*, etc.
___
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: NFSv3 issues with latest -current

2017-10-29 Thread Rick Macklem
Yuri Pankov wrote:
> All file operations (e.g. copying the file over NFSv3 for me) seem to be
> stuck running the latest -current (r325100).  Reverting just the kernel
> to r323779 (arbitrary chosen) seems to help.  I noticed the "Stale file
> handle when mounting nfs" message but I don't get the "stale file
> handle" messages from mount, probably as I'm not running any linux clients.
These kinds of problems are usually related to your net interface device
driver or the TCP stack.

A couple of things to try:
- Disable TSO (look for a sysctl with "tso" in it).
- Try using mount options rsize=32768,waize=32768 to reduce the I/O
  size. Some device drivers don't handle long chains of mbufs well,
  especially when the size is near 64K.
(These issues have been fixed in current, but if a bug slips into a net driver
 update or ???)
- Look at recent changes to the net device driver you are using and try 
reverting
  those changes if you can do so.
- Capture packets and look at them in wireshark (which knows NFS) and see
  what is going on the wire.

There hasn't been any recent changes to NFS that should affect NFSv3 mounts
or to the kernel rpc, so I doubt the NFSv4.1 changes would be involved.

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


NFSv3 issues with latest -current

2017-10-29 Thread Yuri Pankov

Hi,

All file operations (e.g. copying the file over NFSv3 for me) seem to be 
stuck running the latest -current (r325100).  Reverting just the kernel 
to r323779 (arbitrary chosen) seems to help.  I noticed the "Stale file 
handle when mounting nfs" message but I don't get the "stale file 
handle" messages from mount, probably as I'm not running any linux clients.


Is anyone else seeing the same?  Is there any other information I need 
to provide here?

___
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: iwm not in GENERIC kernel

2017-10-29 Thread Thomas Mueller
from Ngie Cooper:

> > On Oct 28, 2017, at 18:09, Gordon Tetlow  wrote:

> > I have an Intel NUC that uses an Intel 8260 wireless driver. This works
> > flawlessly if I load the module if_iwm via the loader or the rc.conf
> > kld_list directive.

> > Do we know if the iwm driver not being in GENERIC is an oversight or on
> > purpose? I couldn't find anything in the list history.

> It’s on purpose since it has a binary blob firmware driver that it relies 
> on, IIRC.
> -Ngie

Is that binary blob the reason why rsu is not in GENERIC?

I use rsu for Hiro H50191 USB wireless adapter.

Tom

___
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: iwm not in GENERIC kernel

2017-10-29 Thread Ngie Cooper (yaneurabeya)

> On Oct 28, 2017, at 18:09, Gordon Tetlow  wrote:
> 
> I have an Intel NUC that uses an Intel 8260 wireless driver. This works
> flawlessly if I load the module if_iwm via the loader or the rc.conf
> kld_list directive.
> 
> Do we know if the iwm driver not being in GENERIC is an oversight or on
> purpose? I couldn't find anything in the list history.

It’s on purpose since it has a binary blob firmware driver that it relies on, 
IIRC.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail