> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
Hi,
I have some minor probem with my CMI8330 chip based integrated sound
card on m726 motherboard.
Here's the URL where you can find how to fix it:
http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz
= cut here =
Thank you very much for your problem report.
It has the
On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" wrote:
>Ladavac Marino wrote:
>>
>> This topic has been trashed to death a few months ago. There is no
>> win-win situation in presence of processes which allocate a lot of memory
>> without actually using it (read: your typical FORTRAN l
Garance A Drosihn wrote:
>
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> But that isn't always the best process to have kil
At 3:18 PM -0700 7/14/99, Matthew Dillon wrote:
>This conversation is getting silly. Do you actually believe
>that an operating system can magically protect itself 100%
>from armloads of hostile users?
>
>Give me a break. You people are crazy. If you have something
>worthwhil
On Thu, 15 Jul 1999, Harold Gutch wrote:
> On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote:
> > We don't _need_ pidentd anymore. It will load down a system more than
> > the inetd's implementation of ident will. Therefore, pidentd should be
> > phased out. Other than that, pidentd
:For the moment I'll pretend that you honestly think that is an
:answer, and I'll note that the very same machine may have well
:over 100 processes each of which takes 1-2 meg of memory. If
:the machine hits a really-out-of-memory error, I would be much
:much happier to see all 100+ of those proce
In message Wayne
Cuddy writes:
: Even though I am developing on FBSD is there a "more portable" way to do this?
No. Well, not short of execing.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
lyn...@orthanc.ab.ca wrote:
> The semantics of malloc() have been defined since almost the dawn of
> time. From the current manpage:
> RETURN VALUES
> The malloc() and calloc() functions return a pointer to the allocated
> memory if successful; otherwise a NULL pointer is returned
Is the reason why adb hasn't been ported to freebsd because the source is
proprietary?
If gdb should suffice for my debugging needs, how can a breakpoint be set
at a particular interrupt, or even at any interrupt? The break command
only seems to accept functions, offsets, linenumbers and addresses
Garance A Drosihn wrote:
>
> >> One of my main freebsd machines is mainly here to run one
> >> process, which is a pretty good-sized process (>40meg). If
> >> I did get into a memory-shortage problem, I do *not* want
> >> that process killed, I'd want some other processes killed.
> >
> > Just siz
John Nemeth wrote:
>
> } > This is based upon your somewhat strange definition of "work". I assure
> } > you that I have run many systems which don't use overcommit, and which I
> } > quite frequently run into "out of VM" conditions, and which I can assure
> } > you, work just fine. When they'
John Nemeth wrote:
>
> } > But that isn't always the best process to have killed off...
> }
> } Sure it is. :-) Let's see...
>
> This statement is absurd. Only a comptetant admin can decide
> which process can be killed. No arbitrary decision is going to be
> correct.
We are talking about
Robert Elz wrote:
>
> Note that all this (large) VM I have described was filled with real data
> (except for the odd times hen innd or named had just forked), none of it
> could be overcommitted and just ignored. Whatever policy was in place,
> the physical VM resources would have run out.
In a
Jason Thorpe wrote:
>
> > > ...um, so, make the code that deals with faulting in the stack a bit
> smarter.
> >
> > Uh? Like what? Like overcommitting, for instance? The beauty of
> > overcommitting is that either you do it or you don't. :-)
>
> One option is to special-case overcommit the s
Sergey Babkin wrote:
>
> > It would be nice to have a way to indicate that, a la SIGDANGER.
>
> Another option may be to add something like "importance classes".
> Suppose we assign an one-byte "importance level" to each process.
> When we get out of swap we start killing processes with the lowes
:Our IMAP server routinely show a footprint of about 1MB private storage.
:This is constant for most operations. However, when you get into doing
:SEARCH and SORT, there are certain cases where we need memory, sometimes
:a *lot* of memory.
:
:Your proposal is that my *well behaved* application shou
:Ted Faber
:>For every strategy there's a counterstrategy.
:exactly: the disappointing thing about this whole thread is there's been
:little discussion of implementing a (tunable) policy how to handle the
:situation when resource shortage materialises.
:
:Overcommitment can be useful, maybe even f
:> I mean, jeeze, the reservation for the program stack alone would eat
:> up all your available swap space! What is a reasonable stack size? The
:> system defaults to 8MB. Do we rewrite every program to specify its own
:> stack size? How do we account for architectural differen
:
:On Jul 15, 12:20am, "Daniel C. Sobral" wrote:
:} "Charles M. Hannum" wrote:
:} >
:} > That's also objectively false. Most such environments I've had
:} > experience with are, in fact, multi-user systems. As you've pointed
:} > out yourself, there is no combination of resource limits and what
John Nemeth wrote:
>
> On one system I administrate, the largest process is typically
> rpc.nisd (the NIS+ server daemon). Killing that process would be a
> bad thing (TM). You're talking about killing random processes. This
> is no way to run a system. It is not possible for any arbitrar
Michael Richardson wrote:
>
> No, I don't agree.
>
> This is a biggest argument against solving the overcommit situation with
> SIGKILL. I have no problem with overcommit as a concept, I have a problem
> with being unable to keep my possibly big processes (X, rpc.nisd,
> etc. depending on cic
Michael Richardson wrote:
>
> Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever
> Ben> come *close*?
>
> Uh, since we don't run overcommit, the answer is specifically *NO*.
And what system do you run?
> I have had it happen on other systems. (Solaris, AIX) It w
John Nemeth wrote:
>
> The machine in question has run out of swap, due to unforseeable
> excessive memory demands. This was accompanied by processes
> complaining about not being able to allocate memory and then cleaning
> up after themselves. I did not see random processes being killed
>
Jason Thorpe wrote:
>
> If you have a lot of users, all of which have buggy programs which eat
> a lot of memory, per-user swap quotas don't necessarily save your butt.
The chance of these buggy programs running at the same time is not
exactly high...
> And maybe the individual programs didn't e
lyn...@orthanc.ab.ca wrote:
>
> What it so evil about having a reasonably intelligent malloc() that
> tells the truth, and returns unused memory to the system? Overcommit
> is for lazy programmers, plain and simple. At least the SGI documentation
> about overcommit admits that (or at least, did at
>
> And what do you do, then, with the processes that happen to have
> legitimate use for more stack?
>
> Or maybe you just find out how much stack each process uses, and
> then set limits appropriate for each one? Which is the equivalent of
> setting limits to each user, of course...
You get a
> Is the reason why adb hasn't been ported to freebsd because the source is
> proprietary?
You make no sense.
> If gdb should suffice for my debugging needs, how can a breakpoint be set
> at a particular interrupt, or even at any interrupt? The break command
> only seems to accept functions, offs
On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote:
> >
> > If you have a lot of users, all of which have buggy programs which eat
> > a lot of memory, per-user swap quotas don't necessarily save your butt.
>
> The chance of these buggy programs running at the same time is not
> exa
> On Tue, 13 Jul 1999, Mike Smith wrote:
>
> > 'siobi' is someone trying to open the serial console, for whatever
> > reason. Without knowing who it was that was stuck there, it's hard to
> > guess what is going on.
>
> D'uh, sorry. Long day. It was amd that was hung in the siobi
> state.
Daniel Eischen writes:
> There are some bugs in libc_r in stable that have been fixed in
> -current. I think the one that you've hit is an uninitialized
> TAILQ_HEAD in a statically declared mutex (in localtime). It's
> probably about time for a MFC. If someone wants to give me the
> go-ahead,
Hi :)
put the following line in your kernel config file .. recompile your
kernel .. boot .. and then try the make again ...
pseudo-device vn1
to create the floppy ... a vertual node is used ..
hope this helps ...
Reinier
> During a make release for 3.2-RELEASE I get the following er
On Tue, 13 Jul 1999, Ted Faber wrote:
> Matthew Dillon wrote:
> >I said:
> >:So, Matt, I understand that you think that the folks who are want to
> >:turn off overcommit are looking to hang themselves, but how much does
> >:it cost to sell them the rope?
> >
> >I'm guessing that a simple impl
On Wed, Jul 14, 1999 at 05:43:21PM +0930, Kris Kennaway wrote:
>
> You know, it occurred to me that with all the time wasted typing up messages
> in this thread someone (e.g. Matt) could have instead coded up a simple
> non-overcommit model, given it to the nay-sayers and said "Run this and see
>
this message may have been posted to hacks but I didnt see it come through.
I greatly apreciate any help.
I have a WaveLAN ISA adaptor.
I am trying to run it in a machine equiped with an AMD K6-2 350
processor running at 66mhz bus speed.
I am getting the following error while ifconfiging the car
Doug Rabson <[EMAIL PROTECTED]> wrote:
> Overcommit can be used for many reasons. I use it to reserve a large
> linear address space to mmap alpha i/o spaces to which allows an efficient
> implementation of inx/outx in user mode:
>
> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT T
# These are currently broken and are no longer shipped due to lack
# of interest.
#optionsCCITT #X.25 network layer
#optionsISO
#optionsTPIP#ISO TP class 4 over IP
#optionsTPCONS
Date:Tue, 13 Jul 1999 15:19:43 -0700 (PDT)
From:Matthew Dillon <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| There are a billion ways to do it and none of them require a swap
| reservation model.
Every method you described was exactly a swap reser
Date:Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
From:Matthew Dillon <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| allocation - most everything is statically allocated and if the system
| tries to use more, it panics and reboots.
I'm finding it difficul
Date:Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
From:Matthew Dillon <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| If you don't have the disk necessary for a standard overcommit model to
| work, you definitely do not have the disk necessary for a non-ove
> I'm not sure if XPG4v2 requires command substitution to behave
> like that. At least, both Solaris' and DEC UNIX... oops...
> True64 UNIX do execute all command substitutions in a subshell
> (`pwd` does not affect the surrounding shell), and both claim
> XPG4 compliance.
They only execute a s
> Maybe if I call the sysctl "vm.crashmenow". No, that will just make more
> people actually try it. It might be doable as a compile-time option,
> since you wouldn't be able to run anything approaching standard on
> such a system anyway. I don't see much use for it myself. As
David Miller wrote:
>
> Couple of questions which are pretty much off topic
>
> 1) Does anyone know of a way to talk to a remote oracle server via odbc or
> oci? Access is required specifically under apache and mod_perl or php,
> but we've spent a couple of man-days looking for straightforw
According to Kris Kirby:
> If they are not shipped, where am I to go to find them?
In the CVS repository. In the Attic of the various subdirectories.
290 [13:04] roberto@keltia:src/sys> ls
Makefile,v ddb/miscfs/ netiso/ posix4/
alpha/ dev/mod
I have a process that forks several times, I want to change the names that the
child processes appear as in the process table. Is there a trick to doing
this?
Thanks,
Wayne
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
setproctitle(3)
Wayne Cuddy wrote:
>
> I have a process that forks several times, I want to change the names that the
> child processes appear as in the process table. Is there a trick to doing
> this?
>
> Thanks,
> Wayne
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe
Ladavac Marino wrote:
>
> This topic has been trashed to death a few months ago. There is no
> win-win situation in presence of processes which allocate a lot of memory
> without actually using it (read: your typical FORTRAN library).
This is not about just Fortran libraries. Imagine a
In C, change argv. Be carefull to not write any strings that are longer
then the space available, or replace the pointers.
Nick
On Wed, 14 Jul 1999, Wayne Cuddy wrote:
> I have a process that forks several times, I want to change the names that the
> child processes appear as in the process
Noriyuki Soda wrote:
>
> Running out of swap can be easily done by normal user privilege.
> Non-overcommiting system can run important application on the system
> which has a normal user, because it never lose critical data, even if
> a user on the system make a mistake. (The application might st
[cutting down on cc's]
"Chris G. Demetriou" wrote:
>
> I'd _really_ like to know how you figure this.
>
> textdatabss dec hex filename
> 45024 4096392 49512 c168/bin/cat
> 311264 12288 9900333452 5168c /bin/sh
> 212960 409628492 245548 3bf2c
Doug Rabson <[EMAIL PROTECTED]> writes:
> Overcommit can be used for many reasons. I use it to reserve a large
> linear address space to mmap alpha i/o spaces [...]
Overcommit can be used for many reasons, but unless you've
misdescribed what you're doing, _that's not one of them_.
The mapped I/O
"Charles M. Hannum" wrote:
>
> That's also objectively false. Most such environments I've had
> experience with are, in fact, multi-user systems. As you've pointed
> out yourself, there is no combination of resource limits and whatnot
> that are guaranteed to prevent `crashing' a multi-user sys
I realize it's not real high on the list of things to fix, but proxy ARP
is still broken in -STABLE. If anyone know the answers to any of these
questions, please drop me a line so I can try fixing it:
1) Can anyone explain the difference between "published" ARP table
entries, and "published (
> "Matthew" == Matthew Dillon <[EMAIL PROTECTED]> writes:
Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will just make
more
Matthew> people actually try it. It might be doable as a compile-time option,
Matthew> since you wouldn't be able to run anyth
"Charles M. Hannum" wrote:
>
> There are many environments where even the possibility of the
> simulation crashing due to external influence is unacceptable. I find
> it sad that you resist making FreeBSD robust against such problems,
> but that's your concern.
FreeBSD is robust against the pro
Robert Elz wrote:
>
> Date:Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
> From:Matthew Dillon <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | If you don't have the disk necessary for a standard overcommit model to
> | work, you definitely do not have
On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
> "Charles M. Hannum" wrote:
> >
> > That's also objectively false. Most such environments I've had
> > experience with are, in fact, multi-user systems. As you've pointed
> > out yourself, there is no combination of resource limits and whatnot
> >
On Wed, 14 Jul 1999, Michael Richardson wrote:
>
> > "Matthew" == Matthew Dillon <[EMAIL PROTECTED]> writes:
> Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will just
>make more
> Matthew> people actually try it. It might be doable as a compile-time
>optio
I am helping a freind install FreeBSD on his machine
(it is running 4.0-CURRENT now). everything works flawlessly, except his
OEM BrookTree 848 based soundcard. The card itself is transplanted from
his gateway machine (where it also had the same problems). Here are some
specifics:
(summary)
M
Can someone familiar with the new threads code tell me what is causing the
following segmentation fault. Thanks.
-Kip
Program terminated with signal 11, Segmentation fault.
#0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
at /usr/src/lib
At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote:
> We don't _need_ pidentd anymore. It will load down a system more
> than the inetd's implementation of ident will. Therefore, pidentd
> should be phased out. Other than that, pidentd should be using
> http://www.FreeBSD.org/~green/freebsd4.c and
Niall Smart wrote in list.freebsd-hackers:
>
> > I'm not sure if XPG4v2 requires command substitution to behave
> > like that. At least, both Solaris' and DEC UNIX... oops...
> > True64 UNIX do execute all command substitutions in a subshell
> > (`pwd` does not affect the surrounding shell)
Even though I am developing on FBSD is there a "more portable" way to do this?
Thanks,
Wayne
On Wed, 14 Jul 1999, Andy Doran wrote:
> Date: Wed, 14 Jul 1999 15:03:55 +0100
> From: Andy Doran <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: FreeBSD Hackers List <[EMAIL PROTECTED]>
> Subject: R
"Chris G. Demetriou" wrote:
>
...
> Overcommit avoidance may not be useful for your particular uses of
> these UNIX-like systems. However, if you think that it's not useful
> to anybody who uses them (or that people who think it's useful are
> deluding themselves 8-), then you're sorely mistaken
Matthew Dillon wrote:
>
> :
> :Heh, really? The camera ships w/ Apache running on it.
> :
> :-- Jason R. Thorpe <[EMAIL PROTECTED]>
>
> They obviously have a lot of memory to play with, then. Or they
> are crazy. Writing a web server is fairly easy to do. I've
> written s
Jason Thorpe wrote:
>
> > There is a lot of hidden 'potential' VM that you haven't considered.
> > For example, if the resource limit for a process's stack is 8MB, then
> > the process can potentially allocate 8MB of stack even though it may
> > actually only allocate 32K of s
At 12:00 PM -0400 7/14/99, Brian F. Feldman wrote:
> So why don't we do something else: when we're down to a certain
> amount of backing store, start collecting statistics. When we're
> out, we check the statistics and find what process has been
> allocating most of it. We kill that process.
Not
Jason Thorpe wrote:
>
> That's just silly. If people want a no-overcommit system, they have it,
> and if they don't, they have that, too.
>
> That's why you make it a switch. No, really, you *can* just make it
> a switch.
So, enlighten me, please... how do you switch it in NetBSD?
--
Daniel
At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> In which case the program that consumed all memory will be killed.
> The program killed is +NOT+ the one demanding memory, it's the one
> with most of it.
But that isn't always the best process to have killed off...
One of my main freebsd mach
"Brian F. Feldman" wrote:
>
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> So why don't we do something else: when we're down to a certain amount of
> backing store, start coll
-BEGIN PGP SIGNED MESSAGE-
Garance A Drosihn wrote:
>At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
>> In which case the program that consumed all memory will be killed.
>> The program killed is +NOT+ the one demanding memory, it's the one
>> with most of it.
>
>But that isn't always
Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way to do this?
setproctitle(3) works at least for FreeBSD and NetBSD. Poke around the
sources of sendmail(8) for a more ... ported way. I'm sure you'll find
something.
- ad
To Unsubscribe: send mail to [EM
Garance A Drosihn wrote:
>
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
>
> But that isn't always the best process to have ki
On Jul 15, 12:20am, "Daniel C. Sobral" wrote:
} "Charles M. Hannum" wrote:
} >
} > That's also objectively false. Most such environments I've had
} > experience with are, in fact, multi-user systems. As you've pointed
} > out yourself, there is no combination of resource limits and whatnot
} >
> I mean, jeeze, the reservation for the program stack alone would eat
> up all your available swap space! What is a reasonable stack size? The
> system defaults to 8MB. Do we rewrite every program to specify its own
> stack size? How do we account for architectural difference
On Wed, 14 Jul 1999 13:28:07 -0400, Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way to
> do this?
See the STANDARDS section of the setproctitle(3) manpage. If you worry
that you may port to an operating system whose setproctitle() has a
different calling
> Can someone familiar with the new threads code tell me what is causing the
> following segmentation fault. Thanks.
>
> -Kip
>
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00)
>
If you wanted to fix this, you could add a patch to malloc that touched
every page that it handed to the application. (and trapped sig11s)
On Wed, 14 Jul 1999 [EMAIL PROTECTED] wrote:
>
> > I mean, jeeze, the reservation for the program stack alone would eat
> > up all your available s
On Wed, 14 Jul 1999, Garance A Drosihn wrote:
> At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote:
> > We don't _need_ pidentd anymore. It will load down a system more
> > than the inetd's implementation of ident will. Therefore, pidentd
> > should be phased out. Other than that, pidentd should b
At 1:28 PM -0400 7/14/99, Wayne Cuddy wrote:
> Even though I am developing on FBSD is there a "more portable" way
> to do this?
The man page for setproctitle(3) notes that none of the ways to do
this are necessarily portable to other systems. That said, I have
a routine from a lambdaMOO program
Ted Faber <[EMAIL PROTECTED]>
>For every strategy there's a counterstrategy.
exactly: the disappointing thing about this whole thread is there's been
little discussion of implementing a (tunable) policy how to handle the
situation when resource shortage materialises.
Overcommitment can be useful,
On Wed, 14 Jul 1999, Daniel Eischen wrote:
> > Can someone familiar with the new threads code tell me what is causing the
> > following segmentation fault. Thanks.
> >
> > -Kip
> >
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x82fb1
> So why don't we do something else: when we're down to a certain amount of
> backing store, start collecting statistics. When we're out, we check the
> statistics and find what process has been allocating most of it. We kill
> that process.
Our IMAP server routinely show a footprint of about 1MB
I just rebuilt libc_r and relinked my application. I am now crashing right
away as opposed to after several hours as I have been.
Program terminated with signal 11, Segmentation fault.
#0 0x82fa07c in _thread_kern_sched_state_unlock ()
(gdb) bt
#0 0x82fa07c in _thread_kern_sched_state_unlock ()
You don't seem to understand that a runaway process/one designed just
to take up memory will be much more active than your little IMAP servers,
and be the one killed, if this scheme were used.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ _
Kip Macy wrote:
> > In the mean time, you can grab libc_r/uthread/* from -current
> > and rebuild libc_r under -stable.
>
> Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a
> result of a problem with infinite recursion in write. When was this bug
> fixed?
The fix for static
> You don't seem to understand that a runaway process/one designed just
> to take up memory will be much more active than your little IMAP servers,
> and be the one killed, if this scheme were used.
No, what I don't understand is how the current behaviour can tell that
my temporary and *valid* n
Kip Macy wrote:
> I just rebuilt libc_r and relinked my application. I am now crashing right
> away as opposed to after several hours as I have been.
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x82fa07c in _thread_kern_sched_state_unlock ()
> (gdb) bt
> #0 0x82fa07c in _thr
On Mon, Jul 12, 1999 at 01:22:49PM -0700, Julian Elischer wrote:
< talking about the recent paper on using KLDs to replace FreeBSD syscalls >
> I would suggest that a version of this document be incorporated into our
> docs.
I've already e-mailed the people concerned to ask. I'll let you know
At 2:40 AM +0900 7/15/99, Daniel C. Sobral wrote:
>Garance A Drosihn wrote:
>>
>> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
>> > In which case the program that consumed all memory will be killed.
>> > The program killed is +NOT+ the one demanding memory, it's the one
>> > with most of it.
On 14 Jul 1999, Chris G. Demetriou wrote:
> Doug Rabson <[EMAIL PROTECTED]> writes:
> > Overcommit can be used for many reasons. I use it to reserve a large
> > linear address space to mmap alpha i/o spaces [...]
>
> Overcommit can be used for many reasons, but unless you've
> misdescribed what
> What you don't understand is that no process is going to die unless either
> someone is running away (in which case they'll get the bullet) or your
> system is horribly misconfigured (in which case you deserve your fate).
*Why* the machine is out of memory is not the issue. The issue is
what h
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "David O'Brien" writes:
> : Since no one has repsonded to this querry, I will be un-staticizing these
> : so they will be available to drivers.
>
> No. Please don't. This is the first I've seen this.
On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
> For the record, professional digital cameras go into the $100K
> range, so I'd be expecting it not only to run Apache, but also to
> come with Doom. :-)
Well you have 16MB RAM, 32MB flash memory, a network interface,
other bits and N
In message <[EMAIL PROTECTED]>, Scott Mitchell writes:
>Ugh. In that case, can someone back out Poul-Henning's changes to the
>if_xe.c in the -STABLE tree?
Uhm my change has not been applied to STABLE, but the 3.2-PAO import
references current rather than stable.
--
Poul-Henning Kamp
On Jul 15, 12:53am, "Daniel C. Sobral" wrote:
} Robert Elz wrote:
} >
} > From:Matthew Dillon <[EMAIL PROTECTED]>
} >
} > | If you don't have the disk necessary for a standard overcommit model to
} > | work, you definitely do not have the disk necessary for a non-overcomm
> "John" == John Nemeth <[EMAIL PROTECTED]> writes:
John> On one system I administrate, the largest process is typically
John> rpc.nisd (the NIS+ server daemon). Killing that process would be a
John> bad thing (TM). You're talking about killing random processes.
John> This i
On Jul 15, 2:40am, "Daniel C. Sobral" wrote:
} Garance A Drosihn wrote:
} > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
} > > In which case the program that consumed all memory will be killed.
} > > The program killed is +NOT+ the one demanding memory, it's the one
} > > with most of it.
}
> "Ben" == Ben Rosengart <[EMAIL PROTECTED]> writes:
Ben> On Wed, 14 Jul 1999, John Nemeth wrote:
>> On one system I administrate, the largest process is typically
>> rpc.nisd (the NIS+ server daemon). Killing that process would be a
>> bad thing (TM). You're talking about
Hi,
I'm trying to dynamically determine the tcp windowsize. Sysctl
has the following to say, but the name/value pairs are not
documented.
net.inet.tcp.rfc1323: 0
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.rttdflt: 3
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
101 - 200 of 261 matches
Mail list logo
