Re: in_pcbbind_setup: wrong condition regarding INP_REUSEPORT ?

On 10/3/22 04:14, Andriy Gapon wrote: I must admit that the condition in question is fairly long and non-trivial and I cannot decipher it, but these two lines look wrong to me: (t->inp_flags2 & INP_REUSEPORT) || (t

Re: Freebsd and 6rd

On 11/29/18 11:53 AM, Reko Turja wrote: > -Original Message- Sent: Thursday, November 29, 2018 8:42 PM > Subject: Re: Freebsd and 6rd > >> Same here.  I followed the Century Link "How to" to activate 6rd on my >> DSL router, and then added the following to my desktop behind it to get >>

Re: Freebsd and 6rd

On 11/29/18 11:28 AM, Reko Turja via freebsd-net wrote: > Hello list! > > My home DSL operator supports idiotically IPv6 via 6rd only. Ive been > trying to set it up using if_stf and if_gif without much success. It > seems that both pfSense and OPNSense do support 6rd, but is there any > support

Re: Reproducible crash in em/igb

On 10/12/18 7:29 AM, Lev Serebryakov wrote: > > I have reproducible crash in igb and em driver on CURRENT, with KASSERT > violation if kernel is built INVARIANTS. > > All information is here: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659 > > (please, start from newest comment

12-CURRENT - IPV6 panic ip6_savecontrol_v4

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231023 It looks like we've induced a panic in the ICMP6 path. This has happened to a console logging server, so I missed the panic string, but I suspect this is enough. Its not enough to just ping6 the machine in question. sean signature.asc

Re: Testing VF/PF code

On 05/29/18 12:15, Kevin Bowling wrote: > iovctl worked at one point with ixgbe. I don’t recall if there is any > way to attach the vf directly if you do that but you can use ppt driver > to pass them into bhyve.  > > On Tue, May 29, 2018 at 9:58 AM Sean Bruno <mailto:

Re: Testing VF/PF code

On 05/29/18 11:55, Harry Schmalzbauer wrote: > Am 29.05.2018 um 18:57 schrieb Sean Bruno: >> Does anyone have a process for testing the VF drivers (ixgbe igb, etc) >> in FreeBSD without actually firing up linux to instantiate a VM or using >> EC2? >> >> sean &

Testing VF/PF code

Does anyone have a process for testing the VF drivers (ixgbe igb, etc) in FreeBSD without actually firing up linux to instantiate a VM or using EC2? sean signature.asc Description: OpenPGP digital signature

Re: netstat(1) -s -f is broken

On 05/03/18 15:32, Dieter BSD wrote: > FreeBSD 10.3-RELEASE > > The fine man page promises: > netstat -i | -I interface -s [-46] [-f protocol_family | -p protocol] > [-M core] [-N system] > Display per-interface statistics for each network protocol, for a >

Re: Getting functional ipv6 on Century Link

On 05/26/18 09:50, Alan Somers wrote: > > On Sat, May 26, 2018 at 9:01 AM, Sean Bruno <mailto:sbr...@freebsd.org>> wrote: > > > http://www.centurylink.com/home/help/internet/modems-and-routers/zyxel-c1100z/ipv6-turn-on.html > > <http://www.centuryl

Getting functional ipv6 on Century Link

http://www.centurylink.com/home/help/internet/modems-and-routers/zyxel-c1100z/ipv6-turn-on.html US DSL carrier that seems to provide v6 via a 6rd configuration. This all seems to be working and my modem reports it has stuff and things. What am I supposed to use as settings in rc.conf to enable c

Re: iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

On 05/08/18 10:23, Harry Schmalzbauer wrote: > Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:52 (localtime): > … >>> But if the simple iflib/hw-support test with kawela+hartwell helps I'm >>> happy to do. >> >> At this point it would be helpful, we think e1000 is nearing pretty >> good sh

Re: Intel I210 (igb) sometimes consume all CPU on not-so-big traffic — need help!

On 11/09/17 13:17, Lev Serebryakov wrote: > > I still have problems with my E-1220v3 server equipped with Intel I210 > adapter. It can not be loaded more than 100Mbit/s because it is > connection to internet. > > But sometimes four interrupt threads "intr{irqXXX: igb0:que Y}" consume > 100% C

[CFT] ixgbe(4) IFLIB conversion

https://reviews.freebsd.org/D11727 We're making good progress on the 10GE driver conversion and are now taking review and run time comments. If you find breakage or performance regressions, now is the time to report them in the Phabricator review. sean signature.asc Description: OpenPGP digit

Re: OCD window scaling behavior on local network.

On 05/29/17 00:50, Zaphod Beeblebrox wrote: > so... I have some really OCD window scaling behavior on a GigE local > network. The protocol is BGP, this is one session recorded. Nearly every > payload packet is answered by both an 'ACK' and a 2nd window scaling > packet. I have examined the pac

Re: igb stats double counting in 12-CURRENT r319025

On 06/03/17 01:25, Ben Woods wrote: > Hi everyone, > > I have noticed my networking statistics appear to be double counting on two > of my FreeBSD 12-CURRENT boxes running r319025. Could someone please help > me to find the problem (I believe it is likely to be a bug in the > networking driver).

Re: Intel 82545 & TSO

On 04/05/17 15:54, Vijay Singh wrote: > This is from FreeBSD 10.3. > > On Wed, Apr 5, 2017 at 2:53 PM, Sean Bruno <mailto:sbr...@freebsd.org>> wrote: > > > > On 04/05/17 10:26, Vijay Singh wrote: > > I am running FreeBSD as a guest on ESX 5.x

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

On 04/11/17 09:39, Ben Woods wrote: > Ben: > > What kind of workload is this machine processing? I'd like to try and > duplicate this failure if possible. > > sean > > > Hi Sean, > > It is a Netgate RCC-VE-8860 running as my home firewall. > https://netgate.com/docs/rcc-ve-8

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

On 03/24/17 19:33, Ben Woods wrote: > Morning! > > Since my recent update from FreeBSD12-current r313908 to r315466, I have > noticed some strange behaviour with one of my network interfaces. > > The interface seems to work fine for a day or so, but on a number of > occasions I have found it to

Re: netmap error on -CURRENT with em and igb

On 02/16/17 02:25, Giuseppe Lettieri wrote: > Hi all, > > the "Operation not permitted" is coming from iflib_netmap_register: > > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); > ... > IFDI_INIT(ctx);// for igb it calls em_if_init() > ... > return (ifp->if_dr

Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6

On 03/16/17 12:26, Harry Schmalzbauer wrote: > Hello, > > I'm wondering if I really loose [RT]XCSUM_IPV6 on if_igb(4) vlan(4) > children. > My igb0 (Kawela, aka 82576) options end with > "TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6" > > The vlan(4) filtered interfaces show these: > options=303

Re: Intel 82545 & TSO

On 04/05/17 10:26, Vijay Singh wrote: > I am running FreeBSD as a guest on ESX 5.x and see Intel device 0x100F in > the guest. The man page for em(4) says: > > " The driver supports Transmit/Receive checksum offload and Jumbo > Frames on all but 82542-based adapters. Furthermore it supports TCP

Re: igb (82575EB) not passing traffic out.

On 02/07/17 10:39, Alexandre Snarskii wrote: > > Hi! > > After upgrading 12-stable from early January 2017 to February 2017 > igb card (onboard dual-port 82575EB) stopped passing outbound traffic. > It can be seen in tcpdump, but switch reports "no packets received" and > sysctl counters repo

Re: NFSROOT and lagg(4)

On 02/04/17 14:00, Konstantin Belousov wrote: > Look at reroot support, see reboot(8) option -r. I suspect you could > need two reroots: first to some tmpfs or memory backed md(4) where > ifconfig is present to reconfigure interfaces, second to boot into the > final root. I'll look into it. Th

NFSROOT and lagg(4)

"what I want" is to pxe/netboot and then switch over to using a lagg(4) interface that includes the interface used in the pxe/netboot boot up. I suspect, I have to switch to MDROOT to do this, but I thought I'd ask if anyone is doing this type of configuration in their labs? What seems to happen i

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

On 01/11/17 13:34, Olivier Cochard-Labbé wrote: > > 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? > > T

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

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 <mailto:sbr...@freebsd.org>> wrote: > > > > Which set of configs from your test suite are you using for this? > Specifically, what packet size are you slam

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

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 01/11/17 12:47, Olivier Cochard-Labbé wrote: > On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno <mailto:sbr...@freebsd.org>> wrote: > > > > Olivier: > > Give this a quick try. This isn't the correct way to do this, but I > want to see if I&#x

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

On 01/11/17 10:24, Michael Tuexen wrote: >> On 10 Jan 2017, at 04:32, Sean Bruno wrote: >> >> 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 Mac

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

On 01/11/17 10:24, Michael Tuexen wrote: >> On 10 Jan 2017, at 04:32, Sean Bruno wrote: >> >> 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 Mac

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 R31184

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

> > Thank you very much for your work! > I'm unsure if I got it right: stabe/11 won't benefit from IFLIB (not > that I know waht IFLIB is all about, yet), but driver changes will be > merged? Yes, we intend on pulling back IFLIB and the IFLIB'd drivers to stable/11 for people's use. The differen

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

y into the freebsd-net@ megaphone for things that I may have broken. man page updates are coming up next. Please let us know if this revision has made things better, worse or none-of-the above on whatever Intel Gigabit NIC you happen to have lying around. sean On 01/05/17 20:18, Sean Bruno wrote

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

On 01/06/17 03:52, Eugene Grosbein wrote: > 06.01.2017 10:18, Sean Bruno пишет: > >> Due to limitations of device registration, igbX devices will become emX >> devices. So, you'll need to make a minor update to your rc.conf and >> scripts that manipulate the

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

Re: Intel 82567V-2 using em driver, no carrier or constant link-state changes with 1000BaseT

On 12/01/16 13:07, Pieper, Jeffrey E wrote: > Sean, > > This is a client (em) part, and should be 10CE (Boazman/Boulder Creek). > > Jeff Yeah, you're right. I think I transposed some numbers instead of copy/paste. Do you have this part lying around to test against? sean signature.asc Des

Re: Intel 82567V-2 using em driver, no carrier or constant link-state changes with 1000BaseT

On 11/27/16 12:40, Michael Knap wrote: > Preface: I've been a long-time linux user, and I am enjoying the BSD > experience. For the following scenario, I have reproduced these results > with 3 or more cables which are known to be good. > > Using FreeBSD 10.3 Stable : > FreeBSD 10.3-STABLE #0 r29

Re: CURRENT: re(4) crashing system

On 10/23/16 23:14, YongHyeon PYUN wrote: > BTW, I was told that the vendor's FreeBSD driver seems to work fine > for normal usage pattern. The vendor's driver triggered an instant > panic and lacked H/W offloading features in the past. It might > have changed though. Hrm ... I just looked and

Re: Will this card (probably) work?

> > OK the vendor got back to me: > > 8086:1522 That appears to be governed by the the igb(4) driver. You should be good to go. fbsd_head/sys/dev/e1000 % grep -r E1000_DEV_ID_I350_FIBER * e1000_api.c:case E1000_DEV_ID_I350_FIBER: e1000_hw.h:#define E1000_DEV_ID_I350_FIBER

Re: Will this card (probably) work?

On 09/20/16 03:42, Lee Brown wrote: > > > On Mon, Sep 19, 2016 at 1:48 PM, Sean Bruno <mailto:sbr...@freebsd.org>> wrote: > > > > On 09/19/16 14:17, Lee Brown wrote: > > I am looking to purchase this > <http://www.ebay.com/itm/1

Re: Will this card (probably) work?

On 09/19/16 14:17, Lee Brown wrote: > I am looking to purchase this card > (LR-LINK I350AM4 Chip Quad SFP Port 1000Base-X Server Adapter I350-F4), > into which I intend to use 1000-LX SFP's. > > If I'm understanding correctly, the igb(4) driver supports the

Re: Question about em_irq_fast

> value of the register for just receive of a packet? > > Thanks, > > -Sreekanth > > > On 8/8/16, 2:02 PM, "Sean Bruno" wrote: > > It sounds like QEMU is spamming packets and interrupts incorrectly as > normal hardware doesn't have this i

Re: Question about em_irq_fast

On 08/08/16 13:14, Sreekanth Rupavatharam wrote: > > > Thanks, > > -Sreekanth > >> On Aug 8, 2016, at 12:09 PM, Sean Bruno wrote: >> >> Is this with the "lem" driver or the "em" driver under QEMU? >> > It's for lem dri

Re: Question about em_irq_fast

On 08/05/16 12:01, Sreekanth Rupavatharam wrote: > We have this code snippet in em_irq_fast > > ifp = > adapter->ifp; > > > > > reg_icr = E100

lagg(4): LOR, deadlock and panic

tl;dr --> https://reviews.freebsd.org/D6845 Navdeep and I have been poking at an LOR that seems to be popping up in -current that is related to lagg(4) and lagg_get_counter(). root@sysdev07:~ # ifconfig lagg0 create laggport ix0 laggproto lacp 192.168.100.11/24 lagg0: link state changed to DOWN r

[Differential] D6148: tcp/syncache: Add comment for syncache_respond

sbruno accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D6148 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, transport, adrian, rwatson, gnn, lstewart, glebius, delphij, mike-karels.net, jtl, hiren, hselask

[Differential] D6120: tcp/syncache: Set flowid and hash type properly for SYN|ACK

sbruno accepted this revision. sbruno added a reviewer: sbruno. REVISION DETAIL https://reviews.freebsd.org/D6120 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, transport, adrian, rwatson, gnn, lstewart, glebius, delphij, mik

[Differential] [Updated] D5853: dhclient: Log a warning instead of bailing upon "illegal" options

sbruno added reviewers: pkelsey, jhb, gnn. sbruno added a comment. spam a few more reviewers who have poked at dhclient in the past. REVISION DETAIL https://reviews.freebsd.org/D5853 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, n

Re: TCP packets Drop !!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/05/16 06:26, shahzaib mushtaq wrote: > Here is the full output of netstat -s : > > http://pastebin.com/pyxDtJkL > > > > On Tue, Apr 5, 2016 at 3:38 PM, shahzaib mushtaq > wrote: > >> Hi Guys, >> >> Hopes i've landed on the correct foru

Re: Intel I219 V2 (if_em) Wake on LAN not working

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/27/16 09:01, Guido Falsi wrote: > On 03/27/16 17:32, Sean Bruno wrote: >> >> >>>> From that, I see that eeprom_data is 0, so adapter->wol >>>> stays zero, so ifconfig >>> do

Re: down network interface

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/25/16 03:47, ??? ??? wrote: > Hello!!! I use FreeBSD Thor 10.1-RELEASE-P17 FreeBSD > 10.1-RELEASE-P17 Frezz network card after repeated opening and > closing phisikal link. Restarting the network does not lead to > solvin

Re: Intel I219 V2 (if_em) Wake on LAN not working

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/16 17:44, Eric van Gyzen wrote: > On 03/23/16 06:57 AM, Guido Falsi wrote: >> Hi, >> >> I have a new machine with the I219 ethernet adapter. (PCI >> deviceID: 0x15b8). >> >> It works fine on the OS, but I cannot enable wake on lan on it

em/igb CFT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Intel has posted a new review for an update to em/lem/igb here: https://reviews.freebsd.org/D3162 If you have time and hardware (em/lem/igb), please give this patch a spin on your hardware and post results to the phabricator review. sean -BEGIN

[CFT] Updates to ixgbe(4)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Intel has posted a phabricator review for -current that enables support for X552 SFP+ 10 GbE, and the single port version of X550T. At this point we are looking to ensure there are no breakages on existing installs. Please give this a test at your

Re: netmap: recommended NIC for 40GbE capture on Linux?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/15 07:03, Bruce Merry wrote: > Hi > > We're aim to do some high-speed data capture and processing on > data being sent from an FPGA over Ethernet. The data is about > 3.3Mpps with 512 bytes of application-level data per packet (plus > som

[Differential] [Commented On] D1986: Teach lagg(4) to change MTU

sbruno added a subscriber: sbruno. sbruno added a comment. In https://reviews.freebsd.org/D1986#77466, @lakshmi.n_msystechnologies.com wrote: > We (Panasas) tried reproducing the problem by applying the patch and enabled > WITNESS in freebsd stable (10.1) kernel. > While testing with this patc

Re: RE not working on 10.2-RELEASE #0 r286731M

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/14/15 13:34, Kim Culhan wrote: > RE on 10.2-RELEASE #0 r286731M appears to pass only arp traffic. > > Replaced if_re.c with version from 273757, appears to work > normally. > > The diff: > > 34c34 < __FBSDID("$FreeBSD: stable/10/sys/dev/re/i

Re: bugzilla chatter?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/04/15 16:13, grenville armitage wrote: > > > > I'm curious about the uptick of bugzilla chatter turning up in > freebsd-net@ the last few days. > > Whilst I can filter it locally, I'm puzzled as to why it would be a > Good Thing for bugzil

Re: Exposing full 32bit RSS hash from card for ixgbe(4)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/05/15 07:10, Barney Cordoba via freebsd-net wrote: > > > > On Wednesday, August 5, 2015 2:19 AM, Olivier Cochard-Labbé > wrote: > > > On Wed, Aug 5, 2015 at 1:15 AM, Barney Cordoba via freebsd-net < > freebsd-net@freebsd.org> wrote: > >

Re: pxeboot with newer Intel NICs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/15/15 12:42, Jeremiah Lott wrote: > I am having trouble using pxeboot with new-ish Intel NICs. We have > been using pxeboot with Intel NICs as part of our infrastructure > for a while successfully. Recently, I got some new 2x10G (ixgbe) > cards

Re: em resource allocation fails on SunFire X4500

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/20/15 11:14, rondzie...@comcast.net wrote: > I am using 10.1-RELEASE on a SunFire X4500 (thumper). It has 4 em > devices, of which only the first two work due to a resource > failure: > > em0: port > 0xcc00-0xcc3f mem 0xfdae-0xfdaf ir

Re: patm device on FreeBSD 9.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/07/15 21:01, Nomad Esst via freebsd-net wrote: > I've recently configured my kernel with the following options > devicepatm deviceutopia deviceatm options > NATM options LIBMBPOOL In order to use patm device on my

ex(4) Removal from -current

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201127 ex(4) is an old Intel ethernet driver that isn't being actively maintained. I propose purging it from -current for 11.0 release things. sean p.s. will post to -current as well -BEGIN P

Re: Lagg-LACP is not working with Intel Fortville NIC on FreeBSD HOL (11.0 Current)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/26/15 04:55, Pushkar Kothavade wrote: > Dear Members, > > To further narrow down the problem, I am evaluating single ixl > link (Intel Fortville NIC) on FreeBSD platform. Single ixl link is > _NOT_ a part of Lagg. > > *Issue* > > Change in M

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

sbruno added a comment. Should this be closed? REVISION DETAIL https://reviews.freebsd.org/D1777 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rrs, imp, gnn, rwatson, lstewart, kib, adrian, jhb, bz, sbruno Cc: ae, bz, freebsd-net-list, emaste, hiren, ju

[CFT] em(4) updates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Intel and Limelight have collaborated a bit to update em(4) and shake loose some features. https://svnweb.freebsd.org/changeset/base/283959 I've left EM_MULTIQUEUE turned off by default but some of the changes in head are relevant to all em(4) chi

[Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

sbruno accepted this revision. sbruno added a comment. This revision is now accepted and ready to land. Randall: I think this needs to be manually closed as the svn commit hook didn't fire when r278469 hit the tree. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lst

[Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage.

sbruno added a comment. Randall: Do you want to close this review as committed? The commit hook doesn't seem to have fired to close this when comitted at svn r278472 REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc

[Differential] [Accepted] D1777: Associated fix for arp/nd6 timer usage.

sbruno accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net ___

Re: Intel 82574L (em) [MultiQueue Support Fixes]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/30/15 13:11, Sean Bruno wrote: > > http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf > > According to 7.1.11, this device does indeed have 2 queues for > stuff and or things. So, basic RSS wo

Re: Intel 82574L (em)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/10/15 19:09, Adrian Chadd wrote: > ... you can still use 1 TX/1 RX ring on -HEAD. If we turn on RSS > in the driver and have it hardware hash things, then the netisr > input routine will throw it into the right per-CPU queue and it'll > distri

Re: Intel 82574L (em)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/10/15 18:49, Sepherosa Ziehau wrote: > On Sat, Jan 31, 2015 at 5:11 AM, Sean Bruno > wrote: >> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> http://www.intel.com/content/dam/doc/datasheet/82574

Re: Silly experiments with netisr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/05/15 11:13, Adrian Chadd wrote: > On 5 February 2015 at 11:03, Sean Bruno > wrote: >> > Some questions came up around the office and we ended up doing > some quite silly things with lo0 and netcat. > > If one run

Silly experiments with netisr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Some questions came up around the office and we ended up doing some quite silly things with lo0 and netcat. If one runs a continuous netcat on localhost to another netcat listener on localhost that writes the output to /dev/null, netisr gets super

Re: Intel 82574L (em)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/15 09:35, Pieper, Jeffrey E wrote: > In the past we have, yes. This was a few years ago, but iirc the > current implementation is supposed to be the official solution. > > Jeff Jeff: Thanks for you feedback. Jack: I've tried compiling

[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)

sbruno added a comment. Sanitized panic #2 Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 6752395264B (6439 MB) Blocksize: 512 Dumptime: Mon Feb 2 14:42:05 2015 Hostname: Magic: FreeBSD Kernel Du

[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)

sbruno added a comment. Sanitized panic #1 Dump header from device /dev/da0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 6451576832B (6152 MB) Blocksize: 512 Dumptime: Sat Jan 31 21:30:37 2015 Hostname: Magic: FreeBSD Kernel Dump Version String:

[Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

sbruno added a comment. We're dubious over here in "actually running this on live systems" land. We're seeing pretty chaotic panics, unsure what we should dig into here. Within minutes of running live on a machine, we see various panics in cam or the network stack running this against stable

Re: Intel 82574L (em)

Cc: > FreeBSD Net Subject: Re: Intel 82574L (em) > > Yup, I wrote that :) > > Sean, I will check around to see if anything may have changed in > that regard. > > Jack > > > On Fri, Jan 30, 2015 at 5:00 PM, hiren panchasara < > hi...@strugglingcoder.info>

Re: Intel 82574L (em)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/30/15 20:30, Jack Vogel wrote: > Yup, I wrote that :) > > Sean, I will check around to see if anything may have changed in > that regard. > > Jack Maybe, but the linux driver has the same limitation and does not enable multiple queues either

Intel 82574L (em)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf According to 7.1.11, this device does indeed have 2 queues for stuff and or things. So, basic RSS would be possible in something like an Atom box. I note that the

pf(4) changes recently?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I use pf and jails on a host to redirect port 80 to the correct jail. I only use 1 routeable IP and have been running this configuration for over a year now. I run nginx in jailA (10.0.0.2) and have it capture port 80 requests and forward them to

Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers

On Sat, 2014-11-01 at 13:24 -0700, Sean Bruno wrote: > ooo lovely. Able to get two different panics out of my laptop today. > Both in urtwn(4). > > Is this a USB problem and not a driver failure? > > https://people.freebsd.org/~sbruno/core.txt.1 > > https://people.free

Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers

ooo lovely. Able to get two different panics out of my laptop today. Both in urtwn(4). Is this a USB problem and not a driver failure? https://people.freebsd.org/~sbruno/core.txt.1 https://people.freebsd.org/~sbruno/core.txt.0 sean ___ freebsd-net@

Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers

On Thu, 2014-10-30 at 11:09 -0700, Sean Bruno wrote: > On Thu, 2014-10-30 at 10:52 +0800, Kevin Lo wrote: > > On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: > > > > > > It looks like recent HEAD seems to fail intermittently here on my home > > > ne

Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers

On Thu, 2014-10-30 at 10:52 +0800, Kevin Lo wrote: > On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: > > > > It looks like recent HEAD seems to fail intermittently here on my home > > network. It will recover, but urtwn(4) seems to lose an ack or > > some

urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers

It looks like recent HEAD seems to fail intermittently here on my home network. It will recover, but urtwn(4) seems to lose an ack or something on txmit. turning on debug, yields this message during the hang event. hw.usb.urtwn.debug: 1 Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf

Re: svn commit: r272089 - head/sys/netpfil/ipfw

I'd really like to see the contents of > A> the frames and what their origin is. > A> > A> I'm worried that they're valid stack-generated frames.. > > I agree on this. Fixing NULL pointer derefs with NULL check is not > always a right thing to do. > >

Re: Multipath TCP for FreeBSD v0.4

On Wed, 2014-09-17 at 12:58 +1000, Nigel Williams wrote: > On 17/09/14 08:48, Sean Bruno wrote: > > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > >> Hi, > >> > >> We recently released a new tech report "Design Overview of > Multipath T

Re: Multipath TCP for FreeBSD v0.4

On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: > Hi, > > We recently released a new tech report "Design Overview of Multipath TCP > version 0.4 for FreeBSD-11" [1]. The report provides some details on > various aspects of the implementation (session management, data-level > retransmis

Re: ixgbe(4) spin lock held too long

On Mon, 2014-09-08 at 15:34 -0400, Eric van Gyzen wrote: > >> Unread portion of the kernel message buffer: > >> spin lock 0x812a0400 (callout) held by 0xf800151fe000 > (tid > >> 13) too long > > TID 13 is usually a kernel idle thread, which would seem to > indicate > a dangling

Re: ixgbe(4) spin lock held too long

On Mon, 2014-09-08 at 12:09 -0700, Sean Bruno wrote: > This sort of looks like the hardware failed to respond to us in time? > Too busy? > > sean > This seems to be affecting my 10/stable machines from 15Aug2014. Not a lot of churn in the code so I don't think this is

ixgbe(4) spin lock held too long

This sort of looks like the hardware failed to respond to us in time? Too busy? sean panic: spin lock held too long GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or dist

[RFC] PLPMTU Blackhole Detection

https://reviews.freebsd.org/D506 This patch implements an attempt to adjust the MTU/MSS of a connection to work around poor networks that block ICMP fragmentation needed indications. sean p.s. I intend on working on a full PLPMTU implementation after working this into the tree.

Re: getpeername returning ENOTCONN for a connected socket

On Fri, 2014-06-20 at 16:21 -0700, hiren panchasara wrote: > Reviving an old thread where Steve found this problem: A call to > getpeername on a connected tcp socket returns ENOTCONN with no prior > errors being reported by previous socket calls. > > Please look at > http://lists.freebsd.org/pipe

re(4) stalls, crashes(supposed patch exists?)

The Bytemark Site of freebsd.org is experiencing periodic stalls and crashes on the machines being used as routers. I have heard of a rumored patch that exists "somewhere" to resolve this, but when I asked at BSDCan, I got no takers. Any thoughts? FreeBSD igw0.bme.freebsd.org 11.0-CURRENT FreeB

  1   2   >