Thanks Navdeep,
I'll make sure we update firmware in future.
Joe Jones
On 25/04/17 00:55, Navdeep Parhar wrote:
On 04/19/2017 08:31, Joe Jones wrote:
Hi Navdeep,
I already got rid of the hw.cxgbe.num_vis line in loader.conf when I
rebooted this morning.
dev.t5nex.0.firmware_version: 1.15.
On 04/19/2017 08:31, Joe Jones wrote:
Hi Navdeep,
I already got rid of the hw.cxgbe.num_vis line in loader.conf when I
rebooted this morning.
dev.t5nex.0.firmware_version: 1.15.37.0
I tried this exact firmware and was able to reproduce the problem. This
appears to be a firmware bug that h
Hi Navdeep,
I already got rid of the hw.cxgbe.num_vis line in loader.conf when I
rebooted this morning.
dev.t5nex.0.firmware_version: 1.15.37.0
On 19/04/17 15:37, Navdeep Parhar wrote:
What is the firmware version?
# sysctl dev.t5nex.0.firmware_version
I'll try to repeat the experiment wi
uname -a
FreeBSD goose2 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11
08:48:40 UTC 2017
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
The card is a 'T520-SO Unified Wire Ethernet Controller'
I ran the following with dtrace running in a separate window
ifconfi
On Mon, Apr 17, 2017 at 11:00:38AM +0100, Joe Jones wrote:
> Hi Navdeep
>
> running "ifconfig up" and then "ifconfig promisc" works. Running "ifconfig
> promisc" and then "ifconfig up" does not work. Running "ifconfig up promisc"
> together does work. Running "ifconfig promisc up" does not work.
Hi Navdeep
running "ifconfig up" and then "ifconfig promisc" works. Running
"ifconfig promisc" and then "ifconfig up" does not work. Running
"ifconfig up promisc" together does work. Running "ifconfig promisc up"
does not work.
The combination that does not work leaves the interface in a sta
On Fri, Apr 14, 2017 at 04:10:59PM +0100, Joe Jones wrote:
> Hi Navdeep,
>
> I think I have found a driver bug. Earlier today I set up the switch I'm
> using so that two of the ports mirror the traffic on one of the other ports.
> We are planning on using a similar setup to allow packet tracing wi
Hi Navdeep,
I think I have found a driver bug. Earlier today I set up the switch I'm
using so that two of the ports mirror the traffic on one of the other
ports. We are planning on using a similar setup to allow packet tracing
without stressing the boxes our application is running on any more
On Fri, Mar 24, 2017 at 6:40 AM, Joe Jones wrote:
> Hello Navdeep,
>
> ...
>
> We were using our own MACs, we can fix the problem by using the mac from the
> vcxl interface. Should we not be able to capture all traffic on the
> interface regardless of what destination MAC it has.
You should, but
Hi Joe,
From your description it's pretty clear that you hit the FreeBSD11 bug
that is now fixed in 11.0-stable (in addition to the upstream netmap
version on github).
The fix was committed in r312783.
Cheers,
Vincenzo
2017-03-24 14:50 GMT+01:00 Joe Jones :
> Hi Vincenzo,
>
> we can get rid
Hi Vincenzo,
we can get rid if the panic if we compile the kernel without netmap,
then load an up to date netmap as a module. We can live with that for now.
Some time last year before Free BSD 11 was branched from head, we
compiled a checkout and it worked without problem on the same hardwar
Hello Navdeep,
This is the panic from 11.0-RELEASE-p8, I think p0 panicked in the same
generic_netmap_txsync function.
Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 0a
fault virtual address= 0x1
fault code= supervisor read data, page not present
instruction po
Hi Joe,
There was a fix for a panic in emulated mode that was applied stable/11
branch, so I guess it also ended up into FreeBSD-11.0-STABLE.
I don't know whether the same fix ended up into in 11.0-RELEASE-p8 (I'm not
familiar with FreeBSD releasing process, sorry!).
Or maybe this panic happens
Hi Vincenzo,
I just tried with that sysctl set to 2, I get a similar looking panic
to before
Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 0e
fault virtual address= 0x1
fault code= supervisor read data, page not present
instruction pointer= 0x20:0xfff
Your netmap application should be using the 'vcxl' interface, not the
cxl interface. Even though they share a physical port they have
different MAC addresses and are totally autonomous. The peer should
use the vcxl interface's MAC if it wants to reach the netmap
application.
Do you have the pani
Hi,
You could try to use netmap in emulated mode (sysctl
dev.netmap.admode=2). If this works, at least you know that the problem is
in the cxgbe netmap support and not in the netmap core itself.
Cheers,
Vincenzo
2017-03-23 14:00 GMT+01:00 Joe Jones :
> Hello,
>
> We have a T520-SO and have m
Hello,
We have a T520-SO and have made a new install of 11.0, to begin with the
box would panic every time we tried to switch the card into netmap mode.
So we recompiled the kernel with netmap removed, then compiled the
netmap kernel module from github, as this in our experience generally
lea
17 matches
Mail list logo
