I've started seeing this too.
We're both running nat/bridge gateways of some sort.
Adrian
On 21 November 2012 16:31, Rui Paulo wrote:
> I just started seeing this on r243286.
>
> lock order reversal:
> 1st 0xfe0001b40400 if_addr_lock (if_addr_lock) @
> /usr/home/rpaulo/freebsd/head/sys/
Greetings,
I just attempted a CD install of RELENG_8 on an AMD box.
The install went nearly as expected, but upon rebooting into the new
install. I ran into
trouble -- cdce0 faking MAC address. CRAP! this'll never work. My ISP
leases the DHCP
by MAC address. Now I won't be able to make an attempt
I just started seeing this on r243286.
lock order reversal:
1st 0xfe0001b40400 if_addr_lock (if_addr_lock) @
/usr/home/rpaulo/freebsd/head/sys/net/rtsock.c:1818
2nd 0x80c693f8 ifnet_rw (ifnet_rw) @
/usr/home/rpaulo/freebsd/head/sys/net/if.c:241
KDB: stack backtrace:
db_trace_self_w
On 21.11.2012 16:41, Marc Peters wrote:
Hi list,
-snip-
Doing some googling brought up a lot of tuning hints, but nothing worked
for us. We tweaked some sysctls:
kern.ipc.maxsockbuf=16777216
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=16384
net
On Wed, Nov 21, 2012 at 3:07 PM, Sergey Kandaurov wrote:
> On 21 November 2012 22:39, Garrett Cooper wrote:
>> While going through the tree trying to document all of our
>> net.inet6 sysctls, I noticed that net.inet6.ip6.rr_prune is defined,
>> but not actually used anywhere in the stack:
>>
On 21 November 2012 22:39, Garrett Cooper wrote:
> While going through the tree trying to document all of our
> net.inet6 sysctls, I noticed that net.inet6.ip6.rr_prune is defined,
> but not actually used anywhere in the stack:
>
> netinet6/ip6_var.h:VNET_DECLARE(int, ip6_rr_prune); /* router
Gleb,
Here is a patch based on my latest igb internal code, I had not yet
committed this as I
was not completely confident about the start/queueing changes, I would love
to have a
wider testing base, so anyone that wishes to test this... Its against HEAD.
It does a few things: change mq_start to
.. and there's also some SACK stuff and RTT prediction that you may be
totally running afoul of over that high latency link?
(I thought this stuff was fixed in -HEAD and -9?)
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mai
On 11/21/12 7:41 AM, Marc Peters wrote:
Hi list,
we are experiencing low throughput on interncontinental connections with
our FreeBSD Servers. We made several tests and are wondering, why this
would be. The first tests were on an IPSEC VPN between our datacenter in
DE and Santa Clara, CA. We are
While going through the tree trying to document all of our
net.inet6 sysctls, I noticed that net.inet6.ip6.rr_prune is defined,
but not actually used anywhere in the stack:
netinet6/ip6_var.h:VNET_DECLARE(int, ip6_rr_prune); /* router
renumbering prefix
netinet6/ip6_var.h:#define V_ip6_rr_p
Hi!
Firstly - please file a PR.
Secondly - there's some great tcp counters in 'netstat -sp tcp' (and
ip, and udp, and icmp.) You can zero them; netstat -sp tcp -z. I
suggest dumping them before/after and compare the values.
Adrian
On 21 November 2012 07:41, Marc Peters wrote:
> Hi list,
>
>
On 21 November 2012 00:30, Andre Oppermann wrote:
> On 21.11.2012 08:55, Adrian Chadd wrote:
>>
>> Something that has popped up a few times, even recently, is breaking
>> out of an RX loop after you service a number of frames.
>
> That is what I basically described.
Right, and this can be done ri
Hi,
I've been TAHI testing FreeBSD 7.x sources for the past couple
months and over the course of my testing via the TAHI IPv6 conformance
test, I changed the knob value from net.inet6.icmp6.nd6_useloopback=1
-> net.inet6.icmp6.nd6_useloopback=0 and ran into a slew of errors
with the addr.p2 pha
Am 21.11.2012 18:32, schrieb Marc Peters:
Hi Ben,
i don't think this is memory related, too. We used plain CLI scp ot ftp
from base, both times.
Here is the requested data:
Linux ---> FreeBSD:
root@linux:~# scp jdk-6u33-linux-x64.bin 172.16.3.10:
Password:
jdk-6u33-linux-x64.bin
On Wed, Nov 21, 2012 at 9:20 AM, Kevin Oberman wrote:
> On Wed, Nov 21, 2012 at 8:58 AM, Benjamin Villain
> wrote:
> > I don't think this is about disk or memory leak as transfering files
> locally
> > seem to work fine.
> >
> > Can you test transferring files from (and to) your Linux boxes to (
--- On Wed, 11/21/12, John Fretby wrote:
> From: John Fretby
> Subject: Re: FreeBSD boxes as a 'router'...
> To: "Victor Balada Diaz"
> Cc: freebsd-...@freebsd.org
> Date: Wednesday, November 21, 2012, 11:40 AM
> On 21 November 2012 14:57, Victor
> Balada Diaz
> wrote:
>
>
> > I think you
On 11/21/2012 05:58 PM, Benjamin Villain wrote:
> I don't think this is about disk or memory leak as transfering files
> locally seem to work fine.
>
> Can you test transferring files from (and to) your Linux boxes to (and
> from) the FreeBSD servers to check that it is not a network issue inside
On Wed, Nov 21, 2012 at 8:58 AM, Benjamin Villain
wrote:
> I don't think this is about disk or memory leak as transfering files locally
> seem to work fine.
>
> Can you test transferring files from (and to) your Linux boxes to (and from)
> the FreeBSD servers to check that it is not a network issu
Hi Gleb,
On 21/11/2012 1:26 AM, Gleb Smirnoff wrote:
Jack,
On Tue, Nov 20, 2012 at 09:19:54AM -0800, Jack Vogel wrote:
J> > I'd suggest the following code:
J> >
J> > if (m)
J> > drbr_enqueue(ifp, txr->br, m);
J> > err = igb_mq_start_loc
I don't think this is about disk or memory leak as transfering files locally
seem to work fine.
Can you test transferring files from (and to) your Linux boxes to (and from) the
FreeBSD servers to check that it is not a network issue inside your DCs.
King regards,
--
Ben
Mehmet Erol Sanlit
On Wed, Nov 21, 2012 at 7:41 AM, Marc Peters wrote:
> Hi list,
>
> we are experiencing low throughput on interncontinental connections with
> our FreeBSD Servers. We made several tests and are wondering, why this
> would be. The first tests were on an IPSEC VPN between our datacenter in
> DE and
Hi list,
we are experiencing low throughput on interncontinental connections with
our FreeBSD Servers. We made several tests and are wondering, why this
would be. The first tests were on an IPSEC VPN between our datacenter in
DE and Santa Clara, CA. We are connected with two gigabit uplinks in
eac
Andre
I'll try to do it today or next monday when I get back from vacation . They
are all hp branded nic's . I ordered them with in the last few years to use in
place of bce nic's on the main boards of hp servers .
---
On Nov 14, 2012, at 5:31 AM, Andre Oppermann wrote:
> Hello
>
> I cur
On 21.11.2012 09:53, Luigi Rizzo wrote:
On Wed, Nov 21, 2012 at 12:36 AM, Andre Oppermann wrote:
On 21.11.2012 09:04, Luigi Rizzo wrote:
The only adjustment i'd suggest to your scheme, if possible, is to add
some control (as it existed in the old polling architecture) to make sure
that users
On Wed, Nov 21, 2012 at 12:36 AM, Andre Oppermann wrote:
> On 21.11.2012 09:04, Luigi Rizzo wrote:
>
>> On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann
>> wrote:
>>
>>> ...
>>
>> very cool. this seems similar to NAPI.
>>
>
> I've heard about NAPI but haven't looked at it. So I'm not sure how
On 21.11.2012 09:04, Luigi Rizzo wrote:
On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann wrote:
On 21.11.2012 03:16, khatfi...@socllc.net wrote:
I may be misstating.
Specifically under high burst floods either routed or being dropped by pf
we would see the system
go unresponsive to user-le
On 21.11.2012 08:55, Adrian Chadd wrote:
Something that has popped up a few times, even recently, is breaking
out of an RX loop after you service a number of frames.
That is what I basically described.
During stupidly high levels of RX, you may find the NIC happily
receiving frames faster tha
On Tue, Nov 20, 2012 at 11:32 PM, Andre Oppermann wrote:
> On 21.11.2012 03:16, khatfi...@socllc.net wrote:
>
>> I may be misstating.
>>
>> Specifically under high burst floods either routed or being dropped by pf
>> we would see the system
>> go unresponsive to user-level applications / SSH for
28 matches
Mail list logo
