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 be down, and constantly outputting the
following me
On 23 Mar 2017, at 9:02, Andrey V. Elsukov wrote:
On 20.03.2017 03:46, Mike Karels wrote:
The context has gotten messy here, so I’m going to break down and
top-post.
I started review https://reviews.freebsd.org/D10059 with a fix for
the
reference-count leak.
It changes the semantics so on
On Fri, Mar 24, 2017 at 5:48 PM, Özkan KIRIK wrote:
> Hi again,
> This patch works perfectly also.
> Thank you so much.
> Is it possible to commit this patch to repo?
>
https://svnweb.freebsd.org/changeset/base/315877
>
> On Thu, Mar 23, 2017 at 10:57 PM, Ermal Luçi wrote:
>
>>
>>
>> On Thu, M
On 03/24/2017 16:53, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER
SCIENCE CORP] wrote:
It looks like netmap is there; however, is there a way of figuring out
if netmap is being used?
If you're not running netmap-fwd or some other netmap application, it's
not being used. You have just 1 txq/
Hi again,
This patch works perfectly also.
Thank you so much.
Is it possible to commit this patch to repo?
On Thu, Mar 23, 2017 at 10:57 PM, Ermal Luçi wrote:
>
>
> On Thu, Mar 23, 2017 at 12:16 PM, Özkan KIRIK
> wrote:
>
>> Ermal thank you again,
>> It compiles but pf still says that "pfctl: e
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218062
Terry Kennedy changed:
What|Removed |Added
Resolution|--- |FIXED
Status|New
It looks like netmap is there; however, is there a way of figuring out
if netmap is being used?
root@router1:~ # dmesg | grep cxl
cxl0: on t5nex0
cxl0: Ethernet address: 00:07:43:2c:ac:50
cxl0: 16 txq, 8 rxq (NIC)
vcxl0: on cxl0
vcxl0: netmap queues/slots: TX 2/1023, RX 2/1024
vcxl0: 1 txq, 1 rx
On 03/24/2017 16:07, Caraballo-vega, Jordan A. (GSFC-6062)[COMPUTER
SCIENCE CORP] wrote:
At the time of implementing the vcxl* interfaces we get very bad results.
You're probably not using netmap with the vcxl interfaces, and the
number of "normal" tx and rx queues is just 2 for these interfac
Hello,
I am trying to compile netmap-fwd from git
(https://github.com/Netgate/netmap-fwd) on a Dell PE 530 with -CURRENT
updated from today (03/24/17). With the dependencies installed ( # pkg
install libucl libevent2 ) I run make and get the following error
followed by 8 warnings:
cc -O2 -fPIC -g
At the time of implementing the vcxl* interfaces we get very bad results.
packets errs idrops bytespackets errs bytes colls drops
629k 4.5k 066M 629k 066M 0 0
701k 5.0k 074M 701k 074M 0 0
On 03/23/2017 19:39, Somayajulu, David wrote:
Hi All,
I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to HEAD.
The patch generated using "svn diff" is about 22Mb. Per gnn's advice I have tried to
submit the patch via Phabricator at https://reviews.freebsd.org/differential/diff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218062
--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:
Author: erj
Date: Fri Mar 24 18:28:48 UTC 2017
New revision: 315916
URL: https://svnweb.freebsd.org/changeset/base/315916
Log:
ixgbe(4): Re-add mutex lock call
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
wblock accepted this revision.
wblock added a comment.
This revision has a positive review.
One suggestion, but looks good otherwise. Thank you!
INLINE COMMENTS
> ng_pppoe.4:115
> +.Qq Li 0x ,
> +eg.
> +.Qq Li 0x6d792d746167
Would prefer "like" or "for example" to exempli gratia here (see
Hi,
Hope you had a chance to review my previous email. Please let me know if
you would be interested in reviewing a sample of your target audience.
Thank you, hope to hear from you.
Thanks & regards,
Elizabeth Walker
Marketing Analyst
_
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218062
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218041
Sean Bruno changed:
What|Removed |Added
Assignee|freebsd-net@FreeBSD.org |sbr...@freebsd.org
--
You are receiv
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218005
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211643
--- Comment #5 from Kurt Jaeger ---
still open: Should the interface autonegotiate 10g ?
It only works with
ifconfig ix0 media 10gbase-t
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211643
--- Comment #4 from Kurt Jaeger ---
Supermicro provided a firmware upgrade for the ethernet interface firmware,
tested with ubiquity, looks good.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206567
Greg V changed:
What|Removed |Added
CC||greg@unrelenting.technology
--- Comment #
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
On 24 Mar 2017, at 2:39, Somayajulu, David wrote:
Hi All,
I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to
HEAD.
The patch generated using "svn diff" is about 22Mb. Per gnn's advice
I have tried to submit the patch via Phabricator at
https://reviews.freebsd.org/differenti
27 matches
Mail list logo
