Heads up for LinuxKPI updates to 12-STABLE

2019-05-25 Thread Johannes Lundberg
Hi As with recent 13-CURRENT, we're pushing some updates that might break build of drm modules temporarily on 12-STABLE. One of those changes is moving lindebugfs.ko from ports to base. If you're building your kernel with MODULES_OVERRIDE, don't forget to include it since it is required by drm

Re: Just a heads up : /usr/bin/time missing after install

2019-05-25 Thread Dennis Clarke
On 5/25/19 11:28 AM, David Wolfskill wrote: On Sat, May 25, 2019 at 10:13:45AM -0400, Dennis Clarke wrote: Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img and /usr/bin/time was seen to be missing. ... I see it on my systems after source-based updates to r348231 and

Re: Just a heads up : /usr/bin/time missing after install

2019-05-25 Thread David Wolfskill
On Sat, May 25, 2019 at 10:13:45AM -0400, Dennis Clarke wrote: > > Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img > and /usr/bin/time was seen to be missing. > ... I see it on my systems after source-based updates to r348231 and r348268 (on amd64). E.g.:

Just a heads up : /usr/bin/time missing after install

2019-05-25 Thread Dennis Clarke
Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img and /usr/bin/time was seen to be missing. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ freebsd-current@freebsd.org

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 >

Heads up for breaking drm update.

2019-05-19 Thread Johannes Lundberg
Hi Cross posting to -current and -x11. 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 packages should be available shortly. A

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

HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-09 Thread Glen Barber
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 progress, and thank you to all involved for their hard

Heads up: nfsuserd -use-udpsock option no longer used

2018-08-22 Thread Rick Macklem
As of r338192 the command line option "-use-udpsock" no longer exists, since r320757 has been reverted. The behaviour is now back to always using a UDP socket the same as stable/11. In other words, if you are using the nfsuserd with the "-use-udpsock" option, just get rid of the "-use-udpsock"

Heads Up: rebuild nfsd if using the "-p" option

2018-07-02 Thread Rick Macklem
r335870 changes the interface between the nfsd and the kernel for the case where the "-p" option is used, so if you are using "nfsd -p" you should rebuild your nfsd from sources of r335871 or later. To be honest, I didn't see problems during testing, but I think that is because there are some

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

Heads Up: pNFS server merge committed to head

2018-06-12 Thread Rick Macklem
Since I only got one response to my query w.r.t. should projects/pnfs-planb-server be merged into head and it wasn't negative, I went with "no news is good news" and did the merge/commit. It is now in head as r335012. Since it has survived a recent "make universe", I hope it won't cause build

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

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

2018-05-14 Thread Ed Maste
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 support. The typical 'make

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

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

2018-04-20 Thread Ed Maste
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 and v4

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@)

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

2018-03-26 Thread Ed Maste
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@) has a patch to start using kernel ifunc, with the first use being Supervisor

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

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

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

HEADS-UP: release-releated documentation moving from base to doc repository

2017-10-05 Thread Glen Barber
Hi, I have expressed my intent to move the release-related documents from the src tree to the doc tree in the past. This has been met with some resistance, but I think this change is far overdue at this point. The primary motivation behind this change is that if there is an error in

[HEADS UP] Update of graphics/drm-next-kmod is required after FreeBSD r323702

2017-09-18 Thread Hans Petter Selasky
Hi, If you are using the drm-next-kmod from ports, don't upgrade your kernel beyond r323702 until the drm-next-kmod port has been updated. There are some changes planned for the LinuxKPI which can lead to memory leaks if you mix the versions together. Rebuilding the drm-next-kmod module is

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

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

2017-07-22 Thread Dimitry Andric
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. Since upstream has just created their 5.0.0 release branch, this is a good month

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

2017-05-26 Thread Bryan Drewery
On 5/26/2017 8:20 AM, Bryan Drewery wrote: > For those running FreeBSD head, the ABI was majorly changed in r318736 > for 64-bit inodes. This change was *backwards compatible* but not > *forward compatible*. This is normal and expected. > > For Pkg users: > > You are advised to upgrade your

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

2017-05-26 Thread Ed Maste
On 26 May 2017 at 12:18, Kurt Jaeger wrote: > Hi! > >> For those running FreeBSD head, the ABI was majorly changed in r318736 >> for 64-bit inodes. This change was *backwards compatible* but not >> *forward compatible*. This is normal and expected. > > Is any fall-out from this

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

2017-05-26 Thread Kurt Jaeger
Hi! > For those running FreeBSD head, the ABI was majorly changed in r318736 > for 64-bit inodes. This change was *backwards compatible* but not > *forward compatible*. This is normal and expected. Is any fall-out from this change already handled or is it wise to wait a few more days ? --

(head users) 64-bit inodes: Packages heads up and Poudriere errors

2017-05-26 Thread Bryan Drewery
For those running FreeBSD head, the ABI was majorly changed in r318736 for 64-bit inodes. This change was *backwards compatible* but not *forward compatible*. This is normal and expected. For Pkg users: You are advised to upgrade your system past r318736 soon or avoid using official packages

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@

  1   2   3   4   5   6   7   8   9   10   >