Looking for feedback on change to iflib and transmit queuing

[Eric Joyner]

Hi, I have a Phabricator review here that I was hoping to get some feedback
on: https://reviews.freebsd.org/D34742

In short, there's already some functionality in current and 13.1-RELEASE
that allows a driver to pick a TX queue for a packet, but this extends that
support to have iflib do some limited parsing in order to give the driver
function extra information in order to make a decision. Performance-wise
this doesn't seem to affect much; I looked at it in VTune across different
types of netperf runs with small packets that want L4 checksums.

In fact, that made me find out that iflib_parse_header() does tons of
unnecessary m_pullups() on small UDP packets; as much as 10% of the CPU
time can be spent just doing that. It should maybe get modified to not
pull-up to the TCP header length for UDP packets.

- Eric

Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))

[Eric Joyner]

Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and
igb devices will use the same function instead of using two different ones
even though it seems em devices generally require the interface restart yet
igb devices do not.

The other issue is that I still don't know which devices need a restart /
which devices do not, or whether a restart is strictly necessary and if
there is another way to do this without worrying about restarting the
device.

- Eric

On Fri, Nov 6, 2020 at 3:35 PM mike tancsa  wrote:

> On 11/6/2020 5:32 PM, Eric Joyner wrote:
> > Could you reply to that issue with what you've found?
> >
> > Though, as far as I can recall, igb(4) devices are not supposed to do
> > the iflib reset talked about in the bug, so I wouldn't expect to see a
> > link flap on those.
> >
> Hi Eric,
>
> I have added my findings to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
> I tried it on 3 different vendor's boards. All I210 variants it seems.
>
> I am testing with
>
> --- if_em.c 2020-11-06 15:00:22.120953000 -0500
> +++ /tmp/if_em.c2020-11-06 14:59:55.678195000 -0500
> @@ -4047,6 +4047,7 @@
>  {
> switch (event) {
> case IFLIB_RESTART_VLAN_CONFIG:
> +   return (false);
> default:
> return (true);
> }
>
> And if fixes the problem, but not quite sure if it introduces any
> regressions or other issues ?
>
> ---Mike
>
>
> > - Eric
> >
> > On Fri, Nov 6, 2020 at 12:48 PM mike tancsa  > <mailto:m...@sentex.net>> wrote:
> >
> > On 11/6/2020 2:17 PM, mike tancsa wrote:
> > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> > >> Hello Ian,
> > >>
> > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> > >>
> > >>> I noticed that my VLAN interfaces stopped working after a
> > recent build.
> > >>> tcpdump showed traffic leaving leaving and entering the
> > interface but no
> > >>> host on the network actually received any packets from this
> > host.  A
> > >>> binary search led me to r360902 and indeed the following
> > change fixed
> > >>> the issue for me:
> > >>  Problem is, this change will return terrible situation when
> > adding new VLAN
> > >> will flap connection status.
> > >>
> > >>  It all worked before iflib: hardware VLAN filtering worked, and
> > >> adding/removing new VLAN didn't cause link to flap.
> > >>
> > >>  Now, with iflib, looks like we can not have all good things at
> > once :(
> >
> >
> > Looks like this is captured in
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818>
> >
> >
> > > Hi All,
> > >
> > > Just came across this thread as I am running into this behaviour on
> > > RELENG_12.  Adding a new vlan causes all vlans on the parent
> > interface
> > > to flap. Not the greatest thing as it bounces a LOT of traffic
> > > potentially, flaps routing etc.  Is there a way around this ?
> > >
> > > This is on r367411 releng12
> > >
> > > igb0@pci0:2:0:0:class=0x02 card=0x153315d9
> > chip=0x15338086
> > > rev=0x03 hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'I210 Gigabit Network Connection'
> > > class  = network
> > > subclass   = ethernet
> > >
> > > eg. just something simple like
> > >
> > > ifconfig vlan16 create 10.1.2.3/29 <http://10.1.2.3/29> vlandev
> > igb1 vlan 16
> > >
> > >  # dmesg | tail -8
> > > igb1: link state changed to DOWN
> > > vlan16: link state changed to DOWN
> > > vlan2049: link state changed to DOWN
> > > vlan15: link state changed to DOWN
> > > igb1: link state changed to UP
> > > vlan16: link state changed to UP
> > > vlan2049: link state changed to UP
> > > vlan15: link state changed to UP
> > >
> > >
> > > ---Mike
> > >
> > >
> > >
> > >
> > > _

Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))

[Eric Joyner]

Could you reply to that issue with what you've found?

Though, as far as I can recall, igb(4) devices are not supposed to do
the iflib reset talked about in the bug, so I wouldn't expect to see a link
flap on those.

- Eric

On Fri, Nov 6, 2020 at 12:48 PM mike tancsa  wrote:

> On 11/6/2020 2:17 PM, mike tancsa wrote:
> > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >> Hello Ian,
> >>
> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >>
> >>> I noticed that my VLAN interfaces stopped working after a recent
> build.
> >>> tcpdump showed traffic leaving leaving and entering the interface but
> no
> >>> host on the network actually received any packets from this host.  A
> >>> binary search led me to r360902 and indeed the following change fixed
> >>> the issue for me:
> >>  Problem is, this change will return terrible situation when adding new
> VLAN
> >> will flap connection status.
> >>
> >>  It all worked before iflib: hardware VLAN filtering worked, and
> >> adding/removing new VLAN didn't cause link to flap.
> >>
> >>  Now, with iflib, looks like we can not have all good things at once :(
>
>
> Looks like this is captured in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
>
> > Hi All,
> >
> > Just came across this thread as I am running into this behaviour on
> > RELENG_12.  Adding a new vlan causes all vlans on the parent interface
> > to flap. Not the greatest thing as it bounces a LOT of traffic
> > potentially, flaps routing etc.  Is there a way around this ?
> >
> > This is on r367411 releng12
> >
> > igb0@pci0:2:0:0:class=0x02 card=0x153315d9 chip=0x15338086
> > rev=0x03 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'I210 Gigabit Network Connection'
> > class  = network
> > subclass   = ethernet
> >
> > eg. just something simple like
> >
> > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16
> >
> >  # dmesg | tail -8
> > igb1: link state changed to DOWN
> > vlan16: link state changed to DOWN
> > vlan2049: link state changed to DOWN
> > vlan15: link state changed to DOWN
> > igb1: link state changed to UP
> > vlan16: link state changed to UP
> > vlan2049: link state changed to UP
> > vlan15: link state changed to UP
> >
> >
> > ---Mike
> >
> >
> >
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Eric Joyner]

I didn't realize it was going to get updated so soon, but the versions on
that page were at "8.16.5" for the Windows and Linux versions when I sent
my email a couple days ago.

It also appears the versions for the OSs aren't all updated at the same
time (.6 seems to only includes Windows/macOS fixes), so it's still
possible we'll see 8.16.6 or 8.16.7 for FreeBSD later, absent any official
messaging.

On Fri, Dec 6, 2019 at 11:08 AM Jamie Landeg-Jones 
wrote:

> Eric Joyner  wrote:
>
> > I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD
> > support? Do you have a link to something that shows that?
> >
> > I still see a FreeBSD tarball in their download archive page for the
> newest
> > version of their tool, which seems to be 8.16.5.
>
> It appears that the "archive" is for older releases. The latest is 8.16.6
> and
> isn't listed for FreeBSD:
>
> https://www.bullseye.com/cgi-bin/download
>
> Cheers, Jamie
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Eric Joyner]

I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD
support? Do you have a link to something that shows that?

I still see a FreeBSD tarball in their download archive page for the newest
version of their tool, which seems to be 8.16.5.

- Eric

On Thu, Aug 8, 2019 at 12:08 PM Alan Somers  wrote:

> Read the bug report.  I can't even load modules when I build with GCOV.
>
> On Thu, Aug 8, 2019 at 1:04 PM Matthew Macy  wrote:
> >
> > The whole point of adding gcov support was for integrating with the
> > ZoL CI framework which does coverage. So it very much does work with
> > modules. Not sure where that comes from.
> > -M
> >
> > On Thu, Aug 8, 2019 at 6:52 AM Alan Somers  wrote:
> > >
> > > On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen 
> wrote:
> > > >
> > > >
> > > >
> > > > > On 8. Aug 2019, at 14:24, Slava Shwartsman 
> wrote:
> > > > >
> > > > > Apparently, Bullseye are dropping support for FreeBSD.
> > > > >
> > > > > We are looking for an alternative for kernel module run time
> analysis.
> > > > > Mostly interested in code coverage (for now).
> > > > >
> > > > > Any suggestions that work for you?
> > > > Have you looked into /dev/kcov. This is used by SYZKALLER for getting
> > > > coverage information from the kernel.
> > > >
> > > > Best regards
> > > > Michael
> > > > >
> > > > >
> > > > > Slava
> > >
> > > That's part of Matt Macy's gcov project, right?.  However, while it
> > > works for the kernel itself, it doesn't work for modules.
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194
> > > -Alan
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building freebsd on another OS

[Eric Joyner]

On Tue, Mar 19, 2019 at 5:40 AM David Chisnall  wrote:

> That said, FreeBSD also runs very well under Hyper-V, so if you have
> enough RAM then you may find that a better option.  In my experience,
> compilers that spawn a new process for every file (e.g. gcc, clang) are
> noticeably faster in a FreeBSD VM on Windows than in WSL or native in
> Windows (and a *lot* faster than their cygwin versions).
>
> David
>

Thanks David, running FreeBSD VM using Hyper-V wasn't something I had
considered before; I thought
my options would've been limited to using WSL or Cygwin/msys2 to get it to
compile on Windows.

I'll go see if I'm allowed to use Hyper-V on my company-issued laptop...

- Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Building freebsd on another OS

[Eric Joyner]

On Sun, Mar 17, 2019 at 6:35 AM Hans Petter Selasky  wrote:

>
> See the freebsd-build utils package for Linux.
>
> --HPS
>
>
Is there anything for Windows?

- Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problem building dev/e1000

[Eric Joyner]

ifdi_if.h is a system generated interface file that network drivers that
depend on iflib use. It's generated from ifdi_if.m in sys/net.

My guess is that you don't have "device iflib" defined in your kernel
configuration. em(4) depends on iflib in FreeBSD 12/13, and with r343617,
iflib is now explicitly a module that needs to be included in your kernel
config if you want to use a driver that depends on it. It's already in the
GENERIC kernel for amd64; are you using a kernel config file that doesn't
inherit from GENERIC?

- Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problem building dev/e1000

[Eric Joyner]

Looking through the SVN logs, it looks like kib put an entry in the
stable/12 UPDATING in r344149 when he MFC'd the "make iflib a loadable
module" changes.

As for the em man page, they don't note the specific "device iflib"
dependency, so that needs to be added (as well as a more general update
since it looks like it's out of date). Though, there is at least a mention
of it using iflib near the bottom.

- Eric

On Fri, Feb 15, 2019 at 10:53 AM Enji Cooper  wrote:

>
> > On Feb 15, 2019, at 10:46, Eric Joyner  wrote:
> >
> > ifdi_if.h is a system generated interface file that network drivers that
> depend on iflib use. It's generated from ifdi_if.m in sys/net.
> >
> > My guess is that you don't have "device iflib" defined in your kernel
> configuration. em(4) depends on iflib in FreeBSD 12/13, and with r343617,
> iflib is now explicitly a module that needs to be included in your kernel
> config if you want to use a driver that depends on it. It's already in the
> GENERIC kernel for amd64; are you using a kernel config file that doesn't
> inherit from GENERIC?
>
> HO Eric!
>
> iflib was a recently added requirement on stable/12 IIRC..?
>
> Does the manpage note this dependency, and is there an UPDATING entry for
> this change?
>
> Thanks!
> -Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Hyper-V FreeBSD-CURRENT Guest and SR-IOV Pass Through

[Eric Joyner]

None of the Intel networking drivers on FreeBSD support Hyper-V.

Could you try "Discrete Device Assignment" instead? Create the VFs on the
host somehow, then pass them through to the VMs? That looks like it might
work for the FreeBSD VF drivers.

- Eric

On Mon, Oct 22, 2018 at 12:11 PM Michael Pro  wrote:

> When we try to enable the SR-IOV function of Network-Adapter in the
> properties of the virtual machine, we get
>
> f12rw kernel: hn0: got notify, nvs type 128
> f12rw kernel: pcib0:  on vmbus0
> f12rw kernel: pcib0: failed to get resource for cfg window
> f12rw kernel: device_attach: pcib0 attach returned 6
>
> In Windows Guest systems 10G SR-IOV function works perfect on this
> Hyper-V hosts.
>
> Hyper-V 2016 and Hyper-V 2019 (windows servers) HOSTS,
> Network adapters Intel X540-T2, X540-T1, X520-T1, X540-AT2 and 10G 2P
> X540-t.
>
> FreeBSD Guest system ( /var/log/messages ):
>
> f12rw syslogd: kernel boot file is /boot/kernel/kernel
> f12rw kernel: ---<>---
> f12rw kernel: Copyright (c) 1992-2018 The FreeBSD Project.
> f12rw kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> 1992, 1993, 1994
> f12rw kernel:   The Regents of the University of California. All
> rights reserved.
> f12rw kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
> f12rw kernel: FreeBSD 13.0-CURRENT #0 e1b49380456(master)-dirty: Sat
> Oct 20 15:26:15 EEST 2018
> f12rw kernel:
> root@f12rw:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-DBGless amd64
> f12rw kernel: FreeBSD clang version 6.0.1 (tags/RELEASE_601/final
> 335540) (based on LLVM 6.0.1)
> f12rw kernel: SRAT: Ignoring memory at addr 0x3f000
> f12rw kernel: SRAT: Ignoring memory at addr 0x10
> f12rw kernel: SRAT: Ignoring memory at addr 0x100
> f12rw kernel: SRAT: Ignoring memory at addr 0x200
> f12rw kernel: SRAT: Ignoring memory at addr 0x400
> f12rw kernel: SRAT: Ignoring memory at addr 0x800
> f12rw kernel: SRAT: Ignoring memory at addr 0x9e800
> f12rw kernel: SRAT: Ignoring memory at addr 0x88
> f12rw kernel: SRAT: Ignoring memory at addr 0x180
> f12rw kernel: SRAT: Ignoring memory at addr 0x300
> f12rw kernel: SRAT: Ignoring memory at addr 0x600
> f12rw kernel: SRAT: Ignoring memory at addr 0xc00
> f12rw kernel: VT(efifb): resolution 1024x768
> f12rw kernel: Hyper-V Version: 10.0.17763 [SP0]
> f12rw kernel:
>
> Features=0x2e7f
> f12rw kernel:   PM Features=0x0 [C2]
> f12rw kernel:
> Features3=0xbed7b2
> f12rw kernel: Timecounter "Hyper-V" frequency 1000 Hz quality 2000
> f12rw kernel: module_register: cannot register pci/ixv from kernel;
> already loaded from if_ixv.ko
> f12rw kernel: Module pci/ixv failed to register: 17
> f12rw kernel: CPU: Genuine Intel(R) CPU  @ 2.90GHz (2900.00-MHz
> K8-class CPU)
> f12rw kernel:   Origin="GenuineIntel"  Id=0x406f0  Family=0x6
> Model=0x4f  Stepping=0
> f12rw kernel:
>
> Features=0x1f83fbff
> f12rw kernel:
>
> Features2=0xfeda3203
> f12rw kernel:   AMD Features=0x2c100800
> f12rw kernel:   AMD Features2=0x121
> f12rw kernel:   Structured Extended
>
> Features=0x1c2fb9
> f12rw kernel:   Structured Extended Features3=0x2000
> f12rw kernel:   XSAVE Features=0x1
> f12rw kernel:   IA32_ARCH_CAPS=0x4
> f12rw kernel: Hypervisor: Origin = "Microsoft Hv"
> f12rw kernel: real memory  = 16777216000 (16000 MB)
> f12rw kernel: avail memory = 16249954304 (15497 MB)
> f12rw kernel: Event timer "LAPIC" quality 100
> f12rw kernel: ACPI APIC Table: 
> f12rw kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
> f12rw kernel: FreeBSD/SMP: 2 package(s) x 2 core(s) x 2 hardware threads
> f12rw kernel: random: unblocking device.
> f12rw kernel: ioapic0  irqs 0-23 on motherboard
> f12rw kernel: Launching APs: 1 3 2 6 7 4 5
> f12rw kernel: Timecounter "Hyper-V-TSC" frequency 1000 Hz quality 3000
> f12rw kernel: random: entropy device external interface
> f12rw kernel: [ath_hal] loaded
> f12rw kernel: kbd0 at kbdmux0
> f12rw kernel: module_register_init: MOD_LOAD (vesa,
> 0x811cdc50, 0) error 19
> f12rw kernel: random: registering fast source Intel Secure Key RNG
> f12rw kernel: random: fast provider: "Intel Secure Key RNG"
> f12rw kernel: netmap: loaded module
> f12rw kernel: nexus0
> f12rw kernel: efirtc0:  on motherboard
> f12rw kernel: efirtc0: registered as a time-of-day clock, resolution
> 1.00s
> f12rw kernel: cryptosoft0:  on motherboard
> f12rw kernel: acpi0:  on motherboard
> f12rw kernel: atrtc0:  port 0x70-0x71 irq 8 on acpi0
> f12rw kernel: atrtc0: registered as a time-of-day clock, resolution
> 1.00s
> f12rw kernel: Event timer "RTC" frequency 32768 Hz quality 0
> f12rw kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> f12rw kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port
> 0x408-0x40b on acpi0
> f12rw kernel: cpu0:  on acpi0
> f12rw kernel: acpi_syscontainer0:  iomem
> 0xf800-0x,0xfe000-0xf on acpi0
> f12rw kernel: vmbus0:  on acpi_s

mount_smbfs stack overflow issue with long hostnames

[Eric Joyner]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228354

Can someone look at fixing this for 12? Non-gracefully handling long names
is a pretty bad bug.

- Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: List test, please ignore.

[Eric Joyner]

Never!

On Tue, Apr 11, 2017 at 3:18 PM Sean Bruno  wrote:

> ignore
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Does someone keep track of how long it takes to buildworld/kernel?

[Eric Joyner]

^ Message ^

It takes forever, but I keep on forgetting to time how long it takes, so I
don't know how long "forever" is.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How many CPU cores does FreeBSD support?

[Eric Joyner]

I started off with a snapshot of 12-CURRENT, but I got a kernel panic on
boot that complained about a duplicate local APIC ID. For now, disabling
Hyper Threading gets rid of that panic. I think there's a KASSERT that
wasn't getting hit on my 11.0-RELEASE install.

On Wed, Jan 4, 2017 at 2:00 PM Eric Joyner  wrote:

> Ok; I will try that and will report back.
>
> - Eric
>
> On Wed, Jan 4, 2017 at 11:59 AM Konstantin Belousov 
> wrote:
>
> On Wed, Jan 04, 2017 at 06:53:23PM +, Eric Joyner wrote:
> > Adding freebsd-current, because that's a good idea.
> >
> > I see these lines in the beginning of dmesg:
> >
> > MADT: Ignoring local APIC ID 256 (too high)
> >
> >
> >   [907/911]
> > MADT: Ignoring local APIC ID 260 (too high)
> >
> >
> >   [906/911]
> > MADT: Ignoring local APIC ID 264 (too high)
> >
> >
> >   [905/911]
> > MADT: Ignoring local APIC ID 268 (too high)
> >
> >
> >   [904/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> >
> >
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> >
> >
> >   [901/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> >
> >
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> >
> >
> >   [901/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> > MADT: Ignoring local APIC ID 284 (too high)
> > MADT: Ignoring local APIC ID 288 (too high)
> > MADT: Ignoring local APIC ID 292 (too high)
> > MADT: Ignoring local APIC ID 296 (too high)
> > MADT: Ignoring local APIC ID 300 (too high)
> > MADT: Ignoring local APIC ID 257 (too high)
> > MADT: Ignoring local APIC ID 261 (too high)
> > MADT: Ignoring local APIC ID 265 (too high)
> > MADT: Ignoring local APIC ID 269 (too high)
> > MADT: Ignoring local APIC ID 273 (too high)
> > MADT: Ignoring local APIC ID 277 (too high)
> > MADT: Ignoring local APIC ID 281 (too high)
> > MADT: Ignoring local APIC ID 285 (too high)
> > MADT: Ignoring local APIC ID 289 (too high)
> > MADT: Ignoring local APIC ID 293 (too high)
> > MADT: Ignoring local APIC ID 297 (too high)
> > MADT: Ignoring local APIC ID 301 (too high)
> > MADT: Ignoring local APIC ID 258 (too high)
> > MADT: Ignoring local APIC ID 262 (too high)
> > MADT: Ignoring local APIC ID 266 (too high)
> > MADT: Ignoring local APIC ID 270 (too high)
> > MADT: Ignoring local APIC ID 274 (too high)
> > MADT: Ignoring local APIC ID 278 (too high)
> > MADT: Ignoring local APIC ID 282 (too high)
> > MADT: Ignoring local APIC ID 286 (too high)
> > MADT: Ignoring local APIC ID 290 (too high)
> > MADT: Ignoring local APIC ID 294 (too high)
> > MADT: Ignoring local APIC ID 298 (too high)
> > MADT: Ignoring local APIC ID 302 (too high)
> > MADT: Ignoring local APIC ID 255 (too high)
> > MADT: Ignoring local APIC ID 259 (too high)
> > MADT: Ignoring local APIC ID 263 (too high)
> > MADT: Ignoring local APIC ID 267 (too high)
> > MADT: Ignoring local APIC ID 271 (too high)
> > MADT: Ignoring local APIC ID 275 (too high)
> > MADT: Ignoring local APIC ID 279 (too high)
> > MADT: Ignoring local APIC ID 283 (too high)
> > MADT: Ignoring local APIC ID 287 (too high)
> > MADT: Ignoring local APIC ID 291 (too high)
> > MADT: Ignoring local APIC ID 295 (too high)
> > MADT: Ignoring local APIC ID 299 (too high)
> > MADT: Ignoring local APIC ID 303 (too high)
> > Copyright (c) 1992-2016 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016
> > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
> LLVM
> > 3.8.0)
> > SRAT: No CPU found for memory domain 1
> > VT(efifb): resolution 800x600
> > CPU: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x50671  Family=0x6  Model=0x57  Stepping=1
> >
> >
> Features=0xbfebfbff
> >
> >
> Featu

Re: How many CPU cores does FreeBSD support?

[Eric Joyner]

Ok; I will try that and will report back.

- Eric

On Wed, Jan 4, 2017 at 11:59 AM Konstantin Belousov 
wrote:

> On Wed, Jan 04, 2017 at 06:53:23PM +0000, Eric Joyner wrote:
> > Adding freebsd-current, because that's a good idea.
> >
> > I see these lines in the beginning of dmesg:
> >
> > MADT: Ignoring local APIC ID 256 (too high)
> >
> >
> >   [907/911]
> > MADT: Ignoring local APIC ID 260 (too high)
> >
> >
> >   [906/911]
> > MADT: Ignoring local APIC ID 264 (too high)
> >
> >
> >   [905/911]
> > MADT: Ignoring local APIC ID 268 (too high)
> >
> >
> >   [904/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> >
> >
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> >
> >
> >   [901/911]
> > MADT: Ignoring local APIC ID 272 (too high)
> >
> >
> >   [903/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> >
> >
> >   [901/911]
> > MADT: Ignoring local APIC ID 276 (too high)
> >
> >
> >   [902/911]
> > MADT: Ignoring local APIC ID 280 (too high)
> > MADT: Ignoring local APIC ID 284 (too high)
> > MADT: Ignoring local APIC ID 288 (too high)
> > MADT: Ignoring local APIC ID 292 (too high)
> > MADT: Ignoring local APIC ID 296 (too high)
> > MADT: Ignoring local APIC ID 300 (too high)
> > MADT: Ignoring local APIC ID 257 (too high)
> > MADT: Ignoring local APIC ID 261 (too high)
> > MADT: Ignoring local APIC ID 265 (too high)
> > MADT: Ignoring local APIC ID 269 (too high)
> > MADT: Ignoring local APIC ID 273 (too high)
> > MADT: Ignoring local APIC ID 277 (too high)
> > MADT: Ignoring local APIC ID 281 (too high)
> > MADT: Ignoring local APIC ID 285 (too high)
> > MADT: Ignoring local APIC ID 289 (too high)
> > MADT: Ignoring local APIC ID 293 (too high)
> > MADT: Ignoring local APIC ID 297 (too high)
> > MADT: Ignoring local APIC ID 301 (too high)
> > MADT: Ignoring local APIC ID 258 (too high)
> > MADT: Ignoring local APIC ID 262 (too high)
> > MADT: Ignoring local APIC ID 266 (too high)
> > MADT: Ignoring local APIC ID 270 (too high)
> > MADT: Ignoring local APIC ID 274 (too high)
> > MADT: Ignoring local APIC ID 278 (too high)
> > MADT: Ignoring local APIC ID 282 (too high)
> > MADT: Ignoring local APIC ID 286 (too high)
> > MADT: Ignoring local APIC ID 290 (too high)
> > MADT: Ignoring local APIC ID 294 (too high)
> > MADT: Ignoring local APIC ID 298 (too high)
> > MADT: Ignoring local APIC ID 302 (too high)
> > MADT: Ignoring local APIC ID 255 (too high)
> > MADT: Ignoring local APIC ID 259 (too high)
> > MADT: Ignoring local APIC ID 263 (too high)
> > MADT: Ignoring local APIC ID 267 (too high)
> > MADT: Ignoring local APIC ID 271 (too high)
> > MADT: Ignoring local APIC ID 275 (too high)
> > MADT: Ignoring local APIC ID 279 (too high)
> > MADT: Ignoring local APIC ID 283 (too high)
> > MADT: Ignoring local APIC ID 287 (too high)
> > MADT: Ignoring local APIC ID 291 (too high)
> > MADT: Ignoring local APIC ID 295 (too high)
> > MADT: Ignoring local APIC ID 299 (too high)
> > MADT: Ignoring local APIC ID 303 (too high)
> > Copyright (c) 1992-2016 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016
> > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
> LLVM
> > 3.8.0)
> > SRAT: No CPU found for memory domain 1
> > VT(efifb): resolution 800x600
> > CPU: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz (1396.80-MHz K8-class CPU)
> >   Origin="GenuineIntel"  Id=0x50671  Family=0x6  Model=0x57  Stepping=1
> >
> >
> Features=0xbfebfbff
> >
> >
> Features2=0x7ff8f39f
> >   AMD Features=0x2c100800
> >   AMD Features2=0x121
> >   Structured Extended
> >
> Features=0x1c0d23ab
> >   Structured Extended Features2=0x1
> >   XSAVE Features=0x1
> >   TSC: P-state invariant, performance statistics
> > real memory  = 223332007936 (212986 MB)
> > avail memory = 2

Re: How many CPU cores does FreeBSD support?

[Eric Joyner]

Adding freebsd-current, because that's a good idea.

I see these lines in the beginning of dmesg:

MADT: Ignoring local APIC ID 256 (too high)


  [907/911]
MADT: Ignoring local APIC ID 260 (too high)


  [906/911]
MADT: Ignoring local APIC ID 264 (too high)


  [905/911]
MADT: Ignoring local APIC ID 268 (too high)


  [904/911]
MADT: Ignoring local APIC ID 272 (too high)


  [903/911]
MADT: Ignoring local APIC ID 276 (too high)


  [902/911]
MADT: Ignoring local APIC ID 280 (too high)


  [901/911]
MADT: Ignoring local APIC ID 272 (too high)


  [903/911]
MADT: Ignoring local APIC ID 276 (too high)


  [902/911]
MADT: Ignoring local APIC ID 280 (too high)


  [901/911]
MADT: Ignoring local APIC ID 276 (too high)


  [902/911]
MADT: Ignoring local APIC ID 280 (too high)
MADT: Ignoring local APIC ID 284 (too high)
MADT: Ignoring local APIC ID 288 (too high)
MADT: Ignoring local APIC ID 292 (too high)
MADT: Ignoring local APIC ID 296 (too high)
MADT: Ignoring local APIC ID 300 (too high)
MADT: Ignoring local APIC ID 257 (too high)
MADT: Ignoring local APIC ID 261 (too high)
MADT: Ignoring local APIC ID 265 (too high)
MADT: Ignoring local APIC ID 269 (too high)
MADT: Ignoring local APIC ID 273 (too high)
MADT: Ignoring local APIC ID 277 (too high)
MADT: Ignoring local APIC ID 281 (too high)
MADT: Ignoring local APIC ID 285 (too high)
MADT: Ignoring local APIC ID 289 (too high)
MADT: Ignoring local APIC ID 293 (too high)
MADT: Ignoring local APIC ID 297 (too high)
MADT: Ignoring local APIC ID 301 (too high)
MADT: Ignoring local APIC ID 258 (too high)
MADT: Ignoring local APIC ID 262 (too high)
MADT: Ignoring local APIC ID 266 (too high)
MADT: Ignoring local APIC ID 270 (too high)
MADT: Ignoring local APIC ID 274 (too high)
MADT: Ignoring local APIC ID 278 (too high)
MADT: Ignoring local APIC ID 282 (too high)
MADT: Ignoring local APIC ID 286 (too high)
MADT: Ignoring local APIC ID 290 (too high)
MADT: Ignoring local APIC ID 294 (too high)
MADT: Ignoring local APIC ID 298 (too high)
MADT: Ignoring local APIC ID 302 (too high)
MADT: Ignoring local APIC ID 255 (too high)
MADT: Ignoring local APIC ID 259 (too high)
MADT: Ignoring local APIC ID 263 (too high)
MADT: Ignoring local APIC ID 267 (too high)
MADT: Ignoring local APIC ID 271 (too high)
MADT: Ignoring local APIC ID 275 (too high)
MADT: Ignoring local APIC ID 279 (too high)
MADT: Ignoring local APIC ID 283 (too high)
MADT: Ignoring local APIC ID 287 (too high)
MADT: Ignoring local APIC ID 291 (too high)
MADT: Ignoring local APIC ID 295 (too high)
MADT: Ignoring local APIC ID 299 (too high)
MADT: Ignoring local APIC ID 303 (too high)
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
3.8.0)
SRAT: No CPU found for memory domain 1
VT(efifb): resolution 800x600
CPU: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz (1396.80-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x50671  Family=0x6  Model=0x57  Stepping=1

Features=0xbfebfbff

Features2=0x7ff8f39f
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x1c0d23ab
  Structured Extended Features2=0x1
  XSAVE Features=0x1
  TSC: P-state invariant, performance statistics
real memory  = 223332007936 (212986 MB)
avail memory = 216976429056 (206924 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 223 CPUs
FreeBSD/SMP: Non-uniform topology

It sounds like those MADT errors point to the problem?

- Eric

On Tue, Jan 3, 2017 at 11:41 PM Shane Ambler  wrote:

> On 04/01/2017 08:08, Eric Joyner wrote:
> > I have an 11.0-RELEASE-p1 system with:
> >
> > hw.model: Intel(R) Xeon Phi(TM) CPU 7250 @ 1.40GHz
> >
> > It's got 68 cores, but with 4-way SMT, I think it should show up with 272
> > logical cores on FreeBSD.
> >
> > However, in both kern.sched.topology_spec and hw.ncpu, it shows there are
> > only 223 cores.
> >
> > Is the limit effectively 223 cores, even though I see some #define MAXCPU
> > 256 lines in the source?
>
> You will probably find freebsd-current a better mailing list for this.
>
> How many show in dmesg?
>
>  From https://svnweb.freebsd.org/base?view=revision&revision=270223
> Bump MAXCPU on amd64 from 64 to 256.  In practice APIC only permits 255
> CPUs (IDs 0 through 254).  Getting above that limit requires x2APIC.
>
> Also note that changing MAXCPU breaks ABI compatability so you will
> need to recom

Re: [VBox] Extreme slow UDP performance between host and guest

[Eric Joyner]

Did you use the "-b" option to set the bandwidth it uses for UDP? It
defaults to 1Mb/s, which is close to what you're seeing.

Plus, I think the recommendation is that you use iperf3, anyway, and I
don't think it has this quirk.

On Thu, Sep 1, 2016 at 2:06 AM Howard Su  wrote:

> I used iperf to do a quick experiment on the UDP performance between
> VirtualBox and Guest through vboxnetadp. Guest is acting as server and Host
> machine is acting as client. the UDP throughput is only 1/350 of TCP
> throughput.
>
> Guest kernel is -Current and Host Kernel is 11.0-RC2. Anyone has idea? is
> there any known issue in vboxnetadp?
>
> 
> Client connecting to 192.168.0.60, UDP port 5001
> Sending 1470 byte datagrams
> UDP buffer size: 9.00 KByte (default)
> 
> [  3] local 192.168.0.1 port 48290 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
> [  3] Sent 893 datagrams
> [  3] Server Report:
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.039 ms0/  893 (0%)
>
> 
> Client connecting to 192.168.0.60, UDP port 5001
> Sending 4096 byte datagrams
> UDP buffer size: 9.00 KByte (default)
> 
> [  3] local 192.168.0.1 port 58009 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
> [  3] Sent 321 datagrams
> [  3] Server Report:
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.100 ms0/  321 (0%)
>
> 
> Client connecting to 192.168.0.60, TCP port 5001
> TCP window size: 32.8 KByte (default)
> 
> [  3] local 192.168.0.1 port 15490 connected with 192.168.0.60 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec   447 MBytes   374 Mbits/sec
>
>
> -Howard
>
> --
> -Howard
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sr-iov issues, reset_hw() failed with error -100

[Eric Joyner]

I don't know if you're still interested in this, but did you do "kenv
hw.vmm.force_iommu=1" before loading the vmm module? I think that might be
necessary.

On Wed, Feb 24, 2016 at 5:12 PM Ultima  wrote:

>  Yeah, still getting the -100 error, I do have sendmail disabled. I just
> tested with sendmail up and running then add the VF's and it still shows
> the error message.
>
> On Wed, Feb 24, 2016 at 8:04 PM, Eric Joyner  wrote:
>
>> Are you still getting the -100 errors when trying to load the VF driver?
>>
>> I've tried SR-IOV on a system here, and I can confirm that traffic stops
>> passing on the PF interface when you create a VF interface. That didn't
>> used to happen, so I'm investigating why that is right now.
>>
>> On Wed, Feb 24, 2016 at 8:09 AM Ultima  wrote:
>>
>>>  Decided to do some more tests, I actually have a second board with
>>> sr-iov
>>> capabilities that I used for awhile with vmware esxi. I decided to test
>>> this out and unfortunately it won't activate, it is giving the no space
>>> left on device error message. I double checked bios and all VT-d related
>>> options are enabled and have hw.ix.num_queues="4" in /boot/loader.conf.
>>> Is
>>> there anything else that may need to be set? .(It did work on vmware)
>>>
>>>  For my second test, I moved the X540-AT1 to the board with the X540-AT2.
>>> It functioned with the same issues as the AT2 tho.
>>>
>>>
>>> I don't think I listed the motherboards in question yet so ill list them
>>> now.
>>>
>>> S1200BTLRM -
>>>
>>> http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRM
>>> MD80-TM0
>>> <http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRMMD80-TM0>
>>> - http://b2b.gigabyte.com/products/product-page.aspx?pid=5146#ov
>>>
>>> I'm not sure if it will be of any help tho.
>>>
>>> Ultima
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "
>>> freebsd-current-unsubscr...@freebsd.org"
>>>
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sr-iov issues, reset_hw() failed with error -100

[Eric Joyner]

Are you still getting the -100 errors when trying to load the VF driver?

I've tried SR-IOV on a system here, and I can confirm that traffic stops
passing on the PF interface when you create a VF interface. That didn't
used to happen, so I'm investigating why that is right now.

On Wed, Feb 24, 2016 at 8:09 AM Ultima  wrote:

>  Decided to do some more tests, I actually have a second board with sr-iov
> capabilities that I used for awhile with vmware esxi. I decided to test
> this out and unfortunately it won't activate, it is giving the no space
> left on device error message. I double checked bios and all VT-d related
> options are enabled and have hw.ix.num_queues="4" in /boot/loader.conf. Is
> there anything else that may need to be set? .(It did work on vmware)
>
>  For my second test, I moved the X540-AT1 to the board with the X540-AT2.
> It functioned with the same issues as the AT2 tho.
>
>
> I don't think I listed the motherboards in question yet so ill list them
> now.
>
> S1200BTLRM -
>
> http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRM
> MD80-TM0
> 
> - http://b2b.gigabyte.com/products/product-page.aspx?pid=5146#ov
>
> I'm not sure if it will be of any help tho.
>
> Ultima
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sr-iov issues, reset_hw() failed with error -100

[Eric Joyner]

I don't really have any ideas on the error -100. Error -100 means there was
a mailbox error, so something failed in the initial communications setup
between the PF and VF, but I don't know what exactly went wrong.

I'm grasping at straws, but try using a smaller number of VFs initially,
like 2? And check to see if VT-d is enabled in your BIOS? (Though I
would've expected iovctl to fail).

- Eric

On Mon, Feb 22, 2016 at 12:01 PM Ultima  wrote:

> After reboot...
>
> ifconfig ix1 up
>
> dhclient ix1
> DHCPDISCOVER on ix1 to 255.255.255.255 port 67 interval 4
> DHCPOFFER from 192.168.1.1
> DHCPREQUEST on ix1 to 255.255.255.255 port 67
> DHCPACK from 192.168.1.1
> bound to 192.168.1.145 -- renewal in 21600 seconds.
>
> ix0 down
> ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.149 ms
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.171 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.167 ms
>
> iovctl -Cf /etc/iovctl.conf
>
> ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 29 packets transmitted, 0 packets received, 100.0% packet loss
> ifconfig ix1 up
> ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 12 packets transmitted, 0 packets received, 100.0% packet loss
>
> ix1 is no longer usable until a restart...
>
> iovctl -Dd ix1
> ifconfig ix1 up
> ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> ^C
> --- 192.168.1.1 ping statistics ---
> 9 packets transmitted, 0 packets received, 100.0% packet loss
>
>
>
> Is there anything else that maybe useful?
>
> here is my ifconfig at the end (after ifconfig ix0 up)
>
>
> ix0: flags=8943 metric 0
> mtu 1500
>
> options=e400b9
> ether -Hidden-
> inet 192.168.1.8 netmask 0xff00 broadcast 192.168.1.255
> inet 192.168.1.9 netmask 0xff00 broadcast 192.168.1.255
> nd6 options=29
> media: Ethernet autoselect (10Gbase-T )
> status: active
> ix1: flags=8843 metric 0 mtu 1500
>
> options=e407bb
> ether -Hidden-
> inet 192.168.1.145 netmask 0xff00 broadcast 192.168.1.255
> nd6 options=29
> media: Ethernet autoselect (10Gbase-T )
> status: active
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> nd6 options=21
> groups: lo
> bridge0: flags=8843 metric 0 mtu
> 1500
> ether -Hidden-
> nd6 options=9
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: ix0 flags=143
>ifmaxaddr 0 port 1 priority 128 path cost 2000
> member: epair0a flags=143
>ifmaxaddr 0 port 5 priority 128 path cost 2000
> epair0a: flags=8943 metric
> 0 mtu 1500
> options=8
> ether -Hidden-
> inet6 fe80::ff:70ff:fe00:50a%epair0a prefixlen 64 scopeid 0x5
> nd6 options=21
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> groups: epair
>
> On Mon, Feb 22, 2016 at 1:51 PM, Eric Joyner  wrote:
>
>> Did you do an ifconfig up on ix1 before loading the VF driver?
>>
>> On Sat, Feb 20, 2016 at 11:57 AM Ultima  wrote:
>>
>>>  Decided to do some testing with iovctl to see how sr-iov is coming
>>> along.
>>> Currently when adding the vf's there are a couple errors, and the network
>>> no longer function after iovctl is started. My guess is the reset_hw()
>>> call
>>> that is failing. Any ideas why this call would fail? I tested this on
>>> both
>>> ports, ix1 is detached and unused for this test, however inserting a
>>> cable
>>> results in an unusable port. iovctl -Dd ix1 removes the vf's, however
>>> functionality is still not restored without a system restart.
>>>
>>> FreeBSD S1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295736: Wed Feb 17
>>> 21:17:28 EST 2016 root@S1:/usr/obj/usr/src/sys/MYKERNEL  amd64
>>>
>>> /boot/loader.conf
>>> hw.ix.num_queues="4"
>>>
>>> /etc/iovctl.conf
>>> PF {
>>> device : ix1;
>>> num_vfs : 31;
>>> }
>>>
>>> DEFAULT {
>>> passthrough : true;
>>> }
>>> VF-0 {
>>> passthrough : false;
>>> }
>>> VF-1 {
>>> passthrough : false;
>>> }
>>>
>>> # iovctl -C -f /etc/iovctl.conf
>&

Re: sr-iov issues, reset_hw() failed with error -100

[Eric Joyner]

Did you do an ifconfig up on ix1 before loading the VF driver?

On Sat, Feb 20, 2016 at 11:57 AM Ultima  wrote:

>  Decided to do some testing with iovctl to see how sr-iov is coming along.
> Currently when adding the vf's there are a couple errors, and the network
> no longer function after iovctl is started. My guess is the reset_hw() call
> that is failing. Any ideas why this call would fail? I tested this on both
> ports, ix1 is detached and unused for this test, however inserting a cable
> results in an unusable port. iovctl -Dd ix1 removes the vf's, however
> functionality is still not restored without a system restart.
>
> FreeBSD S1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295736: Wed Feb 17
> 21:17:28 EST 2016 root@S1:/usr/obj/usr/src/sys/MYKERNEL  amd64
>
> /boot/loader.conf
> hw.ix.num_queues="4"
>
> /etc/iovctl.conf
> PF {
> device : ix1;
> num_vfs : 31;
> }
>
> DEFAULT {
> passthrough : true;
> }
> VF-0 {
> passthrough : false;
> }
> VF-1 {
> passthrough : false;
> }
>
> # iovctl -C -f /etc/iovctl.conf
>
> dmesg
> ixv0:  1.4.6-k> at device 0.129 on pci12
> ixv0: Using MSIX interrupts with 2 vectors
> ixv0: ixgbe_reset_hw() failed with error -100
> device_attach: ixv0 attach returned 5
> ixv0:  1.4.6-k> at device 0.131 on pci12
> ixv0: Using MSIX interrupts with 2 vectors
> ixv0: ixgbe_reset_hw() failed with error -100
> device_attach: ixv0 attach returned 5
> pci12:  at device 0.133 (no driver attached)
> pci12:  at device 0.135 (no driver attached)
> pci12:  at device 0.137 (no driver attached)
> pci12:  at device 0.139 (no driver attached)
> pci12:  at device 0.141 (no driver attached)
> pci12:  at device 0.143 (no driver attached)
> pci12:  at device 0.145 (no driver attached)
> pci12:  at device 0.147 (no driver attached)
> pci12:  at device 0.149 (no driver attached)
> pci12:  at device 0.151 (no driver attached)
> pci12:  at device 0.153 (no driver attached)
> pci12:  at device 0.155 (no driver attached)
> pci12:  at device 0.157 (no driver attached)
> pci12:  at device 0.159 (no driver attached)
> pci12:  at device 0.161 (no driver attached)
> pci12:  at device 0.163 (no driver attached)
> pci12:  at device 0.165 (no driver attached)
> pci12:  at device 0.167 (no driver attached)
> pci12:  at device 0.169 (no driver attached)
> pci12:  at device 0.171 (no driver attached)
> pci12:  at device 0.173 (no driver attached)
> pci12:  at device 0.175 (no driver attached)
> pci12:  at device 0.177 (no driver attached)
> pci12:  at device 0.179 (no driver attached)
> pci12:  at device 0.181 (no driver attached)
> pci12:  at device 0.183 (no driver attached)
> pci12:  at device 0.185 (no driver attached)
> pci12:  at device 0.187 (no driver attached)
> pci12:  at device 0.189 (no driver attached)
>
> pciconf -lv
> ix1@pci0:129:0:1:   class=0x02 card=0x1458 chip=0x15288086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Ethernet Controller 10-Gigabit X540-AT2'
> class  = network
> subclass   = ethernet
> none155@pci0:129:0:129: class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> none156@pci0:129:0:131: class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt0@pci0:129:0:133:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt1@pci0:129:0:135:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt2@pci0:129:0:137:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt3@pci0:129:0:139:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt4@pci0:129:0:141:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Function'
> class  = network
> subclass   = ethernet
> ppt5@pci0:129:0:143:class=0x02 card=0x1458 chip=0x15158086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'X540 Ethernet Controller Virtual Fun

Re: CURRENT: net/igb broken

[Eric Joyner]

Does your i210 now work with the reverted version of igb? I didn't get a
chance to follow up on this earlier.

Also, can you give us the device ID for the device? There are a couple
versions of the i210 hardware.

- Eric

On Sun, Oct 4, 2015 at 10:23 PM O. Hartmann 
wrote:

> On Fri, 2 Oct 2015 08:52:57 -0700
> Sean Bruno  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> >
> > On 10/02/15 00:47, O. Hartmann wrote:
> > > On Thu, 01 Oct 2015 15:39:11 + Eric Joyner 
> > > wrote:
> > >
> > >> Oliver,
> > >>
> > >> did you try Sean's suggestion?
> > >>
> > >> - Eric
> > >>
> > >> On Tue, Sep 22, 2015 at 1:10 PM Sean Bruno 
> > >> wrote:
> > >>
> > >
> > >
> > > On 09/21/15 23:23, O. Hartmann wrote:
> > >>>>> On Mon, 21 Sep 2015 21:13:18 + Eric Joyner
> > >>>>>  wrote:
> > >>>>>
> > >>>>>> If you do a diff between r288057 and r287761, there are
> > >>>>>> no differences between the sys/dev/e1000, sys/modules/em,
> > >>>>>> and sys/modules/igb directories. Are you sure r287761
> > >>>>>> actually works?
> > >>>>>
> > >>>>> I'm quite sure r287761 works (and r287762 doesn't), double
> > >>>>> checked this this morning again. I also checked r288093 and
> > >>>>> it is still not working.
> > >>>>>
> > >>>>> The ensure that I'm not the culprit and stupid here:
> > >>>>>
> > >>>>> I use a NanoBSD environment and the only thing that gets
> > >>>>> exchanged, is the underlying OS/OS revision. The
> > >>>>> configuration always stays the same. The base system for
> > >>>>> all of my tests is built from a clean source - (deleted
> > >>>>> obj/ dir, clean, fresh build into obj/ for every test I
> > >>>>> ran).
> > >>>>>
> > >>>>> I realised a funny thing. Playing around with
> > >>>>> enabling/disabling TSO (I have been told that could be the
> > >>>>> culprit in an earlier Email from this list) with the
> > >>>>> commend sequence:
> > >>>>>
> > >>>>> ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up
> > >>>>> ifconfig igb1 down ifconfig igb1 tso ifconfig igb1 up . .
> > >>>>> .
> > >>>>>
> > >>>>> while a ping is pinging in the background a remote host
> > >>>>> connected to that specific interface, the ping does work
> > >>>>> for a while and dies then after a round trip of roughly 10
> > >>>>> - 20. I can reproduce this.
> > >>>>>
> > >>>>> is that observation of any help?
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> oh
> > >>>>>
> > >>>>>>
> > >>>>>> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann
> > >>>>>>  wrote:
> > >>>>>>
> > >>>>>>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno
> > >>>>>>>  wrote:
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 09/18/15 10:20, Eric Joyner wrote:
> > >>>>>>>>>> He has an i210 -- he would want to revert
> > >>>>>>>>>> e1000_i210.[ch], too.
> > >>>>>>>>>>
> > >>>>>>>>>> Sorry for the thrash Sean -- it sounds like it
> > >>>>>>>>>> would be a good idea for you should revert this
> > >>>>>>>>>> patch, and Jeff and I can go look at trying these
> > >>>>>>>>>> shared code updates and igb changes internally
> > >>>>>>>>>> again. We at Intel really could've done a better
> > >>>>>>>>>> job of making sure these changes worked across a
> > >>>>>>>>>> wider variety of devices.
> > >>>>>>>>>>
> > >>>>>>>>>> - 

Re: This igb change makes my igb not working anymore - Re: regression in igb/clang?

[Eric Joyner]

Are you using IPv6?

On Thu, Nov 19, 2015 at 12:42 PM Alexander Leidinger <
alexan...@leidinger.net> wrote:

> On Wed, 11 Nov 2015 11:45:32 +0100
> Alexander Leidinger  wrote:
>
> > Hi,
> >
> > I' updated a system with -current as of r287323 (end August) to
> > r290633 (yesterday).
> >
> > Result: no network connection (not even ping) on igb.
> > Ping internally (local addresses) works, anything outgoing/incoming
> > doesn't.
>
> And this is the function which causes it:
> e1000_rx_fifo_flush_82575(&adapter->hw);
>
> If I comment it out in if_igb.c, the network card works again.
>
> Full quote below for the PCI ID of my card in case it helps for fixing
> the issue.
>
> Bye,
> Alexander.
>
> > I disabled HW support (tso4, lro, rxcsum, txcsum): doesn't help.
> >
> > Did I miss some known defect/workaround?
> >
> > Anything I should test/provide besides what is below?
> >
> > The igb device is a:
> > ---snip---
> > igb0@pci0:1:0:0: class=0x02 card=0x34e28086 chip=0x10a78086
> > rev=0x02 hdr=0x00 ---snip---
> >
> > My src.conf:
> > ---snip---
> > WITH_IDEA=yes
> > WITHOUT_PROFILE=yes
> > CFLAGS+=-DFTP_COMBINE_CWDS
> > MALLOC_PRODUCTION=yes
> > LOADER_FIREWIRE_SUPPORT=yes
> > #WITH_FAST_DEPEND=yes
> > ---snip---
> >
> > My buildworld related config in make.conf:
> > ---snip---
> > CFLAGS+= -O2 -pipe
> > COPTFLAGS= -O2 -pipe
> > #CPUTYPE?=core2
> > #WITH_CCACHE_BUILD=yes
> > #.if (!empty(.CURDIR:M/usr/src*)
> > || !empty(.CURDIR:M/usr/obj*)|| !empty(.CURDIR:M/space/system/usr_obj*))
> > #.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
> > #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
> > #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} #.endif
> > #.endif
> > ---snip---
> >
> > The commented out parts were active initially, but then I commented
> > them out, cleaned out /usr/obj (rm -r) and rebuild/reinstall to make
> > sure it's not due to them (CPUTYPE commented out due to the fact that
> > there's a new compiler, and I use zsh and there was a commit talking
> > about zsh and CPUTYPE workaround).
> >
> > Bye,
> > Alexander.
> >
>
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0xC773696B3BAC17DC
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0xC773696B3BAC17DC
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

[Eric Joyner]

Oliver,

did you try Sean's suggestion?

- Eric

On Tue, Sep 22, 2015 at 1:10 PM Sean Bruno  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 09/21/15 23:23, O. Hartmann wrote:
> > On Mon, 21 Sep 2015 21:13:18 + Eric Joyner 
> > wrote:
> >
> >> If you do a diff between r288057 and r287761, there are no
> >> differences between the sys/dev/e1000, sys/modules/em, and
> >> sys/modules/igb directories. Are you sure r287761 actually
> >> works?
> >
> > I'm quite sure r287761 works (and r287762 doesn't), double checked
> > this this morning again. I also checked r288093 and it is still not
> > working.
> >
> > The ensure that I'm not the culprit and stupid here:
> >
> > I use a NanoBSD environment and the only thing that gets exchanged,
> > is the underlying OS/OS revision. The configuration always stays
> > the same. The base system for all of my tests is built from a clean
> > source - (deleted obj/ dir, clean, fresh build into obj/ for every
> > test I ran).
> >
> > I realised a funny thing. Playing around with enabling/disabling
> > TSO (I have been told that could be the culprit in an earlier Email
> > from this list) with the commend sequence:
> >
> > ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up ifconfig
> > igb1 down ifconfig igb1 tso ifconfig igb1 up . . .
> >
> > while a ping is pinging in the background a remote host connected
> > to that specific interface, the ping does work for a while and dies
> > then after a round trip of roughly 10 - 20. I can reproduce this.
> >
> > is that observation of any help?
> >
> > Regards,
> >
> > oh
> >
> >>
> >> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann
> >>  wrote:
> >>
> >>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno
> >>>  wrote:
> >>>
> >
> >
> > On 09/18/15 10:20, Eric Joyner wrote:
> >>>>>> He has an i210 -- he would want to revert
> >>>>>> e1000_i210.[ch], too.
> >>>>>>
> >>>>>> Sorry for the thrash Sean -- it sounds like it would be a
> >>>>>> good idea for you should revert this patch, and Jeff and
> >>>>>> I can go look at trying these shared code updates and igb
> >>>>>> changes internally again. We at Intel really could've
> >>>>>> done a better job of making sure these changes worked
> >>>>>> across a wider variety of devices.
> >>>>>>
> >>>>>> - Eric
> >
> > I've reverted the changes to head.  I'll reopen the reviews and we
> > can proceed from there.
> >
> > sean
> >
> >
> >>>>>>
> >>>>>> On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno
> >>>>>> mailto:sbr...@freebsd.org>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> r287762 broke the system
> >>>>>>
> >>>>>>
> >>>>>> Before I revert this changeset *again* can you test
> >>>>>> revert r287762 from if_igb.c, e1000_82575.c and
> >>>>>> e1000_82575.h *only*
> >>>>>>
> >>>>>> That narrows down the change quite a bit.
> >>>>>>
> >>>>>> sean ___
> >>>>>> freebsd-current@freebsd.org
> >>>>>> <mailto:freebsd-current@freebsd.org> mailing list
> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>>>>> To unsubscribe, send any mail to
> >>>>>> "freebsd-current-unsubscr...@freebsd.org
> >>>>>> <mailto:freebsd-current-unsubscr...@freebsd.org>"
> >>>>>>
> >>>
> >>> I'm now on r288057 on that specific machine, supposedly
> >>> reverted changes that seemingly has been identified as the
> >>> culprit. Still NO change in behaviour!
> >>>
> >>> r287761 works with the same configuration on igb (i210), any
> >>> further does not. Not ping/connect from the outside, no
> >>> ping/connect from the inside. Tried different protocols (SAMBA,
> >>> ssh, LDAP, DNS). Affected is/are only boxes with the igb driver
> >>> and

Re: CURRENT: net/igb broken

[Eric Joyner]

If you do a diff between r288057 and r287761, there are no differences
between the sys/dev/e1000, sys/modules/em, and sys/modules/igb directories.
Are you sure r287761 actually works?

On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann 
wrote:

> On Sat, 19 Sep 2015 11:23:44 -0700
> Sean Bruno  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> >
> > On 09/18/15 10:20, Eric Joyner wrote:
> > > He has an i210 -- he would want to revert e1000_i210.[ch], too.
> > >
> > > Sorry for the thrash Sean -- it sounds like it would be a good idea
> > > for you should revert this patch, and Jeff and I can go look at
> > > trying these shared code updates and igb changes internally again.
> > > We at Intel really could've done a better job of making sure these
> > > changes worked across a wider variety of devices.
> > >
> > > - Eric
> >
> > I've reverted the changes to head.  I'll reopen the reviews and we can
> > proceed from there.
> >
> > sean
> >
> >
> > >
> > > On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno  > > <mailto:sbr...@freebsd.org>> wrote:
> > >
> > >
> > >>
> > >> r287762 broke the system
> > >
> > >
> > > Before I revert this changeset *again* can you test revert r287762
> > > from if_igb.c, e1000_82575.c and e1000_82575.h *only*
> > >
> > > That narrows down the change quite a bit.
> > >
> > > sean ___
> > > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> > > mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current To
> > > unsubscribe, send any mail to
> > > "freebsd-current-unsubscr...@freebsd.org
> > > <mailto:freebsd-current-unsubscr...@freebsd.org>"
> > >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQF8BAEBCgBmBQJV/agsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
> > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kkkMH/icGgcIAdm3CIxtXtnhbE5E9
> > N6RrBrgJruoRHP2geJ9UOUGp7MaFwS6AHcwCC7FvxoydzcsT+iMj3Kreu+aEkT4C
> > PZvLsqIvLeX0WVEXSC8jwBAZbrOwJ+4TcMMnW2KZMeUPUHAd8rP0+Skj9AeQ4feJ
> > OfLqv52VdxYTnx+vYbvZSaOgWp8sC+PcoJxiJua7hpmqXwISbcG9eXxQHUil0fcv
> > tqfb2dv89VN12brFuQbFtgEK2RG6gKtbj7IQkeQqzt0g5WL6UnJ5OslajcEJwIA4
> > H6H4eke5CQUugVTUv5cbCwmQDfAF2qF8JgsxuuQDPvQRb4+XH1ks/5SEhENItv0=
> > =JTMu
> > -END PGP SIGNATURE-
>
> I'm now on r288057 on that specific machine, supposedly reverted changes
> that
> seemingly has been identified as the culprit. Still NO change in behaviour!
>
> r287761 works with the same configuration on igb (i210), any further does
> not.
> Not ping/connect from the outside, no ping/connect from the inside. Tried
> different protocols (SAMBA, ssh, LDAP, DNS). Affected is/are only boxes
> with
> the igb driver and i210 chipset (we do not have other chips covered by
> igb).
>
> Regards,
> Oliver
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

[Eric Joyner]

He has an i210 -- he would want to revert e1000_i210.[ch], too.

Sorry for the thrash Sean -- it sounds like it would be a good idea for you
should revert this patch, and Jeff and I can go look at trying these shared
code updates and igb changes internally again. We at Intel really could've
done a better job of making sure these changes worked across a wider
variety of devices.

- Eric

On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno  wrote:

>
> >
> > r287762 broke the system
>
>
> Before I revert this changeset *again* can you test revert r287762 from
> if_igb.c, e1000_82575.c and e1000_82575.h *only*
>
> That narrows down the change quite a bit.
>
> sean
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How should a driver shutdown a taskqueue on detach?

[Eric Joyner]

Or like, "taskqueue_enqueue_if_not_draining()" ? :p

On Wed, Jul 1, 2015 at 2:32 PM Konstantin Belousov 
wrote:

> On Wed, Jul 01, 2015 at 05:09:27PM -0400, Ryan Stone wrote:
> > On Wed, Jul 1, 2015 at 4:58 PM, Jack Vogel  wrote:
> >
> > > But if you've disabled interrupts why would an "interrupt-handling
> task"
> > > even run??
> > >
> > > Jack
> > >
> >
> > There's a race.  The task could have already have been scheduled by a
> > previous interrupt and could be running while I am trying to disable
> > interrupts and drain the taskqueue.
>
> Do you mean, you want some KPI like
> boolean taskqueue_is_draining(struct taskqueue *p);
> so that e.g. executed task could see if it is executing in the
> shutdown state ?
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-head ixgbe build failed

[Eric Joyner]

I made the change in r284767. It leaves out the backwards compatibility
ixgbe build target that the stable/10 commit allowed, but you can now build
the modules seperately.

On Mon, Jun 22, 2015 at 2:29 PM Eric Joyner  wrote:

> I guess I could reverse-MFC r283668, then, to make that work on HEAD.
>
> On Mon, Jun 22, 2015, 12:07 PM Stefano Garzarella <
> stefanogarzare...@gmail.com> wrote:
>
>> Hi all,
>> I tried to compile FreeBSD-head with only "device ix" (without "device
>> ixv") but the build failed.
>>
>> I fixed this behavior using this patch:
>> diff --git a/sys/conf/files b/sys/conf/files
>> index 65606b0..279b161 100644
>> --- a/sys/conf/files
>> +++ b/sys/conf/files
>> @@ -1774,25 +1774,25 @@ dev/ixgbe/if_ix.c   optional ix inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
>>  dev/ixgbe/if_ixv.c optional ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
>> -dev/ixgbe/ix_txrx.coptional ix ixv inet \
>> +dev/ixgbe/ix_txrx.coptional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
>> -dev/ixgbe/ixgbe_phy.c  optional ix ixv inet \
>> +dev/ixgbe/ixgbe_phy.c  optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_api.c  optional ix ixv inet \
>> +dev/ixgbe/ixgbe_api.c  optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_common.c   optional ix ixv inet \
>> +dev/ixgbe/ixgbe_common.c   optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_mbx.c  optional ix ixv inet \
>> +dev/ixgbe/ixgbe_mbx.c  optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_vf.c   optional ix ixv inet \
>> +dev/ixgbe/ixgbe_vf.c   optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_82598.coptional ix ixv inet \
>> +dev/ixgbe/ixgbe_82598.coptional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_82599.coptional ix ixv inet \
>> +dev/ixgbe/ixgbe_82599.coptional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_x540.c optional ix ixv inet \
>> +dev/ixgbe/ixgbe_x540.c optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>> -dev/ixgbe/ixgbe_x550.c optional ix ixv inet \
>> +dev/ixgbe/ixgbe_x550.c optional ix | ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>>  dev/ixgbe/ixgbe_dcb.c  optional ix ixv inet \
>> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>>
>> cheers,
>> Stefano
>>
>> --
>> *Stefano Garzarella*
>> Software Engineer
>>
>> e-mail: stefano.garzare...@gmail.com
>> github: http://github.com/stefano-garzarella
>> linkedin: http://it.linkedin.com/pub/stefano-garzarella
>>
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-head ixgbe build failed

[Eric Joyner]

I guess I could reverse-MFC r283668, then, to make that work on HEAD.

On Mon, Jun 22, 2015, 12:07 PM Stefano Garzarella <
stefanogarzare...@gmail.com> wrote:

> Hi all,
> I tried to compile FreeBSD-head with only "device ix" (without "device
> ixv") but the build failed.
>
> I fixed this behavior using this patch:
> diff --git a/sys/conf/files b/sys/conf/files
> index 65606b0..279b161 100644
> --- a/sys/conf/files
> +++ b/sys/conf/files
> @@ -1774,25 +1774,25 @@ dev/ixgbe/if_ix.c   optional ix inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
>  dev/ixgbe/if_ixv.c optional ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
> -dev/ixgbe/ix_txrx.coptional ix ixv inet \
> +dev/ixgbe/ix_txrx.coptional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe -DSMP"
> -dev/ixgbe/ixgbe_phy.c  optional ix ixv inet \
> +dev/ixgbe/ixgbe_phy.c  optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_api.c  optional ix ixv inet \
> +dev/ixgbe/ixgbe_api.c  optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_common.c   optional ix ixv inet \
> +dev/ixgbe/ixgbe_common.c   optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_mbx.c  optional ix ixv inet \
> +dev/ixgbe/ixgbe_mbx.c  optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_vf.c   optional ix ixv inet \
> +dev/ixgbe/ixgbe_vf.c   optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_82598.coptional ix ixv inet \
> +dev/ixgbe/ixgbe_82598.coptional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_82599.coptional ix ixv inet \
> +dev/ixgbe/ixgbe_82599.coptional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_x540.c optional ix ixv inet \
> +dev/ixgbe/ixgbe_x540.c optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
> -dev/ixgbe/ixgbe_x550.c optional ix ixv inet \
> +dev/ixgbe/ixgbe_x550.c optional ix | ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>  dev/ixgbe/ixgbe_dcb.c  optional ix ixv inet \
> compile-with "${NORMAL_C} -I$S/dev/ixgbe"
>
> cheers,
> Stefano
>
> --
> *Stefano Garzarella*
> Software Engineer
>
> e-mail: stefano.garzare...@gmail.com
> github: http://github.com/stefano-garzarella
> linkedin: http://it.linkedin.com/pub/stefano-garzarella
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Patch to improve TSO limitation formula in general

[Eric Joyner]

Let me remove my concerns earlier in the thread -- this patch won't
negatively affect any of our drivers; and the problem I mentioned with ixl
would require a change somewhere further up the stack.

---
- Eric Joyner

On Mon, Sep 8, 2014 at 5:05 AM, Rick Macklem  wrote:

> Hans Petter Selasky wrote:
> > On 09/06/14 00:09, Rick Macklem wrote:
> > > Hans Petter Selesky wrote:
> > >> On 09/05/14 23:19, Eric Joyner wrote:
> > >>> There are some concerns if we use this with devices that ixl
> > >>> supports:
> > >>>
> > >>> - The maximum fragment size is 16KB-1, which isn't a power of 2.
> > >>>
> > >>
> > >> Hi Eric,
> > >>
> > >> Multiplying by powers of two are more fast, than non-powers of
> > >> two.
> > >> So
> > >> in this case you would have to use 8KB as a maximum.
> > >>
> > > Well, I'm no architecture expert, but I really doubt the CPU delay
> > > of a
> > > non-power of 2 multiply/divide is significant related to doing
> > > smaller
> > > TSO segments. Long ago (as in 1970s) I did work on machines where
> > > shifts
> > > for power of 2 multiply/divide was preferable, but these days I
> > > doubt it
> > > is going to matter??
> > >
> > >>> - You can't get the maximum TSO size for ixl devices by
> > >>> multiplying
> > >>> the
> > >>> maximum number of fragments by the maximum size.
> > >>> Instead the number of fragments is AFAIK unlimited, but a segment
> > >>> can only
> > >>> span 8 mbufs (including the [up to 3] mbufs containing the
> > >>> header),
> > >>> and the
> > >>> maximum TSO size is 256KB.
> >
> > Hi,
> >
> > Maybe that can be a separate parameter?
> >
> > I see that your patch assumes that a segment can be any-length. That
> > is
> > not always the case. Remember there are JUMBO mbufs too.
> >
> I thought JUMBO mbufs were only going to be used on the receive side,
> however I suppose if a packet is received into a JUMBO mbuf and then
> forwarded on another interface...
>
> > With my patch, the maximum segment size is a separate parameter. The
> > total number of TSO bytes is then not so useful.
> >
> Well, if you are referring to if_hw_tsomax, I'm not sure it was the
> best plan to begin with. It was implemented for xen and I'm not sure
> that any other driver uses it as of now.
>
> However...
> I'm not a network/hardware guy, but it seems some devices do have
> the IP_MAXPACKET limit (use the ip_len field in the ip header to
> know how large the TSO segment is). There is also at least one device
> (82598 chip for "ix" driver) that can handle more that IP_MAXPACKET,
> so it seems appropriate to have a value that the driver can set.
>
> Since the maximum size of the gather list for transmit does seem to
> vary a lot between devices, with several handling less than 35, it
> does seem appropriate to allow drivers to specify that.
>
> If devices can't handle a single gather entry over a certain size,
> I think that does need to be specified along with the max size of
> the gather list, since the driver will need to use multiple gather
> entries for a single mbuf and tcp_output() should take that into
> account.
>
> In summary, yep, I basically agree.
>
> rick
> ps: Who will look at your patch soon.
>
> > --HPS
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org"
> >
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Patch to improve TSO limitation formula in general

[Eric Joyner]

There are some concerns if we use this with devices that ixl supports:

- The maximum fragment size is 16KB-1, which isn't a power of 2.

- You can't get the maximum TSO size for ixl devices by multiplying the
maximum number of fragments by the maximum size.
Instead the number of fragments is AFAIK unlimited, but a segment can only
span 8 mbufs (including the [up to 3] mbufs containing the header), and the
maximum TSO size is 256KB.

And one question:

- Is hdr_size_log2 supposed to be the length of the L2 header? We can fit
254 L2 bytes in our hardware during a TSO, so if that's the value, I guess
that's fine, barring the it-not-being-a-power-of-2 issue.

With all that said, the 8 mbuf limit per segment issue is a TSO limitation
that we'd like to notify the stack about, so I wonder if that could be
incorporated along with this. Right now, our driver checks to see if a
segment in a TSO spans more than six mbufs and then m_defrag()'s the entire
chain if one exists; it's less than optimal but necessary to prevent errors.

- Eric

---
- Eric Joyner


On Fri, Sep 5, 2014 at 11:37 AM, Hans Petter Selasky 
wrote:

> Hi,
>
> I've tested the attached patch with success and would like to have some
> feedback from other FreeBSD network developers. The problem is that the
> current TSO limitation only limits the number of bytes that can be
> transferred in a TSO packet and not the number of mbuf's.
>
> The current solution is to have a quick and dirty custom m_dup() in the TX
> path to re-allocate the mbuf chains into 4K ones to make it simple. All of
> this hack can be avoided if the definition of the TSO limit can be changed
> a bit, like shown here:
>
>
>  /*
> + * Structure defining hardware TSO limits.
> + */
> +struct if_tso_limit {
> +   u_int raw_value[0]; /* access all fields as one */
> +   u_char frag_count;  /* maximum number of fragments: 1..255 */
> +   u_char frag_size_log2;  /* maximum fragment size: 2 ** (12..16) */
> +   u_char hdr_size_log2;   /* maximum header size: 2 ** (2..8) */
> +   u_char reserved;/* zero */
> +};
>
>
> First we need to know the maximum fragment count. Typical value is 32.
> Second we need to know the maximum fragment size. Typical value is 4K.
> Last we need to know of any headers that should be subtracted from the
> maximum. Hence this code is running in the fast path, I would like to use
> "u_char" for all fields and allow copy-only access as a "u_int" as an
> optimization. This avoids cludges and messing with additional header files.
>
> I would like to push this patch after some more testing to -current and
> then to 10-stable hopefully before the coming 10-release, because the
> current solution is affecting performance of the Mellanox based network
> adapters in an unfair way. For example by setting the current TSO limit to
> 32KBytes which will be OK for all-2K fragments, we see a severe degradation
> in performance. Even though the hardware is fully capable of transmitting
> 16 4K mbufs.
>
> Comments and reviews are welcome!
>
> --HPS
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Status on igb crash

[Eric Joyner]

Hi Alexandre,

We didn't put the fix into the repository because we think it would have
had a significant impact on throughput. It fixed a crash, but that gotcha
could potentially annoy everyone else using the driver who wasn't
experiencing the same type of crash. That said, I'm going to look into that
performance impact, and will try to submit a patch later without one.

---
- Eric Joyner


On Wed, Feb 26, 2014 at 3:06 AM, Alexandre Martins <
alexandre.mart...@netasq.com> wrote:

> Hi Eric,
>
> In January, I have report a bug into igb driver :
>
> http://lists.freebsd.org/pipermail/freebsd-current/2014-January/047827.html
>
> You send me a patch, but nothing was done into kernel sources.
>
> Will it be planed to put a fix into the repository ?
>
> Kind regards
>
> --
> Alexandre Martins
> NETASQ -- We secure IT
>
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10-RC4: Got crash in igb driver

[Eric Joyner]

All,

I work with Jack on FreeBSD network drivers, and we have a patch that we
think might fix this problem. It re-implements the header pull-up code that
was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you
apply this patch to the igb version in HEAD and try it out on your network?
We can't replicate your setup here.

If it solves your problem, then the next step would be to port the patch to
the ixgbe driver since, as Yonghyeon noted, it looks like that driver will
encounter the same problem. We could then modify em to add IPv6 offload
support as well.

Thanks,

---
- Eric Joyner

On Fri, Jan 10, 2014 at 02:35:29PM +0400, Gleb Smirnoff wrote:
>   Yonghyeon,
>
> On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote:
> Y> > I experience some troubles with the igb device driver on FreeBSD
10-RC4.
> Y> >
> Y> > The kernel make a pagefault in the igb_tx_ctx_setup function when
accessing to
> Y> > a IPv6 header.
> Y> >
> Y> > The network configuration is the following:
> Y> >  - box acting as an IPv6 router
> Y> >  - one interface with an IPv6 (igb0)
> Y> >  - another interface with a vlan, and IPv6 on it (vlan0 on igb1)
> Y> >
> Y> > Vlan Hardware tagging is set on both interfaces.
> Y> >
> Y> > The packet that cause the crash come from igb0 and go to vlan0.
> Y> >
> Y> > After investigation, i see that the mbuf is split in two. The first
one carry
> Y> > the ethernet header, the second, the IPv6 header and data payload.
> Y> >
> Y> > The split is due to the "m_copy" done in ip6_forward, that make the
mbuf not
> Y> > writable and the "M_PREPEND" in ether_output that insert the new
mbuf before
> Y> > the original one.
> Y> >
> Y> > The kernel crashes only if the newly allocated mbuf is at the end of
a memory
> Y> > page, and no page is available after this one. So, it's extremly
rare.
> Y> >
> Y> > I inserted a "KASSERT" into the function (see attached patch) to
check this
> Y> > behavior, and it raises on every IPv6 forwarded packet to the vlan.
The
> Y> > problem disapear if i remove hardware tagging.
> Y> >
> Y> > In the commit 256200, i see that pullups has been removed. May it be
related ?
> Y>
> Y> I think I introduced the header parsing code to meet controller
> Y> requirement in em(4) and Jack borrowed that code in the past but it
> Y> seems it was removed in r256200.  It seems igb_tx_ctx_setup()
> Y> assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf
> Y> of the chain.
> Y> This looks wrong to me.
>
> Can you please restore the important code in head ASAP? Although crashes
happen
> only when the mbuf is last in a page and page isn't mapped, we read
thrash from
> next allocation on almost every packet.
>

It seems other Intel ethernet drivers except em(4) have similar
issues.  I didn't check recent Intel controllers/drivers for long
time so I don't know details on hardware requirements of
offloading.
Since Jack is very responsive and has hardwares to verify, he would
be more appropriate person to handle these issues.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


fix.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"