After pounding on this some more with today's -current (prior to
the MNT_ASYNC flag change) I got a lot more lockups that looked like
this:
On Mon, 12 Jul 1999, Doug wrote:
> Ok, got another hang in "siobi" state (this time after it
> successfully completed the script). Here is th
How hard would it be to add a sysctl variable that controlled whether or not
the system would overcommit memory?
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send
On Tue, 13 Jul 1999 13:20:55 MST, Doug wrote:
> After confirming that it worked with no logging, I tried enabling
> logging to a regular file, and that also worked like a charm. After
> turning syslog style logging back on, it locked up cold, with a very
> similar traceback.
Sheesh, Mark
Look fairly robust:
http://vxatape.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> Doh! Even solaris doesn't overcommit - you think it actually
> reserves data blocks for its file-backed swap? Bzzt! It uses
> an overcommit model too.
Unlike 4.4BSD derived VM, Solar
:How hard would it be to add a sysctl variable that controlled whether or not
:the system would overcommit memory?
:
:-Archie
:
:___
:Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Archie, the
On Tue, 13 Jul 1999 11:59:25 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> We could have the ability to mark processes as being more or less
> preferable as kill candidates. I'm not sure I really care anymore,
> though... there is so much disk space available now that
:
:On Tue, 13 Jul 1999 11:59:25 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > We could have the ability to mark processes as being more or less
: > preferable as kill candidates. I'm not sure I really care anymore,
: > though... there is so much disk space available
:
:> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT),
: Matthew Dillon <[EMAIL PROTECTED]> said:
:
:> Doh! Even solaris doesn't overcommit - you think it actually
:> reserves data blocks for its file-backed swap? Bzzt! It uses
:> an overcommit model too.
:
:Unlike 4.4BSD derived
> On Tue, 13 Jul 1999 14:16:54 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> > Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store.
> Secondly, for such a server to fail to run is just as bad as if
> the system were to run out of swap.
> IRI
>
>
> Look fairly robust:
>
> http://vxatape.com
Their online documentation suggests that this is a stock-standard SCSI
tape device. A refreshing change. 8)
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ [EMAIL PROTECTED]
\\-- Joseph Merrick
:
: So I started thinking that maybe the problem was actually in
:syslog (or amd's interface to it). So I disabled the following two options
:in my amd.conf file:
:
:log_file = syslog:local7
:log_options =all
:
: And lo and behold, it worked like a charm. I was
Matthew Dillon writes:
> :How hard would it be to add a sysctl variable that controlled whether or not
> :the system would overcommit memory?
>
> Archie, the question is barely worth answering. Nobody advocating this
> stuff has even begun to think-out the ramifications. Adding such a k
:> Secondly, for such a server to fail to run is just as bad as if
:> the system were to run out of swap.
:
:> IRIX has a swap reservation flag too, a left-over from the SysV days.
:> It is a totally useless flag.
:
:That's wrong.
:On such systems, critical server has a chance to s
On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> 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-overcommit
> model to work.
You obviously didn't pay atte
:> ram and 512MB of swap (4MB of swap in use), but the kernel reports over
:> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine.
:
:What you say is generally true; however, the problem is that *you*
:are making implicit assumptions about what applications *I* might
On Tue, 13 Jul 1999 14:16:54 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> ... and it doesn't mean squat. What, the absolutely critical server
> that you are trying to run decides to exit because it can't guarentee
> sufficient backing store? First of all, this situat
> After pounding on this some more with today's -current (prior to
> the MNT_ASYNC flag change) I got a lot more lockups that looked like
> this:
>
> On Mon, 12 Jul 1999, Doug wrote:
>
> > Ok, got another hang in "siobi" state (this time after it
> > successfully completed the script)
On Tue, 13 Jul 1999 14:27:54 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> You are assuming that the situation actually occurs. In real life,
> it will not occur unless the critical server is running away with
> memory.
>
> I have never, ever run one of BEST's s
:
:On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > 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-overcommit
: > model to work.
:
:You obviously didn
> On Tue, 13 Jul 1999 14:27:54 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> > That's wrong.
> > On such systems, critical server has a chance to save it's data to
> > filesystem.
> > On 4.4BSD derived systems, it cannot be guaranteed.
> You are assuming that the situat
On Tue, 13 Jul 1999 14:31:38 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :- I might be creating a very limited embedded system with just a few
> : small processes that are all written to *handle* out of memory situations.
>
> Really? Then setting resource limits from with
Matthew Dillon <[EMAIL PROTECTED]> writes:
> 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-overcommit
> model to work.
I'd _really_ like to know how you figure this.
textdatabss de
: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 stop,
:but it never lose data
:
:On Tue, 13 Jul 1999 14:27:54 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > You are assuming that the situation actually occurs. In real life,
: > it will not occur unless the critical server is running away with
: > memory.
: >
: > I have never, ever run one
Matthew Dillon <[EMAIL PROTECTED]> writes:
> Fine... you have ultimate design control over every process running on
> the system. Simply set appropriate resource limits for the processes
> run by the system and you are done.
For some value of ultimate control.
Reality these days
:
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> 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-overcommit
:> model to work.
:
:I'd _really_ like to know how you figure this.
:
:textdata
:
:See chris's point... Maybe you have one process that needs 10MB and a few
:others that need 300K - 1MB. Resource limits are not useful in this
:scenario.
:
:...and, who said anything about using malloc()? :-)
:
:-- Jason R. Thorpe <[EMAIL PROTECTED]>
Sure they are.
limit
> On Tue, 13 Jul 1999 14:53:43 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> If you are talking about a user intentionally attempting to run
> a system out of swap, it is fairly easy to do whether the system
> uses an overcommit model or not. The user has any nu
:For some value of ultimate control.
:
:Reality these days is that if you want an embedded system based on
:UNIX that both doesn't suck and that has the features you need, you
:have to take _some_ off the shelf software components, glue them
:together as simply as possible, and do what you can to
On Tue, 13 Jul 1999 14:56:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Jason, I am using real life situations to demonstrate my point. You are
> perfectly welcome to use your own REAL-LIFE situations to demonstrate
> yours. It is the real-life application that ma
:> a system out of swap, it is fairly easy to do whether the system
:> uses an overcommit model or not. The user has any number of
:> ways of blowing the server up too - for example, by making
:> thousands of connections to it or running many huge queries in
:> parallel.
:
:I
On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> The text size of a program is irrelevant, because swap is never
> allocated for it. The data and BSS are only relevant when they
> are modified.
Bzzt. BSS is relevant when accessed (at least i
:Jason Thorpe wrote:
:>
:> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
:> Matthew Dillon <[EMAIL PROTECTED]> wrote:
:>
:> > 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-overcommit
:> > mode
:Yes, you're using your own REAL-LIFE situations, from a large ISP, using
:systems for a few specific server applications, where you have the space
:to put lots of disk, etc.
:
:The things I'm thinking of aren't even necessarily "large server"
:applcations. NetBSD runs on a CPU that is *often* us
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> This is an excellent example of a solution. Another example would be
> to implement your own memory management subsystem... that is, your own
> shared library which keeps track of memory allocations on a global
> basis. I could do one
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> When you write embedded systems like these, you do not run any general
> purpose binaries at all. You run fully custom binaries and you take
> control of the memory management yourself.
Heh, r
:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > The text size of a program is irrelevant, because swap is never
: > allocated for it. The data and BSS are only relevant when they
: > are modified.
:
:Bzzt. BSS is relevant when accessed (at
> On Tue, 13 Jul 1999 15:29:37 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> In the same manner any truely critical system server must handle the
> resource management itself to deal with all sorts of problem situations,
> including memory. You do not need to bu
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> :
> : So I started thinking that maybe the problem was actually in
> :syslog (or amd's interface to it). So I disabled the following two options
> :in my amd.conf file:
> :
> :log_file = syslog:local7
> :log_options =all
>
On Tue, 13 Jul 1999, Mike Smith wrote:
> > After pounding on this some more with today's -current (prior to
> > the MNT_ASYNC flag change) I got a lot more lockups that looked like
> > this:
> >
> > On Mon, 12 Jul 1999, Doug wrote:
> >
> > > Ok, got another hang in "siobi" state (this ti
:
:On Tue, 13 Jul 1999, Matthew Dillon wrote:
:
:> This is an excellent example of a solution. Another example would be
:> to implement your own memory management subsystem... that is, your own
:> shared library which keeps track of memory allocations on a global
:> basis. I cou
:
: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 several, including the one that BEST runs
> On Tue, 13 Jul 1999, Mike Smith wrote:
>
> > > After pounding on this some more with today's -current (prior to
> > > the MNT_ASYNC flag change) I got a lot more lockups that looked like
> > > this:
> > >
> > > On Mon, 12 Jul 1999, Doug wrote:
> > >
> > > > Ok, got another hang in
:> kernel.
: :
: [snip]
: :
:> To say that FreeBSD does not support a certain class of system because
:> it uses an overcommit model is not correct, because you can trivially
:> solve the problem by implementing your own management of memory rather
:> then us
:*.err;kern.debug;auth.notice;mail.crit /dev/console
:*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
:mail.info /var/log/maillog
:lpr.info/var/log/lpd-errs
:cron.*
Matthew Dillon <[EMAIL PROTECTED]> writes:
> The text size of a program is irrelevant, because swap is never
> allocated for it. The data and BSS are only relevant when they
> are modified.
>
> The only thing swap is ever used for is the dynamic allocation of memory.
> There
-BEGIN PGP SIGNED MESSAGE-
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?
Would adding the sysctl to turn off overcommit be a costly,
time-consuming hunk of work,
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> So far nobody has been able to justify any good reasons for adding it
> to the system. I'm sorry, but just throwing out worst-case theories
> is not a good justification, nor is throwing embedde
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. No way to cle
: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?
:
:Would adding the sysctl to turn off overcommit be a costly,
:time-consuming hunk of work, or a three-line patch? If it's
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> Comment the whole thing out, kill -HUP the syslogd (or kill and restart
> it), and see if amd still locks up.
Ok, now I think I get it. You want me to enable syslog'ing in amd,
then do what you're talking about here. I will try this fi
Matthew Dillon writes:
> :> ram and 512MB of swap (4MB of swap in use), but the kernel reports over
> :> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine.
> :
> :What you say is generally true; however, the problem is that *you*
> :are making implicit assumptions about wha
> 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?
The issue here is that "turning off overcommit" isn't just a switch.
There are a lot of other things that you're likely
:
:Well, all I can say is:
:
: I'm sure glad you don't have any influence over the code
: base I run.
:
:-- Jason R. Thorpe <[EMAIL PROTECTED]>
I'm sure the feeling is mutual. More to the point, I really seriously
doubt that any of the core developers would consider
On Tue, 13 Jul 1999 16:16:07 -0700
Mike Smith <[EMAIL PROTECTED]> wrote:
> Matt's point, which he's not making by virtue of talking too much, is
> that you can't make a "no overcommit" system behave like an "overcommit"
> system, and most people are used to the sort of things that the latte
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> I'm sure the feeling is mutual. More to the point, I really seriously
> doubt that any of the core developers would consider this idea either
> because it's been rejected in the past and, so fa
:(Mike Smith <[EMAIL PROTECTED]>)
:Matt's point, which he's not making by virtue of talking too much, is
:that you can't make a "no overcommit" system behave like an "overcommit"
:system, and most people are used to the sort of things that the latter
:makes practical.
Heh heh.
:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > I'm sure the feeling is mutual. More to the point, I really seriously
: > doubt that any of the core developers would consider this idea either
: > because it's been rejected in the past and
> On Tue, 13 Jul 1999 16:16:07 -0700
> Mike Smith <[EMAIL PROTECTED]> wrote:
>
> > Matt's point, which he's not making by virtue of talking too much, is
> > that you can't make a "no overcommit" system behave like an "overcommit"
> > system, and most people are used to the sort of things th
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith <[EMAIL PROTECTED]> wrote:
> You can make the "overcommit or not overcommit" option a switch, but
> the consumers of the system (may) need to change their behaviour as
> well.
I never said they wouldn't have to.
-- Jason R. Thorpe <[E
> On Tue, 13 Jul 1999 16:29:50 -0700
> Mike Smith <[EMAIL PROTECTED]> wrote:
>
> > You can make the "overcommit or not overcommit" option a switch, but
> > the consumers of the system (may) need to change their behaviour as
> > well.
>
> I never said they wouldn't have to.
"Making it jus
> Doug wrote:
> > John Polstra wrote:
> >>
> >> Are you sure? If you simply don't run an identd, the queries will
> >> get an instant connection refused error. That's even faster than
> >> sending back a bogus response.
> >
> > Many daemons that request ident, and almost all IRC daemons
>
>:
>:Well, all I can say is:
>:
>: I'm sure glad you don't have any influence over the code
>: base I run.
>:
>:-- Jason R. Thorpe <[EMAIL PROTECTED]>
>
>I'm sure the feeling is mutual. More to the point, I really seriously
>doubt that any of the core developers would c
Matthew Dillon scribbled this message on Jul 13:
> FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This
> is due to the design of the interleaving algorithms. Increasing this
> number is simple, but it results in phenominally more kernel memory
> getting wired.
:> And disallowing overcommit also does not give applications the *choice*
:> of dealing gracefully, because they often cannot deal with the
:> situation where they might be refused a reasonable request for memory.
:
:That's objectively false. The application could do something usefu
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> You have to consider the probability of an event occuring, not just
> the possibility that the event might occur. If the probability is
> one in a million years, then it is not something you ne
> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> ... a situation which will never occur if you are managing the memory
> through your own custom library. Therefore not relevant.
Hm. It's misunderstanding.
I don't agree with you about th
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a million years, then it is not so
:hmmm... so this means that on my home server where I have:
:Device 1K-blocks UsedAvail Capacity Type
:/dev/od0b 26214431176 23084012%Interleaved
:/dev/da1b 39321631136 361952 8%Interleaved
:/dev/da2b 26214431072 23094412%Inte
On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote:
> It's "out with the bad, in with the good." Pidentd code is pretty
> terrible.
Hi Brian,
I let your comment above go at the time that you said it and I waited
for Kevin Day to substantiate similar claims. Kevin very kindly took
th
:
:On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > You have to consider the probability of an event occuring, not just
: > the possibility that the event might occur. If the probability is
: > one in a million years, then it is not somethi
-BEGIN PGP SIGNED MESSAGE-
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 implementation would
:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:>Give me a shell and I can crash any machine. If you are assuming
:>hostile users, you cannot assume that your magic overcommit protection
:>will save your server.
> I was checking out the firewall setup in /etc/rc.firewall, and noticed that
> the simple example relied on a fixed IP address for the external interface. I
> don't know ahead of time what IP address is going to be allocated to me before
> I dial up. Would it be possible to specify an interfac
> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> With today's modern high capacity disk drives, a properly configured
> multi-user system will have enough swap that running it out is difficult
> to say the least.
That's wrong.
Please
:> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT),
: Matthew Dillon <[EMAIL PROTECTED]> said:
:
:> With today's modern high capacity disk drives, a properly configured
:> multi-user system will have enough swap that running it out is difficult
:> to say the least.
:
:That's wrong.
> On Tue, 13 Jul 1999 17:53:10 -0700 (PDT),
Matthew Dillon <[EMAIL PROTECTED]> said:
> You keep on saying that users can run the system out of swap
> easily, and I've tried to point out to you that it isn't quite
> as easy as you believe (and I've used a real-life example
Thanks for every one's help - I now have it working nicely. It's amazing what
you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
scan (after I've allowed only smtp & ssh to be connected to) gives the
following -
# ./nmap -v -v -sX foo
Starting nmap V. 2.12 by Fyodor
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from
> its probe routine, in order to identify the type of card and to beat
...
> then making crdread() and crdwrite() (in /sys/pccard/pccard.c)
> non-static and calling them directly from the driver code would be an
> easy
:
:> Has your simulation ever been kicked by the kernel due to lack of
:> swap space?
:
:I already said so. Please at least pretend to read what I wrote
:before replying.
:
:There is a big difference here between a piddling web server and a
:1000-hour simulation. If the web server goes d
> Stephen Hocking wrote:
> you discover when RTFMing. Oddly enough, running nmap with
> the Christmas tree
> scan (after I've allowed only smtp & ssh to be connected to)
> gives the
> following -
>
> Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com
> Nmap run completed -- 1
On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote:
> [about cdread()/cdwrite() in /sys/pccard/pcccard.c]
>
> Since no one has repsonded to this querry, I will be un-staticizing these
> so they will be available to drivers.
This is going to be for both -current and MFC'd back into -st
:Thanks for every one's help - I now have it working nicely. It's amazing what
:you discover when RTFMing. Oddly enough, running nmap with the Christmas tree
:scan (after I've allowed only smtp & ssh to be connected to) gives the
:following -
:
:# ./nmap -v -v -sX foo
:
:Starting nmap V. 2.12 b
>The point is, the OS should have provided *some* mechanism to insure
>that the long-running process wasn't affected. It didn't. That's a
>clear failure of the OS to provide a reasonable environment for this
>type of computing.
>
>Whether this should be solved by switching to a no-overcommit pol
:> swap. How much swap is on this system, by the way?
:
:I could just as rightfully argue that you're blaming a failure of the
:OS on the sysadmin. Fiddling with limits is all fine and dandy, but
:it's not even close to flexible enough. Consider, for example, the
:specific case of testing a
: I've long felt that the best solution to problems like this is a per-user
:swap space quota. This gives admins a knob to manage the allocation of swap
:space while still allowing overcommit. The downside is that it doesn't provide
:a graceful way for a program to recover from it's overconsump
On 14-Jul-99 Jason Thorpe wrote:
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a
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 not linking with libkvm.
Brian Fundakowski Feldman _
is there some reason why whether or not to overcommit can't be a kernel
compile time option?
Or that a process can signal its desire to not get SIGKILL by registering
a non-default SIGDANGER (which we'd have to create) handler ala AIX?
] Train travel features AC outlets with no take-off res
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> There are other ways. For example, even if a user account is resource
> limited, root processes (such as sendmail, popper, identd, and so forth)
> are not. Attacks against these servers generally result in very high
> loads and someti
On Tue, 13 Jul 1999, Matthew Dillon wrote:
> Jason, I am using real life situations to demonstrate my point. You are
> perfectly welcome to use your own REAL-LIFE situations to demonstrate
> yours. It is the real-life application that matters, not a worst-case
> nightmare theor
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. There will be
another cis reading interface as part of the newbusificat
In message <[EMAIL PROTECTED]> Ade Lovett writes:
: This is going to be for both -current and MFC'd back into -stable, yes?
The interface for doing this I'll be merging back into -stable.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of th
On Thu, 8 Jul 1999 09:54:42 +0100 (BST),
Doug Rabson <[EMAIL PROTECTED]> said:
dfr> If I understand this correctly, you are suggesting that we program timer0
dfr> so that we only take interrupts when a finetimer is due to fire? If so,
dfr> then it sounds very good. The idea of taking 6000+ inte
On Wed, 14 Jul 1999 15:54:22 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
tanimura> Thus a callout will have an average delay of 0.5/hz = 50ms. This is
5ms, I mean...
Seigo Tanimura <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
On Tue, 13 Jul 1999, Jon Ribbens wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> > You're browsing with netscape and It hits about 32megs in size,
> > you click on a multimedia object and netscape execs a helper app.
>
> vfork()
>
> > you also have to consider a program wishing to make s
: Back on topic:
:
: Obviously you devote the most time to handling the most common
: and serious failure modes, but if someone else if willing to
: put in the work to handle nightmare cases, should you ignore or
: discard that work?
Of course not. But nobody i
201 - 298 of 298 matches
Mail list logo
