that this should be a problem, mind you; one would assume that the
optimization isn't performed too well).
Due to lack of time, and generally speaking, lack of experience with
GCC, I haven't taken a detailed shot at debugging this.
Bosko.
--
Bosko Milekic
Email: [
n to have a backtrace?
Was anything particular happening at the time of the crash? Do you
have any way to not necessarily directly reproduce the panic but rather
"force" it to happen (e.g. as a consequence of execution of something or,
even as a result of some exte
On Wed, 5 Jan 2000, Jun Kuriyama wrote:
>From: Bosko Milekic <[EMAIL PROTECTED]>
>> You don't happen to have a backtrace?
>
>I don't have it. When my box gives no reaction, I've hit some keys,
>keys, keys...and rebooted automatically. At that time,
uilding and re-installing the loader.
-----
| Bosko Milekic | Coffee vector: 1.0i+1.0j+1.0k |
| Email: [EMAIL PROTECTED] | Sleep vector: -1.0i-1.0j-1.0k |
| WWW: http://pages.infinit.net/bmile
Gualtar
> 4710-057 Braga
> Portugal
> tel.: +351 253604440 Fax:+351 253604471
> http://admin.di.uminho.pt/~jose
>
<-->
Bosko Milekic * [EMAIL PROTECTED] * http://pages.infinit.net/bmilekic/
<-
t is, because if
mb_map hasn't even been exhausted, then you still potentially have space
to allocate from (this is the way it presently works) and the panic is
unlikely to be related to an mbuf pointer being NULL and mis-treated.
--
Bosko Milekic <[EMAIL PROTECTED]>
|
!>=
Yeah, you just caught some bad timing. Re-cvsup, all should be fixed
now. :-)
.. . . . . . . .. .. . .
. Bosko Milekic -- [EMAIL PROTECTED] . .
. . .
R. -
This seems to only be an issue if you're compiling with optimization.
I *think* it's because the compiler tries to make `j' a register. If you
explicitly declare `j' a volatile, you should not get this.
Is this correct?
Bosko.
.. . . . . . . .. .. . .
. Bosko Milekic -- [EMAIL PROTEC
ng off DEBUG and see if I can make a kernel
>that way
>
Hopefully, you've done this and the following will come out
as a pretty useless question for you, but I have not seen it
mentionned in your Email:
Do you have `options INVARIANT_SUPPORT' ?
..
nd sound around that date. After rebuilding
a more recent world, all was well again. As I recall at least one more
person having the exact same problem at the same time, I don't believe it
to be an isolated case.
--Bosko
--
Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.t
nts compiled in statically.
The kernel built fine, but when it came time to boot it, again, no
response from keyboard, nothing at the console. This time though, the
kernel wasn't even booting.
Has anybody noticed/tried this recently? Am I forgetting something?
Cheers,
Bosko
I've noticed so far have revolved around
> optimization issues, but its more then possible that I missed a message
> ...
>
> My last good kernel, that boot'd fine, is:
>
> @(#)FreeBSD 5.0-CURRENT #0: Wed Jun 14 01:03:00 ADT 2000
>
> With every other one since resulting
)_.---._/ presently in: Budapest
> v
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
() when necessary, so I don't
suspect a critical problem. The question is exactly: How much of
kmem_malloc needs to be under splvm() ?
In any case, the comment needs to be changed ASAP (I Emailed the
lists myself about this maybe on 2 different occasions before and have
got
n it ?
>
> --
> Pascal Hofstee < daeron @ shadowmere . student . utwente . nl >
> Managers know it must be good because the programmers hate it so much.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in
Hrmmm, there may be a logic problem here. Try this (apply it manually,
as I am not able to produce a diff at this time):
change:
if ((__mcnt == NULL) && (m_alloc_ref(1) == 0))
panic("mbuf subsystem: out of ref counts!");
to:
if (__mcnt == NULL) {
if (m_alloc_
ent= base 0x0, limit 0xf, type 0x1b
> = DPC 0, pres 1, def 32 1, gran 1
> processor eflag = interrupt enabled, resume, IOPC=0
> current process = 0 (swapper)
> interrupt mask = net tty bio cam <- SMP:XXX
> trap number = 12
> panic:
On Sun, 27 Aug 2000, David Malone wrote:
[...]
> (This is why the flag I was talking about in the other mail
> would be useful for spotting other cases where the storage
> may be writable, even if it's not a cluster).
Thoughts:
1) The mbuf should be marked read-only explicitly wit
nternet Solutions
> tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800
> email: [EMAIL PROTECTED], [EMAIL PROTECTED]
> URL: http://www.is.co.za
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
: [EMAIL PROTECTED]
> URL: http://www.is.co.za
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
;gensig' mail-client-independent .signature generator.
> Get your copy at http://www.geeks.com/~robf/gensig/
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
comment on this is Jonathan Lemon.
> So, no solution, right? :(
Well, you're sending out packets faster than your hardware can
transmit them. You can `artificially' define IFQ_MAXLEN to something
greater than 50 but practically, you probably won't get much besides for
consu
this?
It should stay like this. The easy (macro) case deals with only the
reference count issue. We only call the function if we really have to
free the object (i.e. ref count is dropped to zero).
> Thanks.
>
> --
> Chad David[EMAIL PROTECTED]
> ACNS Inc. Calgary,
..
>
> o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG
> sections (for those that can go into loader.rc).
This last point is neat, especially if whoever is doing it
could setup something with the doc team and actually get to
actively documenting, as things
're trying to get a lock and get pre-empted right after failing
to get it but before grabbing sched_lock and putting ourselves to
sleep). So, in effect, it's a non-issue.
> -Matt
> Matthew Dillon
>
Stephane Legrand wrote:
> On Wed, Feb 28, 2001 at 02:46:06PM +0100, Patrice JACQUES-GUSTAVE
wrote:
> > Bonjour à tous !!!
> >
> > Je découvre jour après jour Freebsd, qui finit par vraiment me
plaire. Du
> > coup, j'aimerais faire partie de votre liste de diffusion.
> >
> > Merci d'avance et me
CURRENT.
> I hope that I'm not too far out of my league, here... :-)
>
>
> Eddy
>
> -------
>
> Brotsman & Dreger, Inc.
> EverQuick Internet / EternalCommerce Division
>
> Phone: (316) 794-8922
>
> ---
Later,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
perations, but only in the case where we lack the cached buffer to
allocate it. There is no practical way of telling up front whether or not
we'll have to malloc(), so I'm wondering how efficiently we would be able
to predict in cases such as these?
>
e everything out of nothing,
> but the nothingness shows through. -- Paul Valery
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
obvious ones like merging uipc_mbuf.c
code with uipc_mbuf2.c code, and ridding ourselves of the latter,
etc.). It also moves a bundle of mbuf related things out of
sys/conf/param.c and into subr_mbuf.c, where they will now
belong. :-)
Best Regards and PLEASE help test (especially if you have alp
eally
expect any problems on alpha, but better be safe than accidently break
alpha and have some very peeved developers on my tail. :-)
Cheers and thanks again,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
t; people to take different points of view. [Dr. Fritz Todt]
>V I C T O R Y N O T V E N G E A N C E
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
\
> _mm->m_next = mmbfree.m_head; \
> mmbfree.m_head = _mm; \
> MBWAKEUP(m_mballoc_wid, &mmbfree.m_starved);\
> mtx_unlock(&mbuf_mtx);
On Thu, Jun 14, 2001 at 03:12:06AM +0900, Hajimu UMEMOTO wrote:
> >>>>> On Wed, 13 Jun 2001 13:42:51 -0400
> >>>>> Bosko Milekic <[EMAIL PROTECTED]> said:
>
> bmilekic> Yes, I certainly didn't write that. I think it was KAME.
>
>
ime, please consider backing it out and
applying this one. Sorry for the inconvenience.
Cheers,
Bosko.
On Wed, Jun 13, 2001 at 01:07:44AM -0400, Bosko Milekic wrote:
>
> Hi -current && -alpha,
>
> If you run -CURRENT on multiprocessor alpha, please
>
lr() sounds like
"m_get a cluster."
> --
>
> I like the "only" comment claifications.
>
> --
>
> I dislike the bloating of one line comments into three lines,
> with the first and last blank.
It happens once or twice, as far as I could see (
Hi Folks,
Here are some performance results. Keep in mind that we're still under
Giant.
http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html
Terry, is this OK for you?
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
On Fri, Jun 15, 2001 at 06:32:55PM -0500, Jonathan Lemon wrote:
> On Fri, Jun 15, 2001 at 06:54:21PM -0400, Bosko Milekic wrote:
> >
> > Hi Folks,
> >
> > Here are some performance results. Keep in mind that we're still under
> > Giant.
> >
ugh
mb_alloc does show to be slightly better here, keep in mind that the x-axis
is logarithmically scaled, so the difference is rather minimal.
> --
> Jonathan
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
CTED]]
> Instead of asking why a piece of software is using "1970s technology,"
> start asking why software is ignoring 30 years of accumulated wisdom.
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
difference that I am aware of is that mbtypes statistics
have been TEMPORARILY disabled. Please be patient. :-)
Thank you for flying -CURRENT,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PROTECTED]>
> Date: 22-Jun-2001
> Time: 11:41:47
> --------
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
m in the process of fixing it immediately. Sorry!
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
dentical. In fact,
subr_mbuf.c is identical modulo one of the lines in the copyright.
> -matt
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
person issues `netstat -m' or, even worse, runs
`systat -mbufs'). The main issue with the mbtypes stats, as I've previously
mentionned, was that it is difficult to *update* them consistently. However,
I think I have devised a way. I'll keep you posted if you're interested i
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Fri, Jun 22, 2001 at 01:32:21PM -0400, Bosko Milekic wrote:
> > mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to
> > sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then
> > hw.ncpus can reference that (well, it's c
" just "locked down," or
"mutexified."
> -GAWollman
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
; | __--_|\ Julian Elischer | \ U \/ / hard at work in
> | / \ [EMAIL PROTECTED] +-->x USA\ a very strange
> | ( OZ)\___ ___ | country !
> +- X_.---._/presently in San Francisco \_/ \\
>
ecome more and more
apparent only as things progress and it should be noted that all of
these "nice things" resulting from all the work we're presently doing
will not just all magically surface when 5.0-RC1 (or whatever it's
going to be called) is "released."
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
today's
> cvsup (i.e. with the 1.63 rev of sys/kern/uipc_socket2.c) hung after
> ssh-ing to this system (or telnet-ting ;-). (See 'current' and 'stable'
> maillists for more detailed description of the problem).
>
> N.Dudorov
Cheers,
Bosko
t thing.
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ion.
Finally, I'm trying to do this as closly as possible with Alfred's
work, so Alfred, maybe you can also glance at point (f) above as well...
:-)
Cheers,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
. None of the
work I mentionned has been committed at any point in time (yet), so the
problem can only be similar, at best (in any case, a `netstat -m' should
offer a clue).
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
cided that this is the strategy
> we are using" document.
>
> --
> __--_|\ Julian Elischer
> / \ [EMAIL PROTECTED]
> ( OZ) World tour 2000
> ---> X_.---._/ presently in: Perth
> v
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-in-stone way right now...
> --
> __--_|\ Julian Elischer
> / \ [EMAIL PROTECTED]
> ( OZ) World tour 2000
> ---> X_.---._/ presently in: Perth
> v
Later,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
o my best to take care of all issues as soon as
possible, if necessary. :-)
If all goes well, more commits, some adding important functionality,
to follow...
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
> Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> No man knows how bad he is
> till he has tried very hard to be good. -- C.S. Lewis
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[EMAIL PROTECTED]
> Systems Administrator @ hub.org
> scrappy@{postgresql|isc}.org ICQ#7615664
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
MAIL PROTECTED] for PGP public key
> See complete headers for address and phone numbers
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
d
only once
/usr/src/usr.sbin/ppp/atm.c:186: for each function it appears in.)
/usr/src/usr.sbin/ppp/atm.c:169: warning: unused variable `sock'
*** Error code 1
...
I don't know who/what broke this. Anybody have any ideas?
Bosko Milekic
[EMAIL PROTECTED]
To Un
e me the quick and dirty
> on how I can provide additional details? This is on -CURRENT from
> 10/16.
You should have debugging enabled in your kernel, then you can
provide, at least, a stack trace. Please see the relevant handbook
section for more information.
> The ha
`struct mtx'
> *** Error code 1
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
w 64Kbit/s
>
> I can reproduce this at will (and have the vmcore), so if anyone needs
> more details, just let me know.
>
> This is -current of a few days ago (18th Nov 2000, if I recall correctly).
>
> -Russell
Thanks,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubs
e 1
>
> Stop in /usr/src/usr.bin/netstat.
> *** Error code 1
>
>
> Sources are from today at 10:27 PST.
> --
> Steve
Cheers,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ee to use the diff for yourselves for now.
Cheers,
Bosko.
On Sun, 26 Nov 2000, Clive Lin wrote:
> Hi,
>
> This works ! I was the dummynet victim due to dummynet, but now
> I'm saved :-) Hopes this to be committed soon.
>
> On Thu, Nov 23, 2000 at 11:40:19A
e NULL in the first place. Is this the case? And if so, why
is nfs_msg() being called with this pointer being passed in in the first
place?
> /assar
>
[...]
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
r
> Chairman of the Supervisory Board: Joerg Menno Harms
> Commercial register: Amtsgericht Boeblingen HRB 4081
> ___
>
Cheers,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
uot;block indefinetely if you can't get me anything."
M_WAIT is now deprecated and M_TRYWAIT should be used in its place.
Happy Holidays!
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I'm sorry guys, I haven't been really "up-to-date" on this thread, but I was
wondering: can config be made to define I386_CPU 0 if any other cpus are
defined (or the inverse behavior)? (Maybe this was already done?) In the
sysinstall case, I think it's safe to just exclude all other processors and
Alfred Perlstein wrote:
> * Alfred Perlstein <[EMAIL PROTECTED]> [010117 09:24] wrote:
> >
> > I'm not going to axe it for a few days, this is a really amazing
> > API that Matt added, the problem is utility and useage over code
> > complexity.
> >
> > It's just a proposal.
>
> I found several p
Hello,
A few hours ago, this has been committed to -CURRENT:
Commit log:
[...]
> Log:
> Implement MTX_RECURSE flag for mtx_init().
> All calls to mtx_init() for mutexes that recurse must now include
> the MTX_RECURSE bit in the flag argument variable. This change is in
> preparatio
Jason Evans wrote:
> Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha.
> The bug also exists on x86, but does not necessarily cause any problems.
> If you run into problems (probably during boot), there is a patch available
> that should fix the WITNESS problem:
>
> http:
Maybe then we could merge the two, or something. Heck, I
don't know. It's not really like doing this is difficult so I don't
know how we would resolve the conflict.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Dec 30, 2002 at 09:35:28AM +0900, Kyunghwan Kim wrote:
> On Sun, Dec 29, 2002 at 06:47:35PM -0500, Bosko Milekic wrote:
> > I don't really know what
> > to tell you because I'm working on the exact same thing (and I
> > mentionned in the Emails you bro
t see a better
solution. Right now, ref counting for regular mbuf clusters works
fine and is pretty damn fast, but I don't know how I could make it
happen for other external buffer types other than the way I just
described.
> Thanks,
>
> Drew
--
Bosko Milekic * [EMAIL PROTEC
P.S.: Try not to use MEXTADD, if possible. Use m_extadd() instead,
which is the procedure-equivalent version. MEXTADD is just provided
for 'backwards-compatibility'. It used to be a large ugly macro.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
27;s perfectly possible to profile the entire kernel if you want to.
Hey Poul-Henning! Thanks!
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to mali
gt; Trish Lynch [EMAIL PROTECTED]
> Ecartis Core Team [EMAIL PROTECTED]
> EFNet IRC Operator @ efnet.demon.co.uk AilleCat@EFNet
> Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16
>
>
> To
ne in the
HTT-enabled model would be effectively 'hlt'-ed when one of the two
threads executes an 'hlt' until the next timer tick.
I guess we'll wait for the two other data sets from Trish: one with
HTT off, and cpu_idle_hlt=0, and the other with HTT off, and
cpu_i
mber, at runtime?
[...]
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> "All of this is for nothing if we don't go to the stars" - JMS/B5
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
r one is HLT'd, then not do the
HLT.
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send
On Sat, Feb 01, 2003 at 12:47:59PM -0800, Terry Lambert wrote:
> Bosko Milekic wrote:
> > On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote:
> > > Another solution would be to have a global mask of 'idle' cpus and send
> > > an IPI to
On Sat, Feb 01, 2003 at 01:28:45PM -0800, Terry Lambert wrote:
> Bosko Milekic wrote:
> > > > Or, as I explained in my previous post, only HLT the [virtual] CPU if
> > > > the other [virtual] CPU that is sharing the same execution & cache
> > > > u
W, I can't say for sure that this
is related to TCP connection timeouts.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sup date tag 1200 GMT 14 Feb 2003 ran
> the week with zero problems. Will try again tomorrow morning
> (1200 GMT) if there are "interesting" kernel commits.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the
3 copies of the same
> > message all the time is kinda annoying. :-(
> >
> I´m running a snort-like application with the interface getting receive only
> packets. It can either connect to a netgraph node or use bpf, both seem to have
> similar performance (most CPU is used elsewhere) as the email I sent previously
> had listed.
>
> Pete
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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
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
>
to analyze this as I cannot reproduce it. Have you tried
running your tests over loopback to see if the same thing happens?
If so, and it does, can you please explain how to exactly replicate
the test?
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send ma
e whether
it's really the common case of mb_free() that's being expensive or if
you're often hitting non-common-cases (in which case the auxilary
routines should register the higher CPU usage).
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
in one of the caches.
>
> Or I could simply remove the limits.
>
>
> harti
>
>
>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
___
[EMAIL PROTEC
On Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote:
> On Sat, 19 Jul 2003, Bosko Milekic wrote:
>
> BM>
> BM>On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote:
> BM>[...]
> BM>> Well the problem is, that nothing is starved. I h
On Mon, Jul 21, 2003 at 03:47:54PM +0200, Harti Brandt wrote:
> On Mon, 21 Jul 2003, Bosko Milekic wrote:
[...]
> BM> It sounds to me like your example is really not the general-case one.
> BM> Basically, you're using a zone capped off at 1 page. Currently in
> BM>
ur problem, try setting the
kern.vm.kmem.size bootable to approximately 350,000,000 or so (even
400,000,000 is OK as long as NMBCLUSTERS is not too-too high).
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
__
unning what
appeared to be stock 5.1-RELEASE, which may or may not be related to
what you're seeing.
If reverting to pre-July 20 gets rid of your problem, perhaps we can
figure out what commit triggered this behavior for you. Also, do you
have PAE enabled?
--
Bosko Milekic * [EM
e box up for this? I'll dig around in the
> developers handbook, I seem to remember seeing something about it in there.
>
> Thanks,
> Stephane.
...
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
_
ll drop you into
the debugger on a kernel panic, at which point you can just issue 'tr'
to get a stack trace. Be careful, if you only have remote access to
the machine, this is generally not a good idea.
> Thanks,
> Stephane.
--
Bosko Mi
nformation on using DDB. If you have the space in /var and
enough swap, you may want to try getting a crashdump so that you can
reboot and use GDB to debug. Again, take a look at the handbook.
> thanks again,
> Stephane.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECT
1 - 100 of 162 matches
Mail list logo
