On Wed, 29 Aug 2012 22:31:25 +0400, Lev Serebryakov wrote:
Hello, Michael.
You wrote 29 ??? 2012 ?., 19:01:08:
I have interface (vr1), most of traffic on which is PPPoE. I have ipfw
firewall, which splits traffic by interfaces via:
add 2000 skipto 5000 all from any to
On 30 August 2012 04:23, Vijay Singh vijju.si...@gmail.com wrote:
Is there any reason why sorele() needs the accept lock to be held?
231 #define sorele(so) do {
\
232 ACCEPT_LOCK_ASSERT();
Hello, Ian.
You wrote 30 августа 2012 г., 10:23:56:
Yep, I'll collapse my two-rule chains in one rule.
IS I guess if the issue persists, we may need to see more of your ruleset.
Not a problem at all, here it is:
http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw
IS Hmm, you shouldn't see
On Wednesday, August 29, 2012 4:45:29 pm Navdeep Parhar wrote:
On 08/29/12 10:30, Vijay Singh wrote:
All, I am seeing this warning on my 8.2 based system.
taskqueue_drain with the following non-sleepable locks held:
exclusive rw lle (lle) r = 0 (0xff0014dc9110) locked @
On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov l...@freebsd.org wrote:
Hello, Ian.
You wrote 30 августа 2012 г., 10:23:56:
Yep, I'll collapse my two-rule chains in one rule.
IS I guess if the issue persists, we may need to see more of your ruleset.
Not a problem at all, here it is:
On Wed, Aug 29, 2012 at 08:01:50AM -0700, Michael Sierchio wrote:
On Wed, Aug 29, 2012 at 8:01 AM, Michael Sierchio ku...@tenebras.com wrote:
ip from any to any in recv vr0
any here is also not appropriate...
it is just sintactic sugar, from any to any corresponds
is just printed
On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote:
On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov l...@freebsd.org wrote:
Hello, Ian.
You wrote 30 ??? 2012 ?., 10:23:56:
Yep, I'll collapse my two-rule chains in one rule.
IS I guess if the issue persists, we may
Hi,
I'm using following devices:
bge0 - NetLink BCM57780 Gigabit Ethernet PCIe
ndis0 - BCM43225 802.11b/g/n
As far as I've tested it, each of them work fine for itself.
I want to aggregate them using lagg in failover mode as explained here[1][2].
But when I remove the wire (wireless
On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote:
On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov l...@freebsd.org wrote:
Hello, Ian.
You wrote 30 августа 2012 г., 10:23:56:
Yep, I'll collapse my two-rule chains in one rule.
IS I guess if the issue persists, we may
On Mon, Aug 27, 2012 at 7:45 AM, Dustin J. Mitchell dus...@v.igoro.us wrote:
On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy pe...@rulingia.com wrote:
On 2012-Aug-26 08:12:51 -0400, Dustin J. Mitchell dus...@v.igoro.us
wrote:
On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell dus...@v.igoro.us
On Thu, Aug 30, 2012 at 01:11:58PM +0400, Lev Serebryakov wrote:
Hello, Ian.
You wrote 30 августа 2012 г., 10:23:56:
Yep, I'll collapse my two-rule chains in one rule.
IS I guess if the issue persists, we may need to see more of your ruleset.
Not a problem at all, here it is:
01.09.2012 01:07, YongHyeon PYUN пишет:
It would be interesting to know whether there is any difference
before/after taskq change made in r235334. I was told that taskq
conversion for vr(4) resulted in better performance but I think
taskq shall add more burden on slow hardware.
Pre-r235334
In previous letter I've described my attempts to try vr(4) from HEAD.
Now I'd like to explain why I've tried it.
The problem is that stock vr(4) from 8.3-STABLE/i386 has serious issues for my
system.
I have home router with two vr interfaces, vr0 is for LAN (IPoE) and vr1 is for
WAN
31.08.2012 12:19, Eugene Grosbein пишет:
With HEAD driver, for same test LA pikes to 8 and higher and it takes up to
10 seconds
for userland applications like shell or screen(1) to respond to physical
console events:
last pid: 1335; load averages: 8.27, 4.05, 2.04up
14 matches
Mail list logo
