> Abel Alejandro.
>
>
> -
> This mail sent through IMP: http://horde.org/imp/
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-cu
, it would still be nice if the acpi users (for whom acpi
works for the most part) could give the patch a try as well (I have a
decent-sized list of testers but would nonetheless welcome/appreciate
more).
> Thanks,
> -Nate
Cheers,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMA
to someone with APM, and then waiting for the results. This
is a time-consuming process, but as soon as the problem is addressed,
I will commit the changes.
Thanks to everyone who has helped test this so far.
Regards,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TE
ant, and that code fails to assert Giant requirements most
of the time. Maybe it's time we start sprinkling the GIANT_REQUIREDs
where we know they belong... that one we talked about adding the
other day, did it catch anything?
--
Bosko Milekic *
problems with
this patch, then make sure that they really do go away with
DISABLE_PSE and DISABLE_PG_G before you contact me; it could just be
bad RAM.
If I commit this, I want it to have the longest "Tested By" list ever
written in a commit message to date. Please help. :-)
less. Otherwise, glance at src/sys/vm/uma.h, which is decently
documented for what concerns exported API.
You shouldn't have to touch 'vm_zone' directly (it doesn't exist
anymore).
> Thanks.
> --
> Craig Rodrigues
> http://crodrigues.org
> [E
hunks were rejected before you build and boot the
kernel.
If after all this you still crash like in the above, then please send
me [off-list] your kernel configuration file as well as a trace (as
above).
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consultin
ore
> than 2mbps
> ideas???
Make sure that you have absolutely no debugging options turned on.
This includes WITNESS, INVARIANT_SUPPORT, and INVARIANTS at the
least (check your kernel configuration file).
> --
>
> Marcos Biscaysaqu
>
> Systems Administrator
&g
ace. Again, I have to re-iterate
that you really need to make sure you're supping to HEAD:
*default release=cvs tag=.
Regards,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
_
now if there is other data you need from me.
>
> Thanks again,
> Stephane.
>
>
> - Original Message -
> From: "Stephane Raimbault" <[EMAIL PROTECTED]>
> To: "Bosko Milekic" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: We
The kernel was cvsuped this afternoon and patched only with your
> patch. I had to panic twice to get a core dump and I have doubts about
> its validity.
> --
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berk
gt; g_io_schedule
> g_up_procbody
> fork_exit
> fork_trampoline
> --- trap 0x1, eip = 0, esp = 0xd23a5d7c, ebp = 0 ---
How about the panic message? There are 4 different panics that could
have occured from uma_dbg_free(). Arguments would also be nice, I
guess.
--
Bosko Mil
_ds = 47, tf_edi = 0, tf_esi = 135299072,
> tf_ebp = -1077937224, tf_isp = -973693580, tf_ebx = 0, tf_edx = 135295016,
> tf_ecx = -1, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134725423, tf_cs
> = 31, tf_eflags = 582, tf_esp = -1077937268, tf_ss = 47}) at
> /home/tim/p4/freebsd/
Try the attached patch.
On Fri, Aug 01, 2003 at 11:02:49AM +, Bosko Milekic wrote:
>
> fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock
> needs to be dropped before allocating or freeing to that zone.
>
> What does Alan think? (cc'd)
>
>
1d
> --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 ---
>
> Lars
> --
> Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * ht
can wait to see if the recent changes fix the same
panic for other people who have been seeing it.
Bonne chance. :-)
> Thanks,
> Stephane.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
_
s worth noting that a small chunk of the above patch may fail as I
just committed a part of it. You should be able to safely ignore
that.
Let me know how it works out.
Regards,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://
the problem of having to account for the
buckets in the zone as well (besides for just the pcpu cache buckets).
So if it does get committed, can the calculation of uz_cachefree from
the timer routine be axed in the same change, as it is no longer
significant?
--
Bosko Mile
isabled also is
indicative that there is a clear reentrancy problems somewhere.
There may also be some bucket leakage (although I have not yet
confirmed this) as well.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS
g this. I was going to do this myself but
had to leave the office. Hopefully Jeff will have a chance to take a
look at it otherwise I`ll be glancing at it tomorrow. Also, it would
be nice if those suffering from recent problems with kmem_map
exhaustion on 5.1 try this and note whether or
eMail: [EMAIL PROTECTED]
> UNIX Systemadministrator Tel.: (+43 1) 4277-14073
> Vienna University Computer Center Fax.: (+43 1) 4277-9140
> University of Vienna http://mailbox.univie.ac.at/~le/
--
Bosko Milekic * [EMAIL
rom the
point of view of the VM, the memory is never reclaimed.
I am unsure as to whether or not the memory allocated by the USB stuff
needs to be type stable so I can't really fix this. I urge the USB
authors to glance there.
If you are using USB, try turning it off to see
On Sat, Jul 26, 2003 at 09:18:01PM +, Dave Johnson wrote:
> Hi
>
> Has anyone manage to load ver 5.x into the Compaq Presario 1370
> notebook. I get kernel panic all the time
>
> Regards
Yes.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS C
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
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
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/
_
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
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/
__
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>
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
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
atch, just submit a PR and then post
the PR number in reply to this thread.
Thanks
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http:
be something funky that we are doing.
>
> - Matt
>
> --
> Matt Loschert - Software Engineer | email: [EMAIL PROTECTED] |
> ServInt Internet Services | web: http://www.servint.net/ |
> McLean, Virginia US
http://mailbox.univie.ac.at/~le/
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
>
--
Bosko Milekic * [EMAIL PRO
indication of bug in the p-III or in the chipset ?
> (ISTR these options could be used to get around unnamed errata of the p-IV)
Please tell me if either DISABLE_PG_G and/or DISABLE_PSE fixes your
problem and if you can reproduce the problem when you don't have those
two options.
opy) What do you think about it?
FWIW, I've tested this yesterday and wanted to commit it but
shamefully I must admit that I don't know how to properly prepare a
port. The screen saver works and is pretty neat although I had to
build in low video mode.
--
neering team.
> >
> Thanks
>
> Ken
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
M because the call is being made with
WAITOK or TRYWAIT. Moving the Giant acquisition from kern_sendit() back
to the top of sendit() should fix it, but I'm CCing dwmalone on this to
see what he thinks is the best approach.
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_
es in the code path from m_getcl() to malloc(), so they must be
happening higher up in the call stack.
> The lock reversal was: 1. fxp softc lock, 2. Giant.
>
> Traceback:
> zalloc...
> malloc()
> mb_pop_cont()
> mb_alloc()
> m_getcl()
> fxp_add_rfabuf()
> fxp_int
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
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
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
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
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
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
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
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
r one is HLT'd, then not do the
HLT.
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send
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
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
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
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
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
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
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
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
a packet header mbuf
for you with external storage and may even allocate more than one and
chain them together for you in one shot and without dropping the
per-CPU cache lock, if it can get away with it. It does a 'best' fit
allocation so you effectively have your 'small,'
a really quick and negligeable size
comparison, but that's it).
As for non-third-party type external storage (your standard 2K mbuf
clusters) those can be allocated in one shot with an mbuf pre-attached
to it by the existing allocator anyway and an interface is provided to
do so (m_ge
to but make sure it's not something that requires freeing afterwords
(in other words, only do it if you do the exact same thing mb_alloc
does for regular clusters because otherwise you'll have to worry
about destructing the counter before freeing the mbuf).
> Drew
--
Bos
PIII system. It was still
> not as fast as stable, but the current/stable performance difference
> was no longer embarrassing.
>
> Drew
>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
uster.
So when the 'n' mbuf is allocated and the cluster with it then a
shallow copy of the packet header is done from mbuf 'm' (the old mbuf)
to the newly allocated mbuf 'n'. What Robert is saying is that
this copy breaks his MAC label semantics which require
On Mon, Nov 25, 2002 at 01:27:39PM -0500, Andrew Gallatin wrote:
> Bosko Milekic writes:
> > On Sun, Nov 24, 2002 at 04:23:33PM -0500, Andrew Gallatin wrote:
> > > If we're going to nitpick the mbuf system, a much, much worse problem
> > > is that you cannot al
M Watson FreeBSD Core Team, TrustedBSD Projects
> [EMAIL PROTECTED] Network Associates Laboratories
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ing problems.
> >
> > I know that both tru64 and aix just malloc their mbufs.
>
> I think we tied that and went back to a separate allocator, but I have
> no idea why.. maybe someone else can enlighten me..
As I mentionned in a previous Email, it all has to do with what wer
ber
UMA the last time I checked) and those have to do with, primarily,
SMP-friendliness.
> Drew
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
the message
>
> --
> Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED]
> http://www.oreillynet.com/pub/q/Big_Scary_Daemons
>
>Absolute BSD: http://www.AbsoluteBSD.com/
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RIPE Network Coordination Centre
> http://www.ripe.net/home/mark/ New Projects Group/TTM
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
. I couldn't even read it due to
mis-aligned braces ( { and } ). Thanks.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
$
> (cvsup'ed today)
>
> Marc
That's not what I was asking for. He mentionned he had a kernel from
the 25th that was working and I wanted the version of subr_mbuf.c that
he had used to build _that_ kernel.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
break it with
any of the changes I've made. My last change was on 2002/07/24 15:11:23
so I don't think it's that, but just to make sure...
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
;t notice a difference.
As a point of reference, however, what hardware do you have this
running on? Specifically, what board, CPUs, how many, and how much
RAM do you have?
Thanks,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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-current" 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
I386_CPU)
> +#if defined(I386_CPU) || 1
> static __inline int
> atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
> {
>
>
> Glenn G.
>
>
> --
> Glenn Gombert
> [EMAIL PROTECTED]
>
> "Never trust any operating system you don't have the source code for"
>
> --
> http://fastmail.fm - Get back to work
>
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
, just some things mentionning that VMWare has trouble with
locking primitives.
What does the patch do?
> Glenn G.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
whatever the name of that option was).
(iv) Boot host OS windows2000, start VMWare, and try booting the
installed -CURRENT with the new cmpxchg-free kernel via
VMWare.
I hope this at least improves the speed situation.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
ain this assumption when/if we move to uma in
the future.
> -- Terry
Cheers,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sleep is called and are M_NOWAIT,
then that's not good. M_NOWAIT means: "only allowed to block on a
mutex."
> It's either incredibly badly named, or it's incredibly badly
> implemented -- I would argue the latter, actually, since even
> if it's completely
On Wed, May 29, 2002 at 01:04:00PM -0700, Terry Lambert wrote:
> Bosko Milekic wrote:
> > On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
> > > Can we get rid of the NULL tests we had to put in when M_WAIT
> > > turned into M_WAITOK?
> >
>
OTECTED]; [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
ry
> "Never solve a vast problem in a half-vast way"
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I486_CPU
> cpu I586_CPU
> ident RATZ
> maxusers 0
> Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
--
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 patch. To me, it doesn't
look like the direction we're supposed to be headed in is wrong. I don't
see a technical argument (yet) saying otherwise besides for this "it's
an optimization and shouldn't go in" thing. Please, if there is one,
state it. The same applies to the ithread lightweight stuff I've been
working on.
> Warner
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ocking to NFS" yourself?
> Give us peace Matt...
>
> --
> 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 malice what can adequately be explain
opefully
[at least] eventually replace malloc(9) and various other kernel
allocators. It will support per CPU working-sets and some cache friendly
goodies.
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
houldn't be acceptable to go "euh, -CURRENT is broken and it's
probably because of me but I have no friggin' clue how or why. I don't
even know where to start looking." It's just common sense.
> On Sat, 23 Feb 2002, Bosko Milekic wrote:
>
> >
> >
d form: "development
bleeding edge version of FreeBSD" (as opposed to "[totally broke and
bleeding] developer [for those who feel like it] version of FreeBSD.").
> DES
> --
> Dag-Erling Smorgrav - [EMAIL PROTECTED]
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
T
'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
>
..
>
> 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
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,
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
;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
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
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
; | __--_|\ Julian Elischer | \ U \/ / hard at work in
> | / \ [EMAIL PROTECTED] +-->x USA\ a very strange
> | ( OZ)\___ ___ | country !
> +- X_.---._/presently in San Francisco \_/ \\
>
" 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
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
1 - 100 of 162 matches
Mail list logo
