vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

Dear all, I found great papers about netmap(4)s desigen and implementation details, and I'm sure it's one other masterpeace of rizzo-quality :-) Thanks to all participants for that great code! To be honest, I haven't read all of that, because I'm short in time and my first mission is to see if

Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

Bezüglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localtime): > 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer <free...@omnilan.de>: … >> I'm familar with epair(4), but not with tap(4). >> I don't understand the man page for tap, perhaps I should read pty(4)… &

Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

Bezüglich Vincenzo Maffione's Nachricht vom 14.10.2016 15:08 (localtime): > Hi, > > Thanks for your feedback. > … >> Accidentally I found out that 'vale-ctl -n testif0' creates a artificial >> interface, which is reported by ifconfig(8): >> testif0: flags=8801 metric 0

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

Bezüglich Sean Bruno's Nachricht vom 10.01.2017 04:32 (localtime): > tl;dir --> you get to keep your igbX devices(thanks jhb), no POLA > violations this week. > > I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on > IFLIB in the kernel. > > At this point, the driver deviates

qualified vale(4) uplink interface clones

Dear netmap gurus, I'm getting different crashes if using vale(4) as a drop in replacement for if_bridge(4). Before collecting dumps I'd like to know if the setup, which I need to keep (including a MTU of 9000 bytes), is meant to be supported at all with netmap. Usually I have two GbE ports

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:29 (localtime): > Hi, > This is supposed to work because of the emulated netmap adapter. > By means of that, Netmap works on tap(4) interfaces if_bridge > interfaces, epairs, etc. Have you tried those to see if that works? Hello

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:51 (localtime): > Hi, > > ./bridge is a netmap application that implements a simple forwarder > between two netmap ports (given as input arguments). I don't see any way > to use that to let two bhyve VMs work together. It's an example >

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 18.03.2017 09:29 (localtime): >… >>> Actually, there is pending work on bhyve and netmap, that is going to be >>> merged soon, available at https://github.com/vmaffione/freebsd/ in >>> branch ptnet-head. >>> >>> If you are interested, here there is some

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): > Two things here: > > - We pushed an important fix to stable/11 1-2 months ago, that prevents > panic on emulated netmap mode. Maybe you are still getting that panic > because you are using an older stable/11 image, you

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localtime): … >> So to summarize for newbies exploring netmap(4) world in combination >> with physical uplinks and virtual interfaces, it's important to do the >> following uplink NIC configuration (ifconfig(8)): >> -rxcsum -txcsum

Are ./valte-ctl and ./bridge friends or competitors?

Hello, I'm still having problems understanding netmap(4) and would highly appreciate brief help. I'm running stable/11. I'd like to replace if_bridge(4) with netmap(4), because virtio-net chops jumbu frames (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215737) and if_bridge(4) requires

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Harry Schmalzbauer's Nachricht vom 17.03.2017 10:06 (localtime): > Hello, > > I'm still having problems understanding netmap(4) and would highly > appreciate brief help. > > I'm running stable/11. I'd like to replace if_bridge(4) with netmap(4), > because virtio-net chops jumbu frames

[panic] netmap(4) and if_lagg(4)

Unforutantely I can't use if_lagg(4) as physical vale interface: lagg0: flags=8843 metric 0 mtu 9000 options=6403b9 ether 96:07:e9:78:c6:ac

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

Bezüglich Andrey V. Elsukov's Nachricht vom 06.04.2017 14:56 (localtime): > On 16.03.2017 21: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) optio

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

Bezüglich Sean Bruno's Nachricht vom 05.04.2017 23:54 (localtime): > > > 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)

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 11:06 (localtime): > Yes, it should integrate and compile out of the box, I've done that > several times with FreeBSD-11.0 and 10.3. Impressive, it needed just a small addition to sys/conf/files to make the linker happy :-) I also recomplied

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Harry Schmalzbauer's Nachricht vom 26.05.2017 14:22 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 11:06 (localtime): >> Yes, it should integrate and compile out of the box, I've done that >> several times with FreeBSD-11.0 and 10.3. > Impressive, it needed just a

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 28.05.2017 09:46 (localtime): >> >> I also recomplied vale-ctl, but I get the following error when trying to >> add em0 (lagg-unrelated): >> 389.083433 [ 835] netmap_obj_malloc netmap_ring request size >> 65792 too large >> 389.091593 [1693]

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:09 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): >> I see the bug is in FreeBSD 11. I attached the simple patch to fix it. >> Can someone commit the patch to 11/stable? >> >> Harry: You should be

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 22:46 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:09 (localtime): >> Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): >>> I see the bug is in FreeBSD 11. I attached the simple patch to

Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6

Bezüglich Harry Schmalzbauer's Nachricht vom 06.04.2017 15:25 (localtime): > Bezüglich Andrey V. Elsukov's Nachricht vom 06.04.2017 14:56 (localtime): >> On 16.03.2017 21:26, Harry Schmalzbauer wrote: >>> Hello, >>> >>> I'm wondering if I really loos

Re: Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6

Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 19:58 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 06.04.2017 15:25 (localtime): >> Bezüglich Andrey V. Elsukov's Nachricht vom 06.04.2017 14:56 (localtime): >>> On 16.03.2017 21:26, Harry Schmalzbauer

vale uplink via vlan-if [Was: Re: Are ./valte-ctl and ./bridge friends or competitors?]

Bezüglich Vincenzo Maffione's Nachricht vom 21.03.2017 19:05 (localtime): > 2017-03-20 19:41 GMT+01:00 Harry Schmalzbauer <free...@omnilan.de>: > >> Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localtime): >> … >>>> So to summarize f

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:31 (localtime): > Hi, > This is a (silly) bug that is not present anymore in the upstream code > https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_freebsd.c#L410-L417 > that is txq and rxq for generic adapter cannot

ovs-netmap forgotten?

Hello, I found lots of interesting papers about research and improvements regarding Open vSwitch and netmap (on FreeBSD, e.g. http://changeofelia.info.ucl.ac.be/pmwiki/uploads/SummerSchool/Program/poster_001.pdf) Again, University of Pisa with a famous team arround Luigi Rizzo did some highly

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 15:01 (localtime): > 2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer <free...@omnilan.de>: > >> Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): … >> I'll try to provide more info about th

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime): > Is lagg0 the only interface attached to vale0? Yes. > Is lagg0 aggregating a VLAN interface? No. > You can try this trivial patch > > diff --git a/sys/dev/netmap/netmap_generic.c > b/sys/dev/netmap/netmap_generic.c

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime): > Is lagg0 the only interface attached to vale0? > Is lagg0 aggregating a VLAN interface? > > You can try this trivial patch > > diff --git a/sys/dev/netmap/netmap_generic.c > b/sys/dev/netmap/netmap_generic.c > index

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:14 (localtime): > Hi, > Your stack trace report this: > > #7 0x8069dc50 at vlan_input+0x1f0 > > which means VLANs are involved, in some way. Is that the correct trace? The trace is from the pnaic after doing 'vale-ctl -a

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 22:57 (localtime): > No, the thing is that I misinterpreted your stack trace. The patch is ok > for a different bug. It seems that the problem are vlans more than lagg. > Which interface did you put in netmap mode, em or em.345? Good morning,

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 10:41 (localtime): > Ok, so you should try to completely replace the code in your > /usr/src/sys with the code in the upstream netmap > repository https://github.com/luigirizzo/netmap (sys directory). Sorry beeing so complicated; But is there

Re: panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c

Bezüglich Harry Schmalzbauer's Nachricht vom 07.06.2017 16:20 (localtime): > lock order reversal: (sleepable after non-sleepable) > 1st 0xf8007519a960 vm object (vm object) @ > /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572 > 2nd 0xf8003299b000 (d)->nm_mtx

Re: ovs-netmap forgotten?

Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:01 (localtime): > Hello, > > I found lots of interesting papers about research and improvements > regarding Open vSwitch and netmap (on FreeBSD, e.g. >

Re: ovs-netmap forgotten?

Bezüglich Vincenzo Maffione's Nachricht vom 01.06.2017 00:39 (localtime): > Hi Harry, > OVS integration with netmap is very patchy and Linux only. Most > importantly, it is not the right way to go, for a number of reasons. > The real solution would be to integrate netmap into OVS would be to >

Re: vale uplink via vlan-if [Was: Re: Are ./valte-ctl and ./bridge friends or competitors?]

Bezüglich Vincenzo Maffione's Nachricht vom 01.06.2017 00:43 (localtime): > If VLAN interface do not work properly with VALE/netmap that's a bug of > the emulated adapter code in FreeBSD. > But in any case the approach is not the right one, since using the > emulated netmap adapter with VALE will

Re: ovs-netmap forgotten?

Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 11:59 (localtime): … > Having other offloadings enabled or disabled (regardless if it's on > parent or vlan-clone) doesn't matter, … I must correct myself! At least when it comes to host-stack traffic. Keeping offloadings enabled on the

Re: ovs-netmap forgotten?

Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime): > Hi Harry, > I've done some investigation on this issue (just for fun) , and I think I > may have found the issue. > > When using vlan interfaces, netmap use the emulated adapter, as the "vlan" > driver is not

panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c

lock order reversal: (sleepable after non-sleepable) 1st 0xf8007519a960 vm object (vm object) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572 2nd 0xf8003299b000 (d)->nm_mtx ((d)->nm_mtx) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_mem2.c:577

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): > I see the bug is in FreeBSD 11. I attached the simple patch to fix it. > Can someone commit the patch to 11/stable? > > Harry: You should be able to workaround the bug by setting > > # sysctl dev.netmap.generic_rings=1

tools/netmap/pkt-gen: clang error

Hello, after merging netmap code from head I can't compile pkt-gen from usr/src/tools/tools/netmap: cc -O2 -pipe -Werror -Wall -Wextra -march=ivybridge -g -std=gnu99 -fstack-protector-strong-Qunused-arguments -Qunused-arguments -std=gnu99 -fstack-protector-strong-Qunused-arguments

Re: ovs-netmap forgotten?

Bezüglich Harry Schmalzbauer's Nachricht vom 05.06.2017 20:25 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime): > … > First quick test shows you're right and this tiny diff solves a decent > share of my (ESXi-replacing) problems: > > ---

Re: Need help

Bezüglich Harry Schmalzbauer's Nachricht vom 12.09.2017 15:23 (localtime): > Bezüglich Igor V. Ruzanov's Nachricht vom 12.09.2017 11:00 (localtime): >> Hello, FreeBSD colleagues! >> Trying to forward my question to freebsd-net@ group, meybe there is a >> chance to dig the answer >> >> I have

Re: Need help

Bezüglich Andrey V. Elsukov's Nachricht vom 12.09.2017 15:38 (localtime): > On 12.09.2017 16:35, Andrey V. Elsukov wrote: >>> Either add E1000_DEV_ID_I350_COPPER_NOEE elsewhere, or try without _NOEE >>> appendix if datasheet suggests. >> >> Hi, >> >> just defining device id in the header usually

Re: Need help

Bezüglich Igor V. Ruzanov's Nachricht vom 12.09.2017 11:00 (localtime): > Hello, FreeBSD colleagues! > Trying to forward my question to freebsd-net@ group, meybe there is a > chance to dig the answer > > I have modern network card Intel i350T2V2 (peripheral dual gigabit > port NIC). And as far as

Q: [rtadvd] prefix info flag 'R' - Mobile IPv6 extension – or how to disable link-local gateway

Hello, it was unavoidable, so I took some time reading rtadvd.conf(5), rfc4861 (Neighbour Discovery for IP version 6, which also describes the Router Advertisement Message Format with it's Prefix Information, flags L and A) and rfc6275 (Mobility Support in IPv6, which extends the Prefix

Re: netmap/vale periodic deadlock

Bezüglich Harry Schmalzbauer's Nachricht vom 22.11.2017 09:39 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime): >> >> 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <free...@omnilan.de >> <mailto:free...@omnilan.de>>: >&g

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime): > > > 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer <free...@omnilan.de > <mailto:free...@omnilan.de>>: > > Bezüglich Vincenzo Maffione's Nachricht vom 21.

Re: Need Netgraph Help

Bezüglich John Lyon's Nachricht vom 15.12.2017 19:59 (localtime): > Harry and Eugene (and others), > > I appreciate all of your help. It's been really insightful. Although I > feel like I'm getting much closer to the solution, I don't think my problem > has been diagnosed. I've outlined my

Re: Need Netgraph Help

Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localtime): > 15.12.2017 4:27, John Lyon wrote: > I'm a new Netgraph user, but am having some problems with a simple Netgraph script I have written. Unfortunately, the error message is cryptic and I can't tell what I

Re: Need Netgraph Help

Bezüglich John Lyon's Nachricht vom 13.12.2017 21:38 (localtime): > Hello All, > > I'm a new Netgraph user, but am having some problems with a simple Netgraph > script I have written. Unfortunately, the error message is cryptic and I > can't tell what I am doing wrong since my script closely

netmap/vale periodic deadlock

Hello, sorry for annoying with another question/problem. I'm using netmap's vale (on stable/11) for bhyve(8) virtio-net backed SDN. The guests – unfortunately in production already – quit network services (resp. are not able to transceive any packets anymore) after about 2 days; repeatedly and

userland shutdown(2)?

Hello, stoping jails leaves open sockets with no process attached. (sockstat shows like this line: ?? ? ? tcp6 2001:db8::fedc:389 2001:db8::abcd:15666 ) Since I make use of mount lines in jail.conf, umounting the root filesystem of the jail fails because "device busy".

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime): > Hi, > It's hard to say, specially because it happens after two days of > normal use. > Can't you enable deadlock debugging features in your kernel? >

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 14:26 (localtime): > It may be that your is not a deadlock but some kind of crash. Enabling > debugging features would probably help (e.g. to get a stack trace). > Maybe your lockup/crash happened because you did some reconfiguration > (ring

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime): … > > If this is the case, although you are allowed to do that, I don't think > it's a convenient way to use netmap. > Since VLAN interfaces like vlan0 do not have (and cannot have) native > netmap support, you are falling

Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys

Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:26 (localtime): > iflib in stable/11 only affects bnxt at this time. > > You should try out HEAD and let us know for the rest of your questions. Ic, sorry for the noise – should have read the commits before wasting others' time :-( Thanks

Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys

Bezüglich Stephen Hurd's Nachricht vom 07.05.2018 23:42 (localtime): > Author: shurd > Date: Mon May 7 21:42:22 2018 > New Revision: 38 > URL: https://svnweb.freebsd.org/changeset/base/38 > > Log: > Merge iflib changes to 11-STABLE > > MFC r300147, r300153, r300154, r300215,

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

l+0x2b9/frame 0xfe008fe188b0 >> sys_ioctl() at sys_ioctl+0x168/frame 0xfe008fe18980 >> amd64_syscall() at amd64_syscall+0x2cc/frame 0xfe008fe18ab0 >> fast_syscall_common() at fast_syscall_common+0x101/frame >> 0xfe008fe18ab0 >> --- syscall (54, FreeBSD

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

Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 19:54 (localtime): … > Please excuse that I'm not familar with the phabricator and just did > "raw diff download" after briefly flying over the comments. > According to st_mtime this was on May 9th, 08:14:02 UTC (10:14 local > (CEST) time).

if_em(4) carrier loss event not recognized with i217; while 82574 does recognize

Hello, if I pull the TP connection from my i217 Clarkville, HEAD still reports media 1000Base-T status "active". Doing the same with the other if_em(4) NIC in that box, a hartwell, 82574LM, the status correctly changes to "no carrier". This is not iflib related, since it's reproducable with

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

Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime): > No need to test the latest revision unless/until you get a LOR or a > panic (both should be possible with the revision you currently have). > With the recent addition of a simple EBR API, mmacy@ is working on a > better

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

Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 21:55 (localtime): > Ok, the review is updated with the EBR. If you can update your tree to > r333466 or newer, apply the patch and retest, that would be great. It > seems to be working here. I took out the sys/net/if.c, sys/net/if_var.h and

Re: if_em(4) carrier loss event not recognized with i217; while 82574 does recognize

Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 21:17 (localtime): > Hello, > > if I pull the TP connection from my i217 Clarkville, HEAD still reports > media > 1000Base-T status "active". > > Doing the same with the other if_em(4) NIC in that box, a hartwell, > 82574LM, the status

iflib-if_igb tests with HEAD success [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:52 (localtime): > On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer <free...@omnilan.de> wrote: … >> But if the simple iflib/hw-support test with kawela+hartwell helps I'm >> happy to do. > > At this point it would

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

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 shape and I need to become familiar with any outstanding

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

Bezüglich Sean Bruno's Nachricht vom 08.05.2018 18:44 (localtime): > > > 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+ha

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

Am 11.05.2018 um 19:24 schrieb Harry Schmalzbauer: Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 21:55 (localtime): Ok, the review is updated with the EBR. If you can update your tree to r333466 or newer, apply the patch and retest, that would be great. It seems to be working here. I

'devctl detach' panic after resume [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

Am 08.05.2018 um 11:52 schrieb Kevin Bowling: On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer <free...@omnilan.de> wrote: Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:26 (localtime): iflib in stable/11 only affects bnxt at this time. You should try out HEAD and let u

Re: Proxy a TCP connection

Am 18.05.2018 um 23:29 schrieb Andrea Venturoli: … Let's say I have a router connected to the Internet on one side and to a LAN with private IPs on the other. I want some clients from outside to be able to connect to a TCP service on a machine on the LAN: they should connect to port X on the

Re: Testing VF/PF code

Am 29.05.2018 um 20:19 schrieb Lewis Donzis: This may be a red herring, but we’d be happy to see VF support for VMware SR-IOV in those drivers. We did a little bit of experimenting with it, but it looked like the code was a long way from working in that environment. ixlv(4) is working fine

Re: Testing VF/PF code

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 To some limited extent I have access to a productive host (ESXi 6) providing VFs

Re: Testing VF/PF code

Am 30.05.2018 um 16:45 schrieb Ryan Stone: On Tue, May 29, 2018 at 12:58 PM Sean Bruno wrote: 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? We have native support for creating VFs for ixl

Re: Testing VF/PF code

Am 30.05.2018 um 17:53 schrieb Kevin Bowling: Harry, I wasn’t aware of anyone desiring vf support for igb but I’ll take a look at it for you if you can test -current with patches when I’m ready. My motive is more to validate and refine the iflib functionality and this is a good exercise.

New iflib/e1000 panic (vlan) report [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

Am 08.05.2018 um 11:52 schrieb Kevin Bowling: On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer wrote: Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:26 (localtime): iflib in stable/11 only affects bnxt at this time. You should try out HEAD and let us know for the rest of your

Re: wlan0 && IPv6

Am 05.07.2018 um 12:22 schrieb Matthias Apitz: El día miércoles, julio 04, 2018 a las 04:02:22p. m. +0200, Harry Schmalzbauer escribió: Am 04.07.2018 um 15:30 schrieb Matthias Apitz: Hello, This morning I was in the Wifi area of the Munich Filmfest. They give the SSID and the WPA-2 password

Re: wlan0 && IPv6

Am 04.07.2018 um 15:30 schrieb Matthias Apitz: Hello, This morning I was in the Wifi area of the Munich Filmfest. They give the SSID and the WPA-2 password to anybody. While my FreeBSD (CURRENT) could associate fine, I did not get any IP addr. My Linux cellphone was working fine out of the box

Re: Default network device

Bezüglich Grzegorz Junka's Nachricht vom 24.03.2018 17:21 (localtime): > Hi, > > In my laptop I have both, wlan0 and ue0 (ethernet). When both are > connected, FreeBSD chooses to use wlan0 by default. Only when I > disable wlan0 it switches to use ue0. Since ue0 is ethernet it's > obviously much

if_ipsec(4) and IKEv1 [security/ipsec-tools, racoon.conf]

Hello, I'm out of ideas how to quick-start with if_ipsec(4) and IKEv1. I'm familar with security/ipsec-tools, but I couldn't find out how racoon(8) would interact with cloned if_ipsec(4) interfaces yet. Also, how to tell racoon(8) to generate such tunnel interfaces, hence policies? I guess the

Re: if_ipsec(4) and IKEv1 [security/ipsec-tools, racoon.conf]

Bezüglich Harry Schmalzbauer's Nachricht vom 27.02.2018 10:56 (localtime): > Hello, > > I'm out of ideas how to quick-start with if_ipsec(4) and IKEv1. > > I'm familar with security/ipsec-tools, but I couldn't find out how > racoon(8) would interact with cloned if_ipsec(4) interfaces yet. > >

Re: if_ipsec(4) and IKEv1 [security/ipsec-tools, racoon.conf]

Bezüglich Andrey V. Elsukov's Nachricht vom 27.02.2018 11:50 (localtime): > On 27.02.2018 12:56, Harry Schmalzbauer wrote: >> Hello, >> >> I'm out of ideas how to quick-start with if_ipsec(4) and IKEv1. >> >> I'm familar with security/ipsec-tools, but I couldn'

RE: [TOPICADJUST:] if_lagg(4)+if_vlan(4) panic: sleeping in an epoch section (igb, e1000_82575, actiall 82576 in use)

Am 08.05.2018 um 11:52 schrieb Kevin Bowling: On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer wrote: Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:26 (localtime): iflib in stable/11 only affects bnxt at this time. You should try out HEAD and let us know for the rest of your

Re: Bridges on VLAN-tagged interfaces.

Am 11.03.2019 um 11:48 schrieb Eric Bautsch: … |ifconfig bridge create ifconfig bridge1 addm re0.33| If I now put an IP on that bridge instead of re0.33, it does not ping. If I do a broadcast ping from another host on that network thus (Solaris system issuing the ping): ping -sn

Re: Bridges on VLAN-tagged interfaces.

Am 15.03.2019 um 11:21 schrieb Harry Schmalzbauer: Am 11.03.2019 um 11:48 schrieb Eric Bautsch: … |ifconfig bridge create ifconfig bridge1 addm re0.33| If I now put an IP on that bridge instead of re0.33, it does not ping. If I do a broadcast ping from another host on that network thus

iflib NICs don't report/recognize link state changes [Was: Re: if_em(4) carrier loss event not recognized with i217; while 82574 does recognize]

Am 18.09.2019 um 08:21 schrieb Harry Schmalzbauer: Am 11.05.2018 um 19:26 schrieb Harry Schmalzbauer:   Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 21:17 (localtime):   Hello, if I pull the TP connection from my i217 Clarkville, HEAD still reports media 1000Base-T status "a

Re: if_em(4) carrier loss event not recognized with i217; while 82574 does recognize

Am 11.05.2018 um 19:26 schrieb Harry Schmalzbauer: Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 21:17 (localtime): Hello, if I pull the TP connection from my i217 Clarkville, HEAD still reports media 1000Base-T status "active". Doing the same with the other if

Re: panic: sleeping in an epoch section

Am 09.10.2019 um 16:47 schrieb Mark Johnston: On Wed, Oct 09, 2019 at 04:18:34PM +0200, Hans Petter Selasky wrote: On 2019-10-09 15:56, Mark Johnston wrote: On Wed, Oct 09, 2019 at 10:40:04AM +0200, Hans Petter Selasky wrote: On 2019-10-09 06:36, Yuri Pankov wrote: Tried updating from

TCP6 regression for MTU path on stable/13

Hello, on one of my production stable/13 setups, MTU definitions from the routing table aren't respected (anymore?). I always had jumbo frames enabled and set a fixed MTU for routed destinations. No issues with stable/13 until april I guess (but I never checked for 'too big" ICMP6 messages

Re: TCP6 regression for MTU path on stable/13

Am 13.09.2021 um 12:37 schrieb Andrey V. Elsukov: 12.09.2021 14:12, Harry Schmalzbauer пишет: Will try to further track it down, but in case anybody has an idea, what change during the last view months in stable/13 could have caused this real-world problem regarding resulting TCP6 throughput

Re: git: 1a72c3d76aea - stable/13 - e1000: always enable PCSD when RSS hashing [Was: TCP6 regression for MTU path on stable/13]

Am 13.09.2021 um 13:18 schrieb Harry Schmalzbauer: Am 13.09.2021 um 12:37 schrieb Andrey V. Elsukov: 12.09.2021 14:12, Harry Schmalzbauer пишет: Will try to further track it down, but in case anybody has an idea, what change during the last view months in stable/13 could have caused this real

Re: Some strangeness with CARP

Am 12.02.2022 um 12:53 schrieb Andrea Venturoli: Hello. I've set up a network with CARP and I think I'm seeing something strange. What follows is a simplified setup (the real one involves lagg and vlan, but this should not matter). I have a Zyxel managed switch, two "servers": - A

pf(4) action match/overload somehow?

Hello, the following real-world proglem urged me to allow UDP connections from LAN to any. STUN is used to establish a fictious UDP connection to the connecting peer on a specific port, to drill the state-hole. Therefore, I have these translation rules added before the general

13.1-beta2 panic: page fault when utilizing iovctl(8) on ixl(4)

Hello, this is most basic 13.1-BETA2 setup, no debug tools yet, just deployed to do a quick ixlv(4) test: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address    = 0x54 fault code        = supervisor read data, page not present instruction pointer    =