Old Synopsis: immediate crash after the start of ipsec processing
New Synopsis: [ipsec] immediate crash after the start of ipsec processing
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jan 23 08:29:29 UTC 2012
Responsible-Chan
The following reply was made to PR kern/164400; it has been noted by GNATS.
From: "Eugene M. Zheganin"
To: bug-follo...@freebsd.org, eug...@zhegan.in
Cc:
Subject: Re: kern/164400: immediate crash after the start of ipsec processing
Date: Mon, 23 Jan 2012 14:22:59 +0600
I've re-read it and I f
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
Hi,
it looks the changes from r226701, which enable dc(4) to handle ALi/ULi
M5261/M5263 ethernet controllers, are present in head, stable/7 and
stable/8, but not in release/9.0.0, as there's no mention in the release
notes, I don't see any of the changes in the repository, and the device
isn'
On Jan 20, 2012, at 10:32 AM, Nikolay Denev wrote:
> On Jan 15, 2012, at 9:52 PM, Nikolay Denev wrote:
>
>> On 15.01.2012, at 21:35, Andrey Zonov wrote:
>>
>>> This helped me:
>>> /boot/loader.conf
>>> net.inet.tcp.hostcache.hashsizee536
>>> net.inet.tcp.hostcache.cachelimit66080
>>>
>>> Act
The following reply was made to PR kern/144917; it has been noted by GNATS.
From: "K. Macy"
To: r...@net1.cc
Cc: bug-follo...@freebsd.org
Subject: kern/144917: [flowtable] [panic] flowtable crashes system [regression]
Date: Mon, 23 Jan 2012 21:50:08 +0100
Have you tested this workload on 9.0 wi
The following reply was made to PR kern/146792; it has been noted by GNATS.
From: "K. Macy"
To: n...@gtelecom.ru
Cc: bug-follo...@freebsd.org
Subject: kern/146792: [flowtable] flowcleaner 100% cpu's core load
Date: Mon, 23 Jan 2012 21:48:09 +0100
Have you tested this workload with 9.0 with the
Hi!
I found a comment in the code:
/*
* This node has all kinds of stuff that could be screwed by SMP.
* Until it gets it's own internal protection, we go through in
* single file. This could hurt a machine bridging beteen two
* GB ethernets so it sho
e entries, which was more than the default limit of
15K I was running with before.
The bug is real. Please try the attached patch to fix the issue for IPv4.
It's against current but should apply to 8 or 9 as well.
--
Andre
http://people.freebsd.org/~andre/tcp_subr.c-pmtud-20120123.diff
Hello,
This message has been sent to freebsd-performance@ but got
the information that should contact also with freebsd-net@.
We use FreeBSD as sniffer (libpcap programs) and we experience
performance problems when incoming traffic is greater than 7.5Gbps/s.
If we check 'top' we see that first
Hi,
On Fri, Jan 20, 2012 at 8:32 AM, Dmukha Nikolay wrote:
> Hello.
> Please, help me to setup this sheme:
> ***
> comp1 comp2
> | |
> | |
> dgs3627g(24)---(12)d
Hi,
I dont see the freebsd ip stack processing ICMP_UNREACH_NEEDFRAG where
protocol is ESP/AH. ( The ipsec4_common_ctlinput is not implemented). If
this is right, how is the PMTU discovery done for ipsec traffic or is it
that freebsd is not doing that?.
Thanks
Reji
_
12 matches
Mail list logo
