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] netmap_mem2_rings_create Cannot allocate RX_ring >> > > It means that you are giving too many slot to each RX ring, probably 4096. > Try to use less slots, or to increase the dev.netmap.ring_size sysctl > (default value is less than 65792). Hmm, then thn I guess a default like dev.netmap.priv_ring_size has changed, because my em txd/rxd were default 4096, for both, native stable/11-netmap and HEAD-netmap... Reducing r/txd to 1024 solved the problem (hw.em.rxd in loader.conf). >> >> Adding lagg still results in a panci, but with your latest >> "return()"-patch, it's different: >> >> 0x8042aefb is in freebsd_generic_rx_handler … >> >> > Yeah, the same bug jist slipped back. Discard the previous patch and > replace it with the attached one. Thanks a lot! This patch avoids the panic :-) But unfortunately kills lagg (existing sockets break, nothing more tested yet) 488.896454 [ 394] nm_os_generic_find_num_desc called, in tx 1024 rx 1024 488.903445 [ 402] nm_os_generic_find_num_queues called, in txq 0 rxq 0 488.910424 [1252] generic_netmap_attach Created generic NA 0xf80036b26400 (prev 0) 488.971772 [ 448] generic_netmap_register Generic adapter 0xf80036b26400 goes on 488.980127 [ 495] generic_netmap_register RX ring 0 of generic adapter 0xf80036b26400 goes on 488.989917 [ 495] generic_netmap_register RX ring 1 of generic adapter 0xf80036b26400 goes on 488.999720 [ 502] generic_netmap_register TX ring 0 of generic adapter 0xf80036b26400 goes on 489.009504 [ 502] generic_netmap_register TX ring 1 of generic adapter 0xf80036b26400 goes on 489.019802 [3055] netmap_transmit lagg0 drop mbuf requiring offloadings 490.579512 [3055] netmap_transmit lagg0 drop mbuf requiring offloadings 491.781780 [3055] netmap_transmit lagg0 drop mbuf requiring offloadings … Have a nice sunday, will try to find some time next week to do more investigation, must close for today, haven't even read the messages, just wanted to drop a note. thnaks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
Hi Harry,
2017-05-26 14:22 GMT+02:00 Harry Schmalzbauer :
> 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 :-)
>
Exactly!
>
> 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] netmap_mem2_rings_create Cannot allocate RX_ring
>
It means that you are giving too many slot to each RX ring, probably 4096.
Try to use less slots, or to increase the dev.netmap.ring_size sysctl
(default value is less than 65792).
>
> Adding lagg still results in a panci, but with your latest
> "return()"-patch, it's different:
>
> 0x8042aefb is in freebsd_generic_rx_handler
> (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/
> netmap/netmap_freebsd.c:276).
> 271 struct netmap_generic_adapter *gna =
> 272 (struct netmap_generic_adapter *)NA(ifp);
> 273 int stolen = generic_rx_handler(ifp, m);
> 274
> 275 if (!stolen) {
> 276 gna->save_if_input(ifp, m);
> 277 }
> 278 }
> 279
> 280 /*
>
> KDB: stack backtrace:
> #0 0x805e4a17 at kdb_backtrace+0x67
> #1 0x805a34b6 at vpanic+0x186
> #2 0x805a3323 at panic+0x43
> #3 0x808a49b2 at trap_fatal+0x322
> #4 0x808a4a09 at trap_pfault+0x49
> #5 0x808a4246 at trap+0x286
> #6 0x8088a521 at calltrap+0x8
> #7 0x806aa3e0 at vlan_input+0x1f0
> #8 0x8069b298 at ether_demux+0x128
> #9 0x8069bf3b at ether_nh_input+0x31b
> #10 0x806b7c00 at netisr_dispatch_src+0xa0
> #11 0x8069b546 at ether_input+0x26
> #12 0x803a0278 at igb_rxeof+0x738
> #13 0x8039f63f at igb_msix_que+0x10f
> #14 0x8056ae1c at intr_event_execute_handlers+0xec
> #15 0x8056b106 at ithread_loop+0xd6
> #16 0x80568475 at fork_exit+0x85
> #17 0x8088aa5e at fork_trampoline+0xe
>
>
Yeah, the same bug jist slipped back. Discard the previous patch and
replace it with the attached one.
Cheers,
Vincenzo
> Any hints how I can get adding em0 (lagg and vlan-less) via vale-ctl
> again? (netmap_obj_malloc netmap_ring request size 65792 too large)
>
> Thanks,
>
> -harry
>
>
>
--
Vincenzo Maffione
diff --git a/sys/dev/netmap/netmap_freebsd.c b/sys/dev/netmap/netmap_freebsd.c
index 66d0637f..fa6427e0 100644
--- a/sys/dev/netmap/netmap_freebsd.c
+++ b/sys/dev/netmap/netmap_freebsd.c
@@ -270,8 +270,13 @@ freebsd_generic_rx_handler(struct ifnet *ifp, struct mbuf *m)
{
struct netmap_generic_adapter *gna =
(struct netmap_generic_adapter *)NA(ifp);
- int stolen = generic_rx_handler(ifp, m);
+ int stolen;
+if (!NM_NA_VALID(ifp)) {
+return;
+}
+
+stolen = generic_rx_handler(ifp, m);
if (!stolen) {
gna->save_if_input(ifp, m);
}
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 small addition to sys/conf/files to make > the linker happy :-) I perpared a diff to merge HEAD's netmap code to 11.1-prerelease for further tests (preferred over replacing stable/11 code with upstream clone, since there were some post-sync (r307394, 2016 Oct.) fixes, which I haven't check if they are FreeBSD specific or also included upstream). This hasn't changed anything regarding my problems (vale-ctl -a vale0:em0 not usable anymore: netmap_ring request size 65792 too large, panic when adding trying to add vale0:lagg0), but hopefully make things easier to narrow down the problems. If anybody else is interested in closer upstream netmap code on stable/11, here's the diff of the inofficial MFC: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/MFC-netmap-to-11.1-prerelease.diff I hope I found all related commits, but I've done by hand; no idea if there's a way to let svn do the same job... List of repspected revisions: r306772, r307394-r307396, r307569, r307572, r307574, r307703, r307706, r307728, r308000, r308038, r309306, r310822, r311045, r311986, r313747, r314915. No guarantee that I missed something! No tests regarding pt_netmap done yet, I just wanted to provide a better testing platfrom! -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 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] netmap_mem2_rings_create Cannot allocate RX_ring
Adding lagg still results in a panci, but with your latest
"return()"-patch, it's different:
0x8042aefb is in freebsd_generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:276).
271 struct netmap_generic_adapter *gna =
272 (struct netmap_generic_adapter *)NA(ifp);
273 int stolen = generic_rx_handler(ifp, m);
274
275 if (!stolen) {
276 gna->save_if_input(ifp, m);
277 }
278 }
279
280 /*
KDB: stack backtrace:
#0 0x805e4a17 at kdb_backtrace+0x67
#1 0x805a34b6 at vpanic+0x186
#2 0x805a3323 at panic+0x43
#3 0x808a49b2 at trap_fatal+0x322
#4 0x808a4a09 at trap_pfault+0x49
#5 0x808a4246 at trap+0x286
#6 0x8088a521 at calltrap+0x8
#7 0x806aa3e0 at vlan_input+0x1f0
#8 0x8069b298 at ether_demux+0x128
#9 0x8069bf3b at ether_nh_input+0x31b
#10 0x806b7c00 at netisr_dispatch_src+0xa0
#11 0x8069b546 at ether_input+0x26
#12 0x803a0278 at igb_rxeof+0x738
#13 0x8039f63f at igb_msix_que+0x10f
#14 0x8056ae1c at intr_event_execute_handlers+0xec
#15 0x8056b106 at ithread_loop+0xd6
#16 0x80568475 at fork_exit+0x85
#17 0x8088aa5e at fork_trampoline+0xe
Any hints how I can get adding em0 (lagg and vlan-less) via vale-ctl
again? (netmap_obj_malloc netmap_ring request size 65792 too large)
Thanks,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
Yes, it should integrate and compile out of the box, I've done that several times with FreeBSD-11.0 and 10.3. And yes, HEAD contains recent code, you can also use that. Cheers, Vincenzo 2017-05-26 11:01 GMT+02:00 Harry Schmalzbauer : > 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 a real chance this integrates > and compiles well out of the box? > My build machine (which is not the test machine) doesn't have internet > access and additionally I'm not faimilar with git, so I'd have to find a > solution getting the source first. And if I need to adapt/port anything > to match stable/11, I won't be abel to do so (much too less knwoledge > about all that code). > > I guess HEAD has already updated codebase. > Maybe it's better to start with HEAD? > But on the other hand, my test equipment is semi-productive with a quiet > special setup (memory-rootfs with additional ZFS boot and sys-pool)... > Very complicated I am... > > worth the stable/11 attempt? > > thanks, > > -harry > > > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 a real chance this integrates and compiles well out of the box? My build machine (which is not the test machine) doesn't have internet access and additionally I'm not faimilar with git, so I'd have to find a solution getting the source first. And if I need to adapt/port anything to match stable/11, I won't be abel to do so (much too less knwoledge about all that code). I guess HEAD has already updated codebase. Maybe it's better to start with HEAD? But on the other hand, my test equipment is semi-productive with a quiet special setup (memory-rootfs with additional ZFS boot and sys-pool)... Very complicated I am... worth the stable/11 attempt? thanks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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).
2017-05-26 10:38 GMT+02:00 Harry Schmalzbauer :
> 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 f148b228..46a3c2c6 100644
> > --- a/sys/dev/netmap/netmap_generic.c
> > +++ b/sys/dev/netmap/netmap_generic.c
> > @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf
> *m)
> > u_int work_done;
> > u_int r = MBUF_RXQ(m); /* receive ring number */
> >
> > + if (!NM_NA_VALID(ifp)) {
> > + return 0;
> > + }
> > +
> > if (r >= na->num_rx_rings) {
> > r = r % na->num_rx_rings;
> > }
>
> Unfortunately code base is too differing for me, since I absolutely
> don't know what I'm doing here.
> My resulting patch follows (combining this patch with the previous you
> provided and adding NM_NA_VALID()), but there are unmatching macros
> involved, which I have no idea about, so I'm not able to test this patch:
> --- src/sys/dev/netmap/netmap_freebsd.c.orig2017-05-25
> 20:36:29.744382000 +0200
> +++ src/sys/dev/netmap/netmap_freebsd.c 2017-05-25 20:35:53.858843000
> +0200
> @@ -259,9 +259,10 @@
> void
> generic_find_num_queues(struct ifnet *ifp, u_int *txq, u_int *rxq)
> {
> - D("called, in txq %d rxq %d", *txq, *rxq);
> - *txq = netmap_generic_rings;
> - *rxq = netmap_generic_rings;
> + u_int num_rings = netmap_generic_rings ? netmap_generic_rings : 1;
> +
> + *txq = num_rings;
> + *rxq = num_rings;
> }
>
>
> --- src/sys/dev/netmap/netmap_kern.h.orig 2017-01-31
> 19:42:41.453502000 +0100
> +++ src/sys/dev/netmap/netmap_kern.h2017-05-26 10:08:17.12842
> +0200
> @@ -1284,6 +1284,12 @@
>
> #endif /* linux */
>
> +#define NM_NA_VALID(ifp) (NA(ifp) && \
> + ((uint32_t)(uintptr_t)NA(ifp) ^ NA(ifp)->magic) == NETMAP_MAGIC )
> +
> + ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
> + } while(0)
> +
> #ifdef __FreeBSD__
>
> /* Assigns the device IOMMU domain to an allocator.
> --- src/sys/dev/netmap/netmap_generic.c.orig2017-01-31
> 19:42:41.45298 +0100
> +++ src/sys/dev/netmap/netmap_generic.c 2017-05-26 09:55:21.265066000
> +0200
> @@ -625,6 +625,10 @@
> u_int work_done;
> u_int rr = MBUF_RXQ(m); // receive ring number
>
> + if (!NM_NA_VALID(ifp)) {
> + return;
> + }
> +
> if (rr >= na->num_rx_rings) {
> rr = rr % na->num_rx_rings; // XXX expensive...
> }
>
> In file included from
> /usr/local/share/deploy-tools/RELENG_11/src/sys/modules/
> cxgbe/if_cxgbe/../../../dev/cxgbe/t4_netmap.c:52:
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1290:24:
> error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
> ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1254:20:
> note: expanded from macro 'NA'
> #define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1290:27:
> error: a parameter list without types is only allowed in a function
> definition
> ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1290:24:
> error: function cannot return function type 'int ()'
> ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1254:19:
> note: expanded from macro 'NA'
> #define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1290:24:
> error: expected ')'
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1254:44:
> note: expanded from macro 'NA'
> #define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:90:25:
> note: expanded from macro 'WNA'
> #define WNA(_ifp) (_ifp)->if_netmap
> ^
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1290:24:
> note: to match this '('
> /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_kern.h:1254:18:
> note: expanded from macro 'NA'
> #define NA(_ifp)((struct netmap_a
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 f148b228..46a3c2c6 100644
> --- a/sys/dev/netmap/netmap_generic.c
> +++ b/sys/dev/netmap/netmap_generic.c
> @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m)
> u_int work_done;
> u_int r = MBUF_RXQ(m); /* receive ring number */
>
> + if (!NM_NA_VALID(ifp)) {
> + return 0;
> + }
> +
> if (r >= na->num_rx_rings) {
> r = r % na->num_rx_rings;
> }
Unfortunately code base is too differing for me, since I absolutely
don't know what I'm doing here.
My resulting patch follows (combining this patch with the previous you
provided and adding NM_NA_VALID()), but there are unmatching macros
involved, which I have no idea about, so I'm not able to test this patch:
--- src/sys/dev/netmap/netmap_freebsd.c.orig2017-05-25
20:36:29.744382000 +0200
+++ src/sys/dev/netmap/netmap_freebsd.c 2017-05-25 20:35:53.858843000 +0200
@@ -259,9 +259,10 @@
void
generic_find_num_queues(struct ifnet *ifp, u_int *txq, u_int *rxq)
{
- D("called, in txq %d rxq %d", *txq, *rxq);
- *txq = netmap_generic_rings;
- *rxq = netmap_generic_rings;
+ u_int num_rings = netmap_generic_rings ? netmap_generic_rings : 1;
+
+ *txq = num_rings;
+ *rxq = num_rings;
}
--- src/sys/dev/netmap/netmap_kern.h.orig 2017-01-31
19:42:41.453502000 +0100
+++ src/sys/dev/netmap/netmap_kern.h2017-05-26 10:08:17.12842 +0200
@@ -1284,6 +1284,12 @@
#endif /* linux */
+#define NM_NA_VALID(ifp) (NA(ifp) && \
+ ((uint32_t)(uintptr_t)NA(ifp) ^ NA(ifp)->magic) == NETMAP_MAGIC )
+
+ ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
+ } while(0)
+
#ifdef __FreeBSD__
/* Assigns the device IOMMU domain to an allocator.
--- src/sys/dev/netmap/netmap_generic.c.orig2017-01-31
19:42:41.45298 +0100
+++ src/sys/dev/netmap/netmap_generic.c 2017-05-26 09:55:21.265066000 +0200
@@ -625,6 +625,10 @@
u_int work_done;
u_int rr = MBUF_RXQ(m); // receive ring number
+ if (!NM_NA_VALID(ifp)) {
+ return;
+ }
+
if (rr >= na->num_rx_rings) {
rr = rr % na->num_rx_rings; // XXX expensive...
}
In file included from
/usr/local/share/deploy-tools/RELENG_11/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_netmap.c:52:
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24:
error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:20:
note: expanded from macro 'NA'
#define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:27:
error: a parameter list without types is only allowed in a function
definition
((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24:
error: function cannot return function type 'int ()'
((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:19:
note: expanded from macro 'NA'
#define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24:
error: expected ')'
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:44:
note: expanded from macro 'NA'
#define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:90:25:
note: expanded from macro 'WNA'
#define WNA(_ifp) (_ifp)->if_netmap
^
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24:
note: to match this '('
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:18:
note: expanded from macro 'NA'
#define NA(_ifp)((struct netmap_adapter *)WNA(_ifp))
thanks,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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
> index f148b228..46a3c2c6 100644
> --- a/sys/dev/netmap/netmap_generic.c
> +++ b/sys/dev/netmap/netmap_generic.c
> @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m)
> u_int work_done;
> u_int r = MBUF_RXQ(m); /* receive ring number */
>
> + if (!NM_NA_VALID(ifp)) {
> + return 0;
> + }
> +
> if (r >= na->num_rx_rings) {
> r = r % na->num_rx_rings;
> }
Thank you very much, I'll compile.
I'd like to point to my other, directly if_vlan(4) related problem:
https://lists.freebsd.org/pipermail/freebsd-net/2017-May/048000.html
Having this explained/solved would split a big part of my
too-much-variables-equation :-)
Thanks,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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 f148b228..46a3c2c6 100644
--- a/sys/dev/netmap/netmap_generic.c
+++ b/sys/dev/netmap/netmap_generic.c
@@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m)
u_int work_done;
u_int r = MBUF_RXQ(m); /* receive ring number */
+ if (!NM_NA_VALID(ifp)) {
+ return 0;
+ }
+
if (r >= na->num_rx_rings) {
r = r % na->num_rx_rings;
}
2017-05-26 9:21 GMT+02:00 Harry Schmalzbauer :
> 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 vale0:lagg0' (while
> lagg0 can have various names, but I'm not using a vlan clone).
>
> Might be that existing, but to my understanding uninvolved vlan clones
> interfere here...
> The lagg0 does have vlan clones (lots of) defined.
> Unfortunately I can't take them out of the game for testing...
>
> Does that picture match the trace?
>
> thanks,
>
> -harry
>
>
>
--
Vincenzo Maffione
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 vale0:lagg0' (while lagg0 can have various names, but I'm not using a vlan clone). Might be that existing, but to my understanding uninvolved vlan clones interfere here... The lagg0 does have vlan clones (lots of) defined. Unfortunately I can't take them out of the game for testing... Does that picture match the trace? thanks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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? Cheers, VIncenzo 2017-05-26 9:12 GMT+02:00 Harry Schmalzbauer : > 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, > > it was if_lagg itself, no vlan clone. > The latter is a completely different problem, and contrary to the > initial panic report, vlan clones don't lead to panics anymore. > > > -harry > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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, it was if_lagg itself, no vlan clone. The latter is a completely different problem, and contrary to the initial panic report, vlan clones don't lead to panics anymore. -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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?
Il 25 mag 2017 10:46 PM, "Harry Schmalzbauer" ha
scritto:
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 able to workaround the bug by setting
>>
>> # sysctl dev.netmap.generic_rings=1
> I'll recompile with your patch, thanks a lot!
Hi, unfortunately I can't confirm it to be fixed.
The kgdb output is exactly the same:
(kgdb) list *0x80426714
0x80426714 is in generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
netmap_generic.c:628).
623 struct netmap_adapter *na = NA(ifp);
624 struct netmap_generic_adapter *gna = (struct
netmap_generic_adapter *)na;
625 u_int work_done;
626 u_int rr = MBUF_RXQ(m); // receive ring number
627
628 if (rr >= na->num_rx_rings) {
629 rr = rr % na->num_rx_rings; // XXX expensive...
630 }
631
632 /* limit the size of the queue */
Current language: auto; currently minimal
Will double-check tomorrow that the binary really includes your patch.
Ofcourse I checked briefly and revision and buildtime check affirms it.
best,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 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
>> I'll recompile with your patch, thanks a lot!
> Hi, unfortunately I can't confirm it to be fixed.
>
> The kgdb output is exactly the same:
>
> (kgdb) list *0x80426714
> 0x80426714 is in generic_rx_handler
> (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628).
> 623 struct netmap_adapter *na = NA(ifp);
> 624 struct netmap_generic_adapter *gna = (struct
> netmap_generic_adapter *)na;
> 625 u_int work_done;
> 626 u_int rr = MBUF_RXQ(m); // receive ring number
> 627
> 628 if (rr >= na->num_rx_rings) {
> 629 rr = rr % na->num_rx_rings; // XXX expensive...
> 630 }
> 631
> 632 /* limit the size of the queue */
> Current language: auto; currently minimal
>
> Will double-check tomorrow that the binary really includes your patch.
> Ofcourse I checked briefly and revision and buildtime check affirms it.
Last note for today; late here:
The patch is against sys/dev/netmap/netmap_freebsd.c (at least my
interpretation of it, since f1.c wasN#t applicable), and the debugger
claims sys/dev/netmap/netmap_generic.c!
thnaks,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 able to workaround the bug by setting
>>
>> # sysctl dev.netmap.generic_rings=1
> I'll recompile with your patch, thanks a lot!
Hi, unfortunately I can't confirm it to be fixed.
The kgdb output is exactly the same:
(kgdb) list *0x80426714
0x80426714 is in generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628).
623 struct netmap_adapter *na = NA(ifp);
624 struct netmap_generic_adapter *gna = (struct
netmap_generic_adapter *)na;
625 u_int work_done;
626 u_int rr = MBUF_RXQ(m); // receive ring number
627
628 if (rr >= na->num_rx_rings) {
629 rr = rr % na->num_rx_rings; // XXX expensive...
630 }
631
632 /* limit the size of the queue */
Current language: auto; currently minimal
Will double-check tomorrow that the binary really includes your patch.
Ofcourse I checked briefly and revision and buildtime check affirms it.
best,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
2017-05-25 18:09 GMT+02:00 Harry Schmalzbauer : > 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 > > I'll recompile with your patch, thanks a lot! > > > And yes, if_lagg(4) doesn't have native netmap support, like all the > > meta-drivers (e.g. vlan, tunnels, etc.). > > Point is that you should implement link aggregation in your application > (in > > user-space). > > Thanks for confirmation. > My problem is that I can't pass frames to guests without vlan filtering > first :-( > Then you need an ad-hoc userspace netmap application that does this job, reading the tagged frames from the NIC, strip the tag and dispatch to the proper VM. > > Focus is not on inter-VM-connection, but most efficient port usage _and_ > vm-interconnection. The more I learn the less I know what to do ;-) > If I only had VF-capable hardware (actually VF-"supported" hardware, > 82576 was SR-IOV enabled, but at the advent of 10GbE, SR-IOV support for > older chips was removed - where initially implemented - and of course > not implemented anywhere else). > > -harry > > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 I'll recompile with your patch, thanks a lot! > And yes, if_lagg(4) doesn't have native netmap support, like all the > meta-drivers (e.g. vlan, tunnels, etc.). > Point is that you should implement link aggregation in your application (in > user-space). Thanks for confirmation. My problem is that I can't pass frames to guests without vlan filtering first :-( Focus is not on inter-VM-connection, but most efficient port usage _and_ vm-interconnection. The more I learn the less I know what to do ;-) If I only had VF-capable hardware (actually VF-"supported" hardware, 82576 was SR-IOV enabled, but at the advent of 10GbE, SR-IOV support for older chips was removed - where initially implemented - and of course not implemented anywhere else). -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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
And yes, if_lagg(4) doesn't have native netmap support, like all the
meta-drivers (e.g. vlan, tunnels, etc.).
Point is that you should implement link aggregation in your application (in
user-space).
Cheers,
Vincenzo
2017-05-25 17:36 GMT+02:00 Harry Schmalzbauer :
> 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 be 0.
> >
> > So I would say the problem is outdated code in the FreeBSD version you
> are
> > using. Which version you are using exactly? Maybe we can try to push a
> fix.
>
> Thanks for the quick reply!
> This panic was with r318629 (stable/11 = FreeBSD 11.1-PRERELEASE)
>
> You mentioned "generic adapter": Does this mean native-netmap support
> get's lost when if_lagg(4) is in game after if_igb(4)?
>
> Thanks,
>
> -harry
>
>
>
--
Vincenzo Maffione
--- f1.c 2017-05-25 17:46:36.948871305 +0200
+++ f.c 2017-05-25 17:46:01.542203054 +0200
@@ -273,9 +273,10 @@ generic_find_num_desc(struct ifnet *ifp,
void
generic_find_num_queues(struct ifnet *ifp, u_int *txq, u_int *rxq)
{
- D("called, in txq %d rxq %d", *txq, *rxq);
- *txq = netmap_generic_rings;
- *rxq = netmap_generic_rings;
+ u_int num_rings = netmap_generic_rings ? netmap_generic_rings : 1;
+
+ *txq = num_rings;
+ *rxq = num_rings;
}
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 be 0. > > So I would say the problem is outdated code in the FreeBSD version you are > using. Which version you are using exactly? Maybe we can try to push a fix. Thanks for the quick reply! This panic was with r318629 (stable/11 = FreeBSD 11.1-PRERELEASE) You mentioned "generic adapter": Does this mean native-netmap support get's lost when if_lagg(4) is in game after if_igb(4)? Thanks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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 be 0.
So I would say the problem is outdated code in the FreeBSD version you are
using. Which version you are using exactly? Maybe we can try to push a fix.
Cheers,
Vincenzo
2017-05-25 16:47 GMT+02:00 Harry Schmalzbauer :
> Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 15:01 (localtime):
> > 2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer :
> >
> >> Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28
> (localtime):
>
> …
> >> I'll try to provide more info about the panic this week. Like discussed
> >> offlist, the panic happend on a machine with the mentioned fix (latest
> >> stable).
> >> Perhaps this panic can be fixed, especialy for the vlan children.
> >>
> >
> > Ok, so if you create a vlan on an interface, and use netmap over the
> vlan,
> > you get a deterministic crash? Does the crash happen when you start
> > transmitting, receiving or both?
> >
>
> Sorry for the long delay.
>
> I now have a crash dump and could provide more info if someone can
> afford having a look at the lagg panic.
> The panic with em0.vlan vanisehd with latest -stable (11.1-prerelease),
> but using lagg reproducably panics.
>
> Unread portion of the kernel message buffer:
> 066.051358 [ 254] generic_find_num_desc called, in tx 1024 rx 1024
> 066.058166 [ 262] generic_find_num_queues called, in txq 0 rxq 0
> 066.064756 [1673] netmap_interp_ringid deprecated API, old ringid
> 0x0 -> ringid 0 reg 1
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0xc
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80426894
> stack pointer = 0x28:0xfe03afccb750
> frame pointer = 0x28:0xfe03afccb770
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 12 (irq269: igb0:que 1)
> trap number = 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> #0 0x805d8277 at kdb_backtrace+0x67
> #1 0x80596d06 at vpanic+0x186
> #2 0x80596b73 at panic+0x43
> #3 0x80898472 at trap_fatal+0x322
> #4 0x808984c9 at trap_pfault+0x49
> #5 0x80897d06 at trap+0x286
> #6 0x8087dfa1 at calltrap+0x8
> #7 0x8069dc50 at vlan_input+0x1f0
> #8 0x8068eb08 at ether_demux+0x128
> #9 0x8068f7ab at ether_nh_input+0x31b
> #10 0x806ab3f0 at netisr_dispatch_src+0xa0
> #11 0x8068edb6 at ether_input+0x26
> #12 0x8039f808 at igb_rxeof+0x738
> #13 0x8039ebcf at igb_msix_que+0x10f
> #14 0x8055e66c at intr_event_execute_handlers+0xec
> #15 0x8055e956 at ithread_loop+0xd6
> #16 0x8055bcc5 at fork_exit+0x85
> #17 0x8087e4de at fork_trampoline+0xe
> Uptime: 1m37s
> Dumping 1535 out of 15529
> MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> …
> Reading symbols from /usr/lib/debug/boot/kernel/uhid.ko.debug...done.
> Loaded symbols for /usr/lib/debug/boot/kernel/uhid.ko.debug
> #0 doadump (textdump=) at pcpu.h:222
> 222 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) list *0x80426894
> 0x80426894 is in generic_rx_handler
> (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/
> netmap/netmap_generic.c:628).
> 623 struct netmap_adapter *na = NA(ifp);
> 624 struct netmap_generic_adapter *gna = (struct
> netmap_generic_adapter *)na;
> 625 u_int work_done;
> 626 u_int rr = MBUF_RXQ(m); // receive ring number
> 627
> 628 if (rr >= na->num_rx_rings) {
> 629 rr = rr % na->num_rx_rings; // XXX expensive...
> 630 }
> 631
> 632 /* limit the size of the queue */
>
> Thanks,
>
> -harry
>
--
Vincenzo Maffione
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 :
>
>> Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime):
…
>> I'll try to provide more info about the panic this week. Like discussed
>> offlist, the panic happend on a machine with the mentioned fix (latest
>> stable).
>> Perhaps this panic can be fixed, especialy for the vlan children.
>>
>
> Ok, so if you create a vlan on an interface, and use netmap over the vlan,
> you get a deterministic crash? Does the crash happen when you start
> transmitting, receiving or both?
>
Sorry for the long delay.
I now have a crash dump and could provide more info if someone can
afford having a look at the lagg panic.
The panic with em0.vlan vanisehd with latest -stable (11.1-prerelease),
but using lagg reproducably panics.
Unread portion of the kernel message buffer:
066.051358 [ 254] generic_find_num_desc called, in tx 1024 rx 1024
066.058166 [ 262] generic_find_num_queues called, in txq 0 rxq 0
066.064756 [1673] netmap_interp_ringid deprecated API, old ringid
0x0 -> ringid 0 reg 1
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80426894
stack pointer = 0x28:0xfe03afccb750
frame pointer = 0x28:0xfe03afccb770
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq269: igb0:que 1)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x805d8277 at kdb_backtrace+0x67
#1 0x80596d06 at vpanic+0x186
#2 0x80596b73 at panic+0x43
#3 0x80898472 at trap_fatal+0x322
#4 0x808984c9 at trap_pfault+0x49
#5 0x80897d06 at trap+0x286
#6 0x8087dfa1 at calltrap+0x8
#7 0x8069dc50 at vlan_input+0x1f0
#8 0x8068eb08 at ether_demux+0x128
#9 0x8068f7ab at ether_nh_input+0x31b
#10 0x806ab3f0 at netisr_dispatch_src+0xa0
#11 0x8068edb6 at ether_input+0x26
#12 0x8039f808 at igb_rxeof+0x738
#13 0x8039ebcf at igb_msix_que+0x10f
#14 0x8055e66c at intr_event_execute_handlers+0xec
#15 0x8055e956 at ithread_loop+0xd6
#16 0x8055bcc5 at fork_exit+0x85
#17 0x8087e4de at fork_trampoline+0xe
Uptime: 1m37s
Dumping 1535 out of 15529
MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%
…
Reading symbols from /usr/lib/debug/boot/kernel/uhid.ko.debug...done.
Loaded symbols for /usr/lib/debug/boot/kernel/uhid.ko.debug
#0 doadump (textdump=) at pcpu.h:222
222 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) list *0x80426894
0x80426894 is in generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628).
623 struct netmap_adapter *na = NA(ifp);
624 struct netmap_generic_adapter *gna = (struct
netmap_generic_adapter *)na;
625 u_int work_done;
626 u_int rr = MBUF_RXQ(m); // receive ring number
627
628 if (rr >= na->num_rx_rings) {
629 rr = rr % na->num_rx_rings; // XXX expensive...
630 }
631
632 /* limit the size of the queue */
Thanks,
-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer : > 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 should check. > > - If you are using "software devices" like if_lagg or even vlan > > interfaces, netmap and VALE won't help you a lot, because the drivers > > are not patched for netmap (and cannot be) > > Thank you for your explanation. I'm aware of loosing most advantages, > but it gives me the possibility to use different MTUs with one > switch/bridge. > > > I'll try to provide more info about the panic this week. Like discussed > offlist, the panic happend on a machine with the mentioned fix (latest > stable). > Perhaps this panic can be fixed, especialy for the vlan children. > Ok, so if you create a vlan on an interface, and use netmap over the vlan, you get a deterministic crash? Does the crash happen when you start transmitting, receiving or both? > Otoh., I guess it's NIC (igb) related and em/igb overhaul will hit > stable/11 eventually. And afaik, theres no native netmap support > anymore :-( > So probably resources are better spent on that instead of fixing a panic > which doesn't seem to affect anyone else than me. > There is an overhaul in progress, yes, but netmap support is going to be restored. > > Thanks, > > -harry > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 should check. > - If you are using "software devices" like if_lagg or even vlan > interfaces, netmap and VALE won't help you a lot, because the drivers > are not patched for netmap (and cannot be) Thank you for your explanation. I'm aware of loosing most advantages, but it gives me the possibility to use different MTUs with one switch/bridge. I'll try to provide more info about the panic this week. Like discussed offlist, the panic happend on a machine with the mentioned fix (latest stable). Perhaps this panic can be fixed, especialy for the vlan children. Otoh., I guess it's NIC (igb) related and em/igb overhaul will hit stable/11 eventually. And afaik, theres no native netmap support anymore :-( So probably resources are better spent on that instead of fixing a panic which doesn't seem to affect anyone else than me. Thanks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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 should check. - If you are using "software devices" like if_lagg or even vlan interfaces, netmap and VALE won't help you a lot, because the drivers are not patched for netmap (and cannot be). You are right, VALE is great for guest-to-guest traffic, and for this you don't need vale-ctl. It's not by design that NIC must be set in promisc mode when attached to VALE or used by netmap. But this is usually the case when you are using VMs (that come with their own MACs). Cheers, Vincenzo 2017-03-17 18:59 GMT+01:00 Harry Schmalzbauer : > 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 Vincenzo, > > thanks a lot for your attention! > > Yes, I tried various epair/tap setups. > Description followes. > > > > Maybe here the problem is that if_lagg is a "metadriver", which > > interacts in a bad way with the emulated adapter, which needs to > > intercept all the packets received from the driver. > > It seems it's a more generic problem to cloned interfaces, since I get > the same panic when trying to add a em0.vlanN to vale. > > There are a lot of component's in my desired setup: > > 2 igb interfaces build one (LACP) lagg cloned if. > Several cloned vlan children of that lagg interface shall handle IPs for > jails without vnet. > Then there are byhve guests, which are not that bandwidth and latency > critical for frames leaving the host, but for guest-to-host and > guest-to-guest connections, thus vale looks promising to me. > > Attaching the 2nd-gen-cloned vlan children of lagg(4) to vale, doesn't > lead to panics, but I couldn't pass any frame. I see arp-who-has and > also the answhers on the vlanIF, but it seems frames don't traverse vale. > > Attaching a 1st-gen cloned vlan(4) children of another em(4) interface, > I get the same panic when trying lagg(4) to vale. > > The only working setup was: > > igb0 --| > lagg0 -bridge0 > igb1 --| ||| > |-> lagg0.101 ---||epair0a|epair0b--vale0port1 > | |epair0b^-vale0port2 > |-> lagg0.102 vif0-vale0port3 > | | > |-> lagg0.103 | > … bhyve -s 5,virtio-net,vif0 > > Attaching lagg0 to vale0 = panic > Attaching lagg0.101 to vale0 = silence > Attaching em0.101 to vale0 = same panic as with lagg0 > Attaching em0 to vale0 = silence with tagged frames > ifconfig em0 -vlanhwtag solves the latter, but this doesn't really > help, because VID filtering inside the guest is no option, was just for > testing. > > I'm running stable/11 as of today. > > Is it by design that the physical vale interface must be set to promisc > mode? > > Thanks, > > -harry > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 Vincenzo, thanks a lot for your attention! Yes, I tried various epair/tap setups. Description followes. > Maybe here the problem is that if_lagg is a "metadriver", which > interacts in a bad way with the emulated adapter, which needs to > intercept all the packets received from the driver. It seems it's a more generic problem to cloned interfaces, since I get the same panic when trying to add a em0.vlanN to vale. There are a lot of component's in my desired setup: 2 igb interfaces build one (LACP) lagg cloned if. Several cloned vlan children of that lagg interface shall handle IPs for jails without vnet. Then there are byhve guests, which are not that bandwidth and latency critical for frames leaving the host, but for guest-to-host and guest-to-guest connections, thus vale looks promising to me. Attaching the 2nd-gen-cloned vlan children of lagg(4) to vale, doesn't lead to panics, but I couldn't pass any frame. I see arp-who-has and also the answhers on the vlanIF, but it seems frames don't traverse vale. Attaching a 1st-gen cloned vlan(4) children of another em(4) interface, I get the same panic when trying lagg(4) to vale. The only working setup was: igb0 --| lagg0 -bridge0 igb1 --| ||| |-> lagg0.101 ---||epair0a|epair0b--vale0port1 | |epair0b^-vale0port2 |-> lagg0.102 vif0-vale0port3 | | |-> lagg0.103 | … bhyve -s 5,virtio-net,vif0 Attaching lagg0 to vale0 = panic Attaching lagg0.101 to vale0 = silence Attaching em0.101 to vale0 = same panic as with lagg0 Attaching em0 to vale0 = silence with tagged frames ifconfig em0 -vlanhwtag solves the latter, but this doesn't really help, because VID filtering inside the guest is no option, was just for testing. I'm running stable/11 as of today. Is it by design that the physical vale interface must be set to promisc mode? Thanks, -harry ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [panic] netmap(4) and if_lagg(4)
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? Maybe here the problem is that if_lagg is a "metadriver", which interacts in a bad way with the emulated adapter, which needs to intercept all the packets received from the driver. Cheers, Vincenzo 2017-03-17 12:50 GMT+01:00 Harry Schmalzbauer : > Unforutantely I can't use if_lagg(4) as physical vale interface: > > lagg0: flags=8843 metric 0 mtu > 9000 > options=6403b9 VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> > ether 96:07:e9:78:c6:ac > nd6 options=29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp lagghash l2,l3,l4 > laggport: igb0 flags=1c > laggport: igb1 flags=1c > > 'vale-ctl -h vale0:lagg0' > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0xc > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80422b54 > stack pointer = 0x28:0xfe0444720740 > frame pointer = 0x28:0xfe0444720760 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (irq268: igb0:que 2) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0x805ccbc7 at kdb_backtrace+0x67 > #1 0x8058aa26 at vpanic+0x186 > #2 0x8058a893 at panic+0x43 > #3 0x808762b2 at trap_fatal+0x322 > #4 0x8087647c at trap_pfault+0x1bc > #5 0x80875b30 at trap+0x280 > #6 0x8085c6f1 at calltrap+0x8 > #7 0x8068d254 at vlan_input+0x1a4 > #8 0x80680188 at ether_demux+0x98 > #9 0x80680eaf at ether_nh_input+0x30f > #10 0x8069a725 at netisr_dispatch_src+0xa5 > #11 0x806804a6 at ether_input+0x26 > #12 0x8039a84d at igb_rxeof+0x6fd > #13 0x80399c54 at igb_msix_que+0x114 > #14 0x805528de at intr_event_execute_handlers+0xde > #15 0x80552bb6 at ithread_loop+0xc6 > #16 0x8054ffc5 at fork_exit+0x85 > #17 0x8085cc2e at fork_trampoline+0xe > > Is vale supposed to work with artificial interfaces like if_lagg? > Is it worth filing a bug report or won't it ever be possible? > > Thanks, > > -harry > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- Vincenzo Maffione ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
