rlying sx lock mutex is
relatively short, in most cases the performance advantage of using the
sx lock is noticable. However, if the window of the original mutex is
also short (compared to the sx lock window), then I wonder if it is
worth it. The sx lock is really only designed for optimizing
ket looks like.
What are you trying to do, exactly?
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_ext() used to be there, iirc), you will see various
points in time where we had this wrong.
> --
> Doug White| FreeBSD: The Power to Serve
> [EMAIL PROTECTED] | www.FreeBSD.org
--
Bosko Milekic
[EMAIL P
latile u_int *)(m->m_ext.ref_cnt);
>
> I'm currently testing that.
>
> Kris
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
P.S.: Not sure if this is related:
http://www.mail-archive.com/bk-commits-24@vger.kernel.org/msg00136.html
On Tue, 1 Mar 2005 18:04:27 -0500, Bosko Milekic
<[EMAIL PROTECTED]> wrote:
> On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin <[EMAIL PROTECTED]> wrote:
> > On Monday 2
or overruns of the reference count (those
may only cause leaking of the cluster).
Furthermore, the above code has been around in that form for some time
now and in fact the loop was probably entered *more* often in the past
(before the 'dofree' variable was introduced there). Since when are
y
at "is a
> general-purpose tool for emulating performance dynamics in IP
> networks".
>
> Cheers
>
> - aW
If you are open to commercial [non-free] solutions, take a look at
OPNet Modeler (http://www.opnet.com/products/modeler/home.html).
--
Bo
> /"\ Best regards, | [EMAIL PROTECTED]
> \ / Max Laier | ICQ #67774661
> X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
> / \ ASCII Ribbon Campaign | Against HTML Mail and News
--
Bosko Milekic
[EMA
interrupts, more packets means more interrupts, always (assuming your
card's coalescing abilities have been exhausted, i.e., very
high pps, all the time), and more interrupts means more latency. In
the case of polling, more packets does not mean more interrupts, and
the system will pro
n taking some of it on.
Oh, and keep me in the CC; I have no idea if I'm
subscribed to these lists anymore. You should also follow
up to this thread on -net and not on -hackers (trim
-hackers from CC in the future). Thanks and happy
hacking!
Regards,
--
Bosko Mil
On Mon, Aug 04, 2003 at 01:05:35PM -0700, Steve Francis wrote:
> Bosko Milekic wrote:
>
> >Actually, he's not running out of address space here; he's probably
> >
> > run out of free pages and could not block to wait for them.
> >
> >
> &g
ed, it
> probably didn't hurt your system much.
Actually, he's not running out of address space here; he's probably
run out of free pages and could not block to wait for them.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * htt
and
kva space will be reserved for them. As I said, the kva used for the
pcbs will come out of kmem_map. If you're allocating the pcbs, then
you're not wasting the kva. When you free them, the kva and memory
stayed reserved, but this is required for type stable storage, which
Synopsis: mbuf-related kernel panic (sbappendaddr)
Responsible-Changed-From-To: freebsd-net->bmilekic
Responsible-Changed-By: bmilekic
Responsible-Changed-When: Wed Jul 16 08:16:48 PDT 2003
Responsible-Changed-Why:
I'll look into this. It seems that the problem is not
directly due to lack of mbu
Synopsis: ether_input casts m_hdr to mbuf and causes bpf_mtap to access random data
Responsible-Changed-From-To: freebsd-net->bmilekic
Responsible-Changed-By: bmilekic
Responsible-Changed-When: Wed Jul 16 08:07:36 PDT 2003
Responsible-Changed-Why:
I'll follow-up on this.
http://www.freebsd.org/c
sumers returns that type of pcb back to the
respective zone.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/ma
useful thing that could be rolled back
> into the source tree? I could make this a kernel option or a tunable sysctl
> variable.
>
> thanks
>
> Scot Loach
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.c
re not done. :-) We can't simply unwind Giant
just anywhere yet because there is still code in other layers that
requires Giant.
Cheers,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
But your driver needs to support it. Currently, the only driver
that does is if_ti in src/sys/pci/if_ti*.[ch]
sendfile(2) is also zero-copy for the most part (for the file part).
That's been in use for a long time. src/sys/kern/uipc_syscalls.c
Regards,
--
Bosko Milekic *
moving buckets to the general cache... see if that's really
happening... The low watermark doesn't affect anything right now.
Can you give me more details on the exact type of test you're running?
Let's move this to -current instead of -current and -net please (fee
r we're in a
starvation situation. The only thing to be done, possibly, is make
the routine smaller by moving those couple of actions to seperate
routines, but I'm not clear that this is very useful, given that
mb_free()'s usage is restricted to only inside subr_mbuf.c
>
commit log clearly states that the new
watermarks do nothing for now. I have a patch that changes that but I
haven't committed it yet because I left for vacation last Sunday and I
only returned early this Monday. Since then, I've been too busy to
clean up and commit it. In ab
CE_POLLING and
> HZ=2000.
>
> --
> CHOI Junho <http://www.kr.FreeBSD.org/~cjh> KFUG
> FreeBSD Project Web Data Bank
> Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Tue, Jan 07, 2003 at 06:09:23PM -0800, Nate Lawson wrote:
> On Tue, 7 Jan 2003, Bosko Milekic wrote:
> > On Tue, Jan 07, 2003 at 02:15:02PM -0800, Nate Lawson wrote:
> > Not to mention that
> > it's totally undefined and random.
>
> Well, you have the
it
universally would be too much in my opinion, especially given that
some hardware takes care of it itself.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
rnel option and it would be nice to avoid this
> problem in the future.
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
o bufs I still maintain that we should keep the counter
for them at the end of the buf because the math works out (see my post
in that thread with the math example) and because their total size is
not a power of 2 anyway. They'll also be more randomly spread out and
use more cache slots.
stra
> John D. Polstra & Co., Inc. Seattle, Washington USA
> "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
Thanks for the cool infos. and feedback.
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
me time. As far as
I know, you can't (intuitively) figure out a way to do both of these
atomically. i.e., maybe you'll set your next's back pointer to whatever
you have in `back' but then your `back' guy will set your back pointer
to whatever he has in `back' and the
LOT;
2) we would probably run into lock order reversal problems.
I see now what Alfred meant when he made his original comment.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
I'm sorry. I should have waited before hitting the "send" button.
I've had a long and [shitty] day and I shouldn't have blew it off here.
Sorry.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
riendly."
[...]
I think it's almost clear now that there are, in fact, no SMP issues
with it (we don't do per-cluster locking, or anything ridiculous like
that), so unless Alfred has the reason again, I'll consider that method
again instead. Thanks for the constructive feedb
er suggestion to make? What do *you* suggest we do
with the external ref. counts? Please, spare me the flame bait. I
wasn't being confrontational when I answered Luigi's post and I don't
need anyone turning this into something confrontational. Thanks.
> Kelly
>
> -
rs and structures only the kernel knows about.
> Thanks.
>
> JFRH
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
discussing jumbo bufs that we would probably end up
allocating them in chunks of 3 or 4 at a time. So that would mean at
least ~9 page 'holes' in the address space from which clusters are
allocated, so that would mean ~18 counters wasted, at least, for every
hole. With the numbe
it's the first reason that
compells me to stash them at the end of the cluster.
> cheers
> luigi
>
> On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote:
> >
> > Hi,
> >
> > Right now, in -CURRENT, there is this hack that I introdu
of this Email is to find out if anyone has concrete
information on why this wouldn't work (if they think it wouldn't).
So, if someone has an example of some broken code somewhere that
wouldn't like this, please point it out to me now before I go off and
do this again and co
On Mon, Jul 08, 2002 at 12:37:57PM -0500, Jonathan Lemon wrote:
> On Mon, Jul 08, 2002 at 10:29:37AM -0700, Luigi Rizzo wrote:
> > On Mon, Jul 08, 2002 at 01:22:14PM -0400, Bosko Milekic wrote:
> > ...
> > > > > Speaking of competition, someone should go look at t
o mind was seeing that discussion; but now I
can't find it through the mailing list search thing on the website.
:-(
> cheers
> luigi
>
> > Sounds interesting.
> >
> > Mike "Silby" Silbersack
Cheers,
--
Bosko Milekic
[EMAIL PROTECT
gather DMA?
> John
> --
> John Polstra
> John D. Polstra & Co., Inc.Seattle, Washington USA
> "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Un
On Fri, Jul 05, 2002 at 10:45:50AM -0400, Andrew Gallatin wrote:
>
> Bosko Milekic writes:
> >
> > On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote:
> > > I think this would be fine, But we'd need to know more about the
> > > hardwa
not four?
Why would you need 4? I can absolutely guarantee that a jumbo buf
will not go over 3 pages (on i386, and 2 pages on alpha).
> Drew
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
d ensure much less
wastage but would mean that not all of them would start at page
boundaries.
> Drew
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
usable right
> now and efficiently from all contexts which run under Giant, and
> easy to upgrade when/if we need it.
>
> And, I am sorry to say... you raise some valid points, but without
> performance numbers to justify them, it is hard to tell how relevant
> they are in
On Tue, Jul 02, 2002 at 10:12:22AM -0700, Luigi Rizzo wrote:
> On Tue, Jul 02, 2002 at 01:01:35PM -0400, Bosko Milekic wrote:
> ...
> > The reason I said "seemingly" is because of the fact that I don't
> > think that it is your "grouping" of both
On Tue, Jul 02, 2002 at 08:04:23AM -0400, Bosko Milekic wrote:
>
> There are several problems with your "simple" code that make it simpler
> than what's in -CURRENT and in -STABLE and therefore yield [obviously]
> seemingly better times.
>
> 1) sleeping in
ool_now < em_pool_max &&
> m->m_next == NULL &&
> m->m_flags & M_EXT &&
> M_WRITABLE(m) ) {
> m->m_nextpkt = em_pool;
> em_pool = m;
> em_pool_now++;
> } else
> m_freem(m);
> tx_buffer->m_head = NULL;
> }
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
it.
Also, I should mention that in his original message, Luigi mentions
that MGETHDR and MCLGET are rather long macros, but in -CURRENT they
are functions so there is not really much added code cache pollution.
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe:
one.
Unfortunately, I don't know if the PIII is doing speculative
cache-loads, but it could very well be the case. If it is and if in
fact the chip does caching based on virtual addresses, then providing it
with virtually contiguous address space may yield better results. If
you try this, please let me know. I'm extremely interested in seeing
the results!
> Cheers,
>
> Drew
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
e fixes, plus several fixes that have gone into -current over the
> past week or so, the zero copy sockets code runs without any WITNESS
> warnings at all now.
>
> Ken
> --
> Kenneth Merry
> [EMAIL PROTECTED]
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
&g
I can almost guarantee
that a lot of stuff isn't going to work without a rebuild when people
decide to go from 4.x to 5.0 anyway. Placing dummy-fillers is just
annoying.
> John
> --
> John Polstra
> John D. Polstra & Co., Inc. Seattle, Wa
er.
>
> Any comments/objections?
None from here. :-)
Just the standard pointer, which you probably already know: -CURRENT
first, please.
> Thanks,
> -Archie
>
> __
> Archie Cobbs * Packet Design * http://www.packetdesign.com
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
m->m_ext.ext_size);
> + if (m->m_ext.ext_ref == NULL)
> + atomic_add_char(&mclrefcnt[mtocl(m->m_ext.ext_buf)], 1);
> + else {
> + int s = splimp();
> +
> + (*m-
On Mon, Jun 03, 2002 at 04:01:29PM -0700, Archie Cobbs wrote:
> Bosko Milekic writes:
> > Secondly, this may not be as much of a problem as you may think.
> > Particularly if you consider the m_split() case, for example. For
> > example, if you're calling m_spl
guys please stop changing the subject :-)
> >
> > Can somebody confirm that they think this bug is real/valid?
> >
> > Thanks,
> > -Archie
> >
> > __
> > Archie Cobbs * Packet Design * http://www.packetdesign.com
> >
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
an mbuf.
Agreed.
[...]
> Updated patch below.
>
> -Archie
[...]
Patch looks good.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Fri, May 31, 2002 at 12:54:39PM -0700, Julian Elischer wrote:
>
>
> On Fri, 31 May 2002, Bosko Milekic wrote:
>
> >
> > I don't remember why the ext_size here was this originally (as you
> > mention, it was imported that way), but it certainly seems
> (*(m->m_ext.ext_ref))(m->m_ext.ext_buf,
> m->m_ext.ext_size);
> - m->m_ext.ext_size = 0; /* For Accounting XX danger */
> n->m_data = m->m_data + len;
> } els
ry
problem or the dump isn't working properly (I've never heard of
anything like this before).
> Thanks,
> -Archie
>
> ______
> Archie Cobbs * Packet Design * http://www.packetdesign.com
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
uick
conclusions with all data structures right away. Instead, I propose
that we first glue-in mbuf allocations to UMA (not too difficult, given
that UMA provides an allocation routine stub). If this is done properly
[without macro-performance loss] then it should be rather trivial to
bring in new
r
but I am prepared to remove large chunks of it and instead glue-into UMA
if this can be done in a relatively clean and elegant manner which,
after looking at UMA, I've decided that it probably can.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PRO
le to have them called from a different context somewhere from
the protocol code when/if the protocol feels that they are necessary.
> R
>
> > > If we don't it seems to me the utility of the drain() fucnction is
> > > very very limited..
> > >
> > > Regards
> > >
> > > R
> > >
> > > --
> > > Randall R. Stewart
> > > [EMAIL PROTECTED] 815-342-5222 (cell phone)
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
;t it seems to me the utility of the drain() fucnction is
> very very limited..
>
> Regards
>
> R
>
> --
> Randall R. Stewart
> [EMAIL PROTECTED] 815-342-5222 (cell phone)
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ILESPERMB 128
> +#define MINAUTOFILES 1024
> +#define MAXAUTOFILES 65536
> +
> +/* Max sockets. These are set in uipc_socket2.c */
> +#define SOCKETSPERMB 64
> +#define MINAUTOSOCKETS 512
> +#define MAXAUTOSOCKETS 32000
> +
> +/* Max mbuf clusters, sendfile buffers. These are set in subr_mbuf.c */
> +#define MCLSPERMB 32
> +#define MINAUTOMCLS 512
> +#define MAXAUTOMCLS 32000
> +#define SFBUFPERMB 16
> +#define MINAUTOSFBUF 1024
> +#define MAXAUTOSFBUF 32000
> +
> +/* Number of TCP hash buckets. These are set in tcp_subr.c */
> +#define TCBHASHPERMB 8
> +#define MINAUTOTCBHASH 512
> +#define MAXAUTOTCBHASH 8192
>
> /*
> * Make this available for most of the kernel. There were too many
> diff -u -r sys.old/sys/systm.h sys/sys/systm.h
> --- sys.old/sys/systm.h Sat Dec 8 16:04:37 2001
> +++ sys/sys/systm.h Sat Dec 8 16:07:45 2001
> @@ -60,6 +60,7 @@
> extern struct cv selwait;/* select conditional variable */
>
> extern int physmem; /* physical memory */
> +extern int physmemMB;/* physical memory size in megabytes */
>
> extern dev_t dumpdev;/* dump device */
> extern long dumplo; /* offset into dumpdev */
> @@ -121,7 +122,8 @@
>
> void cpu_boot __P((int));
> void cpu_rootconf __P((void));
> -void init_param __P((void));
> +void init_hz __P((void));
> +void init_param __P((u_int64_t));
> void tablefull __P((const char *));
> int kvprintf __P((char const *, void (*)(int, void*), void *, int,
> _BSD_VA_LIST_)) __printflike(1, 0);
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
nd the code said that it returns a writable length.
>
> (if necessary) we should create a new API to get the real(?) space as
> David have proposed.
>
> Best regards,
>
> ---
> Keiichi SHIMA
> IIJ Research Laboratory <[EMAIL PROTECTED]>
> KAME Project <[E
-- because in reality,
> clusters are almost never shared except for those on the TCP send
> queue and for multicast packets (but who uses multicast, anyways),
> so there is a chance that we will have buggy code that goes unnoticed
> for a long time.
>
> cheers
>
M_LEADINGSPACE and M_TRAILINGSPACE we have the macros to do so.
I already stated what I thought about it: it's wrong for reasons
mentionned in previous Emails. It means that we will be adding support
for a broken macro, not to mention enlarging the macro, which is bad
especially for code that is
t; IIJ Research Laboratory <[EMAIL PROTECTED]>
> KAME Project <[EMAIL PROTECTED]>
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> I like your patch, it's a good idea, go for it.
>
> good to hear that :)
>
> cheers
> luigi
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
uot; occur unless there was
already at least one "mb_mbtypes[(type)]++" that occured on at least one of the
other containers.
MCHTYPE() is implemented to call a function m_chtype() which changes the type
accordingly and manipulates the mb_mbtypes[] of the general container after
acqui
se two issues in his post, which very
much makes sense as he's the overall stack guru. :-)
> --
> Stanislav Shalunovhttp://www.internet2.edu/~shalunov/
>
> "Nuclear war would really set back cable [television]." -- Ted Turner
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
n, it
looks unnecessary. Other than that, looks fine at this end!
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
t your own FREE, personal Netscape Webmail account today at
>http://webmail.netscape.com/
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
error = sosend(so,(struct sockaddr *) &sin,NULL,top,
> 0,MSG_DONTROUTE);
Error code 22 is EINVAL. Something sosend() calls is telling you that
whatever you're passing to sosend() is probably invalid. Are you sure that
what you're trying to do is OK?
> Thanks/regards
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Thu, Apr 05, 2001 at 09:04:15PM -0700, Archie Cobbs wrote:
> Bosko Milekic writes:
> > NMBUFS accordingly. Chances are, if you are explicitly declaring
> > `NMBCLUSTERS ' in your kernel configuration file, that you are
> > actually lowering the number of clusters/mbu
NMBCLUSTERS and
NMBUFS accordingly. Chances are, if you are explicitly declaring
`NMBCLUSTERS ' in your kernel configuration file, that you are
actually lowering the number of clusters/mbufs that would otherwise be
allowed with your given `maxusers' value (unless you have an unreasona
John Hay wrote:
> >
> > >I'll do it right now if itojun doesn't mind (to save him a task
:-) )
> > >and get authorization from Jordan to commit.
> >
> > please go ahead, i can review the diff if you want me to.
> >
>
> Ok, here is a patch for -current. It was taken from the kame code
> with mino
Euuh, scratch that. I don't see anything committed to HEAD yet, at
all. No use in MFCing something that hasn't yet been committed. :-)
Bosko
I wrote:
> I'll do it right now if itojun doesn't mind (to save him a task
:-) )
> and get authorization from Jordan to commit.
>
> Thanks,
> Bosko.
>
> J
I'll do it right now if itojun doesn't mind (to save him a task :-) )
and get authorization from Jordan to commit.
Thanks,
Bosko.
John Hay wrote:
> >
> > >> > will correct it. thanks for reporting.
> >
> >
http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r
1=1.135&r2=1.136
itojun wrote:
>
> >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets
logged
> >> > > often and after a while all mbufs are used. It turned out
that in
> >> > > sys/net/if_ethersubr.c in ether_output() when
nd6_storelladdr()
> >> > fails,
> >> > > it does a return(0) and does no
John Hay wrote:
> I have configured a 4-stable machine to be a router, routing ipv4,
ipv6
> and ipx. To be able to do Ethernet_II framing on one interface and
802.3
> on another I have used if_ef.ko.
>
> I then noticed that "... kernel: nd6_storelladdr failed" gets logged
> often and after a wh
Adrian Penisoara wrote:
> Hi,
>
> As we are facing a heavy fragments attack (40-60byte packets in a
> ~ 1000 pkts/sec flow) I see some sporadic panics. Kernel/world is
> 4.2-STABLE as of 18 Jan 2001 -- it's a production machine and I
hadn't yet
> the chance for another update; if it's been fix
What type of card is this, exactly? (i.e. name, model number, etc.)
There is some trickery in the NetBSD driver that involves
"Vortex-based (3c59x pci, eisa) and Boomerang (3c900)" which allow
FDDI-sized 4500 byte packets. According to the NetBSD driver's
comments, these cards commands dealing wi
Dan Debertin wrote:
> I have a busy 4.1.1-RELEASE nfs server that stops responding at its
ep
> interface every hour or so. Pings to hosts on that network respond
with
> "sendto: no buffer space available". I've recompiled with MAXUSERS
up at
> 128 and NMBCLUSTERS at 32768, both of which seem ple
Boris Popov wrote:
[...]
> > For this to work, though, m_getm() needs to be modified to free
all of
> > `top' chain if it can't get either a cluster or an mbuf. I don't
know
> > if this was intentional, but it seems to me that there is a subtle
> > problem in m_getm() as it is now:
> >
> > if (l
Boris Popov wrote:
[...]
> Not exactly so. 'option LIBMBUF' will just connect the source file
> to kernel makefile. There is no need for any #ifdef's in the code.
Right. But I assume LIBMBUF will absolutely be needed if code that
uses the routines is compiled. What I just meant to say was:
Hi Luigi, -net:
There seems to be a problem with the BRIDGE-specific
"optimization" in if_ed.c. What it does is avoid getting a packet from
the card if bridge_in() says that we're going to drop it. However, the
code is broken and something eventually leads to a page fault.
Disactivating this
Boris Popov wrote:
[...]
> Since currently there isn't many consumers of this code I can
> suggest to define an option LIBMBUF in the kernel configuration file
and
> add KLD libmbuf (with interface libmbuf), so kernel footprint will
not be
I am in favor of such an option on the condition th
What device are you using? What is the interface you ifconfig'd
down and back up?
Jason, can you also contribute?
Boris, if you're reading this, if you see that both these
gentlemen have the same interface, perhaps we have a winner? I've been
unable to find the problem as of yet (fr
Does this happen regularly? Check `netstat -m' on the machine (you'll
probably have to do it from the console) when this is happening.
If it happens regularly, does anything specific happen that "helps
reproduce it?"
What version of FreeBSD are you running?
-Bosko
G. Jason Middleton wrote:
> I
o.
P.S.: Please feel free to snip -arch from the CC list, if judged appropriate.
Alfred Perlstein wrote:
> * Bosko Milekic <[EMAIL PROTECTED]> [010108 19:13] wrote:
> > Hi Alfred,
> >
> > Can you please review this:
> >
> > http://people.freebsd.org/~b
I would go with (a) unless someone is religiously obsessed with having the
message stay.
Else go with (b) but see if you can fit it in with some "generic verbosity"
sysctl knob, as opposed to creating its own.
Later,
Bosko.
> /kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c
Hi,
Please show us how you're manipulating the mbufs.
You should not be getting page faults unless you're doing
something wrong.
A good idea would also be to check the fault virtual
address and enable debugging support in your kernel in order
to be able to analyze the situation
ll never return NULL. Going in and making sure these guys check
for the possibility of failure will be done once this goes in (I'm doing
it in two parts to avoid merging headaches while working).
Please note that this is planned only for -CURRENT at this time.
Regards,
Bosko Milekic
changing the flag may HELP the developer doing the porting into
not making the mistake of assuming that it will be the same.
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
d
I agree. Anyone else before I re-roll? :-)
Cheers,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
iscommunication, then I have no
problem committing it.
I don't want to start a bigger bikeshed from this post than it
already is. I'd just like to know if anyone has any reasonable objections
to having this change happen.
Regards,
Bosko Milekic
[EMAIL PROTECTED]
response from 394 to 200 packets per second
>
> No other changes have been made, and the updated patch is available at:
> http://www.silby.com/patches/ratelimit-enhancement-3.patch
>
> Mike "Silby" Silbersack
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe
hange the descriptions to something very generic before
> committing them ("ratelimiting TCP RST packets: x/y pps" or something)
Mike said he would do it and re-post the diff.
> --
> Bill Fumerola - security yahoo / Yahoo! inc.
> - [EMAIL PROTEC
1 - 100 of 106 matches
Mail list logo
