Re: Heads up for breaking drm update.

2019-05-20 Thread Niclas Zeising
On 2019-05-20 17:21, Michael Butler wrote: On 2019-05-19 23:21, Johannes Lundberg wrote: On 5/19/19 7:36 PM, Steve Kargl wrote: On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: LinuxKPI in base have received a lot of updates recently for Linux 5.0, a couple of them will

Re: Heads up for breaking drm update.

2019-05-20 Thread Michael Butler
On 2019-05-19 23:21, Johannes Lundberg wrote: > > On 5/19/19 7:36 PM, Steve Kargl wrote: >> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: >>> LinuxKPI in base have received a lot of updates recently for Linux 5.0, >>> a couple of them will break drm-current-kmod. So, as of

Re: Heads up for breaking drm update.

2019-05-19 Thread Steve Kargl
On Sun, May 19, 2019 at 08:21:18PM -0700, Johannes Lundberg wrote: > > On 5/19/19 7:36 PM, Steve Kargl wrote: > > On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: > >> LinuxKPI in base have received a lot of updates recently for Linux 5.0, > >> a couple of them will break

Re: Heads up for breaking drm update.

2019-05-19 Thread Johannes Lundberg
On 5/19/19 7:36 PM, Steve Kargl wrote: > On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: >> LinuxKPI in base have received a lot of updates recently for Linux 5.0, >> a couple of them will break drm-current-kmod. So, as of r347973 you will >> need drm-current-kmod

Re: Heads up for breaking drm update.

2019-05-19 Thread Steve Kargl
On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote: > > LinuxKPI in base have received a lot of updates recently for Linux 5.0, > a couple of them will break drm-current-kmod. So, as of r347973 you will > need drm-current-kmod 4.16.g20190519. Ports have been updated and new >

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-27 Thread David Marec
On 27/10/2018 18:27, Glen Barber wrote: > Package builds are currently in progress (this will be noted in the upcoming BETA2 announcement text I am currently drafting). It will be about 48 hours, give or take, before binary packages from the repository at pkg.freebsd.org are updated. Thanks,

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-27 Thread Glen Barber
On Sat, Oct 27, 2018 at 06:14:39PM +0200, David Marec wrote: > On 09/10/2018 23:34, Glen Barber wrote: > > OpenSSL has been updated to version 1.1.1 as of r339270. > > > > It is important to rebuild third-party packages before running: > > > > # make -C /usr/src delete-old && make -C /usr/src

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-27 Thread David Marec
On 09/10/2018 23:34, Glen Barber wrote: OpenSSL has been updated to version 1.1.1 as of r339270. It is important to rebuild third-party packages before running: # make -C /usr/src delete-old && make -C /usr/src delete-old-libs I just do a fresh install a FreeBSD-12 from

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-26 Thread Oleg Lelchuk
libtorrent still can't be built with the new openssl On Sat, Oct 13, 2018 at 4:40 AM Ronald Klop wrote: > On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis > wrote: > > > On 11 Oct, Don Lewis wrote: > >> On 11 Oct, Don Lewis wrote: > >>> On 11 Oct, freebsd.curr...@clogic.com.ua wrote: > On

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-13 Thread Ronald Klop
On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis wrote: On 11 Oct, Don Lewis wrote: On 11 Oct, Don Lewis wrote: On 11 Oct, freebsd.curr...@clogic.com.ua wrote: On 2018-10-10 06:14, Michael Butler wrote: On 10/9/18 5:34 PM, Glen Barber wrote: OpenSSL has been updated to version 1.1.1 as of

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-12 Thread Don Lewis
On 11 Oct, Don Lewis wrote: > On 11 Oct, Don Lewis wrote: >> On 11 Oct, freebsd.curr...@clogic.com.ua wrote: >>> On 2018-10-10 06:14, Michael Butler wrote: On 10/9/18 5:34 PM, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread Shane Ambler
On 10/10/18 8:04 am, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to rebuild third-party packages before running: > > # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > > Thank you for your patience while this work was in

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread Don Lewis
On 11 Oct, Don Lewis wrote: > On 11 Oct, freebsd.curr...@clogic.com.ua wrote: >> On 2018-10-10 06:14, Michael Butler wrote: >>> On 10/9/18 5:34 PM, Glen Barber wrote: OpenSSL has been updated to version 1.1.1 as of r339270. It is important to rebuild third-party packages before

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread Don Lewis
On 11 Oct, freebsd.curr...@clogic.com.ua wrote: > On 2018-10-10 06:14, Michael Butler wrote: >> On 10/9/18 5:34 PM, Glen Barber wrote: >>> OpenSSL has been updated to version 1.1.1 as of r339270. >>> >>> It is important to rebuild third-party packages before running: >>> >>> # make -C /usr/src

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread freebsd . current
On 2018-10-11 18:02, Jamie Landeg-Jones wrote: freebsd.curr...@clogic.com.ua wrote: Anyway, I think apps from ports need to use openssl from ports. No. Only if it's installed. If not, it's perfectly normal for a port to use the base openssl - it's not a private-lib install. cheers, Jamie I

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread Jamie Landeg-Jones
freebsd.curr...@clogic.com.ua wrote: > Anyway, I think apps from ports need to use openssl from ports. No. Only if it's installed. If not, it's perfectly normal for a port to use the base openssl - it's not a private-lib install. cheers, Jamie ___

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread Oleg Lelchuk
net-p2p/libtorrent also can't be built with the new openssl. On Thu, Oct 11, 2018 at 2:05 AM wrote: > On 2018-10-10 06:14, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > >> OpenSSL has been updated to version 1.1.1 as of r339270. > >> > >> It is important to rebuild

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-11 Thread freebsd . current
On 2018-10-10 06:14, Michael Butler wrote: On 10/9/18 5:34 PM, Glen Barber wrote: OpenSSL has been updated to version 1.1.1 as of r339270. It is important to rebuild third-party packages before running: # make -C /usr/src delete-old && make -C /usr/src delete-old-libs Thank you for your

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Glen Barber
On Wed, Oct 10, 2018 at 08:35:28PM -0400, Ed Maste wrote: > On Wed, 10 Oct 2018 at 18:11, O. Hartmann wrote: > > > > security/libssh > > This one is open as PR 228895. > I don't need to be personally CC'd on every port that fails to build. I'm keeping an eye on them. I do not need the extra

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Manfred Antar
Here are a few more: devel/gnome-vfs comms/kermit security/php56-openssl net-im/telegram textproc/htmldoc > On Oct 10, 2018, at 5:35 PM, Ed Maste wrote: > > On Wed, 10 Oct 2018 at 18:11, O. Hartmann wrote: >> >> security/libssh > > This one is open as PR 228895. > > If there are other

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Wed, 10 Oct 2018 at 18:11, O. Hartmann wrote: > > security/libssh This one is open as PR 228895. If there are other ports that you're trying to build and are failing with OpenSSL 1.1.1 please check PR 228865 and 231931 to see if it is already listed as a dependency. You can see all of the

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Tue, 9 Oct 2018 23:37:02 -0400 Michael Butler schrieb: > On 10/9/18 11:14 PM, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > >> OpenSSL has been updated to version 1.1.1 as of r339270. > >> > >> It is important to rebuild

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Tue, 9 Oct 2018 at 23:15, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > > OpenSSL has been updated to version 1.1.1 as of r339270. > > > > It is important to rebuild third-party packages before running: > > > > # make -C /usr/src delete-old && make -C /usr/src

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Tue, 9 Oct 2018 23:37:02 -0400 Michael Butler schrieb: > On 10/9/18 11:14 PM, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > >> OpenSSL has been updated to version 1.1.1 as of r339270. > >> > >> It is important to rebuild

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-09 Thread Michael Butler
On 10/9/18 11:14 PM, Michael Butler wrote: > On 10/9/18 5:34 PM, Glen Barber wrote: >> OpenSSL has been updated to version 1.1.1 as of r339270. >> >> It is important to rebuild third-party packages before running: >> >> # make -C /usr/src delete-old && make -C /usr/src delete-old-libs >> >> Thank

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-09 Thread Michael Butler
On 10/9/18 5:34 PM, Glen Barber wrote: > OpenSSL has been updated to version 1.1.1 as of r339270. > > It is important to rebuild third-party packages before running: > > # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > > Thank you for your patience while this work was in

Re: Heads Up: pNFS server merge committed to head

2018-06-12 Thread Eitan Adler
On 12 June 2018 at 12:44, Rick Macklem wrote: > Should I bump __FreeBSD_version to force this for head/current? yes. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Dimitry Andric
On 15 May 2018, at 00:58, Ed Maste wrote: > > On 14 May 2018 at 18:05, Julian H. Stacey wrote: >> >> I guess this explains : >> Date: Sun, 13 May 2018 20:26:38 +0200 >> Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend >>

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Julian H. Stacey
Hi, Reference: > From: Ed Maste > Date: Mon, 14 May 2018 18:58:25 -0400 Ed Maste wrote: > On 14 May 2018 at 18:05, Julian H. Stacey wrote: > > > > I guess this explains : > > Date: Sun, 13 May 2018 20:26:38 +0200 > > Subject: cd

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
On 14 May 2018 at 18:05, Julian H. Stacey wrote: > > I guess this explains : > Date: Sun, 13 May 2018 20:26:38 +0200 > Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend > .svn_revision 333575 > linking kernel.full >

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Julian H. Stacey
Ed Maste wrote: > As of r333461 the amd64 kernel makes use of ifuncs, and requires > support in the linker. A safety belt added in r333470 enforces this, > and will produce an explicit error if the linker does not support > ifuncs. > > lld is the default bootstrap linker for amd64 and has ifunc

Re: HEADS-UP: Deprecation of legacy (v3) password database support

2018-04-20 Thread Rodney W. Grimes
> FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain > records in one or both of two versions: > * v3, a legacy architecture-dependent format > * v4, the current architecture- and endian-independent format > > When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Ed Maste
On 27 March 2018 at 02:20, Antoine Brodin wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Antoine Brodin
On Tue, Mar 27, 2018 at 4:14 AM, Ed Maste wrote: > Some changes related to the amd64 linker are nearly ready to be > committed (within a week or three), so I'm sending this notice to > request any final comments or concerns before these changes are made. > > 1. Kostik (kib@)

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-16 Thread Andriy Gapon
On 13/11/2017 17:02, Ed Maste wrote: > On 7 November 2017 at 13:12, Andriy Gapon wrote: >> >> I hope that lld is not that widely used now. >> But I admit that I put the cart before the horse. >> I didn't expect that posix_fallocate is used in the development toolchain >> and I

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-13 Thread Ed Maste
On 7 November 2017 at 13:12, Andriy Gapon wrote: > > I hope that lld is not that widely used now. > But I admit that I put the cart before the horse. > I didn't expect that posix_fallocate is used in the development toolchain and > I > didn't try to check for it. For amd64 it

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-07 Thread Andriy Gapon
On 06/11/2017 19:26, Ian Lepore wrote: > On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote: >> From UPDATING: >> The naive and non-compliant support of posix_fallocate(2) in ZFS >> has been removed as of r325320.  The system call now returns EINVAL >> when used on a ZFS file.  Although the new

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Konstantin Belousov
On Mon, Nov 06, 2017 at 11:43:42AM -0700, Ed Maste wrote: > On 6 November 2017 at 10:56, Ian Lepore wrote: > > > > Oh, right. lld != ld. > > Indeed, but this will be a problem for the arm64 package builds if > they use ZFS and an 11.x userland on a new kernel. We probably need

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Ed Maste
On 6 November 2017 at 10:56, Ian Lepore wrote: > > Oh, right. lld != ld. Indeed, but this will be a problem for the arm64 package builds if they use ZFS and an 11.x userland on a new kernel. We probably need to bring the lld change in as an errata.

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Ian Lepore
On Mon, 2017-11-06 at 12:49 -0500, Allan Jude wrote: > On 2017-11-06 12:26, Ian Lepore wrote: > > > > On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote: > > > > > > From UPDATING: > > > The naive and non-compliant support of posix_fallocate(2) in ZFS > > > has been removed as of r325320.  

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Allan Jude
On 2017-11-06 12:26, Ian Lepore wrote: > On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote: >> From UPDATING: >> The naive and non-compliant support of posix_fallocate(2) in ZFS >> has been removed as of r325320.  The system call now returns EINVAL >> when used on a ZFS file.  Although the new

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Ian Lepore
On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote: > From UPDATING: > The naive and non-compliant support of posix_fallocate(2) in ZFS > has been removed as of r325320.  The system call now returns EINVAL > when used on a ZFS file.  Although the new behavior complies with the > standard, some

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Mark Millard
On 2017-Jul-23, at 7:44 PM, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 09:16:26PM -0400, Shawn Webb wrote: >> On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: >>> On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: Shawn Webb shawn.webb at hardenedbsd.org wrote on

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Mark Millard
On 2017-Jul-23, at 6:16 PM, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: >> On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: >>> Shawn Webb shawn.webb at hardenedbsd.org wrote on >>> Sat Jul 22 15:33:14 UTC 2017 : >>> I haven't nailed down

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Shawn Webb
On Sun, Jul 23, 2017 at 09:16:26PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > > > I

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Shawn Webb
On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > >

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Shawn Webb
On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > Shawn Webb shawn.webb at hardenedbsd.org wrote on > Sat Jul 22 15:33:14 UTC 2017 : > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > default linker, but it looks like we in HardenedBSD are getting an >

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-23 Thread Mark Millard
Shawn Webb shawn.webb at hardenedbsd.org wrote on Sat Jul 22 15:33:14 UTC 2017 : > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > default linker, but it looks like we in HardenedBSD are getting an > undefined symbol during buildworld. In an amd64 ->

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-22 Thread Dimitry Andric
On 22 Jul 2017, at 19:38, Shawn Webb wrote: > > On Sat, Jul 22, 2017 at 01:32:17PM -0400, Shawn Webb wrote: >> On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: >>> On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: Hi, I have

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-22 Thread Shawn Webb
On Sat, Jul 22, 2017 at 01:32:17PM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > > Hi, > > > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > > (trunk

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-22 Thread Shawn Webb
On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > Hi, > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > (trunk r308421) into head. Universe builds went just fine, but if you > > encounter

Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

2017-07-22 Thread Shawn Webb
On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > Hi, > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > (trunk r308421) into head. Universe builds went just fine, but if you > encounter any snags during world and/or kernel builds, please file PRs. > >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-24 Thread Bruce Evans
On Tue, 24 Jan 2017, Sean Bruno wrote: On 01/24/17 08:27, Olivier Cochard-Labb?? wrote: On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno > wrote: Did you increase the number of rx/tx rings to 8 and the number of descriptors to 4k in your tests

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-24 Thread Sean Bruno
On 01/24/17 08:27, Olivier Cochard-Labbé wrote: > On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno > wrote: > > > > Did you increase the number of rx/tx rings to 8 and the number of > descriptors to 4k in your tests or just the defaults? >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-24 Thread Olivier Cochard-Labbé
On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno wrote: > > > Did you increase the number of rx/tx rings to 8 and the number of > descriptors to 4k in your tests or just the defaults? > Tuning are same as described in my previous email (rxd|txd=2048, rx|tx process_limit=-1,

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-24 Thread Sean Bruno
On 01/23/17 23:31, Olivier Cochard-Labbé wrote: > On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno > wrote: > > > > Which set of configs from your test suite are you using for this? > Specifically, what packet size are you slamming across? >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Olivier Cochard-Labbé
On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno wrote: > > > Which set of configs from your test suite are you using for this? > Specifically, what packet size are you slamming across? > > https://github.com/ocochard/netbenches/tree/master/pktgen.configs > ​Because I'm in the

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Sean Bruno
On 01/23/17 08:39, Olivier Cochard-Labbé wrote: > > On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy > wrote: > > > A flame graph for the core cycle count and a flame graph with > cache miss stats from pmc would be a great start. > > >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Olivier Cochard-Labbé
On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy wrote: > > A flame graph for the core cycle count and a flame graph with cache > miss stats from pmc would be a great start. > > > > > > ​I didn't know the exact event name to use for cache miss stats, but > here are the flame

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-18 Thread O. Hartmann
On Wed, 18 Jan 2017 07:59:17 -0700 Sean Bruno wrote: > On 01/18/17 07:41, Sean Bruno wrote: > > > > > > On 01/18/17 00:34, O. Hartmann wrote: > >> On Thu, 5 Jan 2017 20:17:56 -0700 > >> Sean Bruno wrote: > >>> > >> On a Fujitsu Celsius M740, the

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-18 Thread Sean Bruno
On 01/18/17 08:20, O. Hartmann wrote: > On Wed, 18 Jan 2017 07:59:17 -0700 > Sean Bruno wrote: > >> On 01/18/17 07:41, Sean Bruno wrote: >>> >>> >>> On 01/18/17 00:34, O. Hartmann wrote: On Thu, 5 Jan 2017 20:17:56 -0700 Sean Bruno wrote:

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-18 Thread Sean Bruno
On 01/18/17 07:41, Sean Bruno wrote: > > > On 01/18/17 00:34, O. Hartmann wrote: >> On Thu, 5 Jan 2017 20:17:56 -0700 >> Sean Bruno wrote: >>> >> On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can >> still trigger this behaviour on recent CURRENT

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-18 Thread Sean Bruno
On 01/18/17 00:34, O. Hartmann wrote: > On Thu, 5 Jan 2017 20:17:56 -0700 > Sean Bruno wrote: > >> tl;dr --> igbX devices will become emX devices >> >> We're about to commit an update to sys/dev/e1000 that will implement and >> activate IFLIB for em(4), lem(4) & igb(4) and

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-18 Thread O. Hartmann
On Thu, 5 Jan 2017 20:17:56 -0700 Sean Bruno wrote: > tl;dr --> igbX devices will become emX devices > > We're about to commit an update to sys/dev/e1000 that will implement and > activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks > who can test and

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
> A flame graph for the core cycle count and a flame graph with cache miss > stats from pmc would be a great start. > > > ​I didn't know the exact event name to use for cache miss stats, but here > are the flame graphs for CPU_CLK_UNHALTED_CORE: >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Sean Bruno
On 01/11/17 15:44, Sean Bruno wrote: > >> My tunning are (same for both test): >> hw.igb.rxd="2048" (it should be useless now) >> hw.igb.txd="2048" (it should be useless now) >> hw.em.rxd="2048" >> hw.em.txd="2048" >> hw.igb.rx_process_limit="-1" (It should be useless now too) >>

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Sean Bruno
> My tunning are (same for both test): > hw.igb.rxd="2048" (it should be useless now) > hw.igb.txd="2048" (it should be useless now) > hw.em.rxd="2048" > hw.em.txd="2048" > hw.igb.rx_process_limit="-1" (It should be useless now too) > hw.em.rx_process_limit="-1" > > dev.igb.2.fc=0 >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Olivier Cochard-Labbé
On Wed, Jan 11, 2017 at 9:40 PM, Matthew Macy wrote: > > > > I can generate profiling data for you: what kind of data do you want > ? > > > > > > > A flame graph for the core cycle count and a flame graph with cache miss > stats from pmc would be a great start. > > ​I

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
> > > My tunning are (same for both test): > > > hw.igb.rxd="2048" (it should be useless now) > > > hw.igb.txd="2048" (it should be useless now) > > Matt: I think he meant "useless now" because there is no igb, and the > below hw.em version covers it. No. igb still exists and the old

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Allan Jude
On 2017-01-11 15:37, Matthew Macy wrote: > You can still explicitly set the number of descriptors. It is now reported > under the dev sysctl tree. dev... > > -M > > > On Wed, 11 Jan 2017 12:34:23 -0800 Olivier Cochard-Labbé > wrote > > > > On Wed, Jan 11,

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Olivier Cochard-Labbé
On Wed, Jan 11, 2017 at 9:13 PM, Matthew Macy wrote: > > > Hmmm ... did your old tests do 4 or 8 queues on this hardware? > > > > Did the old tests run 1024 tx/rx slots or the max 4096? > > That's a great point, only having one thread per core could easily account > for

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
> > I can generate profiling data for you: what kind of data do you want ? > > > A flame graph for the core cycle count and a flame graph with cache miss stats from pmc would be a great start. ___ freebsd-current@freebsd.org mailing list

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
You can still explicitly set the number of descriptors. It is now reported under the dev sysctl tree. dev... -M On Wed, 11 Jan 2017 12:34:23 -0800 Olivier Cochard-Labbé wrote > > On Wed, Jan 11, 2017 at 9:13 PM, Matthew Macy wrote: >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
On Wed, 11 Jan 2017 12:02:06 -0800 Sean Bruno wrote > > > On 01/11/17 12:47, Olivier Cochard-Labbé wrote: > > On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno > > wrote: > > > > > > > >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Sean Bruno
On 01/11/17 12:47, Olivier Cochard-Labbé wrote: > On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno > wrote: > > > > Olivier: > > Give this a quick try. This isn't the correct way to do this, but I > want to see if I'm on the right

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Olivier Cochard-Labbé
On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno wrote: > > > Olivier: > > Give this a quick try. This isn't the correct way to do this, but I > want to see if I'm on the right path: > ​thanks, it fix the problem, I've got back the 4 queues:​ ​igb2:

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
> > x head r311848: packets per second > + head r311849 and BAR patch: packets per second > +--+ > |++++ + xxx x x| > |

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Sean Bruno
On 01/11/17 05:54, Matthew Macy wrote: > > > > On Wed, 11 Jan 2017 01:23:46 -0800 Olivier Cochard-Labbé > wrote > > On Tue, Jan 10, 2017 at 4:31 AM, Sean Bruno wrote: > > > > > > > > I've updated sys/dev/e1000 at svn R311849 to match

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Matthew Macy
On Wed, 11 Jan 2017 01:23:46 -0800 Olivier Cochard-Labbé wrote > On Tue, Jan 10, 2017 at 4:31 AM, Sean Bruno wrote: > > > > > I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on > > IFLIB in the kernel. > > > > At

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Olivier Cochard-Labbé
On Tue, Jan 10, 2017 at 4:31 AM, Sean Bruno wrote: > > I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on > IFLIB in the kernel. > > At this point, the driver deviates from Intel's code dramatically and > you now get to yell directly into the freebsd-net@

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-09 Thread Sean Bruno
tl;dir --> you get to keep your igbX devices(thanks jhb), no POLA violations this week. I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on IFLIB in the kernel. At this point, the driver deviates from Intel's code dramatically and you now get to yell directly into the

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread John Baldwin
On Thursday, January 05, 2017 08:17:56 PM Sean Bruno wrote: > tl;dr --> igbX devices will become emX devices > > We're about to commit an update to sys/dev/e1000 that will implement and > activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks > who can test and poke at the

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread Sean Bruno
On 01/06/17 03:48, Steven Hartland wrote: > Hmm I'm not sure about everyone else but I we treat emX as legacy > devices (not used one in years) but igbX is very common here. > > The impact of changing a nic device name is quite a bit more involved > than just rc.conf it effects other areas too,

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-06 Thread Steven Hartland
Hmm I'm not sure about everyone else but I we treat emX as legacy devices (not used one in years) but igbX is very common here. The impact of changing a nic device name is quite a bit more involved than just rc.conf it effects other areas too, jails etc so given we can loose access to the

Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-05 Thread Matthew Seaman
On 08/05/16 03:09, Glen Barber wrote: > On Fri, Aug 05, 2016 at 01:59:18AM +, Glen Barber wrote: >> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, >> and will be deprecated effective 11.0-RELEASE (and preceeding RCs). >> > > Stupid editor mistake. OpenSSH DSA keys

Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-04 Thread Glen Barber
On Fri, Aug 05, 2016 at 01:59:18AM +, Glen Barber wrote: > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (and preceeding RCs). > Stupid editor mistake. OpenSSH DSA keys are deprecated upstream. Sorry for any

Re: HEADS UP: caution required with updates using custom kernels

2016-06-27 Thread Erich Dollansky
Hi, On Thu, 23 Jun 2016 21:07:51 + Brooks Davis wrote: > Kernel config minimalists and those running aarch64 and riscv systems > will want to head this UPDATING message. > > In practice, if you're fairly up to date, doing installworld before > installkernel will also

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread Konstantin Belousov
On Sat, Jun 25, 2016 at 05:35:31PM +0200, Tijl Coosemans wrote: > On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov > wrote: > > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: > >> Is there a way to salvage the situation without relying on "customized" >

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread O. Hartmann
Am Sat, 25 Jun 2016 17:35:31 +0200 Tijl Coosemans schrieb: > On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov > wrote: > > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: > >> Is there a way to salvage the situation without relying on

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread Tijl Coosemans
On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov wrote: > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: >> Is there a way to salvage the situation without relying on "customized" >> third party kernels? >> >> I usually use /bin/csh - so this might be of

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread Konstantin Belousov
On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: > Am Sat, 25 Jun 2016 14:35:44 +0300 > Konstantin Belousov schrieb: > > > On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > > > Am Sat, 25 Jun 2016 10:02:38 +0300 > > > Konstantin Belousov

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread O. Hartmann
Am Sat, 25 Jun 2016 14:35:44 +0300 Konstantin Belousov schrieb: > On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > > Am Sat, 25 Jun 2016 10:02:38 +0300 > > Konstantin Belousov schrieb: > > > > > On Fri, Jun 24, 2016 at 10:50:34PM +,

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread O. Hartmann
Am Fri, 24 Jun 2016 15:51:11 + Brooks Davis schrieb: > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > Am Thu, 23 Jun 2016 21:07:51 + > > Brooks Davis schrieb: > > > > > Kernel config minimalists and those running aarch64 and

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread Konstantin Belousov
On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > Am Sat, 25 Jun 2016 10:02:38 +0300 > Konstantin Belousov schrieb: > > > On Fri, Jun 24, 2016 at 10:50:34PM +, Brooks Davis wrote: > > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > >

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread O. Hartmann
Am Sat, 25 Jun 2016 10:02:38 +0300 Konstantin Belousov schrieb: > On Fri, Jun 24, 2016 at 10:50:34PM +, Brooks Davis wrote: > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > argument the user thought they were passing and returning the two file >

Re: HEADS UP: caution required with updates using custom kernels

2016-06-25 Thread Konstantin Belousov
On Fri, Jun 24, 2016 at 10:50:34PM +, Brooks Davis wrote: > pipe(2) had an unnecessarily odd calling convention (ignoring the > argument the user thought they were passing and returning the two file > descriptors via the two return registers). This required machine > dependent assembly for

Re: HEADS UP: caution required with updates using custom kernels

2016-06-24 Thread Chris H
On Fri, 24 Jun 2016 22:50:34 + Brooks Davis wrote > On Fri, Jun 24, 2016 at 03:24:21PM -0700, Chris H wrote: > > On Fri, 24 Jun 2016 15:51:11 + Brooks Davis wrote > > > > > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > > > Am

Re: HEADS UP: caution required with updates using custom kernels

2016-06-24 Thread Brooks Davis
On Fri, Jun 24, 2016 at 03:24:21PM -0700, Chris H wrote: > On Fri, 24 Jun 2016 15:51:11 + Brooks Davis wrote > > > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > > Am Thu, 23 Jun 2016 21:07:51 + > > > Brooks Davis schrieb: > > >

Re: HEADS UP: caution required with updates using custom kernels

2016-06-24 Thread Chris H
On Fri, 24 Jun 2016 15:51:11 + Brooks Davis wrote > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > Am Thu, 23 Jun 2016 21:07:51 + > > Brooks Davis schrieb: > > > > > Kernel config minimalists and those running aarch64 and riscv

Re: HEADS UP: caution required with updates using custom kernels

2016-06-24 Thread Kurt Lidl
Am Fri, 24 Jun 2016 15:51:11 + Brooks Davis schrieb: On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > Am Thu, 23 Jun 2016 21:07:51 + > Brooks Davis schrieb: > > > Kernel config minimalists and those running aarch64 and riscv systems will > > want to head this UPDATING

  1   2   3   4   5   6   7   8   9   10   >