:OK, so far it is working fine. We are doing every network stress test
:(DDoS, flood ping etc.) and it works just fine, I see no errors in
:syslog or anywhere else. I will force the traffic of our dormitory
:through it tonight and see what happens. :-)
:Thank you, guys, your help is highly
On 9/21/06, Sepherosa Ziehau [EMAIL PROTECTED] wrote:
static int
bridge_pfile(...)
{
...
KASSERT(M_WRITABLE(*mp), (%s: modifying a shared mbuf, __func__));
...
}
I don't think M_WRITABLE() applicable to DFLY here, since if *mp is
from driver(e.g. sk(4)), which supports jumbo frames,
:I don't think M_WRITABLE() applicable to DFLY here, since if *mp is
:from driver(e.g. sk(4)), which supports jumbo frames, M_WRITABLE() is
:always == 0:
:1) Driver allocates jumbo frame buffer and turns on M_EXT in mbuf.m_flags
:2) since M_EXT is turned on, while M_EXT_CLUSTER is off,
:
:Matthew Dillon wrote:
:
: Hmm. All right, go ahead and nuke it.
:
:So should I just plain remove that assertion from if_bridge.c?
:Should the last patch be left there or should I revert to the
:original/official version of the sk(4) driver's source?
Leave the patch in and remove
On Thu, Sep 21, 2006 at 08:54:27AM -0700, Matthew Dillon wrote:
What we really need to do here is, well, two things. First, both Jeff
and I have been wanting to get rid of all the ntoh and hton conversions
being done inside the mbuf itself... there are so many layers that it
:..
: is in host order and when it is in network order. It just needs to
: stay in network order. Second, we need to abstract the m_sharecount()
: function so it works with non-cluster extensions.
:
:I was thinking about that as well. What about copying (!) the
:interesting fields
Matthew Dillon wrote:
Leave the patch in and remove the assertion, and lets see how that
works.
OK, so far it is working fine. We are doing every network stress test
(DDoS, flood ping etc.) and it works just fine, I see no errors in
syslog or anywhere else. I will force the traffic
Gergo Szakal wrote:
Sepherosa Ziehau wrote:
mmm, try the attachment :-)
http://rnrdoctor.sytes.net/dfcrash/crash1/
Please also provide the corresponding kernel.1 file from /var/crash.
Sascha
--
http://yoyodyne.ath.cx
http://rnrdoctor.sytes.net/dfcrash/crash1/
Made 2 artistic photos, the 1st one shows even the command that seems to
trigger it (however it comes after a while spontaneously anyway).
FWIW, I have uploaded fresh dumps as well.
Thanks again for bothering with my issue!
Scott Ullrich wrote:
I am coming into this a bit late. What version is this again?
This is 1.6-release (snapshot from yesterday, got the tarball from
chlamydia) and applied the attached patch made by Sepherosa.
diff -ur sk_rel/if_sk.c sk_mod/if_sk.c
--- if_sk.c 2006-09-18
Sepherosa Ziehau wrote:
The problem may be caused by that second skc's skc_probe()
reinitializes a global sk_serializer
Please try the attached patch.
Thanks, but the patch fails to apply successfully against the 20060912
snapshot of 1.6-release, here is what I get:
Bill Hacker wrote:
We've all been (still are) there w/r the economics.
But when funds are needed elsewhere, and 'run what hardware you have' is
mandatory, then DFLY would not be the best choice.
For that to change sooner, rather than someday-maybe, best to leave the
'scarce resource' DFLY
Gergo Szakal wrote:
Bill Hacker wrote:
We've all been (still are) there w/r the economics.
But when funds are needed elsewhere, and 'run what hardware you have'
is mandatory, then DFLY would not be the best choice.
For that to change sooner, rather than someday-maybe, best to leave
the
Sorry, but I don't want to continue this type of discussion.
Of course I will test by putting the HDD into another computer and fire
it up, and see if the problem occurs there as well (no time now, need to
get a UP kernel, as the SMP one does not like UP machines :-P). Thought
I could help in
Gergo Szakal [EMAIL PROTECTED] wrote:
[...]
If you can prove that the problem is caused by the machine itself,
please do it (I don't consider statements like 'It's old cr*p' as
proof), else let's wait for someone else who dug into the problematic
code. Sorry for being a bit harsh, no
cc -c -O -pipe -mtune=pentiumpro -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -ansi -g -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/../include -I/usr/obj/usr/src/sys/SMP
-I/usr/src/sys/dev/acpica5
The more computer DF fits, the more people get interested in the
project, but I doubt the dev team is interested by the number of users -
however it is undoubtedly a motivating factor.
Bill Hacker wrote:
But I *still* say it is 'not kind' to the DFLY project - already struggling
with
scant resources and tough goals, to distract or sidetrack it even a little
bit
to chase aging hardware flakiness - especially when there are other usable
OS
that can make good
:-)
A new crash,right when starting the network.
http://rnrdoctor.sytes.net/dfcrash/
(bug1.jpg and bug2.jpg)
Gergo Szakal wrote:
:-)
A new crash,right when starting the network.
would it be possible for you to pull a kernel dump? it makes it so much more
easy to track down.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\
Work - Mac +++ space for low
Oh, forgot: I am using another DF box with bridging (an xl and an rl
NIC) and it has been running for like 2 weeks with no problem.
Matthew Dillon wrote:
I'm not sure why the mbuf is shared at that point,
but the assertion is definitely in the wrong part of the code path.
I am going to move the assertion. Could you try that patch and
tell me if it works for compiled-in bridging?
No, it does not seem to
Bill Hacker wrote:
Might sound harsh, but you'd be time and money (electric bill alone)
ahead to scrap that PII/450 antique.
You are absolutely right, if this were an option, I'd do it, but this is
not my machine, a friend asked me to set this up as a filtering bridge
for him, and I wanted
Bill Hacker wrote:
*BSD folk, unlike Penguins, are generally agnostic.
Use whatever is the best 'fit for the purpose'.
Using only 1 processor is not enough. An AMD K62/450 is not enough for
the amount of traffic going through. theoretically, DF *should* run on
this flawlessly, that's why
Gergo Szakal wrote:
Bill Hacker wrote:
*BSD folk, unlike Penguins, are generally agnostic.
Use whatever is the best 'fit for the purpose'.
Using only 1 processor is not enough. An AMD K62/450 is not enough for
the amount of traffic going through. theoretically, DF *should* run on
this
Upping this old topic. If the 'bridge' pseudo-device is compiled into
the kernel, there are mysterious lwkt panics (I cannot send a backtrace,
does the system store them anywhere?) which disappear if I comment the
appropriate line and build a quickkernel and load the if_bridge module
instead
Matthew Dillon wrote:
Do you get a db prompt ? Can you do a backtrace ('trace') ? Do you
have a digital camera that you can use to take a picture of the console
screen before and after doing the backtrace ?
Yes, yes and yes. I will post ASAP. it is complaining about modifying a
Oops, forgot to post to the list, cause Matt CC'ed me and I replied to
his mail directly.
http://rnrdoctor.sytes.net/dfcrash/
Should I fill a bugreport instead?
:
:Oops, forgot to post to the list, cause Matt CC'ed me and I replied to
:his mail directly.
:
:http://rnrdoctor.sytes.net/dfcrash/
:
:Should I fill a bugreport instead?
No, that's ok. I'm not sure why the mbuf is shared at that point,
but the assertion is definitely in the wrong part
Ehe. I was stupid, should1ve written bridge instead of if_bridge. It
compiled, and works fine. I only have 1 question remaining: to speed up
building pkgsrc packages, I included these 2 options in
/usr/pkg/etc/mk.conf:
WRAPPER_UPDATE_CACHE=no
MAKE_FLAGS+=-j2
Is this safe (or recommended) to
I have a dual PII/450 system. I would like to run it as a filtering
bridge on a gigabit LAN. I have 2 Planet ENW-9607 (Marvell chip - sk) cards.
I have added the following extra options in addition to what is in GENERIC:
--- config start ---
# Bridging support
pseudo-device
31 matches
Mail list logo
