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

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 /sys/amd64/compile/GENERIC;make cleandepend; make c

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

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 > iflib.o:(.rodata+0x178): undefined

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

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 su

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

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 bui

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

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

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

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 record

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

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 contemporary binutils ld.bfd

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

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@) has a patch to start u

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

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 Mode

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

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 >> didn't try to ch

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

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 is probably not a v

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

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

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 to > bring the lld

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

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

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

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

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

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 c

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

>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

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 release-rela

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

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 no

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

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)

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 wh

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

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 h

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

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)

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)

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 -> TARGET_ARCH=powerpc64

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

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 merged clang, llvm, lld, lldb,

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

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 r30842

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

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)

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

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

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 to

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

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 sys

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

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 change already ha

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

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

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

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 u

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

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 mailto:sbr...@freebsd.org>> 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

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? > > > Tuning are same a

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

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, max_interrupt_rate=16000).

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

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? > > https://github

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

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 point of view of a Telc

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

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. > > > > > > ​I d

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

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 graphs for CPU_CLK_

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

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 "em0" device gets stuck on heavy I/O. I ca

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

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: > On a Fujitsu Celsius M740, t

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

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 (12.0-CURRENT #17 r3123

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

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 would appreciate all

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

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 poke at the drivers to d

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

> 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: > http://dev.bsdrp.net/netgate.r311848.C

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

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) >> hw.em.rx_proces

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

> 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 > dev.igb.3.fc=

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

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 didn't know the exact e

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

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

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

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, 2017 at 9:13 PM, Matth

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

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 this. I'm hoping Sean c

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

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

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

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: > > > Hmmm ... did your old tests do 4 o

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

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: > > > > > > > > Olivier: > > > > Give this a quick try.

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

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 path: > > > ​thanks, it

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

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: port 0x3000-0x301f mem 0xdfea-0xdfeb,0xd

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

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

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 Matt Macy's work on > > > IFLIB in the

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

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 this point, the driver deviates from Int

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

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@ megaphone for things

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

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 freebsd-n

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

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 driver

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

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

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 mach

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

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 drivers to do so this week. This will have some really great changes for pe

[REVISED] [HEADS-UP] 11.0-RELEASE status update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: [Corrected the date.] Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republish

[HEADS-UP] 11.0-RELEASE status update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirro

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

On 09/08/2016 03:23, Jeffrey Bouquet wrote: > Will/could there be some kind of UPDATING announcement re which files > explicitly to switch out/remove/replace/checkfor etc the deprecated > lines and precisely the steps to replace with new or some other > suitable action? Action required for both the

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

tps://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31 > >> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31>> > >> suggesting a return to encryption based on non-elliptic-curve groups. > >> "" > >> Or perhaps

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

_cryptography#cite_note-31 >> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31>> >> suggesting a return to encryption based on non-elliptic-curve groups. >> "" >> Or perhaps RSA? (as des@ recommends) >> (not necessarily to Gle

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

hy#cite_note-31> suggesting a return to encryption based on non-elliptic-curve groups. "" Or perhaps RSA? (as des@ recommends) (not necessarily to Glen but anyone that wants to answer) -- Devin On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SH

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

urity of the NIST recommended elliptic curves,[31] >> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31> >> suggesting a return to encryption based on non-elliptic-curve groups. "" >> >> Or perhaps RSA? (as des@ recommends) >> >>

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

gt; > suggesting a return to encryption based on non-elliptic-curve groups. "" > > Or perhaps RSA? (as des@ recommends) > > (not necessarily to Glen but anyone that wants to answer) > -- > Devin > > >> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >>

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

ly to Glen but anyone that wants to answer) -- Devin > On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (

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

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

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

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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, and will be deprecated effective 11.0-RELEASE (and preceeding RCs). Please see r303716 for details on the relevant commit, but upstream no longer considers them secure

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

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 work (I've tested that

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

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" > >> third party kernels?

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

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 "customized" > >> third party kernels?

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

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 use. > > You need ei

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

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 schrieb: > > > > > > > On Fri,

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

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 +, Brooks Davis wrote: > > > > pipe(2) had

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

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

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

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 > > > argument the user thou

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

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 > > descriptors via the

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

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 eve

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

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 Thu, 23 Jun 2016 21:07:51 + > > > > Br

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

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: > > > > > > > Kernel config minimalists and th

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

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 systems > > > will want to head this UPDA

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

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 mes

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

I put a GENERIC kernel plus modules for amd64 at: http://www.pozo.com/kernel/kernel.tar.bz2 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubs

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

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

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

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 message. > > > > In practice, if you're fairly up to date, doi

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

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 message. > > In practice, if you're fairly up to date, doing installworld before > installkernel will also work (I've tested that cas

HEADS UP: caution required with updates using custom kernels

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 work (I've tested that case from ALPHA4), but is always somewhat risky. -- Brooks - Forwa

Heads Up: struct disk KBI change

This will break binary compatibility for loadable modules that depend on struct disk. DISK_VERSION has been bumped, and I bumped __FreeBSD_version in a subsequent change. So, if you have module that uses struct disk, you'll need to recompile against the latest version of head. Ken - Forwar

<    1   2   3   4   5   6   7   8   9   10   >