See bug: kern/121955
I have received panics with the same configuration of ipfw and
dummynet in 6.3, 7.0-RELEASE, 7.0-STABLE.
But I don't received it in 6.2.
In all panics was corrupted stack.
I use mpd-5.0 for pptp connections and shape traffic with ng_car or
dummynet for different clients.
In
See bug: kern/121955
I have received panics with the same configuration of ipfw and dummynet in 6.3,
7.0-RELEASE, 7.0-STABLE.
But I don't received it in 6.2.
In all panics was corrupted stack.
I use mpd-5.0 for pptp connections and shape traffic with ng_car or dummynet
for different clients.
In
Trouble fixed by updating to FreeBSD 7.0-STABLE. Now:
# uptime
1:14PM up 4:41, 2 users, load averages: 0.00, 0.00, 0.00
Let's look, that will be further.
-- реклама ---
Научим каждого зарабатывать на колебаниях курсов валют.
Запись на
I can not answer this for sure but trying it out is for free :) but it will
not help here I guess
Even if I believe the problem is in ipfw you probably should try to isolate
if
it is in any means related to mpd, probably you can run your ppp from another
server and run ipfw only on
I did tuning, that was in my other letters (net.isr.direct=0, tuning
in /boot/loader.conf)
And received panic after 12 minutes:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xf2a9864
fault code = supervisor read, page not present
After I set net.isr.direct=0 and others:
net.inet.ip.fw.one_pass=0
net.inet.ip.fw.autoinc_step=1
net.isr.direct=0
net.inet.ip.intr_queue_maxlen=1024
net.inet.ip.dummynet.hash_size=256
net.inet.ip.dummynet.expire=0
net.inet.ip.dummynet.max_chain_len=64
net.graph.maxdgram=128000
The following reply was made to PR kern/121955; it has been noted by GNATS.
From: Alexander Shulikov [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
Date: Mon, 24 Mar 2008 10:07:14 +0200
I receive new dump
(but it was added after panic's)
Other thing, that I want to try - net.isr.direct - 0? May be it
temprorary resolved problem, because packet will be going to queue for
processing.
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 12:11:44 Alexander Shulikov wrote:
In real script I have
