Re: FreeBSD Documentation
> 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
-- 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
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 Belousovwrote: 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
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
On Sun, Oct 29, 2017 at 11:29 AM, Ngie Cooper (yaneurabeya) < yaneurab...@gmail.com> wrote: > > > On Oct 29, 2017, at 10:26, Kevin Obermanwrote: > > … > > > 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
> On Oct 29, 2017, at 10:26, Kevin Obermanwrote: … > 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
On Sun, Oct 29, 2017 at 9:49 AM, Ngie Cooper (yaneurabeya) < yaneurab...@gmail.com> wrote: > > > On Oct 29, 2017, at 02:46, Thomas Muellerwrote: > > … > > > 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
On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousovwrote: > 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
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
> On Oct 29, 2017, at 02:46, Thomas Muellerwrote: … > 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
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
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 SchubertFreeBSD 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
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
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
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
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=8843metric 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
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
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=8843metric 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
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
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
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
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
from Ngie Cooper: > > On Oct 28, 2017, at 18:09, Gordon Tetlowwrote: > > 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
> On Oct 28, 2017, at 18:09, Gordon Tetlowwrote: > > 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