From owner-freebsd-hackers@freebsd.org Sun Jul 24 03:04:51 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 537C9B9B640 for ; Sun, 24 Jul 2016 03:04:51 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1291CF6 for ; Sun, 24 Jul 2016 03:04:50 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bR9iZ-0008HS-Tl for freebsd-hackers@freebsd.org; Sun, 24 Jul 2016 05:04:40 +0200 Received: from ip184-189-249-34.sb.sd.cox.net ([184.189.249.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jul 2016 05:04:39 +0200 Received: from julian by ip184-189-249-34.sb.sd.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jul 2016 05:04:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Julian Hsiao Subject: fsync(1) patch to do DIOCGFLUSH on character devices Date: Sun, 24 Jul 2016 03:04:34 +0000 (UTC) Lines: 95 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 184.189.249.34 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 03:04:51 -0000 Hi, The fsync(1) utility is a simple wrapper around fsync(2), but I didn't find a similar utility for calling ioctl(DIOCGFLUSH) for character devices. fsync(2) is a no-op on character device files, which is a little surprising but makes sense I suppose (would raising EINVAL be against POSIX?). However, conceptually the goal is the same: commit writes to permanent storage, so here's a small patch to fsync(1) that calls ioctl(DIOCGFLUSH) for character device files instead. Incidentally, turns out you need to open character device files with O_RDWR (or maybe O_WRONLY is enough, I didn't check) for DIOCGFLUSH, but fsync(2) only needs O_RDONLY for plain files. This seems a little odd; does anyone know why? Julian Hsiao Index: usr.bin/fsync/fsync.1 =================================================================== diff --git a/head/usr.bin/fsync/fsync.1 b/head/usr.bin/fsync/fsync.1 --- a/head/usr.bin/fsync/fsync.1 (revision 303213) +++ b/head/usr.bin/fsync/fsync.1 (working copy) @@ -44,6 +44,8 @@ .Nm utility uses the .Xr fsync 2 +or the +.Xr ioctl 2 function call. .Sh EXIT STATUS If an error occurs, the Index: usr.bin/fsync/fsync.c =================================================================== diff --git a/head/usr.bin/fsync/fsync.c b/head/usr.bin/fsync/fsync.c --- a/head/usr.bin/fsync/fsync.c (revision 303213) +++ b/head/usr.bin/fsync/fsync.c (working copy) @@ -35,6 +35,10 @@ #include #include #include +#include +#include +#include +#include static void usage(void); @@ -44,6 +48,7 @@ int fd; int i; int rval; + struct stat sb; if (argc < 2) { usage(); @@ -58,11 +63,35 @@ rval = EX_NOINPUT; continue; } + memset(&sb, 0, sizeof(sb)); + if (fstat(fd, &sb) == -1) { + warn("fstat %s", argv[i]); + rval = EX_OSERR; + continue; + } - if (fsync(fd) == -1) { - warn("fsync %s", argv[i]); - if (rval == EX_OK) + if (S_ISCHR(sb.st_mode)) { + if (close(fd) == -1) { + warn("close %s", argv[i]); rval = EX_OSERR; + continue; + } + if ((fd = open(argv[i], O_RDWR)) == -1) { + warn("open %s", argv[i]); + rval = EX_NOINPUT; + continue; + } + + if (ioctl(fd, DIOCGFLUSH) == -1) { + warn("ioctl %s", argv[i]); + rval = EX_OSERR; + } + } else { + if (fsync(fd) == -1) { + warn("fsync %s", argv[i]); + if (rval == EX_OK) + rval = EX_OSERR; + } } close(fd); } From owner-freebsd-hackers@freebsd.org Sun Jul 24 05:39:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B09DBA1465 for ; Sun, 24 Jul 2016 05:39:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A28E91DFB for ; Sun, 24 Jul 2016 05:39:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u6O5dFJL010337 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jul 2016 08:39:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u6O5dFJL010337 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u6O5dFop010336; Sun, 24 Jul 2016 08:39:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Jul 2016 08:39:15 +0300 From: Konstantin Belousov To: Julian Hsiao Cc: freebsd-hackers@freebsd.org Subject: Re: fsync(1) patch to do DIOCGFLUSH on character devices Message-ID: <20160724053914.GV38613@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 05:39:21 -0000 On Sun, Jul 24, 2016 at 03:04:34AM +0000, Julian Hsiao wrote: > Hi, > > The fsync(1) utility is a simple wrapper around fsync(2), but I didn't find > a similar utility for calling ioctl(DIOCGFLUSH) for character devices. It is not similar in any reasonable interpretation of the word. > fsync(2) is a no-op on character device files, which is a little surprising > but makes sense I suppose (would raising EINVAL be against POSIX?). POSIX does not mention special nodes at all, so the implementation is free to do whatever it wants/needs. > > However, conceptually the goal is the same: commit writes to permanent > storage, so here's a small patch to fsync(1) that calls ioctl(DIOCGFLUSH) > for character device files instead. This ioctl() does not perform what you describe, at least not on the level of the buffer cache/page cache for the device. It is the duty of the filesystem (or other in-kernel consumer) to ensure that cache is flushed when needed. The ioctl only sends BIO_FLUSH command to the driver, which does something to the hardware. Oftent this 'something' is either nop or have no observable implications. That said, I do not see the proposed change as useful. > > Incidentally, turns out you need to open character device files with O_RDWR > (or maybe O_WRONLY is enough, I didn't check) for DIOCGFLUSH, but fsync(2) > only needs O_RDONLY for plain files. This seems a little odd; does anyone > know why? > > Julian Hsiao > > Index: usr.bin/fsync/fsync.1 > =================================================================== > diff --git a/head/usr.bin/fsync/fsync.1 b/head/usr.bin/fsync/fsync.1 > --- a/head/usr.bin/fsync/fsync.1 (revision 303213) > +++ b/head/usr.bin/fsync/fsync.1 (working copy) > @@ -44,6 +44,8 @@ > .Nm > utility uses the > .Xr fsync 2 > +or the > +.Xr ioctl 2 > function call. > .Sh EXIT STATUS > If an error occurs, the > Index: usr.bin/fsync/fsync.c > =================================================================== > diff --git a/head/usr.bin/fsync/fsync.c b/head/usr.bin/fsync/fsync.c > --- a/head/usr.bin/fsync/fsync.c (revision 303213) > +++ b/head/usr.bin/fsync/fsync.c (working copy) > @@ -35,6 +35,10 @@ > #include > #include > #include > +#include > +#include > +#include > +#include > > static void usage(void); > > @@ -44,6 +48,7 @@ > int fd; > int i; > int rval; > + struct stat sb; > > if (argc < 2) { > usage(); > @@ -58,11 +63,35 @@ > rval = EX_NOINPUT; > continue; > } > + memset(&sb, 0, sizeof(sb)); > + if (fstat(fd, &sb) == -1) { > + warn("fstat %s", argv[i]); > + rval = EX_OSERR; > + continue; > + } > > - if (fsync(fd) == -1) { > - warn("fsync %s", argv[i]); > - if (rval == EX_OK) > + if (S_ISCHR(sb.st_mode)) { > + if (close(fd) == -1) { > + warn("close %s", argv[i]); > rval = EX_OSERR; > + continue; > + } > + if ((fd = open(argv[i], O_RDWR)) == -1) { > + warn("open %s", argv[i]); > + rval = EX_NOINPUT; > + continue; > + } > + > + if (ioctl(fd, DIOCGFLUSH) == -1) { > + warn("ioctl %s", argv[i]); > + rval = EX_OSERR; > + } > + } else { > + if (fsync(fd) == -1) { > + warn("fsync %s", argv[i]); > + if (rval == EX_OK) > + rval = EX_OSERR; > + } > } > close(fd); > } > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Jul 24 08:40:42 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AF9CBA300C for ; Sun, 24 Jul 2016 08:40:42 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E54711B27 for ; Sun, 24 Jul 2016 08:40:41 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bRExd-0001Xs-BM for freebsd-hackers@freebsd.org; Sun, 24 Jul 2016 10:40:33 +0200 Received: from ip184-189-249-34.sb.sd.cox.net ([184.189.249.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jul 2016 10:40:33 +0200 Received: from julian by ip184-189-249-34.sb.sd.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Jul 2016 10:40:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Julian Hsiao Subject: Re: fsync(1) patch to do DIOCGFLUSH on character devices Date: Sun, 24 Jul 2016 08:40:26 +0000 (UTC) Lines: 49 Message-ID: References: <20160724053914.GV38613@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 184.189.249.34 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 08:40:42 -0000 Konstantin Belousov gmail.com> writes: > On Sun, Jul 24, 2016 at 03:04:34AM +0000, Julian Hsiao wrote: > >> The fsync(1) utility is a simple wrapper around fsync(2), but I didn't >> find a similar utility for calling ioctl(DIOCGFLUSH) for character >> devices. > > It is not similar in any reasonable interpretation of the word. Would you agree that fsync(1) is to fsync(2) as printf(1) is to printf(3)? If so, they are "similar" in the sense that they are wrappers of functions they're named after. There's no ioctl(1) AFAIK. >> fsync(2) is a no-op on character device files, which is a little >> surprising but makes sense I suppose (would raising EINVAL be against >> POSIX?). > > POSIX does not mention special nodes at all, so the implementation is > free to do whatever it wants/needs. Right, I'm just half wondering out loud why it doesn't raise EINVAL. Hmm, I suppose prior to devfs(5), calling fsync on device files could be meaningful. >> However, conceptually the goal is the same: commit writes to permanent >> storage, so here's a small patch to fsync(1) that calls >> ioctl(DIOCGFLUSH) for character device files instead. > > This ioctl() does not perform what you describe, at least not on the > level of the buffer cache/page cache for the device. It is the duty of > the filesystem (or other in-kernel consumer) to ensure that cache is > flushed when needed. > > The ioctl only sends BIO_FLUSH command to the driver, which does > something to the hardware. Often this 'something' is either nop or have > no observable implications. > > That said, I do not see the proposed change as useful. Yes, I understand the distinction. One flushes the kernel buffer cache, while the other flushes the hardware cache, lying HBAs / HDDs / SSDs notwithstanding. I was looking for a quick way to test BIO_FLUSH in my own code, and I was too lazy^W^Wdidn't have time (nor need) to write a full-blown ioctl(1) utility. So it's useful to me, and I thought maybe some people would too, so thought I'd share. I figure the audience of fsync(1) wouldn't be confused by the overloading. Julian Hsiao From owner-freebsd-hackers@freebsd.org Wed Jul 27 06:46:02 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 473F7BA5084 for ; Wed, 27 Jul 2016 06:46:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 668151C0C; Wed, 27 Jul 2016 06:46:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA18030; Wed, 27 Jul 2016 09:45:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bSIbJ-000D8N-1U; Wed, 27 Jul 2016 09:45:53 +0300 To: Dimitry Andric , "freebsd-hackers@freebsd.org" From: Andriy Gapon Subject: problem when compiling zfs.ko with clang with O1 on amd64 Message-ID: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> Date: Wed, 27 Jul 2016 09:44:56 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 06:46:02 -0000 First of all, what I describe next happens only when compiling with -O1 which is a non-standard option that I used to get better debugging. So, I compile zfs module with clang on amd64 head. Clang is: FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) When -O1 is used I see that statements like 'T x = { 0 };' are translated to calls to external memset function with the standard arguments. On the other hand, since recently a few ZFS source files (all hash related: sha256c.c, sha512c.c, skein.c) have explicit calls to memset(x, 0, s). Those get inlined but in a particular fashion: a local memset function is generated in each file, the function is a very thin wrapper around bzero and it expects the same argument as bzero. Because of how kernel loadable modules are implemented on amd64 the external calls to memset get resolved to the first of the local functions. Because of the mismatch between the arguments provided and the arguments expected the effective calls are 'bzero(x, 0)', NOPs that is. I am not sure if I can blame clang here. It is probably correct to expect that it can generate a _local_ function named 'memset' without interfering without other compilation units. However, that can be unhelpful as we can see. Some data: $ nm -A --defined-only *.o | fgrep -w memset sha256c.o:0000000000000e60 t memset sha512c.o:00000000000010f0 t memset skein.o:0000000000000120 t memset $ nm /boot/kernel.z/zfs.ko | fgrep -w memset 0000000000019030 t memset 0000000000017e60 t memset 0000000000019500 t memset U memset Assembly of one of the local memset functions: .align 16, 0x90 .type memset, @function memset: # @memset .Lfunc_begin6: .file 5 "/usr/src/sys/sys" "libkern.h" .loc 5 187 0 # /usr/src/sys/sys/libkern.h:187:0 .cfi_startproc # BB#0: # %entry pushq %rbp .Ltmp105: .cfi_def_cfa_offset 16 .Ltmp106: .cfi_offset %rbp, -16 movq %rsp, %rbp .Ltmp107: .cfi_def_cfa_register %rbp #DEBUG_VALUE: memset:c <- 0 .loc 5 191 3 prologue_end # /usr/src/sys/sys/libkern.h:191:3 .Ltmp108: popq %rbp jmp bzero # TAILCALL .Ltmp109: .Lfunc_end6: .size memset, .Lfunc_end6-memset .cfi_endproc -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Jul 27 09:46:33 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76E79BA6BF0 for ; Wed, 27 Jul 2016 09:46:33 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id CFECF1B02 for ; Wed, 27 Jul 2016 09:46:32 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 47830 invoked by uid 907); 27 Jul 2016 09:46:31 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (203.14.245.130) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Wed, 27 Jul 2016 19:46:31 +1000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: problem when compiling zfs.ko with clang with O1 on amd64 From: Jan Mikkelsen In-Reply-To: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> Date: Wed, 27 Jul 2016 19:46:31 +1000 Cc: Dimitry Andric , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <67459C58-6E85-467A-803A-1E67243E9AC5@transactionware.com> References: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 09:46:33 -0000 Hi, (Resend because I was subscribed with the wrong address =E2=80=A6) Yes, there is serious namespace pollution in the amd64 kernel linker. = File statics are like globals but without multiple definition detection. = I find this a bit scary. See this thread for an example that affected me about a year ago: https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082751.html There are lots of possible silent failures here. Static functions with = the same name, as you have discovered. Static variables silently being = shared. The easiest solution I saw was decorating the local names to avoid a = clash. I started looking at it as a post kernel module link step but = couldn=E2=80=99t dedicate the time to get far enough. Regards, Jan. > On 27 Jul 2016, at 16:44, Andriy Gapon wrote: >=20 >=20 > First of all, what I describe next happens only when compiling with = -O1 > which is a non-standard option that I used to get better debugging. >=20 > So, I compile zfs module with clang on amd64 head. > Clang is: > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) >=20 > When -O1 is used I see that statements like 'T x =3D { 0 };' are > translated to calls to external memset function with the standard = arguments. >=20 > On the other hand, since recently a few ZFS source files (all hash > related: sha256c.c, sha512c.c, skein.c) have explicit calls to = memset(x, > 0, s). Those get inlined but in a particular fashion: a local memset > function is generated in each file, the function is a very thin = wrapper > around bzero and it expects the same argument as bzero. >=20 > Because of how kernel loadable modules are implemented on amd64 the > external calls to memset get resolved to the first of the local > functions. Because of the mismatch between the arguments provided and > the arguments expected the effective calls are 'bzero(x, 0)', NOPs = that is. >=20 > I am not sure if I can blame clang here. It is probably correct to > expect that it can generate a _local_ function named 'memset' without > interfering without other compilation units. However, that can be > unhelpful as we can see. >=20 > Some data: > $ nm -A --defined-only *.o | fgrep -w memset > sha256c.o:0000000000000e60 t memset > sha512c.o:00000000000010f0 t memset > skein.o:0000000000000120 t memset >=20 > $ nm /boot/kernel.z/zfs.ko | fgrep -w memset > 0000000000019030 t memset > 0000000000017e60 t memset > 0000000000019500 t memset > U memset >=20 >=20 > Assembly of one of the local memset functions: > .align 16, 0x90 > .type memset, @function >=20 > memset: > # @memset > .Lfunc_begin6: > .file 5 "/usr/src/sys/sys" "libkern.h" > .loc 5 187 0 # /usr/src/sys/sys/libkern.h:187:0 > .cfi_startproc >=20 > # BB#0: # %entry > pushq %rbp >=20 > .Ltmp105: > .cfi_def_cfa_offset 16 >=20 > .Ltmp106: > .cfi_offset %rbp, -16 > movq %rsp, %rbp >=20 > .Ltmp107: > .cfi_def_cfa_register %rbp >=20 > #DEBUG_VALUE: memset:c <- 0 > .loc 5 191 3 prologue_end # /usr/src/sys/sys/libkern.h:191:3 >=20 > .Ltmp108: > popq %rbp > jmp bzero # TAILCALL >=20 > .Ltmp109: > .Lfunc_end6: > .size memset, .Lfunc_end6-memset > .cfi_endproc >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Jul 27 09:31:37 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16185BA6997 for ; Wed, 27 Jul 2016 09:31:37 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 95A65168F for ; Wed, 27 Jul 2016 09:31:35 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 42917 invoked by uid 907); 27 Jul 2016 09:24:51 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (203.14.245.130) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Wed, 27 Jul 2016 19:24:51 +1000 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: problem when compiling zfs.ko with clang with O1 on amd64 From: Jan Mikkelsen In-Reply-To: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> Date: Wed, 27 Jul 2016 19:24:51 +1000 Cc: Dimitry Andric , "freebsd-hackers@freebsd.org" Message-Id: <39ABE4A1-70C6-4096-AF1D-97495F0D2BE6@transactionware.com> References: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Wed, 27 Jul 2016 11:04:52 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 09:31:37 -0000 Hi, Yes, there is serious namespace pollution in the amd64 kernel linker. = File statics are like globals but without multiple definition detection. = I find this a bit scary. See this thread for an example that affected me about a year ago: = https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D395455+0+archive/2015/free= bsd-stable/20150719.freebsd-stable = There are lots of possible silent failures here. Static functions with = the same name, as you have discovered. Static variables silently being = shared. The easiest solution I saw was decorating the local names to avoid a = clash. I started looking at it as a post kernel module link step but = couldn=E2=80=99t dedicate the time to get far enough. Regards, Jan. > On 27 Jul 2016, at 16:44, Andriy Gapon wrote: >=20 >=20 > First of all, what I describe next happens only when compiling with = -O1 > which is a non-standard option that I used to get better debugging. >=20 > So, I compile zfs module with clang on amd64 head. > Clang is: > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) >=20 > When -O1 is used I see that statements like 'T x =3D { 0 };' are > translated to calls to external memset function with the standard = arguments. >=20 > On the other hand, since recently a few ZFS source files (all hash > related: sha256c.c, sha512c.c, skein.c) have explicit calls to = memset(x, > 0, s). Those get inlined but in a particular fashion: a local memset > function is generated in each file, the function is a very thin = wrapper > around bzero and it expects the same argument as bzero. >=20 > Because of how kernel loadable modules are implemented on amd64 the > external calls to memset get resolved to the first of the local > functions. Because of the mismatch between the arguments provided and > the arguments expected the effective calls are 'bzero(x, 0)', NOPs = that is. >=20 > I am not sure if I can blame clang here. It is probably correct to > expect that it can generate a _local_ function named 'memset' without > interfering without other compilation units. However, that can be > unhelpful as we can see. >=20 > Some data: > $ nm -A --defined-only *.o | fgrep -w memset > sha256c.o:0000000000000e60 t memset > sha512c.o:00000000000010f0 t memset > skein.o:0000000000000120 t memset >=20 > $ nm /boot/kernel.z/zfs.ko | fgrep -w memset > 0000000000019030 t memset > 0000000000017e60 t memset > 0000000000019500 t memset > U memset >=20 >=20 > Assembly of one of the local memset functions: > .align 16, 0x90 > .type memset, @function >=20 > memset: > # @memset > .Lfunc_begin6: > .file 5 "/usr/src/sys/sys" "libkern.h" > .loc 5 187 0 # /usr/src/sys/sys/libkern.h:187:0 > .cfi_startproc >=20 > # BB#0: # %entry > pushq %rbp >=20 > .Ltmp105: > .cfi_def_cfa_offset 16 >=20 > .Ltmp106: > .cfi_offset %rbp, -16 > movq %rsp, %rbp >=20 > .Ltmp107: > .cfi_def_cfa_register %rbp >=20 > #DEBUG_VALUE: memset:c <- 0 > .loc 5 191 3 prologue_end # /usr/src/sys/sys/libkern.h:191:3 >=20 > .Ltmp108: > popq %rbp > jmp bzero # TAILCALL >=20 > .Ltmp109: > .Lfunc_end6: > .size memset, .Lfunc_end6-memset > .cfi_endproc >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Jul 28 03:02:08 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F965BA6978; Thu, 28 Jul 2016 03:02:08 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9247316B0; Thu, 28 Jul 2016 03:02:07 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-b4bff70000004c44-60-579975ac2974 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id BD.6E.19524.CA579975; Wed, 27 Jul 2016 23:02:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u6S3237a013193; Wed, 27 Jul 2016 23:02:03 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u6S320N8003579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2016 23:02:02 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u6S31x5M028228; Wed, 27 Jul 2016 23:01:59 -0400 (EDT) Date: Wed, 27 Jul 2016 23:01:59 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@FreeBSD.org cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2016 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixCmqrbumdGa4wYqDkhZz3nxgsti++R+j xeFmIQdmjxmf5rMEMEZx2aSk5mSWpRbp2yVwZTzd3spS8PQYS8XbZWeYGxi/H2XuYuTkkBAw kfi4tpsdxBYSaGOS+Hm3pouRC8jeyCgx4/ciVgjnEJPE9J+v2CCcBkaJhicXWEFaWAS0JW4v /8QEYrMJqEmsX3ENaqyixOZTk8BsEQF5iX1N78FWMAtYS7SsfAHWKyxgJ9HZ+YsNxOYVcJA4 d+42mC0qoCOxev8UFoi4oMTJmU+AbA6gXn+JD+fiJzDyz0KSmYWQmQW2QFfizaqDTBC2tsT9 m21sCxhZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgQFKruL8g7Gl33ehxgF OBiVeHgfPJ4RLsSaWFZcmXuIUZKDSUmUNyx0ZrgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7b BUA53pTEyqrUonyYlDQHi5I47/Zv7eFCAumJJanZqakFqUUwWRkODiUJ3tgSoEbBotT01Iq0 zJwShDQTByfIcB6g4clFIMOLCxJzizPTIfKnGMM5Hk27tpaJ49jcG0BywcKbQHLbyjtA8t/r eyCRKfeB5Bow+WwqkBRiSS9KrJQS511fDDROAGRcRmke3EZw0trNpPqKURwYAMK8e0AO4wEm PLidr4DOYQI6pzh2Bsg5JYkIKakGRu7r99689563aOGi/cpxbYvn9a9fEO35Tt3ix78T2zYq 3WGR/Bz1rPPu8ilnNnw+qb92StvjI933Jxh+F3j7L7Qh8VNV94aj8YULXpZHpfRwun45mXbH v21CmfbR3mtO1qnl4R8rSlqFXzC+uJ90bdKyvN1zkxbrqKw54i1zIMnJQG/uVOZzV+2UWIoz Eg21mIuKEwGxVWWaNQMAAA== Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 03:02:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report - Second Quarter 2016 Now available: the 2016Q2 model of the FreeBSD Project Status Report! This quarter brings several exciting improvements over previous models. We have enhancements from different teams, new features like robust mutexes and support for full disk encryption with GELI. You'll find expanded graphics support, both at the chipset and window manager levels, and ongoing development in many pending features. Perhaps most exciting, under the hood you'll find a brand-new Core Team. Don't wait. Take FreeBSD for a spin today. --Michael W. Lucas __________________________________________________________________ Please submit status reports for the third quarter of 2016 by October 7. __________________________________________________________________ FreeBSD Team Reports * FreeBSD IRC Admin Team * FreeBSD Issue Triage Team * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation Projects * ASLR Interim State * Ceph on FreeBSD * EFI Refactoring and GELI Support * Robust Mutexes * The Graphics Stack on FreeBSD Kernel * ARM Allwinner SoC Support * FreeBSD on Hyper-V and Azure * VIMAGE Virtualized Network Stack Update Architectures * FreeBSD/arm64 Userland Programs * Reproducible Builds in FreeBSD * Updates to GDB * Using lld, the LLVM Linker, to Link FreeBSD Ports * Bringing GitLab into the Ports Collection * GNOME on FreeBSD * Intel Networking Tools * IPv6 Promotion Campaign * KDE on FreeBSD * Obsoleting Rails 3 __________________________________________________________________ FreeBSD Team Reports FreeBSD IRC Admin Team Links FreeBSD IRC Wiki URL: https://wiki.FreeBSD.org/IRC/ Contact: IRC Admin Team Contact: Kubilay Kocak Contact: Eitan Adler The FreeBSD IRC Admin team manages the FreeBSD Project's IRC presence on the freenode IRC network, looking after: * Registrations and ongoing management of channels within the official namespace (#freebsd*). * Liaising with freenode staff. * Allocating freebsd hostmask cloaks for users. * General user support. In order to facilitate a constructive and positive environment for all members of the FreeBSD community, IRC Admin over the past 3-9 months has established and consolidated a consistent baseline with respect to the management of its channels on freenode. This report is a summary of what has happened so far and things to come. These activities were completed over the last few quarters: * Registered FreeBSD Group Contacts (GC) with freenode staff. For information on what this means, see the group registration page. * Created a FreeBSD NickServ account to assign as primary owner/founder of the #freebsd* namespace channels. * The primary channels are owned/founded by a generic FreeBSD account that is owned and managed by the FreeBSD Project. * Created the Services::IRC component in Bugzilla for change requests and issue reports. * Obtained a report of all registered freenode channels matching the #freebsd* namespace and assessed the list for current ownership and activity status. * Assigned freebsd/ user cloaks to users requesting them. For more information, see IRC Cloaks. * Obtained a report on all nicknames and accounts with existing freebsd/* user cloaks. * Liaised with freenode staff on upcoming changes to freebsd channels. The goals for the next few quarters are to: * Complete the transfer of founder ownership for all #freebsd* channels. Existing channel creators, some of whom are project members and others who are not, will be contacted using known contact information or contact information set in their registered NickServ account, in order to initiate the transfer of the channel to the FreeBSD Project. If the contact information of the existing channel owner cannot be obtained, or if no response is received after a suitable period of time has elapsed, IRC Admin will complete the ownership transfer with freenode staff. * Deregister defunct and inactive #freebsd* channels. Channels which have no visible signs of activity based on last active time or registered owner last seen, have been deprecated by alternative channels, or have no other way of having ownership transferred will be deregistered. For channels where a sunset period may be suitable, a channel topic will be set, and optionally a forwarding channel, informing users of the changes, including support and contact information. * Create and document baseline procedures and guidelines. These include: Community and User Guidelines, a Code of Conduct, Operator and Moderator Guidelines and Expectations, Abuse Reporting and Dispute Resolution Guidelines, and procedures for delegation of channel management. * Standardize and re-create channel access lists. Existing access lists and user permissions for all #freebsd* channels remain in their states prior to FreeBSD Group Registration. Consolidation and reassignment to the FreeBSD Project is needed. In order to ensure a consistent user and community experience in official FreeBSD channels going forward, access lists for all channels will be created from the ground up. Users with existing access to channels may, at the IRC Admin team's discretion, be provided with the opportunity to re-apply for access subject to any conditions, terms, or guidelines that may be appropriate. * Determine the methods for informing project members and the community of future changes to IRC services, procedures, and policies. * Determine methods to designate existing channel founders as channel managers or similar. * Update the channels list on the Wiki to distinguish official and unofficial channels. * Establish consistent modes, entry messages, and topics for all channels. Users are invited to /join #freebsd-irc on the freenode IRC network. The IRC Admin team welcomes ideas, contructive criticism, and feedback on how the FreeBSD Project can improve the service and experience it provides to the community. While the vast majority of the broader community interacts on the freenode IRC network, the FreeBSD developer presence there needs to be significantly improved. There are many opportunities to be had by increasing the amount and quality of interaction between FreeBSD users and developers, both in terms of developers keeping their finger on the pulse of the community and in encouraging and cultivating greater contributions to the Project over the long term. It is critical to have a strong developer presence amongst users, and IRC Admin would like to call on all developers to join the FreeBSD freenode channels to help support that presence. We are the FreeBSD giants on whose shoulders the future contributors stand. It is important to be there, in force. __________________________________________________________________ FreeBSD Issue Triage Team Contact: Vladimir Krstulja Contact: Kubilay Kocak Contact: Bugmeister Since the Triage Team was introduced in the October-December 2015 report, it has been working on the following three major aspects of issue triage: * Recruiting and educating more users to assist in issue triage. * Identifying problem areas, especially from the fresh eyes perspective, revealing issues not immediately obvious to contributors with experience. * Proposing changes to improve the issue triage process. Our efforts have almost exclusively focused on issues in the "Ports & Packages" component as that is the easiest starting point. Other categories like "Base System" require more knowledge and experience with problem content and workflow. During this time, Rodrigo was inactive due to lack of available time, and Vladimir was unable to commit enough time during the first quarter of the year, but provided active contribution during the second. It became obvious that the Issue Triage Team must concentrate on additional recruitment in the coming quarter. In the last two quarters, several problems were identified and the formulated solutions will be published on our upcoming Wiki page. A summary of those issues is given here: 1. Issue triage, defined as "ensure that an issue is summarized, classified, and assigned to appropriate people", is too time consuming. Bugzilla automation through auto-assign helps, but is insufficient. If the triage process is extended to include "track the issue through its entire life to resolution", the time and effort required grows exponentially. Fortunately, there are many things the community can do, with minimum effort, that help greatly. Part of the recruitment and education process is educating users on how to properly treat their own issues and issues they interact with, in order to maximize the efficiency of issue tracking and problem resolution. 2. Various timeouts are inadequate. For example, the maintainer timeout is too long and does not differentiate between classes of issues, such as a non-security and a security timeout. Other timeouts are not covered, such as assignee timeouts, when an issue has been assigned with no follow-up activity. Another example is a timeout where additional information was requested but never provided. We will be recommending several changes and documenting these in our Wiki. 3. Partially as a consequence of inadequate timeouts and inadequate ability to efficiently track issues through their entire lifecycle, a great number of issues are open for too long. We have identified several classes of those issues and will document the solutions to each in the near future. 4. Bugzilla is not perfect and at times it can hinder the ability to properly track issues clearly and accurately, in order to resolve them quickly. However, changing bug tracking software is a tremendous effort, so we will instead recommend technical and workflow improvements in order to improve the user experience as much as possible. For example, we identified additional saved searches to help track and quickly find issue categories and, more importantly, their states. Another example is ensuring that various flags and keywords are unambiguous and well understood. For instance, "patch" and "patch-ready" can often be misunderstood or misapplied. 5. Issue statistics are lacking, and for the next quarter we intend to change that. Statistics help to provide insight into potential bottlenecks and inform the prioritization of improvements to the issue tracker and workflows. Open tasks: 1. Recruit more suitable triagers into the team, both committers and community members. 2. Gather and present some interesting statistics for the next report. 3. Set up the Wiki page with identified problems and recommended guidelines and policies. 4. Find common use patterns and add more saved searches to Bugzilla. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 10.3-RELEASE schedule URL: https://www.FreeBSD.org/releases/10.3R/schedule.html FreeBSD 11.0-RELEASE schedule URL: https://www.FreeBSD.org/releases/11.0R/schedule.html FreeBSD Development Snapshots URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team completed the 10.3-RELEASE cycle late April, led by Marius Strobl. The release was one week behind the original schedule, to accommodate for a few last-minute critical issues that were essential to fix in the final release. The FreeBSD 11.0-RELEASE cycle started late May, one month behind the original schedule. The schedule slip was primarily to accommodate efforts for packaging the FreeBSD base system with the pkg(8) utility. However, as work on this progressed, it became apparent that there were too many outstanding issues. As a result, packaged base will be a "beta" feature for 11.0-RELEASE, with the goal of promoting it to a first-class feature in 11.1-RELEASE. It is expected that provisions will be made to ensure a seamless transition from older supported releases. Despite the fact that packaged base is not going to be a prime feature for FreeBSD 11.0-RELEASE, the Release Engineering Team would like to thank everyone who tested, provided patches, provided ideas and feedback, and in some cases, shot themselves in the foot due to bugs. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ports Collection Links FreeBSD Ports Website URL: https://www.FreeBSD.org/ports/ How to Contribute URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html Ports Monitoring Website URL: http://portsmon.FreeBSD.org/index.html Ports Management Team Website URL: https://www.FreeBSD.org/portmgr/index.html Ports Management Teamon Twitter URL: https://twitter.com/freebsd_portmgr/ Ports Management Team on Facebook URL: https://www.facebook.com/portmgr Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The 2016Q3 branch of the Ports Tree currently contains over 26,100 ports, with the PR count around 2,000. Of those, around 425 are unassigned. The activity dropped somewhat, with 5,300 commits made by 125 active committers. Almost 1,760 PRs were closed in the last quarter. In the last quarter, we added two new committers: Ben Woods (woodsb02) and Torsten Z=FChlsdorff (tz). No commit bits were taken in for safe keeping. On the management side, mat took over the role of cluster admin liaison from erwin, who decided to step down from portmgr. rene took over the role of port manager secretary from culot. No other changes were made. A lot of work was done on modernizing the infrastructure of the Ports Tree, by introducing 6 new USES knobs, one new keyword, and splitting out the larger targets of bsd.port.mk into separate scripts. There were a total of 42 exp-runs to validate these and other infrastructure changes and package updates. Furthermore, checks were added to the quality assurance phase of Poudriere to check for missing indirect dependencies, and advancements were made for reproducable package builds. Some noticeable package updates are: Firefox 47.0.1, Firefox ESR 45.2.0, Thunderbird 45.1.1, Chromium 51.0.2704.106, Ruby 2.2.5, Ruby Gems 2.6.2, pkg 1.8.6, gmake 4.2.1, KDE 4.14.10, Python 2.7.12, libc++ 3.8.0, and binutils 2.26. Behind the scenes, antoine made sure that the exp-run- and package builders were kept up-to-date. bdrewery worked on further automating and hardening the package building infrastructure. During BSDCan, mat worked on various items, including updating the Porter's Handbook, and portmgr held a meeting to discuss various items. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The highlight of Core's second quarter has been the regular biennial election of a new Core team. Core would like to thank Dag-Erling Sm=F8grav and Glen Barber for running the vote. Despite an initially slo= w uptake on nominations, fourteen candidates eventually stood, including four incumbent members of core. The ninth FreeBSD Core team will be: * John Baldwin * Baptiste Daroussin * Allan Jude * Ed Maste * Kris Moore * George V. Neville-Neil * Benedict Reuschling * Benno Rice * Hiroki Sato The new Core Team would like to thank the departing members for their many years of service. Members stepping down are: * Gavin Atkinson * Gleb Smirnoff * David Chisnall * Robert Watson * Peter Wemm The second most notable achievement this quarter was the successful conclusion of an issue that had been on Core's agenda for many years. With the creation of planet.FreeBSD.org, the FreeBSD Project finally has an official blog aggregation service. Core spent a significant amount of time reviewing licensing and ensuring that the FreeBSD source remains unencumbered by onerous license terms. This quarter involved approving Adrian Chadd's plan to import GPLv2 licensed code, allowing bwn(4) to be built as a loadable module with support for 802.11n networking. This required confirmation that the license terms on the latest dummynet AQM patches were acceptable and that its variant on the BSD 2-clause license is suitable for use in the FreeBSD base system. Core applied for, and received, a project-wide license for the use of the JetBrains static analysis tool suite, at the behest of Mathieu Previot. Another of Core's important functions is to ensure good relations amongst developers. To that end, members of Core provided oversight over the backing-out of disputed blacklistd-related patches to OpenSSH, and acted to smooth over ruffled tempers. This quarter saw the usual quota of gentle reminders to avoid intemperate language and other counter-productive behavior. Core had to take immediate action about death threats appearing on some of the mailing lists. The culprit was immediately banned from the mailing lists and reported to their email service provider. That person will be similarly removed should they be identified as having rejoined under a different alias. Other activities included: * Working with university authorities in an attempt to get documentation certifying that a prospective GSoC student was legally allowed to work on FreeBSD code as a foreigner enrolled at a USA university. This issue was eventually solved by the student returning home for the summer and working from there. * Issuing guidance on policy around forced commits, or trivial changes used as a means of correcting a commit message. In these cases, the correct approach is to revert the commit and re-commit with the correct message. This ensures the continuing usefulness of svn blame. * Approving a delay to the planned introduction of packaged base and confirming that this did not require any change to the new support policies to be introduced with 11.0-RELEASE. During this quarter, four new commit bits were awarded and none were taken in. Please welcome Emmanuel Vadot, Landon Fuller, Mike Karels, and Eric Badger as new src committers. Yes, that is the same Mike Karels who was once a member of the CSRG at Berkeley and co-author of The Design and Implementation of the 4.3BSD UNIX Operating System. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.freebsdfoundation.org/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Our work is 100% funded by your donations. Our spending budget for 2016 is $1,250,000 and we've raised $265,000 so far. Our Q1-Q2 financial reports will be posted by August 1. As you can see, we need your donations to continue supporting FreeBSD at our current level. Please consider making a donation here: freebsdfoundation.org/donate. OS Improvements The Foundation improves FreeBSD by funding software development projects approved through our proposal submission process, and our internal software developer staff members. Two Foundation-funded projects continued last quarter; one project is to improve the stability of the vnet network stack virtualization infrastructure, and the second is phase two of the FreeBSD/arm64 port project. Foundation staff members were responsible for many changes over the quarter. Kostik Belousov accomplished the following work last quarter: implemented robust mutexes support, as part of ongoing efforts to bring our threading library into POSIX compliance and feature completeness; documented kernel interfaces used by the threading library and produced almost 30 pages of technical text; completed and committed the elimination of the pvh_global_lock from the amd64 pmap, which removed a hot contested lock; and fixed bugs that help keep FreeBSD stable and reliable. Edward Napierala accomplished the following work last quarter: added filesystem thoughput limits to RCTL; committed iSER initiator support; added support for rerooting into NFS; and added iscsictl -e, which makes it possible to enable and disable iSCSI sessions. Ed Maste, our Project Development Director, accomplished the following work last quarter: investigated the state of reproducible builds in the ports tree, with some work in progress to address issues; updated the ELF Tool Chain tools with bug fixes and improved handling of malformed input; investigated using lld, the linker from the LLVM family, to link the FreeBSD base system; and reported on and tested patches for issues found. He also managed the arm64 development project and investigated and fixed a number of bugs. Lastly, he imported LLVM's libunwind and prepared it for use in FreeBSD 11, and investigated and reviewed the blacklistd proposal and patches. George Neville-Neil continued hosting the bi-weekly Transport conference call (notes at https://wiki.FreeBSD.org/TransportProtocols) and the bi-weekly DTrace conference call (notes at https://wiki.FreeBSD.org/DTrace. Ed continued facilitating the bi-weekly graphics call to coordinate efforts on the i915 driver and other graphics stack work. Several of these projects are described elsewhere in this quarterly report. Release Engineering Foundation employee and release engineer Glen Barber worked closely with Marius Strobl on the 10.3-RELEASE, which was completed in April. Glen also merged the release-pkg branch to 11-CURRENT, though this will be a beta feature for 11.0-RELEASE. Lastly, with the Release Engineering Team, he started the 11.0-RELEASE cycle. Find out more in the Release Engineering Team status entry in this report. "Getting Started with FreeBSD" Project We hired a summer intern, with no FreeBSD, Linux, or any command line operating system experience, to figure out on his own how to install and use FreeBSD. He is writing easy-to-follow how-to guides to help make the new user experience straightforward and positive. He's also been submitting bug reports and problems through the appropriate channels. You can check out his first how-to guide at https://www.freebsdfoundation.org/freebsd/how-to-guides/. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. Some of the work we did last quarter to support FreeBSD advocacy included: Creating a FreeBSD page on our website to promote FreeBSD derivative projects and showcase FreeBSD users (https://www.freebsdfoundation.org/freebsd/), and promoting FreeBSD research by creating a Research page on our site and conference handout (https://www.freebsdfoundation.org/what-we-do/research/). We created guidelines and a repository for using the Project and Foundation logos (https://www.freebsdfoundation.org/about/brand-assets/). To help showcase FreeBSD contributors, we published two new Faces of FreeBSD stories, about Michael Lucas (https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-michael-lu= cas/) and Kris Moore https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-kris-moore/= ). We published the March/April and May/June issues of the FreeBSD Journal and participated in editorial board work. Kirk McKusick wrote a feature article on the Fast Filesystem for the March/April issue, and other team members helped review and edit Journal articles. We also published monthly newsletters to highlight work being done to support FreeBSD, tell you about upcoming events, and provide other information to keep you in the loop on what we're doing to support the FreeBSD Project and community. George Neville-Neil and Robert Watson continued teaching and developing open source FreeBSD teaching materials at teachbsd.org. We launched the first Hosting Partner Spotlight to showcase the Project's partnership with NYI (https://www.freebsdfoundation.org/blog/hosting-partner-spotlight-nyi-at= -the-heart-of-freebsd/) We worked with Microsoft to get FreeBSD onto Azure (https://www.freebsdfoundation.org/blog/more-from-the-freebsd-foundation= -on-the-projects-partnership-with-microsoft/). The Foundation was quoted in Cavium's Thunder X2 press release (http://www.prnewswire.com/news-releases/cavium-announces-thunderx2-3002= 76536.html George worked with ARM to coordinate the upcoming ARM Partner Meeting in Cambridge. Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness about FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. In April, Benedict Reuschling helped organize and run a hackathon in Essen April 22-24. He then attended the Open Source Datacenter conference in Berlin, with Allan Jude, to give a talk about "Interesting things you can do with ZFS," which highlighted OpenZFS features and how well they work on FreeBSD (https://www.netways.de/index.php?id=3D3445#c44065). We promoted FreeBSD at: * Flourish -- April 1-2 in Chicago (http://flourishconf.com/2016/) * LFNW -- April 23-24 in Bellingham WA (https://www.linuxfestnorthwest.org/2016). * OSCON -- May 18-19 in Austin, TX (http://conferences.oreilly.com/oscon/open-source-us Deb Goodkin and Dru Lavigne attended the Community Leadership Summit in Austin: May 14, 15 (http://www.communityleadershipsummit.com/schedule/) Deb promoted FreeBSD at USENIX ATC June 22-23 in Denver, CO. Our team attended BSDCan and the Ottawa Developer Summit. We held our annual board meeting to vote on officers, board members, and work on our strategic planning. Most of us attended the developer/vendor summits. Kirk McKusick presented "A Brief History of the BSD Fast Filesystem" (http://www.bsdcan.org/2016/schedule/events/654.en.html). Ed Maste gave a presentation on "Reproducible Builds in FreeBSD". George helped run the vendor summit. We sponsored five FreeBSD contributors to attend BSDCan. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. FreeBSD Community Engagement We launched our first Community Survey. The purpose was to get input from the community on why they use FreeBSD, what they'd like to see the Foundation support, and other input to help us determine our direction and how we should support the Project. Anne Dickison, our Marketing Director, has been overseeing the efforts to rewrite the Project's Code of Conduct to help make this a safe, inclusive, and welcoming community. Other Stuff We Did Last quarter we purchased a server to reside at NYI to improve the continuous integration tools within the Project. We had two face-to-face board meetings last quarter to work on strategic planning and identify areas in the project we should support. We also held our first ever staff retreat in Boulder, Colorado to give our small team an opportunity to work together in person. We hired Sabine Percarpio as our Administration Manager. She is helping us manage donations, accounting, travel grant applications, handle questions that come in to the Foundation, and run our organization smoothly. __________________________________________________________________ Projects ASLR Interim State Links Patch Home URL: http://kib.kiev.ua/kib/aslr Contact: Konstantin Belousov This is an interim report on the technical state of my work towards ASLR support in the FreeBSD base system. The proccontrol(1) utility was written to manage and query ASLR enforcement on a per-process basis. It is required for analyzing ASLR failures in specific programs. This utility leverages the procctl(2) interface which was added to the previous version of the patch, with some bug fixes. With r300792, ASLR settings are reset to system-wide defaults whenever a setuid binary is executed. The command's syntax is: proccontrol -m (trace|aslr) [-q] [-s (enable|disable)] [-p pid | command] with possible arguments -m (specifies the trace mode to control debugger attachments) -q (queries the state of the specified mode for the process with the PID specified by the -p option) -s (toggles the feature on or off for the given process or itself) If a command is specified, it inherits the applied settings from proccontrol. For instance, to start a build of a program with ASLR disabled, use proccontrol -m aslr -s disable make. A ports exp-run was done with ASLR tuned up to the most aggressive settings. The results can be found in PR 208580. Case study: Lisp SBCL is an interesting case which illustrates several points. It is much smaller than JDK, and its build system is easier to work with. The code provides a very non C-like language runtime which utilizes a lot of corner cases and makes non-standard uses of the VM system, at least from the point of view of a typical C programmer. SBCL compiles Lisp forms into the machine native code and manages its own arena for objects. The precompiled Lisp runtime is mapped from a core file. SBCL relies on the operating system's C runtime for the initial load of Lisp, and needs a functional libc to issue many system calls, including syscalls, as well as the dynamic loader. The end result is that there are unfixed mmap(2) calls during both startup and runtime, interfering with other MAP_FIXED mmaps. The loading of the core file and the private arenas are hard-coded to exist at fixed addresses. This happens to work on the default address map, which is not changed often, so the SBCL choices of the base addresses evolved to work. But any significant distortion of the standard map results in SBCL mmap(MAP_FIXED) requests attempting to override memory from other allocators. FreeBSD uses the MAP_EXCL flag to mmap(2), which must be used in the form MAP_FIXED|MAP_EXCL to cause mmap(2) to fail if the requested range is already used. I tried to force MAP_FIXED requests from SBCL to implicitly set MAP_EXCL, but this did not go well, since SBCL sometimes pre-allocates regions for later use with MAP_FIXED. So, MAP_EXCL mappings failed, dumping the process into ldb. On Linux, if it is detected that the kernel is in AS-randomization mode, the initial SBCL runtime sets its personality to non-random and re-execs. This might be a solution for FreeBSD as well, after the ASLR patch is committed, so that the procctl(2) knob is officially available. SBCL still has issues on Linux, even with re-exec, when more aggressive randomization from the PaX patch is applied, as seen in bug 1523213. Case study: Emacs The Emacs build procedure involves loading the temacs image with the compiled Emacs Lisp files and then dumping its memory to create an image with the content preloaded, in order to reduce startup time. Recent Emacs sources seem to generally avoid MAP_FIXED, except in some situations. When Emacs does use the flag, it carefully checks that the selected region is not busy. In fact, Emacs would benefit from using MAP_EXCL. I tried several runs of building Emacs and running the dumped binary, but was not able to reproduce any issues. It seems that the code improved enough to tolerate ASLR both in Linux and NetBSD without turning it off. In my opinion, it is not reasonable to fight the issues in the kernel as most of it is not fixable from the kernel side. The procctl(2) interface and proccontrol(1) utilities provide an override when needed, but are not automated. Conclusions The set of ports which cannot be built with ASLR turned on should be limited but fluid. However, exp-runs may not reliably uncover all problems due to randomization, as seen in the Emacs example. In the route to enable ASLR by default (with non-aggressive settings), the ports framework should provide an option like ASLR_UNSAFE=3Dyes which spawns proccontrol -m aslr -s disable make for the build stages of the unsafe port. Users would still need to be aware of proccontrol(1) in order to run the resulting binary or wrapper scripts provided to do so. A recommended approach is a flag in the ELF binary to mark it as not compatible with non-standard AS layouts. This frees users from having to use proccontrol(1), but still requires patching the application's build process and upstreaming the changes. This approach is also useful outside the context of ASLR. However, that mechanism is not yet ready, and developing it is a larger work than ASLR itself. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My Fork URL: https://github.com/wjwithagen/ceph Pull Request With FreeBSD-Specific Changes to Ceph URL: https://github.com/ceph/ceph/pull/7573 Contact: Willem Jan Withagen Ceph is a distributed object store and filesystem designed to provide excellent performance, reliability, and scalability. It provides the following features: 1. Object Storage: Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. 2. Block Storage: Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. 3. File System: Ceph provides a POSIX-compliant network filesystem that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because using HAST with CARP and ggate did not meet my requirements. My primary goal with Ceph is to run a storage cluster of ZFS storage nodes where the clients run bhyve on RBD disks stored in Ceph. The FreeBSD build process can build most of the tools in Ceph. However, the RBD-dependent items do not work, since FreeBSD does not yet provide RBD support. Since the last quarterly report, the following progress was made: 1. Switching to using CMake from Automake results in a much cleaner development environment and better test output. The changes can be found in the wip-wjw-freebsd-cmake branch. 2. The throttling code has been overhauled to prevent live locks. These mainly occur on FreeBSD but also manifest on Linux. 3. A few more tests were fixed. On one occasion, I was able to complete the full test suite without errors. 11-CURRENT is used to compile and build-test Ceph. The Clang toolset needs to be at least version 3.7, as the Clang 3.4 available on stable/10 does not have all of the capabilities required to compile everything. This setup will get things running for FreeBSD: * Install bash and link to it in /bin (requires root privileges): sudo pkg install bash sudo ln -s /usr/local/bin/bash /bin/bash * Build Ceph: git clone https://github.com/wjwithagen/ceph.git cd ceph git checkout wip-wjw-freebsd-tests ./do_freebsd-cmake.sh --deps The --deps argument is only needed for the initial installation, to pull in the necessary dependencies; it should be omitted for subsequent builds. CMake is now used to build Ceph on FreeBSD; the old method using automake is no longer used. Parts Not Yet Included: * RBD: Rados Block Devices are currently implemented in the Linux kernel, but there used to be a userspace implementation. It is possible that ggated could be used as a template, since it provides some of the same functionality and it has a userspace counterpart. * BlueStore: FreeBSD and Linux have a different AIO API which needs to be bridged. There has been some discussion about aio_cancel not working for all device types in FreeBSD. * CephFS: Cython tries to access an internal field in struct dirent, which fails to compile. * Tests that verify the correct functionality of these features are also excluded from the test suite. Tests Not Yet Included: * ceph-detect-init/run-tox.sh: the current implementation does not know anything about FreeBSD's rc system. * Tests that make use of nosetests do not really work since nosetests is not in /usr/bin, and calling /usr/bin/env nosetests does not work on FreeBSD. * test/pybind/test_ceph_argparse.py * test/pybind/test_ceph_daemon.py Open tasks: 1. The current and foremost task is to get the test suite to complete without errors. 2. Build an automated test platform that will build ceph/master on FreeBSD and report the results back to the Ceph developers. This will increase the maintainability of the FreeBSD side of things, as developers are signaled that they are using Linux-isms that will not compile or run on FreeBSD. Ceph has several projects that support this: Jenkins, teuthology, and palpito. But even a while { compile } loop that reports the build data on a static webpage is a good start. 3. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 4. Get the currently excluded Python tests to work. 5. Compile and test the userspace RBD (Rados Block Device). 6. Investigate if an in-kernel RBD device could be developed akin to ggate. 7. Investigate the keystore which currently prevents the building of Cephfs and some other parts. 8. Integrate the FreeBSD /etc/rc.d init scripts in the Ceph stack for testing and for running Ceph on production machines. __________________________________________________________________ EFI Refactoring and GELI Support Links GELI Support Branch URL: https://github.com/emc2/freebsd/tree/geli_efi EFI Refactoring Branch URL: https://github.com/emc2/freebsd/tree/efize Contact: Eric McCorkle The EFI bootloader has undergone considerable refactoring to make more use of the EFI API. The filesystem code in boot1 has been eliminated, and a single codebase for filesystems now serves both boot1 and loader. This codebase is organized around the EFI driver model and it should be possible to export any filesystem implementation as a standalone EFI driver without too much effort. Both boot1 and loader have been refactored to utilize the EFI_SIMPLE_FILE_SYSTEM interface. In the loader, this is accomplished with a dummy filesystem driver that is just a translation layer between the loader filesystem interface and EFI_SIMPLE_FILE_SYSTEM. A reverse translation layer allows the existing filesystem drivers to function as EFI drivers. The EFI refactoring by itself exists in a branch on github. Additionally, GELI support has been added using the EFI refactoring. This allows booting from a GELI-encrypted filesystem. Note that the EFI system partition, which contains boot1, must be a plaintext msdosfs partition. This patch adds an intake buffer to the crypto framework, which allows injection of keys directly into a loaded kernel, without the need to pass them through arguments or environment variables. This patch only uses the intake buffer for EFI GELI support, as legacy BIOS GELI support still uses environment variables. EFI GELI support depends on the efize branch. These patches have been tested and used and should be able to handle use by early adopters. Note that the LOADER_PATH variable has been changed to /boot/loader.tst, to facilitate safe testing. IMPORTANT: As this is an encrypted filesystem patch, an error can potentially leave data inaccessible. It is strongly recommended to use the following procedure for testing: 1. Back up your data! 2. Do not forget to back up your data! 3. Install an EFI shell on the EFI System Partition (ESP). 4. Install the patched boot1 on the ESP to something like /boot/efi/BOOTX64.TST. 5. Install the patched loader to /boot/loader.tst on your machine. 6. Create a GELI partition outside of the normal boot partition. 7. First, try booting /boot/efi/BOOTX64.TST and make sure it properly handles the encrypted partition. 8. Copy a boot environment, including the patched loader, to the encrypted partition. 9. Use the loader prompt to load a kernel from the encrypted partition. 10. Try switching over to an encrypted main partition once everything else is working. Open tasks: 1. Testing is needed. 2. The code will need review, and some style(9) normalization must occur before it goes into FreeBSD. __________________________________________________________________ Robust Mutexes Contact: Konstantin Belousov Contact: Ed Maste Now that process-shared locks are implemented for our POSIX threads implementation, libthr, the only major feature lacking for POSIX compliance is robust mutexes. Robust mutexes allow applications to detect, and theoretically recover from, crashes which occur while modifying the shared state. The supported model is to protect shared state by a pthread_mutex, and the crash is detected as thread termination while owning the mutex. A thread might terminate alone, or it could be killed due to the termination of the containing process. As such, the robust attribute is applicable to both process-private and -shared mutexes. An application must be specifically modified to handle and recover from failures. The pthread_mutex_lock() function may return a new error EOWNERDEAD, which indicates that the previous owner of the lock terminated while still owning the lock. Despite returning this non-zero value, the lock is granted to the caller. In the simplest form, an application may detect the error and refuse to operate until the persistent shared data is recovered, such as by manual reinitialization. More sophisticated applications could try to automatically recover from the condition, in which case pthread_mutex_consistent(3) must be called on the lock before unlocking it. However, such recovery can be considered to be very hard. Still, even the detection of inconsistent shared state is useful, since it avoids further corruption and random faults of the affected application. It is curious but not unexpected that this interface is not used widely. The only real-life application which utilizes it is Samba. Using Samba with an updated FreeBSD base uncovered minor bugs both in the FreeBSD robust mutex implementation, and in Samba itself. It is believed that libthr in FreeBSD 11 is POSIX-compliant for major features. Further work is planned to look at inlining the lock structures to remove overhead and improve the performance of the library. Most of the implementation of the robustness feature consisted of making small changes in the lock and unlock paths, both in libthr and in kern_umtx.c. This literally required reading all of the code dealing with mutexes and condition variables, which was something I wanted to help future developers with. In the end, with the help of Ed Maste, man pages for umtx(2) and all thr*(2) syscalls were written and added to the base system's documentation set. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Use the implementation in real-word applications and report issues. __________________________________________________________________ The Graphics Stack on FreeBSD Links GitHub Repository URL: https://github.com/FreeBSDDesktop/freebsd-base-graphics Graphics Stack Roadmap and Supported Hardware Matrix URL: http://wiki.FreeBSD.org/Graphics Ports Development Repository URL: https://github.com/FreeBSD/freebsd-ports-graphics DRM 4.6 Development Repository URL: https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-n= ext-4.6 GSoC 2016: Link /dev Entries to Sysctl Nodes URL: https://wiki.FreeBSD.org/SummerOfCodeIdeas#Devices_management:_lin= k_.2Fdev_entries_to_sysctl_nodes GSoC 2016: Redesign libdevq URL: https://wiki.FreeBSD.org/SummerOfCode2016/RethinkLibdevq Graphics Team Blog URL: http://planet.FreeBSD.org/graphics Contact: FreeBSD Graphics team Contact: Matthew Macy In the Ports tree, Mesa was updated to 11.2.2. The next major release, 12.0.0 release candidate 4, is ready for testing in our development tree. The GSoC project about being able to connect a /dev entry to sysctl nodes is making progress. After some fruitful discussons on the freebsd-arch@ mailing-list, Kiloreux finished the design and is now implementing the solution. The GSoC project on libdevq was abandoned. All Intel GPUs up to and including the unreleased Kaby Lake are supported. The xf86-video-intel driver will be updated soon. Updating this driver requires updating Xorg, which in turn is blocked on Nvidia updates. Several problems remain to be solved: * There are instances of visual artifacts that appear with varying frequency, depending on workload. Of particular note is the lack of redraw when a Qt5 window is partially covered by a menu and then uncovered. * WebGL demos will sometimes fail due to a recoverable render ring hang. * There are still some known stability issues with processors prior to Sandy Bridge (pre-2010). Matt Macy is hoping to be able to diagnose the first two issues, along with others, by updating Linux support to the point where the Intel GPU Tools work on FreeBSD. The Radeon AMD/ATI driver has been updated to GCN 1.0. This has only been tested on an R7 240. 2D-accelerated X works. Due to apparent issues with user library support, X does not recognize the KMS driver as being 3D-capable and reports it as "not DRI2 capable". The OpenCL benchmark clpeak fails in drm/ttm, so there may in fact be issues in the underlying 3D support. The Amdgpu AMD/ATI driver has been updated to GCN 1.1 and higher. The KMS driver loads and attaches on discrete GPUs, though problems still exist on the Carizzo APU. X will not start due to unimplemented functions in libdrm. Koop Mast is actively working on this and should have it fixed soon. None of the required patches to src/sys were committed in time for FreeBSD 11. Although the plan is to ultimately make linuxkpi, drm, i915, radeon, and amdgpu updates available as ports, this will likely not happen until development has slowed to the point where it is economical to backport them to FreeBSD in svn. Until that time, modern GPU support will be available in PC-BSD snapshots and in the drm-next-4.6 branch on GitHub. __________________________________________________________________ Kernel ARM Allwinner SoC Support Links Allwinner FreeBSD Wiki URL: https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner Contact: Jared McNeill Contact: Emmanuel Vadot Allwinner SoCs are used in multiple hobbyist devboards and single-board computers. Recently, support for these SoCs received many updates. Theses tasks were completed during the second quarter of 2016: * Switch to upstream DTS * A83T SoC support * H3 SoC support * Switch to the new clock framework * Convert the A10 interrupt controller to INTRNG * OHCI support * A generic ALLWINNER kernel config file * A20/A31 NMI support * AXP209 PMU interrupts, GPIO, and sensors support * A83T thermal sensor support * RSB (Reduced Serial Bus) support * AXP813/AXP818 PMU support * A83T Security ID support * Support for the Allwinner Gigabit Ethernet controller found in H3/A83T/A64 * USB OTG (in review) * A10/A20 Security ID support (in review) * A13 SoC Support (in review) Ongoing work: * A64 support * Use U-Boot EFI implementation for ARM32/ARM64 Open tasks: 1. SPI driver 2. LCD Support 3. Any unsupported hardware device that might be of interest. __________________________________________________________________ FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD virtual machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang During BSDCan 2016, Microsoft announced the global availability of FreeBSD 10.3 images in Azure. There are many FreeBSD-based Azure virtual appliances in the Azure Marketplace, including Citrix Systems' NetScaler and Netgate's pfSense. Microsoft also made an in-depth technical presentation to introduce how the performance of the Hyper-V network device driver was optimized to reach full line rate on 10Gb networks and achieved decent performance on 40Gb networks. The slides and video from the presentation are available from the BSDCan website. Microsoft continues to strive to further optimize the performance of Hyper-V network and storage device drivers. Work is ongoing to replace the internal data structure in the LRO kernel API from a singly-linked list to a double-linked list, to speed up the LRO lookup by hash table, and to evaluate the performance with tcp_lro_queue_mbuf(). The handling of SCSI inquiry in the Hyper-V storage driver is enhanced to make sure that disk hotplug and smartctl(8) work reliably. Refer to PR 210425 and PR 209443 for details. BIS test cases are available on GitHub for Hyper-V and for Azure. This project was sponsored by Microsoft. __________________________________________________________________ VIMAGE Virtualized Network Stack Update Links Project Workspace (Now Merged to Head). URL: https://svnweb.FreeBSD.org/base/projects/vnet/ Contact: Bjoern A. Zeeb VIMAGE is a virtualization framework on top of FreeBSD jails that was introduced to the kernel about eight years ago with the vnet virtualized network stack. Over the last few years, many people started to use VIMAGE in production, production-like setups, and appliances. This adoption increased the urgency to finish the work to avoid panics on network stack teardown and to avoid memory leaks. The vnet teardown has been changed to be from top to bottom, trying to tear down layer by layer. This is preferable to removing interfaces first and then cleaning everything up, as no more packets could flow once the interfaces are gone. Along with this work, various paths with potential memory leaks were plugged. Lastly, vnet support was added to formerly unvirtualized components, such as the pf and ipfilter firewalls and some virtual interfaces. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Please test FreeBSD 11.0-ALPHA6 or later. When reporting a problem, use the vimage keyword in the FreeBSD bug tracker. __________________________________________________________________ Architectures FreeBSD/arm64 Links FreeBSD/arm64 Wiki Entry URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner The arm64 pmap code has been updated to work with the full 4 pagetable levels. This allows us to increase the user virtual address space to 256TB, with a concomittant increase of the kernel virtual address space. It also allows an increase in the size of the physical memory FreeBSD can handle to up to 2TB. The interrupt framework has been replaced with intrng on arm64. This allows both arm and arm64 to share interrupt controller drivers, as is the case with the GICv2 driver. The GICv3 ITS driver has been rewritten to better integrate with intrng. Busdma was updated to handle the cache. The updated code assumes that devices are non-coherent by default, unless the device driver marks the DMA tag as coherent when creating it. The generic and ThunderX PCIe drivers have been updated to create coherent mappings when the device tree marks the hardware as coherent. This work also fixed issues found with the sync operation where it was missing memory barriers. A number of issues with hwpmc have been fixed. This improves the stability of hwpmc on arm64, with no known software issues. There is a single known issue which seems to be hardware-related, however, further testing is required. NEW_PCIB has been enabled on arm64. This includes handling the PCI_RES_BUS resource type. Old interfaces replaced before FreeBSD-11 have been removed from the arm64 kernel and libraries. This includes support for compatibility with libc from releases prior to 11.0. The brk and sbrk functions have also been removed. This allows a workaround for these functions in the arm64 C runtime to be removed. loader.efi has been updated to use an event timer to implement its internal time function. This is needed, as many UEFI implementations do not handle the GetTime runtime service method. This means that loader.efi will now correctly count down before automatically booting. Initial support for the ARM Juno reference platform has been added. This hardware is common within ARM, and has been useful for finding assumptions on cpuids. Booting on the Juno required fixing the kernel to remove the assumption that it is booting from CPU zero. This included assigning cpuids and fixing assumptions within the GICv2 driver that the cpuid is the same as the GIC cpuid. FreeBSD can now boot on the 4 Cortex-A53 CPUs of the Juno board. Further investigation is needed to track down why the boot fails when the 2 Cortex-A57 CPUs are enabled. Initial work has started on booting FreeBSD on the Pine64 and Raspberry Pi 3 boards. Both can boot to multiuser mode with out-of-tree patches. Further work is needed to bring these patches into the tree, but it is expected this will happen soon after the end of the code freeze. This project was sponsored by The FreeBSD Foundation, and ABT Systems Ltd. __________________________________________________________________ Userland Programs Reproducible Builds in FreeBSD Links Base System Reproducible Builds Wiki Page URL: https://wiki.FreeBSD.org/ReproducibleBuilds Ports Reproducible Builds Wiki Page URL: https://wiki.FreeBSD.org/PortsReproducibleBuilds BSDCan 2016 Reproducible Builds in FreeBSD talk URL: http://www.bsdcan.org/2016/schedule/events/714.en.html Reproducible Builds Website URL: https://reproducible-builds.org/ Diffoscope Home Page URL: https://diffoscope.org/ Diffoscope Results from the BSDCan Reproducible Builds Talk URL: https://people.FreeBSD.org/~emaste/reproducible-builds/iteration-1= /diffoscope/ Contact: Ed Maste Reproducible builds are a set of software development practices which create a verifiable path from human-readable source code to the binary code used by computers. In brief, the idea is that building the same binary, software package, document, or other binary artifact twice from the same source produces identical output. The reproducible-builds.org website provides background information and documentation on making builds reproducible. Many folks have contributed to the reproducible build effort in FreeBSD src and ports over the last decade. There are many practical benefits of reproducible builds, such as bandwidth and storage savings. However, there is a growing interest in the broad open source and free software communities, primarily from a software and toolchain integrity perspective. Over the last few years, some members of the Debian Project have led a comprehensive and structured reproducible builds effort. Baptiste Daroussin and Ed Maste attended the first Reproducible Builds Summit in Athens last year. Since then, Ed investigated the state of build reproducibility in the ports tree, and presented Reproducible Builds in FreeBSD at BSDCan 2016. With some work-in-progress patches, over 80% of the FreeBSD ports tree builds reproducibly. The Diffoscope tool performs in-depth comparison of files, archives, or directories to understand why a binary artifact does not build reproducibly. Diffoscope results for the nonreproducible builds in Ed's talk are available at one of the links above. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Integrate FreeBSD ports builds into the reproducible-builds.org continuous integration infrastructure. 2. Integrate reproducible build patches into the ports tree. 3. Investigate sources of nonreproducibility in individual ports. __________________________________________________________________ Updates to GDB Contact: John Baldwin Contact: Luca Pizzamiglio The devel/gdb port has been updated to GDB 7.11.1. Support for system call catchpoints has been committed upstream. Support for examining ELF auxiliary vector data via info auxv has been committed upstream. Both features will be included in GDB 7.12. Open tasks: 1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 2. Add support for more platforms, such as arm, mips, and aarch64, to upstream gdb for both userland and kgdb. 3. Add support for debugging powerpc vector registers. 4. Add support for $_siginfo. 5. Implement info proc commands. 6. Implement info os commands. __________________________________________________________________ Using lld, the LLVM Linker, to Link FreeBSD Links FreeBSD lld Wiki Page URL: https://wiki.FreeBSD.org/LLD Status Report on Linking FreeBSD/amd64 With lld URL: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html BSDCan 2016 Talk on lld for FreeBSD URL: http://www.bsdcan.org/2016/schedule/events/656.en.html Contact: Rafael Esp=EDndola Contact: Davide Italiano Contact: Ed Maste lld is the linker in the LLVM family of projects. It is intended to be a high-performance linker and supports the ELF, COFF, and Mach-O object formats. Where possible, lld maintains command-line and functional compatibility with the existing GNU BFD ld and gold linkers. However, the authors of lld are not constrained by strict compatibility where it would hamper performance or desired functionality. Over the last quarter, the lld project implemented version script support sufficient to handle the FreeBSD base system. This is an important milestone on the path to having lld as a viable system linker. lld still lacks comprehensive linker script expression evaluation support, and therefore cannot yet be used to link the FreeBSD kernel. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Develop linker script expression improvements in the upstream lld project. 2. Import a newer lld snapshot into the vendor area, add the build infrastructure, and connect it to the world build, installed as ld.lld. 3. Request a ports exp-run with /usr/bin/ld a symlink to ld.lld. 4. Extensive testing. __________________________________________________________________ Ports Bringing GitLab into the Ports Collection Links GitLab Port URL: http://freshports.org/www/gitlab PR: Not Starting on Boot URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D208793 Contact: Torsten Z=FChlsdorff After being in the FreeBSD Ports Collection for three months, GitLab continues to mature and gain adoption. Most of its initial problems have been resolved, with one known issue left: it does not start on boot. Any help in solving this issue is welcome. Staying in sync with upstream is now easy for minor versions. But, some of the monthly major releases create a big workload by introducing a number of new dependencies. This makes testing and updating an expensive process. The GitLab project itself now mentions native support on FreeBSD, which is quite a commendation. Current work aims to fix the open problems, get the latest major version into the port, and create documentation for the update progress. __________________________________________________________________ GNOME on FreeBSD Links FreeBSD GNOME Website URL: http://www.FreeBSD.org/gnome Development Repository URL: https://github.com/FreeBSD/freebsd-ports-gnome Upstream Build Bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook= /using-gnome.html GNOME/Gtk+ 3.20 Update Bug URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D210272 Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies, but with a GNOME 2 look and feel. GNOME 3.20 was ported with help from Ruslan Makhmatkhanov and Gustau Perez. Work is being done on updating GDM from the old 3.16 version to the 3.20 version. For some reason, scrollbars in Firefox are no longer working, though this has not been investigated. With Gtk+ 3.20, theme support was again changed, and the changes are not backwards compatible. If you have a theme update that requires the new Gtk+ version, feel free to add it as a blocker bug to the GNOME/Gtk+ 3.20 update bug. This bug will be used for the exp-run of GNOME 3.20, when it is ready, and to track the theme-related ports. Also, there is a problem with the open and save dialog content going invisible. Open tasks: 1. Finish GDM 3.20 porting. 2. Investigate why the scrollbars in Firefox are missing and why the open/save dialog content is missing. __________________________________________________________________ Intel Networking Tools Contact: Sergey Kozlov Several tools for Intel(R) Ethernet networking products are now available as ports and packages for FreeBSD: * sysutils/intel-nvmupdate: An application that is used to update non-volatile memory on XL710- and X710-based network devices. * sysutils/intel-qcu: An application used to switch QSFP+ ports between 1x40Gbps and 4x10Gbps mode on XL710-based network devices. * net/intel-ixl-kmod: An updated driver which enables the tools support on FreeBSD-10.x. This project was sponsored by Intel Corporation. Open tasks: 1. FreeBSD 11 support is under development and will be included in the next release. __________________________________________________________________ IPv6 Promotion Campaign Links Wiki Page URL: https://wiki.FreeBSD.org/IPv6PortsTODO Contact: Torsten Z=FChlsdorff Half a year ago, I started a promotion campaign to improve support for fetching ports via IPv6. Research performed in December 2015 showed that 10,308 of 25,522 ports were not fetchable when using IPv6-only, as these ports ignore the FreeBSD.org pkg mirror. As a result of the campaign, the following servers now successfully support IPv6: 1. mirror.amdmi3.ru 2. vault.centos.org 3. mirror.centos.org 4. gstreamer.freedesktop.org 5. people.FreeBSD.org This enables 711 more ports to be fetched via IPv6. I would like to thank Wolfgang Zenker, who is very active in supporting the adoption of IPv6. During the latest RIPE meeting, he brought up the topic of non-support of IPv6 being a hindrance to business. I am hopeful that his talk changed some more minds and will help widen the support of IPv6. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD Website URL: https://freebsd.kde.org/ KDE Ports Staging Area URL: https://freebsd.kde.org/area51.php KDE on FreeBSD Wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD Mailing List URL: https://mail.kde.org/mailman/listinfo/kde-freebsd Development Repository for Integrating KDE 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Development Repository for Integrating Qt 5.6 URL: http://src.mouf.net/area51/log/branches/qt-5.6 Development Repository for Integrating Qt 5.7 URL: http://src.mouf.net/area51/log/branches/qt-5.7 Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and improving the user experience of KDE and Qt on FreeBSD. Many updates were committed to the ports tree this quarter, and even more were committed to our experimental ports repository. Tobias Berner, Adriaan de Groot, and Ralf Nolden were responsible for most of the work. The following notable updates landed in the ports tree this quarter: * The CMake ports were updated to 3.5.1 and 3.5.2. * The DigiKam ports were updated to 4.14.0. * The KDevelop ports were updated to 4.7.3. * The devel/qbs port was added for Qt's future build system, QBS. * Qt Creator was updated to 3.4.0, 3.5.0, 3.5.1, 3.6.0, 4.0.0, 4.0.1, and 4.0.2. * A new port misc/qt5-examples was added for the project examples provided by Qt. This makes Qt Creator more functional. * A new port misc/qt5-doc was added for Qt's API documentation, used by Qt Creator and other programs. * The base KDE4 ports were updated to 4.14.10. The following work occurred in our development repository: * Created ports for Qt 5.6.1-1 (branches/qt-5.6). * Created ports for Qt 5.7.0 (branches/qt-5.7). * The plasma5 branch is up-to-date with KDE's upstream and contains ports for Frameworks 5.24.0, Plasma Desktop 5.7.0, and Applications 16.04.2 (branches/plasma5). __________________________________________________________________ Obsoleting Rails 3 Contact: Torsten Z=FChlsdorff Ruby on Rails is the base for most of the rubygems in the Ports Collection. Currently, versions 3.2 and 4.2 coexist. Since Rails 3.2 is running out of support, the time has come to switch to 4.2. While there is ongoing progress to remove Rails 3.2 from the ports tree, there are some ports for which this is a major update that blocks the overall process. The most recent blocker was the outstanding update of www/redmine from 2.6 to 3.2. This has completed successfully, so we can now move on. To help with porting or testing, feel free to contact me or the ruby@FreeBSD.org mailing list. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJXmXSQAAoJECjZpvNk63USVmcMHiiijppbDx1Q2MDhPiC+TOEV QkmBzDwG92TQPWUDbDFr9CTgeNY9jyq2EhvZ3A7kJu1bMOq8ENDugXdb4o4gwXVT 6jWYhhs6dHiFF9XbV/8u8ShfRTp9v4kXXxgPnHxviMI1sDAeokjEQs9ooAA0Z4q7 cx/qzDyDvJazlKT2zIzOxEfcf1ItdDOouMMEi+bhX1olaRX6d3/PuOxfu+xM8W25 hUI+g4fa1MftCPe2nnFYfPZ7/Gaizs60OWieoTCJbTFTTk9dwDJ5fE281zPGajR+ T8ORjWdbt9kzjQP+PKij/trcpwBKIIYlctyWZ6Por2e3AYb14dj5tun8GXgbg352 S2lQdkkKl6WSKM/z5e2TtR4egqs+W+BaRpgaRHBSdeHuUbUrpjW2uMIR4F2qPIqt vw76DxZm2i0thuWkPJKxKFsK+R/nPK4r75eAVkrJ00IPQBm3iLiO3n6l0eUWiAC+ f5Mm/dhA6RgRkPCf/Kx/24QX84vTx+8F3B3cPzXR+Ade04k=3D =3DbO9i -----END PGP SIGNATURE----- From owner-freebsd-hackers@freebsd.org Thu Jul 28 14:29:44 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D55CBA771B for ; Thu, 28 Jul 2016 14:29:44 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19C2614BD for ; Thu, 28 Jul 2016 14:29:43 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1bSlug-0000Fn-10 for freebsd-hackers@freebsd.org; Thu, 28 Jul 2016 16:03:50 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bSluf-0000Yz-MQ for freebsd-hackers@freebsd.org; Thu, 28 Jul 2016 16:03:49 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0BD412A1807 for ; Thu, 28 Jul 2016 16:03:58 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id k6H9_bMGpqmP for ; Thu, 28 Jul 2016 16:03:55 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 94F1A2A180B for ; Thu, 28 Jul 2016 16:03:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Nm9HVORrY42h for ; Thu, 28 Jul 2016 16:03:55 +0200 (CEST) Received: from mauderer-linux.eb.localhost (unknown [10.10.171.6]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 042642A1807 for ; Thu, 28 Jul 2016 16:03:54 +0200 (CEST) From: Christian Mauderer Subject: Changes to pfctl to allow easier integration into a library To: "freebsd-hackers@freebsd.org" Message-ID: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> Date: Thu, 28 Jul 2016 16:03:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CEAB064E2114F2B63F37D90C" X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/21984/Thu Jul 28 13:06:09 2016) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 14:29:44 -0000 This is a multi-part message in MIME format. --------------CEAB064E2114F2B63F37D90C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I'm currently working on a porting pfctl to a real-time operating system. This is done using the same framework that Sebastian Huber mentioned here (and probably at some other occasions): https://lists.freebsd.org/pipermail/freebsd-hackers/2013-October/043553.h= tml We more or less want to use the pfctl program as a library. The following changes simplify this. Obviously my problems are quiet similar to the ones discussed in the linked topic. - There has been a prototype that didn't quite match with its implementation. A parameter was unsigned int instead of u_int32_t what is the same on FreeBSD but not necessarily on a newlib based system. - I added const qualifiers wherever they were applicable. This saves RAM on a system where the code is executed from a ROM (like Flash). - I had to pull some static variables out of their functions. This allows to put them into an extra linker section without touching too much of the code. We use the linker section to save / restore the content before / after the program is called. Would the attached patches be acceptable for integration into the FreeBSD sources? I've generated the patches against the git commit b6ff7c02cf9 on https://github.com/freebsd/freebsd.git. Please tell me if another form would be better. Kind regards, Christian Mauderer --=20 -------------------------------------------- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.mauderer@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . --------------CEAB064E2114F2B63F37D90C Content-Type: text/x-patch; name="0001-pfctl-Match-prototype-of-pfctl_load_hostid.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-pfctl-Match-prototype-of-pfctl_load_hostid.patch" =46rom 0bb6283b06d9fabade44503a18ce47786c313462 Mon Sep 17 00:00:00 2001 From: Christian Mauderer Date: Thu, 28 Jul 2016 15:04:39 +0200 Subject: [PATCH 1/3] pfctl: Match prototype of pfctl_load_hostid. The prototype and the implementation of the pfctl_load_hostid used a different data type for one of the parameters. This patch fixes that. --- sbin/pfctl/pfctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c index 43d9dc5..f3462a3 100644 --- a/sbin/pfctl/pfctl.c +++ b/sbin/pfctl/pfctl.c @@ -82,7 +82,7 @@ int pfctl_load_limit(struct pfctl *, unsigned int, uns= igned int); int pfctl_load_timeout(struct pfctl *, unsigned int, unsigned int); int pfctl_load_debug(struct pfctl *, unsigned int); int pfctl_load_logif(struct pfctl *, char *); -int pfctl_load_hostid(struct pfctl *, unsigned int); +int pfctl_load_hostid(struct pfctl *, u_int32_t); int pfctl_get_pool(int, struct pf_pool *, u_int32_t, u_int32_t, int, char *); void pfctl_print_rule_counters(struct pf_rule *, int); --=20 1.8.4.5 --------------CEAB064E2114F2B63F37D90C Content-Type: text/x-patch; name="0002-pfctl-Use-const-where-possible.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-pfctl-Use-const-where-possible.patch" =46rom 5f2eb3f7d61353fd4fd3f25111db184dab4cc933 Mon Sep 17 00:00:00 2001 From: Christian Mauderer Date: Thu, 28 Jul 2016 15:17:27 +0200 Subject: [PATCH 2/3] pfctl: Use const where possible. This adds const qualifiers where it is possible. --- sbin/pfctl/pfctl.c | 16 ++++++++-------- sbin/pfctl/pfctl_parser.c | 10 +++++----- sbin/pfctl/pfctl_radix.c | 2 +- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c index f3462a3..6d553c5 100644 --- a/sbin/pfctl/pfctl.c +++ b/sbin/pfctl/pfctl.c @@ -100,7 +100,7 @@ int pfctl_ruleset_trans(struct pfctl *, char *, stru= ct pf_anchor *); int pfctl_load_ruleset(struct pfctl *, char *, struct pf_ruleset *, int, int); int pfctl_load_rule(struct pfctl *, char *, struct pf_rule *, int); -const char *pfctl_lookup_option(char *, const char **); +const char *pfctl_lookup_option(char *, const char * const *); =20 struct pf_anchor_global pf_anchors; struct pf_anchor pf_main_anchor; @@ -111,7 +111,7 @@ const char *showopt; const char *debugopt; char *anchoropt; const char *optiopt =3D NULL; -char *pf_device =3D "/dev/pf"; +const char *pf_device =3D "/dev/pf"; char *ifaceopt; char *tableopt; const char *tblcmdopt; @@ -203,27 +203,27 @@ static const struct { { NULL, NULL } }; =20 -static const char *clearopt_list[] =3D { +static const char * const clearopt_list[] =3D { "nat", "queue", "rules", "Sources", "states", "info", "Tables", "osfp", "all", NULL }; =20 -static const char *showopt_list[] =3D { +static const char * const showopt_list[] =3D { "nat", "queue", "rules", "Anchors", "Sources", "states", "info", "Interfaces", "labels", "timeouts", "memory", "Tables", "osfp", "all", NULL }; =20 -static const char *tblcmdopt_list[] =3D { +static const char * const tblcmdopt_list[] =3D { "kill", "flush", "add", "delete", "load", "replace", "show", "test", "zero", "expire", NULL }; =20 -static const char *debugopt_list[] =3D { +static const char * const debugopt_list[] =3D { "none", "urgent", "misc", "loud", NULL }; =20 -static const char *optiopt_list[] =3D { +static const char * const optiopt_list[] =3D { "none", "basic", "profile", NULL }; =20 @@ -1975,7 +1975,7 @@ pfctl_show_anchors(int dev, int opts, char *anchorn= ame) } =20 const char * -pfctl_lookup_option(char *cmd, const char **list) +pfctl_lookup_option(char *cmd, const char * const *list) { if (cmd !=3D NULL && *cmd) for (; *list; list++) diff --git a/sbin/pfctl/pfctl_parser.c b/sbin/pfctl/pfctl_parser.c index 4bb1477..d9aa49a 100644 --- a/sbin/pfctl/pfctl_parser.c +++ b/sbin/pfctl/pfctl_parser.c @@ -76,7 +76,7 @@ struct node_host *host_v4(const char *, int); struct node_host *host_v6(const char *, int); struct node_host *host_dns(const char *, int, int); =20 -const char *tcpflags =3D "FSRPAUEW"; +const char * const tcpflags =3D "FSRPAUEW"; =20 static const struct icmptypeent icmp_type[] =3D { { "echoreq", ICMP_ECHO }, @@ -473,10 +473,10 @@ print_pool(struct pf_pool *pool, u_int16_t p1, u_in= t16_t p2, printf(" static-port"); } =20 -const char *pf_reasons[PFRES_MAX+1] =3D PFRES_NAMES; -const char *pf_lcounters[LCNT_MAX+1] =3D LCNT_NAMES; -const char *pf_fcounters[FCNT_MAX+1] =3D FCNT_NAMES; -const char *pf_scounters[FCNT_MAX+1] =3D FCNT_NAMES; +const char * const pf_reasons[PFRES_MAX+1] =3D PFRES_NAMES; +const char * const pf_lcounters[LCNT_MAX+1] =3D LCNT_NAMES; +const char * const pf_fcounters[FCNT_MAX+1] =3D FCNT_NAMES; +const char * const pf_scounters[FCNT_MAX+1] =3D FCNT_NAMES; =20 void print_status(struct pf_status *s, int opts) diff --git a/sbin/pfctl/pfctl_radix.c b/sbin/pfctl/pfctl_radix.c index 38f16c4..5038e0b 100644 --- a/sbin/pfctl/pfctl_radix.c +++ b/sbin/pfctl/pfctl_radix.c @@ -401,7 +401,7 @@ pfi_get_ifaces(const char *filter, struct pfi_kif *bu= f, int *size) =20 /* buffer management code */ =20 -size_t buf_esize[PFRB_MAX] =3D { 0, +const size_t buf_esize[PFRB_MAX] =3D { 0, sizeof(struct pfr_table), sizeof(struct pfr_tstats), sizeof(struct pfr_addr), sizeof(struct pfr_astats), sizeof(struct pfi_kif), sizeof(struct pfioc_trans_e) --=20 1.8.4.5 --------------CEAB064E2114F2B63F37D90C Content-Type: text/x-patch; name="0003-pfctl-Pull-static-variables-out-of-the-function.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0003-pfctl-Pull-static-variables-out-of-the-function.patch" =46rom 72f9cdf74fc87a357a66ea1029b8f8fba7241310 Mon Sep 17 00:00:00 2001 From: Christian Mauderer Date: Thu, 28 Jul 2016 15:20:33 +0200 Subject: [PATCH 3/3] pfctl: Pull static variables out of the function. This will make it easier to link as a library. --- sbin/pfctl/pfctl.c | 3 ++- sbin/pfctl/pfctl_altq.c | 11 ++++++----- sbin/pfctl/pfctl_optimize.c | 13 ++++++------- sbin/pfctl/pfctl_qstats.c | 3 ++- sbin/pfctl/pfctl_radix.c | 2 +- 5 files changed, 17 insertions(+), 15 deletions(-) diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c index 6d553c5..a95ac23 100644 --- a/sbin/pfctl/pfctl.c +++ b/sbin/pfctl/pfctl.c @@ -227,6 +227,8 @@ static const char * const optiopt_list[] =3D { "none", "basic", "profile", NULL }; =20 +static const int nattype[3] =3D { PF_NAT, PF_RDR, PF_BINAT }; + void usage(void) { @@ -967,7 +969,6 @@ pfctl_show_nat(int dev, int opts, char *anchorname) { struct pfioc_rule pr; u_int32_t mnr, nr; - static int nattype[3] =3D { PF_NAT, PF_RDR, PF_BINAT }; int i, dotitle =3D opts & PF_OPT_SHOWALL; =20 memset(&pr, 0, sizeof(pr)); diff --git a/sbin/pfctl/pfctl_altq.c b/sbin/pfctl/pfctl_altq.c index 6b0443a..eed3173 100644 --- a/sbin/pfctl/pfctl_altq.c +++ b/sbin/pfctl/pfctl_altq.c @@ -1285,18 +1285,19 @@ sc_x2y(struct service_curve *sc, double x) #define R2S_BUFS 8 #define RATESTR_MAX 16 =20 +static char r2sbuf[R2S_BUFS][RATESTR_MAX]; /* ring bufer */ +static int r2sidx =3D 0; + char * rate2str(double rate) { char *buf; - static char r2sbuf[R2S_BUFS][RATESTR_MAX]; /* ring bufer */ - static int idx =3D 0; int i; static const char unit[] =3D " KMG"; =20 - buf =3D r2sbuf[idx++]; - if (idx =3D=3D R2S_BUFS) - idx =3D 0; + buf =3D r2sbuf[r2sidx++]; + if (r2sidx =3D=3D R2S_BUFS) + r2sidx =3D 0; =20 for (i =3D 0; rate >=3D 1000 && i <=3D 3; i++) rate /=3D 1000; diff --git a/sbin/pfctl/pfctl_optimize.c b/sbin/pfctl/pfctl_optimize.c index 9511720..0f89b22 100644 --- a/sbin/pfctl/pfctl_optimize.c +++ b/sbin/pfctl/pfctl_optimize.c @@ -204,6 +204,8 @@ struct pf_rule_field { PF_RULE_FIELD(min_ttl, NEVER), PF_RULE_FIELD(set_tos, NEVER), }; +static int pf_opt_create_table_num; +static int add_opt_table_num =3D 0; =20 =20 =20 @@ -1226,7 +1228,6 @@ add_opt_table(struct pfctl *pf, struct pf_opt_tbl *= *tbl, sa_family_t af, #ifdef OPT_DEBUG char buf[128]; #endif /* OPT_DEBUG */ - static int tablenum =3D 0; struct node_host node_host; =20 if (*tbl =3D=3D NULL) { @@ -1239,7 +1240,7 @@ add_opt_table(struct pfctl *pf, struct pf_opt_tbl *= *tbl, sa_family_t af, =20 /* This is just a temporary table name */ snprintf((*tbl)->pt_name, sizeof((*tbl)->pt_name), "%s%d", - PF_OPT_TABLE_PREFIX, tablenum++); + PF_OPT_TABLE_PREFIX, add_opt_table_num++); DEBUG("creating table <%s>", (*tbl)->pt_name); } =20 @@ -1275,7 +1276,6 @@ add_opt_table(struct pfctl *pf, struct pf_opt_tbl *= *tbl, sa_family_t af, return (0); } =20 - /* * Do the dirty work of choosing an unused table name and creating it. * (be careful with the table name, it might already be used in another = anchor) @@ -1283,7 +1283,6 @@ add_opt_table(struct pfctl *pf, struct pf_opt_tbl *= *tbl, sa_family_t af, int pf_opt_create_table(struct pfctl *pf, struct pf_opt_tbl *tbl) { - static int tablenum; struct pfr_table *t; =20 if (table_buffer.pfrb_type =3D=3D 0) { @@ -1306,9 +1305,9 @@ pf_opt_create_table(struct pfctl *pf, struct pf_opt= _tbl *tbl) /* Now we have to pick a table name that isn't used */ again: DEBUG("translating temporary table <%s> to <%s%x_%d>", tbl->pt_name, - PF_OPT_TABLE_PREFIX, table_identifier, tablenum); + PF_OPT_TABLE_PREFIX, table_identifier, pf_opt_create_table_num); snprintf(tbl->pt_name, sizeof(tbl->pt_name), "%s%x_%d", - PF_OPT_TABLE_PREFIX, table_identifier, tablenum); + PF_OPT_TABLE_PREFIX, table_identifier, pf_opt_create_table_num); PFRB_FOREACH(t, &table_buffer) { if (strcasecmp(t->pfrt_name, tbl->pt_name) =3D=3D 0) { /* Collision. Try again */ @@ -1318,7 +1317,7 @@ again: goto again; } } - tablenum++; + pf_opt_create_table_num++; =20 =20 if (pfctl_define_table(tbl->pt_name, PFR_TFLAG_CONST, 1, diff --git a/sbin/pfctl/pfctl_qstats.c b/sbin/pfctl/pfctl_qstats.c index 3dd9d3a..884b2ae 100644 --- a/sbin/pfctl/pfctl_qstats.c +++ b/sbin/pfctl/pfctl_qstats.c @@ -71,6 +71,8 @@ struct pf_altq_node { struct queue_stats qstats; }; =20 +static u_int32_t last_ticket; + int pfctl_update_qstats(int, struct pf_altq_node **); void pfctl_insert_altq_node(struct pf_altq_node **, const struct pf_altq, const struct queue_stats); @@ -143,7 +145,6 @@ pfctl_update_qstats(int dev, struct pf_altq_node **ro= ot) struct pfioc_qstats pq; u_int32_t mnr, nr; struct queue_stats qstats; - static u_int32_t last_ticket; =20 memset(&pa, 0, sizeof(pa)); memset(&pq, 0, sizeof(pq)); diff --git a/sbin/pfctl/pfctl_radix.c b/sbin/pfctl/pfctl_radix.c index 5038e0b..a048a61 100644 --- a/sbin/pfctl/pfctl_radix.c +++ b/sbin/pfctl/pfctl_radix.c @@ -534,10 +534,10 @@ pfr_buf_load(struct pfr_buffer *b, char *file, int = nonetwork, return (rv); } =20 +static char next_ch =3D ' '; int pfr_next_token(char buf[BUF_SIZE], FILE *fp) { - static char next_ch =3D ' '; int i =3D 0; =20 for (;;) { --=20 1.8.4.5 --------------CEAB064E2114F2B63F37D90C-- From owner-freebsd-hackers@freebsd.org Thu Jul 28 15:59:28 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42BFDBA75C2 for ; Thu, 28 Jul 2016 15:59:28 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 062D21D90 for ; Thu, 28 Jul 2016 15:59:28 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F34A625D3857; Thu, 28 Jul 2016 15:59:23 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 19FC5D1F880; Thu, 28 Jul 2016 15:59:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 6cqp2vGjRZ3l; Thu, 28 Jul 2016 15:59:22 +0000 (UTC) Received: from [10.248.105.13] (fresh-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4920:2ef0:eeff:fe03:ee34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C19D1D1F87F; Thu, 28 Jul 2016 15:59:21 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Christian Mauderer" Cc: "freebsd-hackers@freebsd.org" Subject: Re: Changes to pfctl to allow easier integration into a library Date: Thu, 28 Jul 2016 15:59:20 +0000 Message-ID: In-Reply-To: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6042) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:59:28 -0000 On 28 Jul 2016, at 14:03, Christian Mauderer wrote: > Hello, > > I'm currently working on a porting pfctl to a real-time operating > system. This is done using the same framework that Sebastian Huber > mentioned here (and probably at some other occasions): > … > Would the attached patches be acceptable for integration into the > FreeBSD sources? Hi, (a) I’d prefer uintX_t to u_intX_t and I think FreeBSD is using the former generally. (b) All the variables you pulled out of functions that are not const, would need to be virtualised for VIMAGE, as otherwise one virtual network stack could affect another. Would you be willing to look into this? Gruesse /bz From owner-freebsd-hackers@freebsd.org Thu Jul 28 16:57:32 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F2AFBA7464 for ; Thu, 28 Jul 2016 16:57:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C82CE133A for ; Thu, 28 Jul 2016 16:57:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u6SGtUBu080024 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jul 2016 18:55:30 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u6SGtNeN012648 for ; Thu, 28 Jul 2016 18:55:23 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u6SGtIBH012645 for ; Thu, 28 Jul 2016 18:55:18 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Thu, 28 Jul 2016 18:55:18 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: can anyone explain how UFS ACLs work actually Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Thu, 28 Jul 2016 18:55:30 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 16:57:32 -0000 i turned UFS ACL on one filesystem. added some entries and default entries for one directory. added say user john with rwx permissions When i access this directory from user john logged in FreeBSD - everything works as expected. I have samba server running - with windows to unix user mapping. Everything works as expected EXCEPT with directory i set ACL entry. windows cannot access it. i don't have ACL support enabled in samba because i don't want to be viewable/settable from windows. I assumed samba - just as every other unix program - would just obey this settings, but seems it does not. what i do wrong? From owner-freebsd-hackers@freebsd.org Thu Jul 28 18:25:26 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1AABBA77C1 for ; Thu, 28 Jul 2016 18:25:26 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 649221F8C for ; Thu, 28 Jul 2016 18:25:26 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.14.9) with ESMTPS id u6SIPNN2084863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Jul 2016 20:25:23 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id u6SIPGP6012948 for ; Thu, 28 Jul 2016 20:25:16 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id u6SIPABV012945 for ; Thu, 28 Jul 2016 20:25:11 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Thu, 28 Jul 2016 20:25:10 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: can anyone explain how UFS ACLs work actually - solved In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Thu, 28 Jul 2016 20:25:23 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:25:26 -0000 compile samba with ACL support and use nt acl support = no not it's fine. samba respect ACLs but windows users can't set/modify them. From owner-freebsd-hackers@freebsd.org Thu Jul 28 18:27:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BF6DBA7894 for ; Thu, 28 Jul 2016 18:27:43 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC3D1242 for ; Thu, 28 Jul 2016 18:27:41 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.4.185]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0LwZJ9-1bENP5408l-018LYG for ; Thu, 28 Jul 2016 20:02:57 +0200 Received: from bsch by becker.bs.l with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bSpe3-000Mnb-Sg for freebsd-hackers@freebsd.org; Thu, 28 Jul 2016 20:02:55 +0200 Date: Thu, 28 Jul 2016 20:02:55 +0200 From: Bertram Scharpf To: freebsd-hackers@freebsd.org Subject: Segfault in OpenSSL even though GnuTLS demanded Message-ID: <20160728180255.GA79509@becker.bs.l> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) Sender: Bertram Scharpf X-Provags-ID: V03:K0:OBozWzLcqCPd/XIzfQjMG1lz4n9dhQ1KsWiGW55QYNerUtwajXO 0X9fajG2DJw+lDKdJ5CzZr9VEJRvjq4j4Hl38jrcksfcRzXMAyvgWUyFQt6d5AWewwB4X1c FLtudHc/OAHbkUyY3zUfqZJtJoDFBsOg6XzcNwZs/0wlvBE7sDkQBeeu02DV/e+6cpqJI0m X7Ezgt0pBpR11MHIkEahw== X-UI-Out-Filterresults: notjunk:1;V01:K0:t5sZ6+nBmQc=:G5rdEBw/PZedw99WW/stdQ AHrVYzsay/i9s/Ri0nSngOji6eRYp5BI5+Ys40g+KDDWFGDGGMDkkSrLz3OcS9g5lkMRCj0kI gvj+ilFLOSrA8magqL1CEP7FgVcJyhcuqcwXR3nkkIHY1RME6mBSZfCxtyLdTZFI0NcTsJ7Cj R03yBXKHAzMl+cuWbz3MbnFKlGjUIv033H9D9qbmh3Jly+5OoIXTTDnySqsR3uRvajuZhN1nZ R2EiX/ZmLCazkogr8noauYUw+HLi7m5v6POMdXz6JY1cVWYfPnxULRQrEbD9+AOrE6znU0+VV X1Fm1X/kmCixMrE5LAdDmJxCdrsRMdpNCrHl9OiO3qaV8ZRU9VP8jP3o4SiwbAXkBfBs84I/n fGjzcKHNh8e00e2udKAOxKAfPFJFA0769YnleJlsMWweQet/IUwmbLxuT8UXbpFgdqx7h1GEf kflE/K3mvbTu5NC3W1nUi9YzCJkBjPhsWySGVIx4wf7XgU20murOidZGB6OIi+1WSZ3WcS9HT xHwW/MOVsasnefIz0Tt0spu4Y3t1OMB5JJAFPeKhwHxEWOUPz3Adv42vkTzRKwinHE0Sl0gYe 4A0Utr/SsF1IzIqlWuo+sjfAMtNwLtZ0ZRKbxL7lIJktJelrbCChs6ZgsXJUi7GImcLU7dLvz 1nST2W7xiYS/zhiDvQPjJWTd8Z4NpyPbjT8KFO7Lq3q01KT1OIpbjvZqNgZUau+8NKUc= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:27:43 -0000 Hi, first of all, I am compiling ports myself. No packages. I try to install a console XMPP client. To my disappointment, both irssi-xmpp and mcabber, too, crash with the same segfault. Here's an output from gdb. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 29403080 (LWP 101275/mcabber)] 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 Both ports do no SSL themselves but depend on loudmouth. However, I have disabled OpenSSL there. # grep SSL\\\|TLS /var/db/ports/net-im_loudmouth/options _FILE_COMPLETE_OPTIONS_LIST=DOCS GNUTLS OPENSSL OPTIONS_FILE_SET+=GNUTLS OPTIONS_FILE_UNSET+=OPENSSL I have checked the ./configure calls parameters and there is a --with-ssl=gnutls indeed. I tried to config loudmouth with OpenSSL instead of GnuTLS, but I encounter the same segfault. What is going on here? What can I do further? Thanks in advance. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Thu Jul 28 19:28:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61452BA774D for ; Thu, 28 Jul 2016 19:28:55 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8FE137A for ; Thu, 28 Jul 2016 19:28:54 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 5EEC3194EEA for ; Thu, 28 Jul 2016 15:19:52 -0400 (EDT) Date: Thu, 28 Jul 2016 15:19:50 -0400 From: Mason Loring Bliss To: FreeBSD Hackers Subject: Disappointment with wifi... Message-ID: <20160728191950.GF4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oxour8c+zPVguRmP" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 19:28:55 -0000 --oxour8c+zPVguRmP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all. I'm coming to you with a minor existential crisis. :) I've got a Thinkpad T420, initially purchased as my best bet for FreeBSD hardware compatibility. For wifi it has Centrino Advanced-N 6205 [Taylor Peak]. I did a fresh install of 11.0-BETA2 the other day, and that worked well enough, up to and including finding local wifi and initially connecting. However, on boot, dhclient keeps saying, repeatedly: send_packet: Network is down send_packet: No buffer space available =2E..and of course my network is largely unusable this way. It seems to come and go, but I can't predict it. I know it's a volunteer project, and I know that laptops aren't a priority, especially as compared with servers, but I'd really like for this to work. The last time I tried to tackle something like this myself, however, it went badly - I had an onboard Realtek gigabit NIC, and the best I could get was a brute-force reset of the driver when it would fall over. I made an initial effort to compare the (functionally flawless, as far as I could see) Linux driver with ours, but I quickly got lost. I've never attained the lofty heights of kernel hacking and I completely lacked context to understand the code. What would you folks recommend, given a strong interest in seeing FreeBSD support my T420 well enough for me to be able to use fully? Running FreeBSD in an interactive role is going to be the best way for me to maintain my interest in pushing it forward, finding pain points to bring up, etc., and this laptop is one of my most heavily-used systems, as I'm using it whenever I'm not at a desk. I could just go back to RHEL on it, but I'd like to take the opportunity to address this issue and make the world a better place. It looks like we've had support for this chip for a while... I see it mentioned a number of times in SVN: http://svnweb.freebsd.org/base/head/sys/dev/iwn/if_iwn.c?view=3Dlog Revision 285234 from last year looks interesting... It notes issues with HT40. I see my local network using HT20, so I would expect this to not describe my issue, but it does make me wonder if there's anything I can set to influence driver behaviour. Nothing jumps out at me from iwn(4). Thanks in advance for ideas and direction. --=20 Mason Loring Bliss (( If I have not seen as far as others, it is because mason@blisses.org )) giants were standing on my shoulders. - Hal Abels= on --oxour8c+zPVguRmP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXmlrWAAoJEJ6yV3B27yVVArYP/0fT/1KoFgRT8MlW/WqeyR9H c8Pws61VxTwOcNdmMwxPWTn8kfh7J5HYabI6T6vJjSdxIWo4YAT5PQN3jq+ZMfyN GbDfH+fFOXFMI31i1bDSIF1DjnCOi2a0vg5cNbA140RrhsYUpAbMjGPHvCsPuXeE nzb4MZ1Ax6qGKscBmN/NocOG0RFU/Vf9Sql4Sn6iPyogOEHHM1vRvPxeMKRI+RwK y086jLlqa27bzV9Sq7EQN5GkbrjmVUquHaBpMRhD4W8nmpgCB88DN+Ah1Q9bCe5E LLBk9CqmkmVsEMo89cVp2GcfHGLFp0fhUuTElo6JKEe2uSwdQAAN7G2qtz5aZofx IKEUmzJkG86YWR/VbnnBx9PGbGsZN41pEveqPEQhKTolLrtWzBmKsggAzpHHsAQB OEHhU9/+/wNRvlf02sCmNjJ3+I4yHvX4Y+cSRvOX56mblcHYuQ8ttSl9mPvXuWN6 j4j8QspHW0/5np0sWer9GkeciRErONx9ouykQPfu+nUkl4MF4OXfpRBP2p6w9iSb FmKIshSs/V/8aGvQUqckm2+7YDcbz2yM8ASd9jEk0siEqAMHD/WkPV9+noqsumVM XDP6kp5W4wWC9gATN9zoaxGSihQz1rJH6kE3bq3icb72Oh8jceTPZhaaiowp8iAd WY1k+Slzc97lwP2c4KZY =3Qyr -----END PGP SIGNATURE----- --oxour8c+zPVguRmP-- From owner-freebsd-hackers@freebsd.org Thu Jul 28 19:37:06 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F82EBA7A9E for ; Thu, 28 Jul 2016 19:37:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6761B22 for ; Thu, 28 Jul 2016 19:37:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: Segfault in OpenSSL even though GnuTLS demanded To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> From: Jung-uk Kim Message-ID: <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> Date: Thu, 28 Jul 2016 15:37:00 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160728180255.GA79509@becker.bs.l> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6VCvBQXHI5bdPoRIVrvKSB26ONCN5nL7n" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 19:37:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6VCvBQXHI5bdPoRIVrvKSB26ONCN5nL7n Content-Type: multipart/mixed; boundary="Vf8nTahAUtuJWK5sgd02NPTxmWHqioLGI" From: Jung-uk Kim To: freebsd-hackers@freebsd.org Message-ID: <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> Subject: Re: Segfault in OpenSSL even though GnuTLS demanded References: <20160728180255.GA79509@becker.bs.l> In-Reply-To: <20160728180255.GA79509@becker.bs.l> --Vf8nTahAUtuJWK5sgd02NPTxmWHqioLGI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/28/16 02:02 PM, Bertram Scharpf wrote: > Hi, >=20 > first of all, I am compiling ports myself. No packages. >=20 > I try to install a console XMPP client. To my > disappointment, both irssi-xmpp and mcabber, too, crash with > the same segfault. Here's an output from gdb. >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 29403080 (LWP 101275/mcabber)] > 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.= 8 >=20 > Both ports do no SSL themselves but depend on loudmouth. > However, I have disabled OpenSSL there. >=20 > # grep SSL\\\|TLS /var/db/ports/net-im_loudmouth/options > _FILE_COMPLETE_OPTIONS_LIST=3DDOCS GNUTLS OPENSSL > OPTIONS_FILE_SET+=3DGNUTLS > OPTIONS_FILE_UNSET+=3DOPENSSL >=20 > I have checked the ./configure calls parameters and there is a > --with-ssl=3Dgnutls indeed. >=20 > I tried to config loudmouth with OpenSSL instead of GnuTLS, > but I encounter the same segfault. >=20 > What is going on here? What can I do further? Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a Kerberos issue. Jung-uk Kim --Vf8nTahAUtuJWK5sgd02NPTxmWHqioLGI-- --6VCvBQXHI5bdPoRIVrvKSB26ONCN5nL7n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXml7iAAoJEHyflib82/FGOvIH/2RmHrwUbMyHOkQ25R9y8vsT QC1bSaAG8lm1ylC/Y49evIuQ3AZRx3gSeZ8KrVtZAFbBkVMy++QRW8ySecPsN6/K 106O9USWAiBtwMBe0xFWiLrkLOoCLR36z2TgDW7MiVGbx/HX+ELXboUubMMMC1nj wRwv50CmsOPkZN52TfNnif1qZabOReTOszCvQKzREufmlbXe3wRuf/rh9+LljSC/ cwd5U5+ROClav2dZr/gu5EfVY1SSQlnhUcDMBBH7r3HqqyNo9i6emSIb9GDpB8zc 8CKjg67YuNfLvE9PtXvzC1HUo86/yGKlpXX/LTy7iVMjApbkDx2YZJQZg09oqeQ= =Ck4+ -----END PGP SIGNATURE----- --6VCvBQXHI5bdPoRIVrvKSB26ONCN5nL7n-- From owner-freebsd-hackers@freebsd.org Thu Jul 28 20:10:31 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A870EBA724F for ; Thu, 28 Jul 2016 20:10:31 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66DDC1CDD for ; Thu, 28 Jul 2016 20:10:31 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x232.google.com with SMTP id r9so97047235ywg.0 for ; Thu, 28 Jul 2016 13:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5aDawK/rvpnUk+aoeaReg5Pjbs70G0hp0Lasuq2K6oQ=; b=WLhspWDj+PkzvEmUgpMIE7KLbsubkznALwHXSWVWjunUnEyw3/gLpRgDSIq1ETSnSv CcoQE01gijVvBNLFMsOGU/jdCgoXzf2vxYYP9xY5f/n+AR/ZguhycLxixrvOClMqx/3V NynHWtiu+CWioauxXvhtrO3nIWEUSwNXQvHkvm9GLonISOWclPW3zy4jW+CBqig0ybNL kVpkzHtWGseYqJSwXyjyOj43/b0hpYaigWv53Fa9aTP1B1wPyTE469sC4crLKQaE2NrK e7XCbNSr8sHDyF4wETj2+f1EiWot7a3LUttURQ7XM/jnMYK3ffiU5+ybLd6fQS9CPJqF mM1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5aDawK/rvpnUk+aoeaReg5Pjbs70G0hp0Lasuq2K6oQ=; b=NbroRIboUSKleXEjUjPhHytCOVU9mNgsiRdm/v6ngXOoe0dpFQLDkUohxCSOR8GxlI U4tbPBBuXOMk1rUdDPcVZ6JylfOnFoibkV4S8CjShXofbDxkcDHUrMgQDhCUBvRYwGDT F3SgCF+E6BCXtry8cSLxmeARygXqgcoQUcJL1CL/Vj3srnYbXnzsszQP5GKV4S5/glfi tlNpmhYn6udVQS+Vjlxr5ZDis96J4elxNmX8gazbJpZ37yXF0UvOW8VNkTuJ5TbLicWx ZAEASOSf/PtXlQXqqZBmcuN9QYOLUvlGjmMll8s1SHCJ3DHZClIzKreA2Sr9Y3g6iJD2 H0Sw== X-Gm-Message-State: AEkooutH7GJ5w1LIXM5069q7bJzIpcKlbXj4N7a9sFyvgQlzTV5A1KyEO5GkIB4J2KhqHoR6h/n+w/0AsQvqCw== X-Received: by 10.13.229.1 with SMTP id o1mr33056470ywe.95.1469736630499; Thu, 28 Jul 2016 13:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.201.71 with HTTP; Thu, 28 Jul 2016 13:10:29 -0700 (PDT) In-Reply-To: <20160728191950.GF4313@blisses.org> References: <20160728191950.GF4313@blisses.org> From: Ed Schouten Date: Thu, 28 Jul 2016 22:10:29 +0200 Message-ID: Subject: Re: Disappointment with wifi... To: Mason Loring Bliss Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:10:31 -0000 Hi Mason, 2016-07-28 21:19 GMT+02:00 Mason Loring Bliss : > Hi all. I'm coming to you with a minor existential crisis. :) > > I've got a Thinkpad T420, initially purchased as my best bet for FreeBSD > hardware compatibility. For wifi it has Centrino Advanced-N 6205 [Taylor > Peak]. > > I did a fresh install of 11.0-BETA2 the other day, and that worked well > enough, up to and including finding local wifi and initially connecting. > > However, on boot, dhclient keeps saying, repeatedly: > > send_packet: Network is down > send_packet: No buffer space available > > ...and of course my network is largely unusable this way. It seems to come > and go, but I can't predict it. It would be interesting to know whether this has always bugged or whether this is a regression, especially with the 11.0 release coming up. Are these devices supported by FreeBSD 10.x? If so, does it work properly there? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-hackers@freebsd.org Thu Jul 28 20:50:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A847BA7B30 for ; Thu, 28 Jul 2016 20:50:41 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F5BD11D9 for ; Thu, 28 Jul 2016 20:50:41 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id D9231194EEA; Thu, 28 Jul 2016 16:50:38 -0400 (EDT) Date: Thu, 28 Jul 2016 16:50:36 -0400 From: Mason Loring Bliss To: Ed Schouten Cc: FreeBSD Hackers Subject: Re: Disappointment with wifi... Message-ID: <20160728205036.GG4313@blisses.org> References: <20160728191950.GF4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vqZEy/DEMZDTzjXG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:50:41 -0000 --vqZEy/DEMZDTzjXG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2016 at 10:10:29PM +0200, Ed Schouten wrote: > It would be interesting to know whether this has always bugged or whether > this is a regression, This was also a problem with 10.3. I'd started off on 10 and had problems with wifi and the trackpad, but I perked up on hearing that iwn had been tweaked for 11. --=20 The creatures outside looked from pig to man, and from man to pig, and from= pig to man again; but already it was impossible to say which was which. - G. Or= well --vqZEy/DEMZDTzjXG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXmnAcAAoJEJ6yV3B27yVVbTgP/0fzs8h6A+PgEoQi9wEsp75N l4sXicSyH2YTYs7dTd9jS3GxKMMPU6ptsC94gqsD8jQWDZWw4EpMGSJcIn5SxMI8 8npl4t9gcbAU4RTaUNnG/GqVUY8QK1KKjcifr7XX6LsWhTbKDWsmyYUfvvpBMUXf hlBnOnuyu1R+NVmXxM4DQd0VZj0iQ6kfA0RXjbq/Hv1w6rt1jpnfPzEIe9hgJt5y YLERngQ8NoFF0BJJrJXGS9lP2a6xMnJzGlsDAd1GWEW4QEhaP8Pew2E7uNb93Ivw Wjmdn9G8Gf8qyzCNxPh+6z8djGg1oclJyu6CM77J7U7cugIfnMoT1P+MUixV7eJ1 9fiVmb1lO6Ct/BK1kxQ9IeoV37pNa1YP4UEKOFNjNIoW8VMn8xuEed1+/oArVFgD utMtbDkF17EhudF/hauYWN4prD0uwwQxJmtxqrMYO9Rt4/e0eVDP6LWN+e6x/JNw Bs0IAjGck5FUMh/0U19MQ/AwlS78U6BnsmH2yG6eYHvgBJeUq5hKOeK9eTzCXnGb /4ozXFm0idMQltAwsZEjOivSX5Am/FuYIU6UWVhuEuEID2v7BdfPZZqkvYI2Q8Et VuC+IrFRgHjG7UboMAgg1hhkHHVbbg3OdXzV8bnbNnrt2oQj0QZAIAciJeY6XOJv 5fa1sj5ykpDzCHE4PJ9Z =qydi -----END PGP SIGNATURE----- --vqZEy/DEMZDTzjXG-- From owner-freebsd-hackers@freebsd.org Thu Jul 28 20:55:26 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 717F3BA7D22 for ; Thu, 28 Jul 2016 20:55:26 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C79911761 for ; Thu, 28 Jul 2016 20:55:25 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.4.185]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0McAjL-1blEhO0TeZ-00JekP for ; Thu, 28 Jul 2016 22:55:17 +0200 Received: from bsch by becker.bs.l with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bSsKq-000PYJ-Eo for freebsd-hackers@freebsd.org; Thu, 28 Jul 2016 22:55:16 +0200 Date: Thu, 28 Jul 2016 22:55:16 +0200 From: Bertram Scharpf To: freebsd-hackers@freebsd.org Subject: Re: Segfault in OpenSSL even though GnuTLS demanded Message-ID: <20160728205516.GA94239@becker.bs.l> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: Bertram Scharpf X-Provags-ID: V03:K0:WqxbZchBxt8xyVeh8HDbNfcJf0/7K2iNWmy1IXkGTZWyYC4UbFD HiaAfIrZmYopwsvJv6evNHE9mG/QjbnpIAjz8jwxX7JiMsWUfLksrOT6Bu0jvqceKG8Robc +AyyusdFJhDX4SvXUtKF2yvfp5xBcjlrpCDVul0EIj9menKbFLKMQTAep4KjwSSBGcCZYnP jr6mWchtKYtmgw3tc6s2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:4tSkfqchozU=:fb7d9a3Pg0FL1mp3EQ4PWG rdLaTMKQU3AFIxRN1zfYhfZVBQrks1l48bly7tbtikcDU6x/Hm2julCG3iN3WqYJHgxgaPWbj z01uM2GjwcBUrREw88dFuUnJtaR6VhDMT0A+TejD3w+sjPs5HO5G0hoJ025j4//BzBTetPNSV SEkZv9yq06wXBu5fSBCrcIoFeDa6djliWW7KIfoWVU7LWFyDrVzyMTE0l6JHYXUMPGkfLo6B0 5upXvB+r7Vl01UWyqBB1+U5qp/nsqUuaWO11imoRfLVjB8Q8yu3/GbcALeVfDTyDNbqFhO4c2 8wPrvYZ3P+jJVBRCnAh5IomziZO6sRSMCuq8ks2Q1s9skvcTb+vHxaAxCABGCgGmYjb6o9q8d RAycmm3qlbGLLT4cudZidvygDhfGjDctWo5PN+wLC52mCckJYsPYvRcg5cuG232UjCYQ6vJnM mZzo42sm6vSNjswAdLmsE5n9pxlI3jyla54gVXH1bsYMRfrAhTBFAnGmdPYLa2ULwy1frKmLN HfIr5pAt1M7lv5O7nLXwO1QUiueZblPfyU6vjg5nn8J7ZKQJJc2cwmMdjfcsqTx4mDUqntsTV aXLPJKzyv7XolhmpeZlXtYWs+euS0L2oKE0b3//Vi6P/dmDms5xDpT/hUaPpzl7ZtHXA0om7y K4oFJwaQ41Hvv/4zIwwTkDlIdpKOVA0j4Z9W1jRM1BgtgbvaYstrbrCrFROD3UcVRn6Y= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:55:26 -0000 On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: > On 07/28/16 02:02 PM, Bertram Scharpf wrote: > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 29403080 (LWP 101275/mcabber)] > > 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 > > Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a > Kerberos issue. No errors. They do all exist. I double-checked it: $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=>\s*(\S+)/ and not -e $1 and print $1' Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Thu Jul 28 21:25:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85F58BA766F for ; Thu, 28 Jul 2016 21:25:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5101118F2 for ; Thu, 28 Jul 2016 21:25:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: Segfault in OpenSSL even though GnuTLS demanded To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> From: Jung-uk Kim Message-ID: Date: Thu, 28 Jul 2016 17:25:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160728205516.GA94239@becker.bs.l> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ODkch2mQsiWJIRCMeWrAcxqORC7Uw4tfQ" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 21:25:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ODkch2mQsiWJIRCMeWrAcxqORC7Uw4tfQ Content-Type: multipart/mixed; boundary="EPINvhJGsArPS4PMSxl4m8LjFDDFKhH2c" From: Jung-uk Kim To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: Segfault in OpenSSL even though GnuTLS demanded References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> In-Reply-To: <20160728205516.GA94239@becker.bs.l> --EPINvhJGsArPS4PMSxl4m8LjFDDFKhH2c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/28/16 04:55 PM, Bertram Scharpf wrote: > On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: >> On 07/28/16 02:02 PM, Bertram Scharpf wrote: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 29403080 (LWP 101275/mcabber)] >>> 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.s= o.8 >> >> Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a >> Kerberos issue. >=20 > No errors. They do all exist. I double-checked it: >=20 > $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=3D>\s*(\S= +)/ and not -e $1 and print $1' I guess you misunderstood. I didn't mean you have a missing library. I believe it links *two* libcrypto.so's, i.e., one from base and one from ports. Jung-uk Kim --EPINvhJGsArPS4PMSxl4m8LjFDDFKhH2c-- --ODkch2mQsiWJIRCMeWrAcxqORC7Uw4tfQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXmnheAAoJEHyflib82/FGoycH/2mmXE0VqGQF2M74lQYD5ZCV D4ypg0rFA6zuBEjFHj0VDkaa4FtKK5R1hUOOlM+pWF5NDpyb8jFguP7Fp1D496Jq h5tY66SzVLs1a75CI6Z99joD09QpowAbNXpUbtjF548Lt0HhbENeNnyG7kM+9B5Z 7JUGud9WbF3H3RZnR8yX8XqDBKJnwVQpsQM28HjiyH55bIXLoQ/UXE3VWU8bkLsM 8dCYOtGs0KllBHhMn9pvdY7RZKI8GBRif1RWLg+pDHBIjOxTaUmXzTL+2VXAappf l04Z5AJ3rZjQVXa1A2jUs4LkbzuiFSVOzDlj9jcq5sts41zeY+29cBcdnttvPDU= =iDk3 -----END PGP SIGNATURE----- --ODkch2mQsiWJIRCMeWrAcxqORC7Uw4tfQ-- From owner-freebsd-hackers@freebsd.org Thu Jul 28 21:37:27 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C5C3BA7963 for ; Thu, 28 Jul 2016 21:37:27 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C046011EA for ; Thu, 28 Jul 2016 21:37:26 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.2.88]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0M5UF6-1b4jP32jPc-00xeae for ; Thu, 28 Jul 2016 23:37:17 +0200 Received: from bsch by becker.bs.l with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bSszV-000PfK-6T for freebsd-hackers@freebsd.org; Thu, 28 Jul 2016 23:37:17 +0200 Date: Thu, 28 Jul 2016 23:37:17 +0200 From: Bertram Scharpf To: freebsd-hackers@freebsd.org Subject: Re: Segfault in OpenSSL even though GnuTLS demanded Message-ID: <20160728213717.GA98586@becker.bs.l> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: Bertram Scharpf X-Provags-ID: V03:K0:WdELBRox3fAPd/0EQanMqsKeHR0WTwZWQcFV9+q3bY5g1OqvvIZ +LoxmFwHwJI1SPtbQrMtBMXkDk3y9I5lIZBInUG5AexnJKzsAGOr5zgPIHL9PYgrpSkPoCV Lx4RAWp6XoEusr2HNdQv2YDIprHRzImzzlcnjBYNdCwdiaSwcmsOBOYgVabLruidGQyD/hw +4KAUG8k+5qvM5ZThorEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:B1poaTTMvoI=:bBiGGl0V6T6ubcZ1W73LLR 1UMAxkvw/Cu4Rb9AFNkr2t+1fyYH7F8WNkibJ+FXCM3h+Cq/ucoky5W2En0SH8ZyHTVfWFrYj R9rSPA3lW6AuW4bhfQrbAgmygaXzC+iPl7wYUfiKFp6xgmAwO6HIbXHEM+j8Klv5k7YAOF+kt 0e3MNwHwe5/3EIQZBDA9sUWZtzVB24QH/Igz9pbItAHEXYcIoqCUCNVz3MLIr7qDry6BDCg18 jldjuBH9ILO+3CqNJKuXvigDxXjNFn28tywk6IEe1Hn7LpkhmDrc25oJu5GmOikPR4buNbON2 zjeYGezx/44/EvmmjEA95iwcbB7BGu6SGlOIIF9piUVEDpdJXnDN7YmwCDXEpf6pH4wU0nuag R6UtRqCkhqtUyP04RohGlB2hNpLxnqnaL/To4SSnnjCRzzUfyACc6nE35JMjhWDL+WCdsSsxk u1JIvTCHSd6Hj1JUB2pLeFcRfMM+T1XMMemjTLvAKH99sGFbYI3FfEakz6VwdIp2tRbH8rUY3 NOnt5BvCcFsBWeOAmIYhqEOLTQJgcvakJUc5vH/+6blOac1zbvx9LeRJYtvgr2b/8BaKcZ2Mq QG3h65c/oisKzbc+nH6RMiEfZ//6fXxYP8pfjUQ99xemJK4f30/ROlHRYnt52jHxeJLi9Vlnw 3+MmOWY1MwX5PxHhH3281L9G0eSpIPuPNKJEb4I21B5U/2/Ac5fvWmN2vBvZPg1taHNQ= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 21:37:27 -0000 On Thursday, 28. Jul 2016, 17:25:50 -0400, Jung-uk Kim wrote: > On 07/28/16 04:55 PM, Bertram Scharpf wrote: > > On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: > >> On 07/28/16 02:02 PM, Bertram Scharpf wrote: > >>> > >>> Program received signal SIGSEGV, Segmentation fault. > >>> [Switching to Thread 29403080 (LWP 101275/mcabber)] > >>> 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 > >> > >> Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a > >> Kerberos issue. > > > > No errors. They do all exist. I double-checked it: > > > > $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=>\s*(\S+)/ and not -e $1 and print $1' > > I guess you misunderstood. I didn't mean you have a missing library. I > believe it links *two* libcrypto.so's, i.e., one from base and one from > ports. Indeed: # ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | grep libcrypto libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28d00000) libcrypto.so.7 => /lib/libcrypto.so.7 (0x2925b000) So, how could I resolve this? Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Thu Jul 28 21:48:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D909CBA7B62; Thu, 28 Jul 2016 21:48:49 +0000 (UTC) (envelope-from jesa7955@gmail.com) Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com [209.85.217.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C98916BB; Thu, 28 Jul 2016 21:48:49 +0000 (UTC) (envelope-from jesa7955@gmail.com) Received: by mail-ua0-f193.google.com with SMTP id 39so3089247uah.0; Thu, 28 Jul 2016 14:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cLeWsAI4R0tkv5X7+yEUiZpYoQFMzl9nztNTzUW+H94=; b=CdTcLTXnPOn+Hmoj+uu1AUQj4R/de0eMVfez74dLUlTbtN7/fH3bsBJgjAM7ZPbbfo b13NLnD3MAGIM/FJYk4v8TWIu5eEdVdDp+fFlmKDipQ/sjsfTx6Y8ShROpyxdj9gZk2B OAWhzTLrC1ixY5LPQVDkCy7DljRYVBjQl89Z6tNY4Dy+pBoeAac5c8LjZXq7ZT26hdPC oaz6bt8eUijB4VMrslOupD3SxIyA0ffo7DQevO4EwL7nO5Ssir/JzDPth2+FTu0YgDzA z5u1izqzQJO5UfvBxDLj/+HeNxx4ZZJ01R75PdkU4jfWuhDtEQD5KWhXE7CIWOp5BgNW GfLQ== X-Gm-Message-State: AEkoousaBS+lRlTKJsxD2CWAl+ultI8QgTlcFdzY3adBKcYATp4S96vHJ9d2vKkJXZHa/Q== X-Received: by 10.159.39.3 with SMTP id a3mr16418904uaa.62.1469727951443; Thu, 28 Jul 2016 10:45:51 -0700 (PDT) Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com. [209.85.217.170]) by smtp.gmail.com with ESMTPSA id 40sm1905258uat.9.2016.07.28.10.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jul 2016 10:45:51 -0700 (PDT) Received: by mail-ua0-f170.google.com with SMTP id 35so45050412uap.1; Thu, 28 Jul 2016 10:45:51 -0700 (PDT) X-Received: by 10.176.64.195 with SMTP id i61mr16639949uad.40.1469727951032; Thu, 28 Jul 2016 10:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.108 with HTTP; Thu, 28 Jul 2016 10:45:50 -0700 (PDT) From: Tong Li Date: Fri, 29 Jul 2016 01:45:50 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Call for testing on vagrant-bhyve To: freebsd-virtualization@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Cc: Steve Wills , Michael Dexter Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 21:48:50 -0000 Hello Everyone, As part of this year's GSoC, we created a project named vagrant-bhyve which enables bhyve as a backend of Vagrant so that we can use Vagrant to manage bhyve VMs. Now most of fundamental functions are working, including booting up a box, providing network access to a box, getting ssh into a box (you can check status in details on GitHub). My mentors and I have done some testes, but we still need more hands to help us find bugs. We also need more users' feedbacks to help us confirm most needed functions other than basical ones and prioritize their implementation. So, please help us. I have documented a step by step guide on how to test vagrant-bhyve, you can follow that. When you find some problems or need some new features, feel free to open an issue. All your testing and feedback will be much appreciated. :) Here is another thing. I am using PF to porvide NAT and port forwarding (thanks to vm-bhyve's hints), but got two problems. One is about PF anthor and another is about port forwarding. I opened two issues for them, please also help me figure out these two problems if you have met them before. Thanks a lot. Best Regards, Tong From owner-freebsd-hackers@freebsd.org Thu Jul 28 21:56:51 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51CBABA5064 for ; Thu, 28 Jul 2016 21:56:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1906712D9 for ; Thu, 28 Jul 2016 21:56:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: Segfault in OpenSSL even though GnuTLS demanded To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> <20160728213717.GA98586@becker.bs.l> From: Jung-uk Kim Message-ID: <7483738d-01e7-0bb2-81e9-9c26d8ef8c9f@FreeBSD.org> Date: Thu, 28 Jul 2016 17:56:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160728213717.GA98586@becker.bs.l> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x2hrMiBoLT3xgRg1h4f6LlI5NopgvCV9D" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 21:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x2hrMiBoLT3xgRg1h4f6LlI5NopgvCV9D Content-Type: multipart/mixed; boundary="EmE0jm9I0UJTNwS0jG45MW0CFjcm0xONo" From: Jung-uk Kim To: freebsd-hackers@freebsd.org Message-ID: <7483738d-01e7-0bb2-81e9-9c26d8ef8c9f@FreeBSD.org> Subject: Re: Segfault in OpenSSL even though GnuTLS demanded References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> <20160728213717.GA98586@becker.bs.l> In-Reply-To: <20160728213717.GA98586@becker.bs.l> --EmE0jm9I0UJTNwS0jG45MW0CFjcm0xONo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/28/16 05:37 PM, Bertram Scharpf wrote: > On Thursday, 28. Jul 2016, 17:25:50 -0400, Jung-uk Kim wrote: >> On 07/28/16 04:55 PM, Bertram Scharpf wrote: >>> On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: >>>> On 07/28/16 02:02 PM, Bertram Scharpf wrote: >>>>> >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> [Switching to Thread 29403080 (LWP 101275/mcabber)] >>>>> 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto= =2Eso.8 >>>> >>>> Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a >>>> Kerberos issue. >>> >>> No errors. They do all exist. I double-checked it: >>> >>> $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=3D>\s*(= \S+)/ and not -e $1 and print $1' >> >> I guess you misunderstood. I didn't mean you have a missing library. = I >> believe it links *two* libcrypto.so's, i.e., one from base and one fro= m >> ports. >=20 > Indeed: >=20 > # ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | grep libcrypto > libcrypto.so.8 =3D> /usr/local/lib/libcrypto.so.8 (0x28d00000) > libcrypto.so.7 =3D> /lib/libcrypto.so.7 (0x2925b000) >=20 > So, how could I resolve this? You may ask its maintainer (gnome@FreeBSD.org) to add USES+=3Dgssapi and add an option to select GSS-API from ports. Another solution may be removing all packages depending on /usr/local/lib/libcrypto.8 and rebuilding them with base OpenSSL. Jung-uk Kim --EmE0jm9I0UJTNwS0jG45MW0CFjcm0xONo-- --x2hrMiBoLT3xgRg1h4f6LlI5NopgvCV9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXmn+eAAoJEHyflib82/FGZowH/Rgxz51bYAL6hL7Jgq1KlxKr NuJZbLSlJErMpt1jbRFIYHZbjFMOon06bJaKkH5BomX35R/a7CeE8nTkNSjmMMUe UalxoOFs/yRZ2NjtQmKzhLeWtlAVQBXOFRQTSEMLzMk6wEzha4htPKqDriRkgLxg q8Xk7q1KHOkwegtPyJt3L7HmsdFSuK3ZGbAGubZguIeTE3PLhQ4MutjrpS0Ky+C+ r6TNGvEOc5AoprxnEg4FlVB0wuaKmYLhN9Me6zLmyKSfmQ0T0A8G1QvKrpuZonVM P5jruZb/KoIKePGdhf2cMQURmLL60rPWrfkCQW9XNdhYwZEcJfbBabfRawQcHCg= =QkNk -----END PGP SIGNATURE----- --x2hrMiBoLT3xgRg1h4f6LlI5NopgvCV9D-- From owner-freebsd-hackers@freebsd.org Fri Jul 29 01:05:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E3F6BA6139 for ; Fri, 29 Jul 2016 01:05:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1649A124E for ; Fri, 29 Jul 2016 01:05:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x233.google.com with SMTP id f6so94858029ith.0 for ; Thu, 28 Jul 2016 18:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PMc/B+CnHayk6b/4kFycn35+k0RAVnLTWdCyRwn/9Uc=; b=IYsWGJvSn0vh3r9yueNd4MgwVffUwd/8SKNwNakQjXy1LrWWwEvOAXNPOjHsuk/Ivh 6TwlIWjEAtAGQtiQWWOovwG+ZiWzkAWNPAWL2E6zwj0txA947xR9368VO/ot5BVFjzwy jRaHWqamR6nreSOELnrn5mgRPU5/X6+SRoYZ87p3haqcueqzHpqDWSle74HzxW4usA/3 kOqCGva4uJ9jHFPAR4I2MPHaIMmXlMiA6VNOQh8qzokRMRksNUo+bQ5/YOZ/RLUKhJuA e73Zzs2Gn8KBFfvX7Zy7oA8oirdn2rOSgr+aeZRV0bq+ymDV+nUJmu7uqst1pYxTW8lp JhDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PMc/B+CnHayk6b/4kFycn35+k0RAVnLTWdCyRwn/9Uc=; b=Fk1cdf9MSX9HnTDDj6N8WFCQWpTYtip3uM4yJHJfxbd/xyHt0m/rpKq2acntThP8Sn 3wiE/FzOo5+22pfzTswUKCrbQb2ersMWH0NE+5qSGolnTJo9IwNTHWg9aE9cByh0nMet B5iNlDu64hAZOSkJq6jjVsMiNoYcit0HIDPF4JW0iY6LZfzaXhUISkYUlCn2QqCFJ4dI ahV2J7r29gbjN0F+/xy7NkwD/CE5R8h7z9UFLVJqy+14n35J8OaL9oIfq9MZQ7SXO38/ qqbiwh6WZmGQxBTv2nKqjChHsR5WQQWNicISRhuY03yEqRmoZ24qWa7WXNZeHJuI23XA 5DAw== X-Gm-Message-State: AEkoouuS2/t5SfSfGEBJh4l8JpWKh+T/iW6g8eysxD38WhaEuDqxbUcVHxtA7j8tUw2GE55kqCMaiwqF+0eWBg== X-Received: by 10.36.212.6 with SMTP id x6mr34093410itg.71.1469754347335; Thu, 28 Jul 2016 18:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Thu, 28 Jul 2016 18:05:46 -0700 (PDT) In-Reply-To: <20160728205036.GG4313@blisses.org> References: <20160728191950.GF4313@blisses.org> <20160728205036.GG4313@blisses.org> From: Adrian Chadd Date: Thu, 28 Jul 2016 18:05:46 -0700 Message-ID: Subject: Re: Disappointment with wifi... To: Mason Loring Bliss Cc: Ed Schouten , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 29 Jul 2016 02:35:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 01:05:49 -0000 Hi! FreeBSD wireless progresses at the rate at which people pay for FreeBSD! You should let your vendor know about your problem! Ok, so that aside: * I use iwn daily at home and at work, it doesn't have issues; * whenever I or other developers see issues, we try to fix them! So, given that, let's figure out what's going on. You should totally start by doing this: $ ifconfig -v wlan0 list sta $ ifconfig -v wlan0 $ ifconfig -v wlan0 list scan Then let's see what's going on! THanks, -adrian From owner-freebsd-hackers@freebsd.org Fri Jul 29 05:17:14 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81DDFBA7588 for ; Fri, 29 Jul 2016 05:17:14 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 652D31C31 for ; Fri, 29 Jul 2016 05:17:14 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 9893D1404 for ; Fri, 29 Jul 2016 05:17:07 +0000 (UTC) Subject: Re: Disappointment with wifi... To: freebsd-hackers@freebsd.org References: <20160728191950.GF4313@blisses.org> <20160728205036.GG4313@blisses.org> From: Allan Jude Message-ID: Date: Fri, 29 Jul 2016 01:17:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 05:17:14 -0000 On 2016-07-28 21:05, Adrian Chadd wrote: > Hi! > > FreeBSD wireless progresses at the rate at which people pay for > FreeBSD! You should let your vendor know about your problem! > > Ok, so that aside: > > * I use iwn daily at home and at work, it doesn't have issues; > * whenever I or other developers see issues, we try to fix them! > > So, given that, let's figure out what's going on. You should totally > start by doing this: > > $ ifconfig -v wlan0 list sta > $ ifconfig -v wlan0 > $ ifconfig -v wlan0 list scan > > Then let's see what's going on! > > THanks, > > > > -adrian > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > I have a T530, it has the same 6205 wifi chip, and it works fine. I have sometimes had better luck by disabling ht20 (ifconfig wlan0 -ht20), but I don't recall the last time I had to do that. -- Allan Jude From owner-freebsd-hackers@freebsd.org Fri Jul 29 07:31:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FC90BA76DF for ; Fri, 29 Jul 2016 07:31:55 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2101BFC for ; Fri, 29 Jul 2016 07:31:55 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1bT2Gu-0004YH-88; Fri, 29 Jul 2016 09:31:52 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bT2Gt-0004t8-T4; Fri, 29 Jul 2016 09:31:52 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CD93E2A1807; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wcLaQW6QAwwr; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 536322A180B; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ikIC7FLfqwyZ; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from mauderer-linux.eb.localhost (unknown [10.10.171.6]) by mail.embedded-brains.de (Postfix) with ESMTPSA id E844C2A1807; Fri, 29 Jul 2016 09:31:59 +0200 (CEST) Subject: Re: Changes to pfctl to allow easier integration into a library To: "Bjoern A. Zeeb" References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> Cc: "freebsd-hackers@freebsd.org" From: Christian Mauderer Message-ID: Date: Fri, 29 Jul 2016 09:31:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/21989/Fri Jul 29 08:57:54 2016) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:31:55 -0000 Am 28.07.2016 um 17:59 schrieb Bjoern A. Zeeb: > On 28 Jul 2016, at 14:03, Christian Mauderer wrote: >=20 >> Hello, >> >> I'm currently working on a porting pfctl to a real-time operating >> system. This is done using the same framework that Sebastian Huber >> mentioned here (and probably at some other occasions): >> > =E2=80=A6 >> Would the attached patches be acceptable for integration into the >> FreeBSD sources? >=20 > Hi, >=20 > (a) I=E2=80=99d prefer uintX_t to u_intX_t and I think FreeBSD is using= the > former generally. >=20 > (b) All the variables you pulled out of functions that are not const, > would need to be virtualised for VIMAGE, as otherwise one virtual > network stack could affect another. >=20 > Would you be willing to look into this? >=20 > Gruesse > /bz Hello Bjoern, thanks for the feedback. Regarding (a): Normally I would prefer the POSIX names from stdint.h too. But it seems that the whole pfctl code uses the u_intX_t names. Therefore I used this naming convention too. I think if the type names are changed, this should be done in one commit for the whole pfctl code. Should I create such a patch? Regarding (b): Of course I can look into it. I only have the problem that I didn't know VIMAGE before you mentioned it. I took a quick glance at the following page: https://wiki.freebsd.org/VIMAGE/porting-to-vimage It seems to me that this is meant for kernel code only and not for a user space application like pfctl. Did I miss something? Is the pfctl code used directly in the kernel somewhere? Or is the virtualisation also necessary for user space tools? Please don't understand me wrong: I have no problem doing the work. On contrary: As far as I can tell, the macro wrappers that are used in files like sys/netinet/igmp.c could be useful for our porting effort too. It seems that they wrap exactly the variables that are problematic for us. So it would be at least simpler to identify the problematic variables. It's even possible that we could use the macros to manipulate the variables in the way we need. Kind regards Christian Mauderer --=20 -------------------------------------------- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.mauderer@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Fri Jul 29 10:15:14 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6BFBA6925 for ; Fri, 29 Jul 2016 10:15:14 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A753D1E62 for ; Fri, 29 Jul 2016 10:15:12 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.2.88]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0M8hRj-1b6TLO07FL-00wGCi for ; Fri, 29 Jul 2016 12:09:53 +0200 Received: from bsch by becker.bs.l with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bT4jo-0001eR-6y for freebsd-hackers@freebsd.org; Fri, 29 Jul 2016 12:09:52 +0200 Date: Fri, 29 Jul 2016 12:09:52 +0200 From: Bertram Scharpf To: freebsd-hackers@freebsd.org Subject: Re: Segfault in OpenSSL even though GnuTLS demanded Message-ID: <20160729100952.GA4967@becker.bs.l> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> <20160728213717.GA98586@becker.bs.l> <7483738d-01e7-0bb2-81e9-9c26d8ef8c9f@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7483738d-01e7-0bb2-81e9-9c26d8ef8c9f@FreeBSD.org> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: Bertram Scharpf X-Provags-ID: V03:K0:4sFu6FWq6BltJFPBzdOBbtUPWxRMA8tXa5AEEURe3JYe3cFYsX7 +Cqz+CU1FRuJvr5SA52+ivOhBscZNuKiFtxhmFrlhJVCQ7p8rPRHe0Y5NQlMbcHa4cC6i7L s5CJN/WcAN/8lkuDBIxmyxtrHlVt5TPwBMsauS9sOi9mKvxEABCFpDW7u+H0vgYsKvSzykv y9+tkkqyufjONuTumKRJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:mPkCnPhLN6Q=:shOwxrC0Y5h5nSHd9FNQgU xM5DTj0EuozLW+7zYKfwjwtWTC+Q98lOxVMVjLUfwLNuo0GBggaMMkHgS/DSmNEasg/I7ZORx iIp9WszBKjtQprFk9VqM+tqCQXfqmCjUY6npsxOC36s6vsXXNVM1jrqVLMlFzu3eACIo8qEST FpwUWwQWw0bz5TKs/Xl8VFp/Ks9hMlzXBRrnAVDykU9zSP08krKrzSGMTmye3hOAdZKxO0YDN v4QRG/hlBBl4QrlMKN3T+z8lBfGYBL2jOJ8LJrFOsTLDbA83wpGIiJkfl9khe+KNgK9TSB+Rc uZIsFDHdJ53F2vhoLohCDXX5Fs3QZHURhNbXKK+ezV4rQD7JIr1S/E4jsvoSzdZ3V6/rTrv0E 4j8LtSalNq6WNvBxOS5qbSSD9nEK9ffVrNWWCILN8ALGKQMCE4MEAe3vdmoHrswhYuL2Wcyqq jKjBHT3fdMb/cIrh+X8JEc8keti/wZbLCN87x9zPB4wDBePjrxlukMcGiBTfRmQn6ah6V0qv1 vtIwcWNb9af7ivIhRZriSYKIGtHRj/6oejGdI8tLXKeUzaCL2g4T3iUBoYYdixN6nA2E2vVDo m+7wIMbqLD/GIQINcxIJqzUFCluWH4gNNC00BwOvwWpPwDIdO6yDvYLiGkvWY0EziRRNswIsn QtBc8BuRwPfvi0surPz/Regw0Ub2OwGwSth1X34lKrZ67/Ue1rOFK3k9rkr4pu2sypyQ= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 10:15:14 -0000 On Thursday, 28. Jul 2016, 17:56:46 -0400, Jung-uk Kim wrote: > On 07/28/16 05:37 PM, Bertram Scharpf wrote: > > On Thursday, 28. Jul 2016, 17:25:50 -0400, Jung-uk Kim wrote: > >> On 07/28/16 04:55 PM, Bertram Scharpf wrote: > >>> On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: > >>>> On 07/28/16 02:02 PM, Bertram Scharpf wrote: > >>>>> > >>>>> Program received signal SIGSEGV, Segmentation fault. > >>>>> [Switching to Thread 29403080 (LWP 101275/mcabber)] > >>>>> 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 > >>>> > >>>> Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a > >>>> Kerberos issue. > >>> > >>> No errors. They do all exist. I double-checked it: > >>> > >>> $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=>\s*(\S+)/ and not -e $1 and print $1' > >> > >> I guess you misunderstood. I didn't mean you have a missing library. I > >> believe it links *two* libcrypto.so's, i.e., one from base and one from > >> ports. > > > > Indeed: > > > > # ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | grep libcrypto > > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28d00000) > > libcrypto.so.7 => /lib/libcrypto.so.7 (0x2925b000) > > > > So, how could I resolve this? > You may ask its maintainer (gnome@FreeBSD.org) to add USES+=gssapi and > add an option to select GSS-API from ports. Another solution may be > removing all packages depending on /usr/local/lib/libcrypto.8 and > rebuilding them with base OpenSSL. I cannot remove _all_ packages that depend on OpenSSL. # pkg info -qr openssl-1.0.2_14 | wc -l 38 The first thing I do not understand is why it is so important for so many packages to pull in the package. # openssl version OpenSSL 1.0.1t-freebsd 3 May 2016 # /usr/local/bin/openssl version WARNING: can't open config file: /usr/local/openssl/openssl.cnf OpenSSL 1.0.2h 3 May 2016 The second thing I do not understand is why GSS-API should help. I searched for USES+=gssapi and did find only four projects that really have it. None of them is installed here. $ rbfind /usr/ports 'prune if name == "work" ; name == "Makefile" and grep /\bUSES.*gssapi/' Many ports have GSSAPI disabled here and they do not segfault because of an OpenSSL conflict. Example: # grep -h 'SET.*GSS' /var/db/ports/databases_postgresql95-*/options OPTIONS_FILE_UNSET+=GSSAPI OPTIONS_FILE_UNSET+=GSSAPI The third thing I do not understand is why there is an OpenSSL conflict at all. I definitely told loudmouth to use GnuTLS. # grep SSL\\\|TLS /var/db/ports/net-im_loudmouth/options _FILE_COMPLETE_OPTIONS_LIST=DOCS GNUTLS OPENSSL OPTIONS_FILE_SET+=GNUTLS OPTIONS_FILE_UNSET+=OPENSSL # cd net-im/loudmouth # make run-depends-list build-depends-list | grep ssl\\\|tls /usr/ports/security/gnutls /usr/ports/security/gnutls This appears to be a real port bug to me. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Fri Jul 29 12:28:23 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC698BA8E3D for ; Fri, 29 Jul 2016 12:28:23 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC78A1271 for ; Fri, 29 Jul 2016 12:28:23 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from [127.0.0.1] (unknown [107.15.73.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id B7F8B239442 for ; Fri, 29 Jul 2016 08:28:22 -0400 (EDT) Subject: Re: Disappointment with wifi... To: freebsd-hackers@freebsd.org References: From: Nikolai Lifanov Message-ID: Date: Fri, 29 Jul 2016 08:28:21 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 12:28:23 -0000 On 07/29/16 08:00 AM, freebsd-hackers-request@freebsd.org wrote: > Hi all. I'm coming to you with a minor existential crisis. :) > > I've got a Thinkpad T420, initially purchased as my best bet for FreeBSD > hardware compatibility. For wifi it has Centrino Advanced-N 6205 [Taylor > Peak]. > I have a workstation with 11.0-BETA2 on it and this card: iwn0@pci0:10:0:0: class=0x028000 card=0x13018086 chip=0x00828086 rev=0x34 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6205 [Taylor Peak]' class = network For what it's worth, mine is stable and works like a charm. > I did a fresh install of 11.0-BETA2 the other day, and that worked well > enough, up to and including finding local wifi and initially connecting. > > However, on boot, dhclient keeps saying, repeatedly: > > send_packet: Network is down > send_packet: No buffer space available > - Nikolai Lifanov From owner-freebsd-hackers@freebsd.org Fri Jul 29 13:11:28 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5741BA7B5F for ; Fri, 29 Jul 2016 13:11:28 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56D1E10E9 for ; Fri, 29 Jul 2016 13:11:28 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id f93so5294154lfi.0 for ; Fri, 29 Jul 2016 06:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=u/LuC18lMPU9eFWNbUbLtsZrNqXs2NeHNpN8QvsxMcs=; b=ThZHnhH3XGVl4CJnDzHUkSGHVXckCrmWCHe0qfCB9rsf+fmNUhGKlosb6U436br0qx IayHAHUv9nsuqfdp+ReJxCCBdh5PQx2/7Kbvycngy1coAcQ3bTitSHJFjlYIjS4bzfeA eQQJnjLBEV3Wjyo0LFEKuwHiTo6VNJpXtcW0ZUgusIZUAsRnCo/E0/mmYBzg2uGnYost rBoDdx+GxjE5ZDe2MBU4xt9Jf6MiLYsf5ZowYCBzeGRX9jFgI+yFBDi+IHdG3jCvPOd5 JLXcTw5Ckr3HK0l7k1cTjur8x7zgK++RgZz3sUfTMQ9RXJ8Om++KW7ngG3F6wsAPF7Xe 8YWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u/LuC18lMPU9eFWNbUbLtsZrNqXs2NeHNpN8QvsxMcs=; b=QUENP2+mOExSpEi/FAwqeHS6ukmuytMWoyVnk2vkkMCQG+xLzRNrr9Ra1yIVDSJ9bP j8fPuK62hutcGkhtT8Ucfr9fIMvRo/yJaYfy2CMz00pX3n4LqHyqZg41f2sLl0RGZ1HB hLLo/84IL6Y48FViR92QSgYQhAwBt9iI1JsLlAaCwk0r84K+iTSbPx9Wp4iVXvU0NAr6 n34OHYFjxWwBkXERkWjU1yYm33dLm0HyFDwVnQt1HNyQlnE4kKGB3xgwvr3boY4EMLF6 XLLTQkvSKI08OhCo57X6wHnD0ww3MN8WUDbwZ34MlXNmnCi513gKGvwZyUcgrQtXiqvh Q62w== X-Gm-Message-State: AEkoout8cwy/kIdq6/din6MyemDfK1WHNTtXrNRWOY9GD3gx6TAH9Ty06d+1S05s2q/lyZfA47IXtr0w0Q3zEA== X-Received: by 10.25.149.76 with SMTP id x73mr14019999lfd.27.1469797885706; Fri, 29 Jul 2016 06:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.29.193 with HTTP; Fri, 29 Jul 2016 06:11:25 -0700 (PDT) From: Adam Starak Date: Fri, 29 Jul 2016 15:11:25 +0200 Message-ID: Subject: Modify user space from kernel. To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:11:28 -0000 Hello! My name is Adam. I participate in Google Summer of Code this year. I came up with a big problem, which doesn't allow me to go further in my project. I made a new syscall, which is going to retrieve sysctl data and put it inside the nvlist. And here my problem is. I need to move somehow this data (packed nvlist) into the user space. Is there any chance to pass data from kernel to user space without knowing the size of it? Right now, the implementation of __sysctl() function requests void pointer and size in order to get data. If allocated memory is too low, it returns ENOMEM and you need to realloc the data. I wanted to avoid this situation. Best regards, Adam Starak From owner-freebsd-hackers@freebsd.org Fri Jul 29 13:53:13 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5406BA6767 for ; Fri, 29 Jul 2016 13:53:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 795EC1668 for ; Fri, 29 Jul 2016 13:53:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bT7kd-000NA7-2P; Fri, 29 Jul 2016 16:22:55 +0300 Date: Fri, 29 Jul 2016 16:22:55 +0300 From: Slawa Olhovchenkov To: Adam Starak Cc: freebsd-hackers@freebsd.org Subject: Re: Modify user space from kernel. Message-ID: <20160729132254.GD46309@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:53:13 -0000 On Fri, Jul 29, 2016 at 03:11:25PM +0200, Adam Starak wrote: > Hello! > > My name is Adam. I participate in Google Summer of Code this year. I came > up with a big problem, which doesn't allow me to go further in my project. > > I made a new syscall, which is going to retrieve sysctl data and put it > inside the nvlist. And here my problem is. I need to move somehow this data > (packed nvlist) into the user space. Is there any chance to pass data from > kernel to user space without knowing the size of it? > > Right now, the implementation of __sysctl() function requests void pointer > and size in order to get data. If allocated memory is too low, it returns > ENOMEM and you need to realloc the data. I wanted to avoid this situation. char *intrname; size_t inamlen; sysctlbyname("hw.intrnames", NULL, &inamlen, NULL, 0); intrname = malloc(inamlen); sysctlbyname("hw.intrnames", intrname, &inamlen, NULL, 0); NB: check error! From owner-freebsd-hackers@freebsd.org Fri Jul 29 13:55:52 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5186BA6849 for ; Fri, 29 Jul 2016 13:55:52 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 664C817E6 for ; Fri, 29 Jul 2016 13:55:52 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id f93so71957278lfi.2 for ; Fri, 29 Jul 2016 06:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ovc1HR++LRxC3vyn+KZtSB6Yh05WZsSpVW+r9zvhCNg=; b=F8yI/A+EUnJbw6lWlh86F1MBDFLfP1VKHCNoqfTBxZl8bzND4SMJLPeGWHr+OyV66D gi8OcS8H96sQyslMqgtEuNm76xAILsEj+ctinWzGBOLcDu75bz3soYwmY7fsaTXXRogr mUFzkOcWVCzxfLpKRbLeOX+9vmDGauLOEbJc5v5IKsUwQYq+iRY6lnjKiVZdiDZLnnL2 csT43PMbJANly2IzGrUq4DlYIv5Uoyq5cYysM4xcslOFSWsLisUK0cLrrJ7RZMfzoPG/ e8olsVhWoYjvQ5eUjPP9TwLzyrBFlYeiTk4cskURJXyCvuzLLVDLGQ90MLfpM9e39IEL w6Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Ovc1HR++LRxC3vyn+KZtSB6Yh05WZsSpVW+r9zvhCNg=; b=JAzms0uohZsNMjURW+FFF+Xr/kGbDWt3bEmgVHR1XVWt2qx2XSGRxdFUa07gNQAJFc c2Zn7SW/1pPtown0PJYzkBK/QV4ISValY/d27iCThdetBNTLFhfddPyxo1IOeAMmxTW8 y7WzczwyzMB7syCTNC5ZDlZ88++N6WmQeSU91MR4LJJnCIPMGpT3VCkbqOfMNIqS1TF8 rS+gX47TUBFnF00QsFysVGjYouBAVgMcVxhdhsE7vPwzGlr30YBmxhYlNor0hApLcbpc osQ8KzuUpcAsnJUJ1wjyJ9CpowhUdVJpD9FyCrMbO48N8TB6fagZ2eCyBzNhfd0bTB5X 1I5g== X-Gm-Message-State: AEkooutF27TFgI4JPaco5i52mQpU2d/1GqbOTemFHUvWaBLgFt6uVfeW1LG980h0F58dpw== X-Received: by 10.25.27.70 with SMTP id b67mr13245662lfb.218.1469800550400; Fri, 29 Jul 2016 06:55:50 -0700 (PDT) Received: from [192.168.0.11] (d84-146.icpnet.pl. [77.65.84.146]) by smtp.gmail.com with ESMTPSA id p102sm2735762lfi.9.2016.07.29.06.55.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jul 2016 06:55:49 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: can anyone explain how UFS ACLs work actually From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Fri, 29 Jul 2016 15:55:48 +0200 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <90C9626E-6A77-4314-AD01-A1148BEA3112@FreeBSD.org> References: To: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 13:55:53 -0000 Dnia 28.07.2016 o godz. 18:55 Wojciech Puchar napisa=C5=82= (a): > i turned UFS ACL on one filesystem. >=20 > added some entries and default entries for one directory. added say user j= ohn with rwx permissions You need NFSv4 ACLs for Windows, not the POSIX ones. (And, generally speaki= ng, 49% of Samba code for dealing with permissions is unused and obsolete, w= hile another 49% is useless and harmful; the trick is to configure the latte= r to do as little as possible.) From owner-freebsd-hackers@freebsd.org Fri Jul 29 15:11:19 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6BD3BA7C35 for ; Fri, 29 Jul 2016 15:11:19 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8996C1562 for ; Fri, 29 Jul 2016 15:11:19 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 72B72194EA6 for ; Fri, 29 Jul 2016 11:11:16 -0400 (EDT) Date: Fri, 29 Jul 2016 11:11:14 -0400 From: Mason Loring Bliss To: FreeBSD Hackers Subject: Re: Disappointment with wifi... Message-ID: <20160729151114.GH4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YtWd7p+F4osuzCU+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 15:11:19 -0000 --YtWd7p+F4osuzCU+ Content-Type: multipart/mixed; boundary="nSa29feRGwiKgVww" Content-Disposition: inline --nSa29feRGwiKgVww Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2016 at 06:05:46PM -0700, Adrian Chadd wrote: > FreeBSD wireless progresses at the rate at which people pay for FreeBSD! > You should let your vendor know about your problem! That's what I'm doing now! :P > $ ifconfig -v wlan0 list sta > $ ifconfig -v wlan0 > $ ifconfig -v wlan0 list scan Alright. I'm attaching these. The signal strength is pretty weak despite my being somewhat close to the WAP. (Which is, FWIW, a node in a small Unifi zero- handoff network.) That said, I manage solid connection with this lapt= op in the same spot running Linux, and with MacBooks. I'll happily supply more diagnostic information, as needed. On Fri, Jul 29, 2016 at 01:17:07AM -0400, Allan Jude wrote: > I have a T530, it has the same 6205 wifi chip, and it works fine. Same here running Linux. It's only problematic with FreeBSD driving the hardware. I'd very much like FreeBSD to be driving this unproblematically. > I have sometimes had better luck by disabling ht20 (ifconfig wlan0 > -ht20), but I don't recall the last time I had to do that. This was briefly hopeful. I set that in rc.conf and rebooted, and I got a quick, solid connection. But then through several subsequent reboots my wifi light is flashing and connectivity is sporadic at best, with the same messages piling into the console. --=20 Mason Loring Bliss (( "In the drowsy dark cave of the mind dreams mason@blisses.org )) build their nest with fragments dropped http://blisses.org/ (( from day's caravan." - Rabindranath Tagore --nSa29feRGwiKgVww Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=typescript Content-Transfer-Encoding: quoted-printable Script started on Fri Jul 29 10:29:09 2016 root@elided:~ # ifconfig -v wlan0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG =20 ElidedStationMAC 11 6 18M 14.5 0 25 4112 EPS AQE SSID RATES DSPARMS<6> TIM<0505000100021= 2> ERP<0x0> RSN XRATES HTCAP HTINFO WME ATH<0x7fff> VEN root@elided:~ # ifconfig -v wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether ElidedMAC inet ElidedIP netmask 0xffffff00 broadcast ElidedBroadcast=20 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet OFDM/18Mbps mode 11g status: associated ssid ElidedBSSID channel 6 (2437 MHz 11g) bssid ElidedStationMAC regdomain FCC country US anywhere -ecm authmode WPA2/802.11i -wps -tsn privacy ON deftxkey UNDEF AES-CCM 2:128-bit powersavemode OFF powersavesleep 100 txpower 30 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 10 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 =20 roam:11ng rssi 7dBm MCS 1 =20 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS -ht htcompat ampdu ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi htprotmode RTSCTS -puren -smps -rifs -stbc wme -burst -dwds roaming MANUAL bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm groups: wlan=20 root@elided:~ # ifconfig -v wlan0 list scan SSID/MESH ID BSSID CHAN RATE S:N IN= T CAPS ElidedBSSID ElidedStationMAC 6 54M -74:-95= 100 EPS SSID RATES DSPARMS<6>= TIM<05050001000212> ERP<0x0> RSN = XRATES HTCAP HTINFO WME ATH<0x7fff= > VEN linksys2 00:26:b8:be:9a:db 6 54M -91:-95 10= 0 EPS SSID RATES DSPARMS<6> PWRCNSTR<= 200100> ERP<0x0> XRATES<48,72,96,108> WME HTCAP HTINFO ATH<0x7fff> VEN COUNTRY root@elided:~ # exit exit Script done on Fri Jul 29 10:29:34 2016 --nSa29feRGwiKgVww-- --YtWd7p+F4osuzCU+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXm3ISAAoJEJ6yV3B27yVVsDsQAJOdKJYAn1VXvRCa0Z/9dr48 4WCvhRRGdt35blYcUpNlqNFozpN80iHaFZPRyA9rQ3nWeLfm7S0k+9CSvfw0q1rr dKZHEFMKObTpb75NrcAugCAhjVp1+jqTWRqZROjUsiQb+XAETj7WgRsaXdf8fz8H PT0KPEbsUjp7KHtTjMhkXlat0vZk6ZBGnHU13WhYCg9wxt8YKpX6FaqbubUM8Cku wxGAMn4H9hNrWJkboJn+JH2wJ+86j2LoPyC+CBUT6r3y9dnbB+u992DdsNeOylvA BXtjlxhVw6mQv5OmUEWayYmTNrJDJOcmWKBO0mt3R3eokzxdsw/nokmCzbfYTlNE wwUq8yemYzawgbABsp4HqFx1jVo/YE0RJk2B6/Nve1bae95Vz5g+so+zPOj9WCxl Z7i+jKs6W0Cia876udeZBjzaUn2P0A6+uvRU7Dm6kxaZsNu6Mt1FADUW8AU42Yxy N6xVnh8mJu4ZGclXp5Z+63eJD4af1M4lyaLwRyBnKbYgj+GnXZ1evJe/wQSiIMkb 74sn8j0AdRK0zxIfDT+6fvmX5YB9I4bIFJvJs1fB7IwkKB8WoX2YMp1xKiI5NARn d2A0KWNivP8vP3E1RHfvAtwugR3GMCuSnjvM2JQYfZMwvdjKjxqSmKpCgpCLRWwo 403c16mpDfkjW+ZgdwTN =rSHI -----END PGP SIGNATURE----- --YtWd7p+F4osuzCU+-- From owner-freebsd-hackers@freebsd.org Fri Jul 29 16:05:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 700E8BA8C55 for ; Fri, 29 Jul 2016 16:05:43 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42C6B1956 for ; Fri, 29 Jul 2016 16:05:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f42.google.com with SMTP id f6so112039007ith.0 for ; Fri, 29 Jul 2016 09:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=iOg9itSckkx4+635eV66zoiN4cM9yYgnWkOhCoxkVjA=; b=PNiQo5codMTlIgnHHMeY8HcpSqWY66tCI6YrqyrmV5m3neu6bhYQRLnzHYL3BZGera PnpRi3J2kmc0Ik1wcMmQDDxkYw1rhqt7mt2aG8xMkvYNo6IBF+hNOfsBQ7gH1PgAzmjN b2dzZgo5YvgiPpKbBmTosTSibjJSOtWD9frzc/GEQwBhGLuv47ivc7pepyOj1lOQLeCB YbwKnA3aEFdAyczqc4bjp8a08g7JWwdpJpl9O0PoOJxlmnAQnmDOmMkcXg5rqxH4bLLU c9nrTWdxpuEzhVnJjZr23tkM5LyHesw5gyrH1ak4QTDY+ZSeXlSCQdwEWW3xwUtiQNb+ J2Bg== X-Gm-Message-State: AEkoouuClh927NFm8Jvbv452K73lmxfbkO5OP49Cw6P9x2DLsIqGuS2VnKNqLf8vm2tVDA== X-Received: by 10.36.209.130 with SMTP id w124mr2139692itg.2.1469808336033; Fri, 29 Jul 2016 09:05:36 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id 97sm7447925ioi.12.2016.07.29.09.05.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 09:05:35 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id m101so132659312ioi.2 for ; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) X-Received: by 10.107.56.70 with SMTP id f67mr46768817ioa.162.1469808335597; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.233.67 with HTTP; Fri, 29 Jul 2016 09:05:35 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Fri, 29 Jul 2016 09:05:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Modify user space from kernel. To: Adam Starak Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:05:43 -0000 On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wrote: > Hello! > > My name is Adam. I participate in Google Summer of Code this year. I came > up with a big problem, which doesn't allow me to go further in my project= . > > I made a new syscall, which is going to retrieve sysctl data and put it > inside the nvlist. And here my problem is. I need to move somehow this da= ta > (packed nvlist) into the user space. Is there any chance to pass data fro= m > kernel to user space without knowing the size of it? > > Right now, the implementation of __sysctl() function requests void pointe= r > and size in order to get data. If allocated memory is too low, it returns > ENOMEM and you need to realloc the data. I wanted to avoid this situation= . Hey Adam, That is the usual way to do it. Just curious =E2=80=94 why do you want to avoid that situation? Your other option might be to put an upper limit on the size of the result, and pass a buffer of that size in from userspace. But then you are artificially limited to some arbitrary size and must preallocate a large buffer even in the case that the output is small. Best, Conrad From owner-freebsd-hackers@freebsd.org Fri Jul 29 16:49:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78045BA7C33 for ; Fri, 29 Jul 2016 16:49:59 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C9FF1362; Fri, 29 Jul 2016 16:49:59 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id o80so160228737wme.1; Fri, 29 Jul 2016 09:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3z0pheZ5eF0z69R6nqVkcCcFIybTg2iPwIqax6JFmNc=; b=Yq8X1M7KbY33dGT3GztS1KnwGJYQC2HYRNBiYMSaMqlZO4IPdu7Lmm7P670gvEy/XG fMezxgWIXUDYB/VUn6IVwKLFurdZdLRyTVEaJc5YYb2KLRqbEw5X5c03xGRhoi/hQNbv wTBeVYlYvDQP7KXikApNpNfKJbj2lhlTBEH9mpVNi7Ts7Hq66KuVeGFW9e+qGZu/se2n cwcrhN2iZ3+hhRFRJOrlm5E8uvCFAUml+cgc7Id2BWa6TDkbA1luwnaN4tQSqJ6gUG6W tDXALU7iAx8Ul17k1OtDAM203AQFMhf5Y9pa8br4A+lZAQ8QKSc3zSqF8lQZFpoVswil 0Gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3z0pheZ5eF0z69R6nqVkcCcFIybTg2iPwIqax6JFmNc=; b=grMzgoy94P7z5AmeDVWKP5vm/fwIyf/c/lt4ynfDS0quhN2i0CXD/3xjuk9AvvezZh bSDFcFqadt3NP9les2OWvF3lX+Dnp4xPAvJPoYJOnjIZ3w++fEs69S7FJOseS0fPtG13 XiQy3MYaKjkJCLI8jvfyw7JLwDtyxKuwXi+zaCQQQNPeXpMYqbZaRNQsf8E3QAK6Qh6q bNLH4/I7rCt7VugSBGuTPQICxoyB2SLk8h4Hsz1T6JOFnKxTN2+j25pDnQGt2xbzBXL0 +g2hC6bDrRFqX/zEHrbiX81/z0fqmJjiSGdHZbch/9+TRmzFZ/96TsWUoXrDSVgq6EFX xA9w== X-Gm-Message-State: AEkoouuRvd04GmQ3RcGFSWli6Sk3kPC4g99QwTlY5YbrV/rBMdTuRIDWpOZEbNmluR+Nsg== X-Received: by 10.28.100.70 with SMTP id y67mr2078845wmb.23.1469810997055; Fri, 29 Jul 2016 09:49:57 -0700 (PDT) Received: from [100.84.96.220] (188.146.71.199.nat.umts.dynamic.t-mobile.pl. [188.146.71.199]) by smtp.gmail.com with ESMTPSA id q187sm3845498wma.17.2016.07.29.09.49.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jul 2016 09:49:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Modify user space from kernel. From: Adam Starak X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Fri, 29 Jul 2016 18:49:55 +0200 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> References: To: cem@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:49:59 -0000 My project is focused on nvlist. I'm improving and expanding its usage. Nvli= st can be used in userland as well as in kernel. My goal is to establish com= munications between them via nvlist. That's why setting a fixed size or loop= ing doesn't satisfy me. It'll be some kind of IPC, not only for sysctl ofc.=20= Best regards, Adam Starak Dnia 29.07.2016 o godz. 18:05 Conrad Meyer napisa=C5=82(a)= : >> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wrot= e: >> Hello! >>=20 >> My name is Adam. I participate in Google Summer of Code this year. I came= >> up with a big problem, which doesn't allow me to go further in my project= . >>=20 >> I made a new syscall, which is going to retrieve sysctl data and put it >> inside the nvlist. And here my problem is. I need to move somehow this da= ta >> (packed nvlist) into the user space. Is there any chance to pass data fro= m >> kernel to user space without knowing the size of it? >>=20 >> Right now, the implementation of __sysctl() function requests void pointe= r >> and size in order to get data. If allocated memory is too low, it returns= >> ENOMEM and you need to realloc the data. I wanted to avoid this situation= . >=20 > Hey Adam, >=20 > That is the usual way to do it. Just curious =E2=80=94 why do you want to= > avoid that situation? >=20 > Your other option might be to put an upper limit on the size of the > result, and pass a buffer of that size in from userspace. But then > you are artificially limited to some arbitrary size and must > preallocate a large buffer even in the case that the output is small. >=20 > Best, > Conrad From owner-freebsd-hackers@freebsd.org Fri Jul 29 16:55:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21A34BA7DDB for ; Fri, 29 Jul 2016 16:55:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73191792 for ; Fri, 29 Jul 2016 16:55:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id f6so113308195ith.0 for ; Fri, 29 Jul 2016 09:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=kQxXCLTPF1+GhFXQLrjCmieLCUIKjLvgfm7pN1WJsjY=; b=YENu939FhcxTsqdaLAgnwaD6StwdZceKAfNTmbC3m1eG6zPcTuFP/UcSb2p5GwwzYn +K+AWw62B9KkLX7fasNIoncr4McBG0NyrIflVlHMV8fNU24YB/qtQFXyKTVYOSzzNMxk srpFdr+AftFImaqw8BnFr4ttJ1GUN8hF1nM+2AJK0RS0rogln7g7Yyt0w2GZwiU6KVwz 5Z4jIMnZStu84n17EFU5mU6vkkFCtrTdwo98Kw9eh6ekNBwPxIbHsMI1NLvjPhACrWis ld6H3r34nldqAakNd4ToS+wBd1pQDN3awjBr6Fq/UZCKFVRsQkdljmtpb6rGce9Z0HwM WuQA== X-Gm-Message-State: AEkoouu7j4OYl1ttfLouZeMCta2dEQuwSaxgdiFpc0fbSCsjhXDlzUybueYtMxbwQeoK9w== X-Received: by 10.36.189.7 with SMTP id x7mr7964317ite.97.1469811350333; Fri, 29 Jul 2016 09:55:50 -0700 (PDT) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com. [209.85.214.41]) by smtp.gmail.com with ESMTPSA id f9sm7529740ioi.2.2016.07.29.09.55.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 09:55:50 -0700 (PDT) Received: by mail-it0-f41.google.com with SMTP id u186so198082180ita.0 for ; Fri, 29 Jul 2016 09:55:50 -0700 (PDT) X-Received: by 10.36.189.7 with SMTP id x7mr7964291ite.97.1469811349884; Fri, 29 Jul 2016 09:55:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.233.67 with HTTP; Fri, 29 Jul 2016 09:55:49 -0700 (PDT) In-Reply-To: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> References: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> From: Conrad Meyer Date: Fri, 29 Jul 2016 09:55:49 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Modify user space from kernel. To: Adam Starak Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 16:55:57 -0000 Hi Adam, You could create a pipe or socket if there will be continuous IPC between kernel and userspace. Sockets have defined behavior around message boundaries. For that approach, you could look at the implementation of sys_socket or sys_pipe2. Or maybe the best approach is just to define some new address family. I'm not sure what the standards allow. Best, Conrad On Fri, Jul 29, 2016 at 9:49 AM, Adam Starak wrote: > My project is focused on nvlist. I'm improving and expanding its usage. N= vlist can be used in userland as well as in kernel. My goal is to establish= communications between them via nvlist. That's why setting a fixed size or= looping doesn't satisfy me. It'll be some kind of IPC, not only for sysctl= ofc. > > Best regards, > Adam Starak > > Dnia 29.07.2016 o godz. 18:05 Conrad Meyer napisa=C5=82= (a): > >>> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wr= ote: >>> Hello! >>> >>> My name is Adam. I participate in Google Summer of Code this year. I ca= me >>> up with a big problem, which doesn't allow me to go further in my proje= ct. >>> >>> I made a new syscall, which is going to retrieve sysctl data and put it >>> inside the nvlist. And here my problem is. I need to move somehow this = data >>> (packed nvlist) into the user space. Is there any chance to pass data f= rom >>> kernel to user space without knowing the size of it? >>> >>> Right now, the implementation of __sysctl() function requests void poin= ter >>> and size in order to get data. If allocated memory is too low, it retur= ns >>> ENOMEM and you need to realloc the data. I wanted to avoid this situati= on. >> >> Hey Adam, >> >> That is the usual way to do it. Just curious =E2=80=94 why do you want = to >> avoid that situation? >> >> Your other option might be to put an upper limit on the size of the >> result, and pass a buffer of that size in from userspace. But then >> you are artificially limited to some arbitrary size and must >> preallocate a large buffer even in the case that the output is small. >> >> Best, >> Conrad From owner-freebsd-hackers@freebsd.org Fri Jul 29 17:00:56 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 950E9BA808B for ; Fri, 29 Jul 2016 17:00:56 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55DD81ACA for ; Fri, 29 Jul 2016 17:00:56 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id l65so114216279oib.1 for ; Fri, 29 Jul 2016 10:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=th++wD/9kEemCDycPu0qN6pNfnpMqCx9xGFN4xbnXW0=; b=eXM+q7xj16MWdyq1P9KPRdadEK9UZU3MYlwAVbcQlLUxRsboP5bL+nLagmgrxe3dgO MVMud7mYS2f8MhynBmzK4NugPPm1nmQmQ82+2KCBs5jFZ0wiV0A+zxJhONCTjQdlh9GC zvlIdzdcSG+Q/GS3XHzeBxu/D9ubwePi6nVxQqe7JDCp/40NpfpL1y46fhfirhffOYXQ 2LZiC9wa5HlGRROtPP3msXkjzFOLLaN3+sdZtytqmdrvrnO1tbmnVCez3lAnq5rDDFey jDp0+7ac62ZkuB8Ni4RzSKCTevWKm7R9hLSz+hL02ZkIfeZNaTIEXLpgKavNkrjKfJly DOaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=th++wD/9kEemCDycPu0qN6pNfnpMqCx9xGFN4xbnXW0=; b=THUAo39hZ3lmP3XKfHuowRPL3QJZWIK8EuneCU8qDluSFOIY9hdYsV6M47E6wSb9tx Smykom/1A2HeIXpCgM+hydF97xLfuONKuJkikO9ljcXVw1k+ECBxvH9QbbjEXG0oSQlt cEv2yXvuxKgjfaSPar9usrudQSLNHM3Yj9hHCBonHVgjI3rwmt89fQDNwUrUErrbsWSw CDJArQCBki1B70GSiMUDFb/v0sLDjjb+Y21zQknJH5EpAS3AUiP/2c9eqaK7d28mFwYe lJbM8+rXp7FRe5l3ztUzuK6XttneVm/+b8ZdxcqIgTioihkuiIsryVSRP6O8gf/iuOoR 3jKg== X-Gm-Message-State: AEkoouuBOJIUG2Too36fkpvc4M68kIBLkTkL6UnRYbnR4GIFo2Zd07pIeXJN1/fb6Prusf8i/gtkESwh92Ae2Q== X-Received: by 10.202.193.195 with SMTP id r186mr24167780oif.109.1469811654896; Fri, 29 Jul 2016 10:00:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.234 with HTTP; Fri, 29 Jul 2016 10:00:54 -0700 (PDT) In-Reply-To: <20160729100952.GA4967@becker.bs.l> References: <20160728180255.GA79509@becker.bs.l> <599ca93e-31ed-fcb4-75de-7d05667d928e@FreeBSD.org> <20160728205516.GA94239@becker.bs.l> <20160728213717.GA98586@becker.bs.l> <7483738d-01e7-0bb2-81e9-9c26d8ef8c9f@FreeBSD.org> <20160729100952.GA4967@becker.bs.l> From: Kimmo Paasiala Date: Fri, 29 Jul 2016 20:00:54 +0300 Message-ID: Subject: Re: Segfault in OpenSSL even though GnuTLS demanded To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 17:00:56 -0000 On Fri, Jul 29, 2016 at 1:09 PM, Bertram Scharpf wrote: > On Thursday, 28. Jul 2016, 17:56:46 -0400, Jung-uk Kim wrote: >> On 07/28/16 05:37 PM, Bertram Scharpf wrote: >> > On Thursday, 28. Jul 2016, 17:25:50 -0400, Jung-uk Kim wrote: >> >> On 07/28/16 04:55 PM, Bertram Scharpf wrote: >> >>> On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote: >> >>>> On 07/28/16 02:02 PM, Bertram Scharpf wrote: >> >>>>> >> >>>>> Program received signal SIGSEGV, Segmentation fault. >> >>>>> [Switching to Thread 29403080 (LWP 101275/mcabber)] >> >>>>> 0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 >> >>>> >> >>>> Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0". It looks like a >> >>>> Kerberos issue. >> >>> >> >>> No errors. They do all exist. I double-checked it: >> >>> >> >>> $ ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | perl -lne '/=>\s*(\S+)/ and not -e $1 and print $1' >> >> >> >> I guess you misunderstood. I didn't mean you have a missing library. I >> >> believe it links *two* libcrypto.so's, i.e., one from base and one from >> >> ports. >> > >> > Indeed: >> > >> > # ldd /usr/local/lib/libloudmouth-1.so.0.1.0 | grep libcrypto >> > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28d00000) >> > libcrypto.so.7 => /lib/libcrypto.so.7 (0x2925b000) >> > >> > So, how could I resolve this? >> You may ask its maintainer (gnome@FreeBSD.org) to add USES+=gssapi and >> add an option to select GSS-API from ports. Another solution may be >> removing all packages depending on /usr/local/lib/libcrypto.8 and >> rebuilding them with base OpenSSL. > > I cannot remove _all_ packages that depend on OpenSSL. > > # pkg info -qr openssl-1.0.2_14 | wc -l > 38 > > > The first thing I do not understand is why it is so > important for so many packages to pull in the package. > > # openssl version > OpenSSL 1.0.1t-freebsd 3 May 2016 > # /usr/local/bin/openssl version > WARNING: can't open config file: /usr/local/openssl/openssl.cnf > OpenSSL 1.0.2h 3 May 2016 > > > The second thing I do not understand is why GSS-API should > help. I searched for USES+=gssapi and did find only four > projects that really have it. None of them is installed > here. > > $ rbfind /usr/ports 'prune if name == "work" ; name == "Makefile" and grep /\bUSES.*gssapi/' > > Many ports have GSSAPI disabled here and they do not > segfault because of an OpenSSL conflict. Example: > > # grep -h 'SET.*GSS' /var/db/ports/databases_postgresql95-*/options > OPTIONS_FILE_UNSET+=GSSAPI > OPTIONS_FILE_UNSET+=GSSAPI > > > The third thing I do not understand is why there is an > OpenSSL conflict at all. I definitely told loudmouth to use > GnuTLS. > > # grep SSL\\\|TLS /var/db/ports/net-im_loudmouth/options > _FILE_COMPLETE_OPTIONS_LIST=DOCS GNUTLS OPENSSL > OPTIONS_FILE_SET+=GNUTLS > OPTIONS_FILE_UNSET+=OPENSSL > > # cd net-im/loudmouth > # make run-depends-list build-depends-list | grep ssl\\\|tls > /usr/ports/security/gnutls > /usr/ports/security/gnutls > > > This appears to be a real port bug to me. > > Bertram > > > -- > Bertram Scharpf > Stuttgart, Deutschland/Germany > http://www.bertram-scharpf.de It's not exactly a port bug, it's a consequence of how dynamic linking works. If you link against the base system GSSAPI you will pull in the base system OpenSSL as well and that can't be avoided regardless of which version of OpenSSL your port links against. The situation is exactly the same with for example ftp/curl, see this discussion from last year: https://lists.freebsd.org/pipermail/freebsd-ports/2015-April/098651.html -Kimmo From owner-freebsd-hackers@freebsd.org Fri Jul 29 17:46:45 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10870BA8C36 for ; Fri, 29 Jul 2016 17:46:45 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7E3A1E83 for ; Fri, 29 Jul 2016 17:46:44 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u6THkvJO020827 for ; Fri, 29 Jul 2016 10:47:03 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20160729151114.GH4313@blisses.org> References: <20160729151114.GH4313@blisses.org> From: "Chris H" Subject: Re: Disappointment with wifi... Date: Fri, 29 Jul 2016 10:47:03 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-Milter: Spamilter (Reciever: udns.ultimatedns.net; Sender-ip: 127.0.0.1; Sender-helo: ultimatedns.net; ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 17:46:45 -0000 On Fri, 29 Jul 2016 11:11:14 -0400 Mason Loring Bliss wrote > On Thu, Jul 28, 2016 at 06:05:46PM -0700, Adrian Chadd wrote: > > > FreeBSD wireless progresses at the rate at which people pay for FreeBSD! > > You should let your vendor know about your problem! > > That's what I'm doing now! :P > > > > $ ifconfig -v wlan0 list sta > > $ ifconfig -v wlan0 > > $ ifconfig -v wlan0 list scan > > Alright. I'm attaching these. The signal strength is pretty weak despite my > being somewhat close to the WAP. (Which is, FWIW, a node in a small Unifi > zero- handoff network.) That said, I manage solid connection with this laptop > in the same spot running Linux, and with MacBooks. > > I'll happily supply more diagnostic information, as needed. > > > On Fri, Jul 29, 2016 at 01:17:07AM -0400, Allan Jude wrote: > > > I have a T530, it has the same 6205 wifi chip, and it works fine. > > Same here running Linux. It's only problematic with FreeBSD driving the > hardware. I'd very much like FreeBSD to be driving this unproblematically. > > > > I have sometimes had better luck by disabling ht20 (ifconfig wlan0 > > -ht20), but I don't recall the last time I had to do that. > > This was briefly hopeful. I set that in rc.conf and rebooted, and I got a > quick, solid connection. But then through several subsequent reboots my wifi > light is flashing and connectivity is sporadic at best, with the same > messages piling into the console. Just a thought. But have you introduced any new hardware in the vicinity? I'm thinking there may be some additional interference that's possibly causing the weak signal strength. Just a possibility I thought worth mentioning, in case it saves some (otherwise) needless diagnostic(s). --Chris From owner-freebsd-hackers@freebsd.org Fri Jul 29 23:46:28 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B91DBA7DAD for ; Fri, 29 Jul 2016 23:46:28 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CC0E177F for ; Fri, 29 Jul 2016 23:46:27 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 91AB0194EA6; Fri, 29 Jul 2016 19:46:20 -0400 (EDT) Date: Fri, 29 Jul 2016 19:46:18 -0400 From: Mason Loring Bliss To: Adrian Chadd Cc: FreeBSD Hackers Subject: Re: Disappointment with wifi... Message-ID: <20160729234618.GQ4313@blisses.org> References: <20160729151114.GH4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I30T0A8abtL/6dyk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 23:46:28 -0000 --I30T0A8abtL/6dyk Content-Type: multipart/mixed; boundary="YiSnftFthKPM0z4v" Content-Disposition: inline --YiSnftFthKPM0z4v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2016 at 03:54:40PM -0700, Adrian Chadd wrote: > Heh. If you didn't pay, then there's no vendor. :) I'm counting the Foundation. =3Dsnicker=3D > Let's post a dmesg as well, in case it's something silly (like > firmware crashing or whatnot.) Attached. Although sadly there is no silliness to be found there. (Maybe using SSDs for RAID is silly. No *relevant* silliness, let's say.) It was a challenge, FWIW, getting the net up to actually scp the dmesg over to where I could mail it. --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --YiSnftFthKPM0z4v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-BETA2 #0 r303168: Fri Jul 22 02:23:56 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT(efifb): resolution 640x480 CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.96-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0xbfebfbff Features2=0x1fbae3ff AMD Features=0x28100800 AMD Features2=0x1 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3980636160 (3796 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff81018940, 0) error 19 cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x5000-0x503f mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device pci0: at device 22.0 (no driver attached) uart2: port 0x50b0-0x50b7 mem 0xf252c000-0xf252cfff at device 22.3 on pci0 em0: port 0x5080-0x509f mem 0xf2500000-0xf251ffff,0xf252b000-0xf252bfff at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:21:cc:b4:f6:3d em0: netmap queues/slots: TX 1/1024, RX 1/1024 ehci0: mem 0xf252a000-0xf252a3ff at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: mem 0xf2520000-0xf2523fff at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.1 on pci0 pci1: on pcib2 iwn0: mem 0xf2400000-0xf2401fff at device 0.0 on pci1 pcib3: at device 28.3 on pci0 pcib3: [GIANT-LOCKED] pcib4: at device 28.4 on pci0 pcib4: [GIANT-LOCKED] pci2: on pcib4 sdhci_pci0: mem 0xf1400000-0xf14000ff at device 0.0 on pci2 sdhci_pci0: 1 slot(s) allocated ehci1: mem 0xf2529000-0xf25293ff at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x50a8-0x50af,0x50bc-0x50bf,0x50a0-0x50a7,0x50b8-0x50bb,0x5060-0x507f mem 0xf2528000-0xf25287ff at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahciem0: on ahci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc0000-0xcffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 usbus0: 480Mbps High Speed USB v2.0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec nvme cam probe device init hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 31,25 and 35,27 on hdaa0 hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hdacc1 (no driver attached) hdacc2: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc2 pcm1: at nid 5 on hdaa1 pcm2: at nid 6 on hdaa1 pcm3: at nid 7 on hdaa1 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number CVDA5066005L1207GN ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors) ada0: quirks=0x1<4K> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number PNY20162178980100273 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1245978962 Hz quality 1000 Trying to mount root from zfs:tank/ROOT/default []... uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 GEOM_ELI: Device ada0p4.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: hardware GEOM_MIRROR: Device mirror/swap launched (2/2). uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 GEOM_ELI: Device ada1p4.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: hardware GEOM_ELI: Device mirror/swap.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware wlan0: Ethernet address: ElidedMAC iwn0: iwn_read_firmware: ucode rev=0x12a80601 wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN --YiSnftFthKPM0z4v-- --I30T0A8abtL/6dyk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXm+rKAAoJEJ6yV3B27yVVc7wQAI/XQFOQtMVVycf6Mr8MINx+ usOMjcH7Y1r3KQFckHFzSqbdIFxf4ePAVW/Yi8ie0eWjqCm5rF636UHVcKz06ov7 sX/OdKi6sUNmcR/VV/2lmTVsijGV9pr6jmt8oKKR5lXaeGci/ItseW5g7MqREUVi ukgrO61K/ViPmuznAAiijAmRzoR0QODse1yv0+JXufYwEW1slHMUqravcvWNFepH dC26MiQtT2YI9sdvhm5kB+SEK6nA0LmC0oRqP3vo6yWwoSXnErGEN4mrTl2gfNxC v0xqzEBUq5VLiOr2F9I9fhT39pJ/JVje4Ex6Lc1dhq0gOL8HdbpVoDB7cOnpXcGY GduuGtQ9iheYEjTnfbyIcI4Y9NKDIeiIJNYLxGTVlH+DKDDhxBr8yhKx5CJ36Pqj zBIihkSbJyTng+B2zH1kH/oOZQ0z38seu1XzIr81FHcQuX7Ovnd2IvlrOk/m2hXi RspXx97Vg6lGU/akpb8lLhMMEr0GJA1z7fQ6KsqOTezb9OEJ0w+3zdtisZQglvWs 8x1A/DMAgSSrOgHFvEPrpKehB2TuT82fmg5GMUgPzPF06s6I5BSAF9QQaD1gh52V rD26DE2zgydsk32ir7CsfV1rtCS6RBtrj4COJ4BZw4NNmPt3j6FeqH4X/2itZCPQ ox/1h4cMKsNYSX5HlHdX =Tb73 -----END PGP SIGNATURE----- --I30T0A8abtL/6dyk-- From owner-freebsd-hackers@freebsd.org Fri Jul 29 23:47:58 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4901ABA7E91 for ; Fri, 29 Jul 2016 23:47:58 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ECF21948 for ; Fri, 29 Jul 2016 23:47:57 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id CABF9194EA6; Fri, 29 Jul 2016 19:47:56 -0400 (EDT) Date: Fri, 29 Jul 2016 19:47:55 -0400 From: Mason Loring Bliss To: Chris H Cc: freebsd-hackers@freebsd.org Subject: Re: Disappointment with wifi... Message-ID: <20160729234755.GR4313@blisses.org> References: <20160729151114.GH4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RNYIsZSUNfbU4BwD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 23:47:58 -0000 --RNYIsZSUNfbU4BwD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2016 at 10:47:03AM -0700, Chris H wrote: > Just a thought. But have you introduced any new hardware in the vicinity? I suspect a local microcell might be causing some signal loss, but this see= ms to be unrelated, as the same laptop locks on and works fine with Linux driving it. --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --RNYIsZSUNfbU4BwD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXm+srAAoJEJ6yV3B27yVV8uoQAIoKByoYea5Y96SeyOPmdenk aMKnygku89HpehL596Oyj1wSxSlR5B8emMTeQYkA5yLLbjC0tC464qci2goY/YqP +FynyFmvMrvG/QvUqs7KKMsd1T44nN2Hknzyt82Y36wm02IL1oomR7qV+jJFPBaK vbpfd8A80NXQNd6In30gpCCFJkJsoaUYGjP17zZvaNHmj+tI0zUJswVg+n7X3p7M x7PxjtFR/gKeM1kHU9Bvn3KOa8gDlvbq6xJbYeE+iU+YwpSEK6CBA4XLMCVfLmMs ea3Z7KVFu0RrL1cK4fQzF6/myI2ey3DbGImeKx1yzUfuJsIh6PIuYgFOGQTQmoe+ mLwmXwxrPWrA8ByoyvH68l2eIGd6otrLaEu/0YLxCszGKc3dQp2nQB01HK5wXYYc ulNNCK3qDqF/qts/0Y8JT4oBaFljGsh+hi/9aNBdksNPC9kVINDg1jJktC73CHvT LZAYMHeTk0gyKjEXrCi2jxFkpPqrpGYqV/wVB2z65WCUt6at9P3RB3Py9ycbJrzp xSi4CMn8joFYLcxbKvc7hdNcGIlvTnMGArhze8XtxI6VSqNH5DQHOYM4Wwj2lLI4 GLh1O0ODGTAMTVCQCOybaO5ETnHfR3Q+NW9w7nNN222GwlaK54iePAvCWZgAebW0 9H7RCGsyef25+GU/7sU9 =g5VW -----END PGP SIGNATURE----- --RNYIsZSUNfbU4BwD-- From owner-freebsd-hackers@freebsd.org Fri Jul 29 22:53:23 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F380BA70F2 for ; Fri, 29 Jul 2016 22:53:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AEE21506 for ; Fri, 29 Jul 2016 22:53:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id j124so122358016ith.1 for ; Fri, 29 Jul 2016 15:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=igQ2vfbqJxHHl6m5gG0eLFhBR8VTApCQXWGRHMMDGEA=; b=EIsA7fZOoIvjF00cb2RFHp1IOiqrq+HhwIoKOJ7QD6L7czHc8FhlEPcgDHOHO+Cj5F MwV4dfS0/o0KUs4NfOnfKx/LvHDeRZl8dJLydxsL5m++Omq5ziqLmnOOQg9CiM5fCNj1 cU6T2pNFkluu9YFwabPloa7NoNIPH+lE0/F1NQDJk/t735XWuC+8mDxcoUIG2HOH+DN4 O7aWJrV+bw349YOOqsmn9/0TYEnsjdoInVZIKKl07fy13CRhutivqgal0LBj9sT9mbvE 5Mdvn39Wpc7nu9spUZTXkI/KrYjhgXU0T42m19T26Z9kLb0dv+j/4Sfr1O/M1yKDw6bx EOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=igQ2vfbqJxHHl6m5gG0eLFhBR8VTApCQXWGRHMMDGEA=; b=SzTXQ8ZIpiISXxJ0/J7sSw9ZRSEPBCZ1wyZaKfqHEQ6JUL57vZfy4ppM+Kts/51zdu QflrTVTG4l2xQ5WiwH7F06INS7wkH3H3hrhQZFYPulHkXHXbqsr/tZjlifkAecK81wLG OiETSKu+w+OA2YZ2oJdaDnIoY2Rf/kPg6nMadpfRz1vtq+/EVtn7A4Nz61uo2UkrmAzR Ny3KJSGbQUOq6MzTi7ngCTVnIzW4QZzAzT6e3mzluDgS4cyIe3YTUJq0jsP2CP7tjGQY ge6FK0mI0oTKPYFzwiwo8BAigc3uoGoUHoYMnRMcFI+OX3gMp+DT/Zp35OIMPKy5s+RX t6lg== X-Gm-Message-State: AEkoouurB1v5P6jCCNYEQkIJ0AqGWpNMC66NpFVACtUOcsnutsmVZ/osndRqW4QKt1Ru3S1Mevt7M5H5T2ZMyQ== X-Received: by 10.36.242.68 with SMTP id j65mr3492521ith.25.1469832802806; Fri, 29 Jul 2016 15:53:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 29 Jul 2016 15:53:22 -0700 (PDT) In-Reply-To: References: <20160729151114.GH4313@blisses.org> From: Adrian Chadd Date: Fri, 29 Jul 2016 15:53:22 -0700 Message-ID: Subject: Re: Disappointment with wifi... To: Chris H Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 30 Jul 2016 02:27:26 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 22:53:23 -0000 Hi, Can you post a 'dmesg' too? In case anything odd is showing up. Thanks, -adrian From owner-freebsd-hackers@freebsd.org Fri Jul 29 22:54:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D14C0BA712E for ; Fri, 29 Jul 2016 22:54:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BB071556 for ; Fri, 29 Jul 2016 22:54:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 38so141675513iol.0 for ; Fri, 29 Jul 2016 15:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mvgU3x8BK2e266yMUMOQ7G+bipI3tl0GIdmOLzp657o=; b=IQX/ELw7V02MAp3b+WldBGjnGARqNir/p88PBXHXxkRhhsKBhP6NoJIr3CfSfB0dFB DvngClaEvzmmguJ3TMKSZ/JNrkpUpJwOUC/jLTrwQPrGwHThAxqMvkCf56w9ymIwrXP1 RCTLy7y6+o5k9RudUgxneqyeB3PTvCk64JWrJ5VelrNc17UTCWTzhir3YBow8WeYqshE ixyfw3FQOcC6KUJe9p7+KJpV7LQ0KObS2PKyJ9GpTVx//9ONobj6IYLDaBy6U/C9S3Wu nzqL0S8ISBuODupuEWPWfgsb6ObjNR9nw1dqGopsW9FDAdnnpQDsDoH7+wENTR9rtsi5 8OdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mvgU3x8BK2e266yMUMOQ7G+bipI3tl0GIdmOLzp657o=; b=E3SwY+zJ1dbpFF79TfYXo9efOsa7fk+WpH6EJ3Kv1waB2B8e32Nmd98fzT164OrcWe L8BlD/v1ytgViBJ5uzi20s2ocjaJNvoO/ggkSVcEwErMgBb00XiOEujKXyQkVIHEFaqd GRpKDNQDjYLF4fDMgs5NHpgRi1wSf7NaxLQfb69uD4LEXcREwI8lyuIIwGR4OY9sJJKE I/EsmKMgdoVWyLUYiTn5S715obWUWnexHqiVFE7x8nBHiZBkTznrqXFRe1NFX8hUcYle N17c/xgIEkgW07aqNdJOsf5h3qIGjclFTdL8B+MKrvrajSC8Akhfp6kiWtESnTOEqkA2 Wn9A== X-Gm-Message-State: AEkoouuOaDXaTAy/j7cqXg74WVUdVhX+NPOA0X8xxf8nkAhVmvZNWInJCwZHmNT7FRzswNWNa5gLZNsWwm8+qQ== X-Received: by 10.107.15.229 with SMTP id 98mr2928002iop.123.1469832881066; Fri, 29 Jul 2016 15:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 29 Jul 2016 15:54:40 -0700 (PDT) In-Reply-To: <20160729151114.GH4313@blisses.org> References: <20160729151114.GH4313@blisses.org> From: Adrian Chadd Date: Fri, 29 Jul 2016 15:54:40 -0700 Message-ID: Subject: Re: Disappointment with wifi... To: Mason Loring Bliss Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 30 Jul 2016 02:27:39 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 22:54:41 -0000 On 29 July 2016 at 08:11, Mason Loring Bliss wrote: > On Thu, Jul 28, 2016 at 06:05:46PM -0700, Adrian Chadd wrote: > >> FreeBSD wireless progresses at the rate at which people pay for FreeBSD! >> You should let your vendor know about your problem! > > That's what I'm doing now! :P Heh. If you didn't pay, then there's no vendor. :) >> $ ifconfig -v wlan0 list sta >> $ ifconfig -v wlan0 >> $ ifconfig -v wlan0 list scan > > Alright. I'm attaching these. The signal strength is pretty weak despite my > being somewhat close to the WAP. (Which is, FWIW, a node in a small Unifi > zero- handoff network.) That said, I manage solid connection with this laptop > in the same spot running Linux, and with MacBooks. Heh, I'm pretty sure that the vendors in question have spent more than $0.00 on their wifi development. For us it's all for love and spare time. > I'll happily supply more diagnostic information, as needed. > > > On Fri, Jul 29, 2016 at 01:17:07AM -0400, Allan Jude wrote: > >> I have a T530, it has the same 6205 wifi chip, and it works fine. > > Same here running Linux. It's only problematic with FreeBSD driving the > hardware. I'd very much like FreeBSD to be driving this unproblematically. > > >> I have sometimes had better luck by disabling ht20 (ifconfig wlan0 >> -ht20), but I don't recall the last time I had to do that. > > This was briefly hopeful. I set that in rc.conf and rebooted, and I got a > quick, solid connection. But then through several subsequent reboots my wifi > light is flashing and connectivity is sporadic at best, with the same > messages piling into the console. Let's post a dmesg as well, in case it's something silly (like firmware crashing or whatnot.) -adrian From owner-freebsd-hackers@freebsd.org Sat Jul 30 03:29:02 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B7AEBA7B09 for ; Sat, 30 Jul 2016 03:29:02 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 511B51194 for ; Sat, 30 Jul 2016 03:29:01 +0000 (UTC) (envelope-from mason@blisses.org) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id D3328194EA6 for ; Fri, 29 Jul 2016 23:28:59 -0400 (EDT) Date: Fri, 29 Jul 2016 23:28:58 -0400 From: Mason Loring Bliss To: FreeBSD Hackers Subject: Re: Disappointment with wifi... Message-ID: <20160730032858.GS4313@blisses.org> References: <20160728191950.GF4313@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bIK/Xm5bvUaTMa1a" Content-Disposition: inline In-Reply-To: <20160728191950.GF4313@blisses.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 03:29:02 -0000 --bIK/Xm5bvUaTMa1a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2016 at 03:19:50PM -0400, Mason Loring Bliss wrote: > However, on boot, dhclient keeps saying, repeatedly: >=20 > send_packet: Network is down > send_packet: No buffer space available For lack of other ideas, I looked and noted that there's new Unifi software, both controller and firmware. Installed that, and I have yet to see these issues. I have no answer for why Linux and MacOS were able to talk reliably with the older Unifi stuff. If this starts misbehaving again I'll note it here. Otherwise, I guess it's working now, without anything changing on the FreeB= SD side. (Well. I'm assuming nothing has changed. I noticed that BETA3 images were out so I wrote one to a USB stick and installed with that. Did anything change in BETA3 that could matter here?) BTW, the new hardening screen in the installer is interesting. Made me wond= er if anything breaks with, for instance, the stack guard. --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --bIK/Xm5bvUaTMa1a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJXnB75AAoJEJ6yV3B27yVVEFUP/3TIx337V/nUY8flUd0Gu/PE phDacRzvdyQtlRr+9LtSYtmMK+HB3g2JbFLCKi2v5GE66Iaib5mTpoQ5WM/6G+SN kEjG2LwLrd5glNRz0Fax/YQcZMWr/NRy//iYcnDzhyadr2/yQAlgkEwscukoJ2+1 ooK0U4Dwyi7W4b7Kl24cvVtsOYD9HxLWL1tX2IJN28yqSZgHFsmUW+WqWeNu0E04 y/JCDeO9mzmdcCMHzOPJe59afGGjIPIUkQa+VG5Niwi1AkfEfQQEnJ/1Jy35/rfp DWkRhkBYTcyuK5WVLKd5Riqgd7N84tQu1BAzJs2e3eAgyBdKdAyVNt8e+TRZaHDN /XFchm9thCUArxHXqrUwC9twVnRyrCPxznqSQysXUXstff1TdedXsA3B6c0kQQ66 ppx1wtYlMbW6KSHzqbkY9iPdPBUwL52b6HsSOgQP46erREGUPv1Q4a2bKewOsc3h 18J7F//sxRK8A3uG1Gm4TgXsTjJzwrs+bVh72YFYAuk4rPpixG00fN2jDO2ta+GY QHo5IARL9N0SN5Uh1N35KiUcEKhwq5V7MmmVWjEVCf+6TwxuV1w69YSy+Hqtd6lv Xk+bY0qqZvnfugVk/af1xHKR+8tK/7FTezi1oeJtGr5rNnTnFFpZptPZnkMs1G0q X2yloXnMS2AeuNUmBjwl =42i/ -----END PGP SIGNATURE----- --bIK/Xm5bvUaTMa1a-- From owner-freebsd-hackers@freebsd.org Sat Jul 30 07:26:01 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 294A3BA9DF1 for ; Sat, 30 Jul 2016 07:26:01 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C318A1FE3; Sat, 30 Jul 2016 07:26:00 +0000 (UTC) (envelope-from starak.adam@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id o80so178288258wme.1; Sat, 30 Jul 2016 00:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HvYrIuILBpkHWdce92itoJh5Zc9cnSqJZ1D2sbmqcmc=; b=WtISUp55Aqhy2A93vBIul6NVrXxk8ROIwg+FLg5jNmXnURA82tFWCB1NfTQSVHIOLd jDbC8nbjiJKaB6BlHWjEKOf6dzH5O58xtWWs7A5VNRrQrLaDPUGSznYp7MINBB+eRFxt V4rCwSK0TL7YzoxlCJ7eX7rL0DGz1ZcCI9bhJNAbiESAOcxjSN8mjbgqaajuGK5kDwPR AXteB7Vysq3ynu33EtiEPueB6W7EBpg8ZLm1zq6QTANNXBwI4cIBa5fPyBsE+kNK/D6t LBfF8+K178lRSoxUpsDo/pkYrqGeyoKFPrMpcy/Go2lnLPaKyvUPmmShPIVBSLL2O8Zs KWRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HvYrIuILBpkHWdce92itoJh5Zc9cnSqJZ1D2sbmqcmc=; b=FJkU3DX6M15RvB/LJXSbHoQJL2zk633SoIdvoSTcD5I2XSn539sXcudlZMaBQK1wq0 3o+xaSsbu12hBCV1ghKten0quLtJIIFf7es0nq/jYquz/qMstFcvDDpxp808mCD3r7aI ygCWCKJ4m+QMYbF0tJossAZ3rgO8ZfOGS9Aw0kcsdUFMzmlQIEB7RRlLPB6vUFKST5Fz U/vnpNjYg1vNMmix+W1wcnG86GhsX9NTjMPLdRSpDkXVJ3inc8lanZmCGryRpFVqJat4 YYn8pTCSYFk6Hx1eqoZDnm93DudPBSQSbUSjiqy3oSczMknpXRXLAmGdPQju8vVjD4oJ Fy7w== X-Gm-Message-State: AEkoouuKWZCKqR3dktRgkyqIG2H9aAZjcgnEI+txXo5aP/yu2tr679pMUf2uMTP6qoSqvg== X-Received: by 10.195.9.226 with SMTP id dv2mr41164709wjd.180.1469863559052; Sat, 30 Jul 2016 00:25:59 -0700 (PDT) Received: from [192.168.0.115] (bnj119.neoplus.adsl.tpnet.pl. [83.28.255.119]) by smtp.gmail.com with ESMTPSA id r127sm6460395wmf.23.2016.07.30.00.25.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 Jul 2016 00:25:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Modify user space from kernel. From: Adam Starak X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Sat, 30 Jul 2016 09:25:56 +0200 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <00058592-A469-440C-884E-5C057DAE2AB6@gmail.com> To: cem@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 07:26:01 -0000 Hey, That's also pretty cool idea, because nvlist can be easily transferred over s= ockets. Thank you all guys for your fast response.=20 Best regards, Adam Starak Dnia 29.07.2016 o godz. 18:55 Conrad Meyer napisa=C5=82(a)= : > Hi Adam, >=20 > You could create a pipe or socket if there will be continuous IPC > between kernel and userspace. Sockets have defined behavior around > message boundaries. >=20 > For that approach, you could look at the implementation of sys_socket > or sys_pipe2. Or maybe the best approach is just to define some new > address family. I'm not sure what the standards allow. >=20 > Best, > Conrad >=20 >> On Fri, Jul 29, 2016 at 9:49 AM, Adam Starak wrot= e: >> My project is focused on nvlist. I'm improving and expanding its usage. N= vlist can be used in userland as well as in kernel. My goal is to establish c= ommunications between them via nvlist. That's why setting a fixed size or lo= oping doesn't satisfy me. It'll be some kind of IPC, not only for sysctl ofc= . >>=20 >> Best regards, >> Adam Starak >>=20 >> Dnia 29.07.2016 o godz. 18:05 Conrad Meyer napisa=C5=82= (a): >>=20 >>>> On Fri, Jul 29, 2016 at 6:11 AM, Adam Starak wr= ote: >>>> Hello! >>>>=20 >>>> My name is Adam. I participate in Google Summer of Code this year. I ca= me >>>> up with a big problem, which doesn't allow me to go further in my proje= ct. >>>>=20 >>>> I made a new syscall, which is going to retrieve sysctl data and put it= >>>> inside the nvlist. And here my problem is. I need to move somehow this d= ata >>>> (packed nvlist) into the user space. Is there any chance to pass data f= rom >>>> kernel to user space without knowing the size of it? >>>>=20 >>>> Right now, the implementation of __sysctl() function requests void poin= ter >>>> and size in order to get data. If allocated memory is too low, it retur= ns >>>> ENOMEM and you need to realloc the data. I wanted to avoid this situati= on. >>>=20 >>> Hey Adam, >>>=20 >>> That is the usual way to do it. Just curious =E2=80=94 why do you want t= o >>> avoid that situation? >>>=20 >>> Your other option might be to put an upper limit on the size of the >>> result, and pass a buffer of that size in from userspace. But then >>> you are artificially limited to some arbitrary size and must >>> preallocate a large buffer even in the case that the output is small. >>>=20 >>> Best, >>> Conrad From owner-freebsd-hackers@freebsd.org Sat Jul 30 23:40:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C3F3BA9624 for ; Sat, 30 Jul 2016 23:40:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D7D21230 for ; Sat, 30 Jul 2016 23:40:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2167E5A9F27; Sat, 30 Jul 2016 23:32:24 +0000 (UTC) Date: Sat, 30 Jul 2016 23:32:24 +0000 From: Brooks Davis To: Adam Starak Cc: freebsd-hackers@freebsd.org Subject: Re: Modify user space from kernel. Message-ID: <20160730233224.GB98042@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 23:40:41 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 29, 2016 at 03:11:25PM +0200, Adam Starak wrote: > Hello! >=20 > My name is Adam. I participate in Google Summer of Code this year. I came > up with a big problem, which doesn't allow me to go further in my project. >=20 > I made a new syscall, which is going to retrieve sysctl data and put it > inside the nvlist. And here my problem is. I need to move somehow this da= ta > (packed nvlist) into the user space. Is there any chance to pass data from > kernel to user space without knowing the size of it? >=20 > Right now, the implementation of __sysctl() function requests void pointer > and size in order to get data. If allocated memory is too low, it returns > ENOMEM and you need to realloc the data. I wanted to avoid this situation. If you want a memory based interface, that is what how it should be. If the size won't change, then you can output the required size on failure. For example, if your syscall has a definition like: int give_me_an_nvlist(void *buf, size_t *buflen); On ENOMEM you'd write the required size to buflen. If the list really don't change size, requiring two system calls would be a lot cheaper and easier to handle than a socket as someone else proposed. -- Brooks P.S. Purely as an FYI, there is technically another option. You could inject a set of page mappings into the process, write the nvlist to them, and then return a pointer to them. This would be fragile, prone to hard to diagnose memory leaks, and would probably break all sorts of tools like valgrind, but it's theoretically possible. I seriously doubt such an interface would be acceptable to the project. --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXnTkHAAoJEKzQXbSebgfAuzYH/1qM5Mt3c8ipz3GSmajtWWpl U26v7nQhFSMujDFvcJSickWGYuBmMjt+SCkVjOCafY11iQ+9aCSLCKsmwSnp8JJh DeIDJKV3icD7Owx9STkRW3Uw0n5PaFjp15LVWsZI6EraBN5JUPIZTxJUcfksp/gA +UBg2kW5oqzh1BisIOf+I3kxVVNJHO8H0g9wTBul5siSJ/hsdDdijYHPspm2X50/ HBDNuEtwv4xENtuwa4ZXn6Y26smtwTH0wJ6dvI+rrDONIIgIeWgamvm0E6UbhYng 7A2Bzgr+lvLVYkVyi6MngUgSQNFXM4ulfErx3OUIgARCxJwyjkl2Yl0XoQXR4n0= =LnlL -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--