Re: Reading CIS from kernel?

1999-07-14 Thread Warner Losh
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

Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)

1999-07-14 Thread Seigo Tanimura
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+

Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)

1999-07-14 Thread Seigo Tanimura
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 the

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Doug Rabson
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 sparse use

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: 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

Re: Which device should I make with this error?

1999-07-14 Thread Reinier Bezuidenhout
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Robert Elz
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Niall Smart
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 I

Re: X.25 drivers

1999-07-14 Thread Ollivier Robert
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/

changing argv[0] after fork()

1999-07-14 Thread Wayne Cuddy
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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 stop,

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Chris G. Demetriou
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

Final (maybe) ARP breakage plea

1999-07-14 Thread Jasper O'Malley
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Brian F. Feldman
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 that are

brooktree 848 OEM card/no sound :(

1999-07-14 Thread David E. Cross
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)

Re: bin/12578: `` subshell taints PWD

1999-07-14 Thread Oliver Fromme
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), and

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
"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 and

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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 several,

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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 stack.

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Garance A Drosihn
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
"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 collecting

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Julian Elischer
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 swap

Re: a BSD identd

1999-07-14 Thread Doug
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 be

Re: changing argv[0] after fork()

1999-07-14 Thread Garance A Drosihn
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

Re: Swap overcommit

1999-07-14 Thread Danny Thomas
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,

new seg fault in thread code

1999-07-14 Thread Kip Macy
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Brian F. Feldman
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] _ __

Re: seg fault in mutex_queue_enq

1999-07-14 Thread Daniel Eischen
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread lyndon
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*

Re: (forw)

1999-07-14 Thread Nik Clayton
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Doug Rabson
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 you're

Re: Swap overcommit

1999-07-14 Thread lyndon
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

Re: Reading CIS from kernel?

1999-07-14 Thread Scott Mitchell
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. There

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread David Brownlee
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

Re: Reading CIS from kernel?

1999-07-14 Thread Poul-Henning Kamp
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Michael Richardson
"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 is no way

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread John Nemeth
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. } }

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Michael Richardson
"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 killing

tcp windowsize query?

1999-07-14 Thread John W. DeBoskey
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

Re: tcp windowsize query?

1999-07-14 Thread Mike Smith
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.sendspace: 16384 net.inet.tcp.recvspace: 16384 ... send/recv space might be what I'm looking for... They're the default

Re: tcp windowsize query?

1999-07-14 Thread Matthew Dillon
: net.inet.tcp.recvspace: 16384 :... :send/recv space might be what I'm looking for... : :They're the default send/receive window sizes, yes. You can tweak them :with socket ioctls on a per-socket basis. : :delayed ack sounds interesting : :Turning that off disables TCP slow-start.

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Robert Elz
Date:Thu, 15 Jul 1999 00:53:17 +0900 From:"Daniel C. Sobral" [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Would you care to name such systems? munnari was one (the system of the From: header, even though this mail isn't actually going anywhere near it). I

Re: tcp windowsize query?

1999-07-14 Thread David Greenman
delayed ack sounds interesting Turning that off disables TCP slow-start. It's a huge performance booster for things like SMB service, where you have lots of short-lived TCP connections on a local net. Uh, that's not what it does. Slow start is a behavior where the sender opens the

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
:Now let's look at what happens with the two methods. : :With all VM backed by real mem or swap space, processes go about allocating :memory - when there is no more left, the allocations start failing. :If the process is perl, it just collapses in a heap, and the log file :summary doesn't get

Re: new seg fault in thread code

1999-07-14 Thread Kip Macy
Do you want an executable? Anyway, I compiled the tests in /usr/src/lib/libc_r/test/ and they both seg faulted in the exact same way: Note: I had to add the -static to the LDFLAGS in order for gdb to find symbols for them. adsl-216-101-22-188 [libc_r/test/sigwait|14:14|210|]gdb sigwait

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Jason Thorpe
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: What does that have to do with overcommit? I student administrate a undergrad CS lab at a university, and when student's programs misbehaved, they generate a fault and are killed. The only machines that

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread sthaug
Also, your named is badly misconfigured if it grows to 130MB. We never allow ours to grow past 30MB. How do you know what kind of name server configuration kre is running? Here's an example of a name server running *non-recursive*, serving 11.500 zones: PID USERNAME PRI NICE SIZE

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: : Also, your named is badly misconfigured if it grows to 130MB. We never : allow ours to grow past 30MB. : :How do you know what kind of name server configuration kre is running? :Here's an example of a name server running *non-recursive*, serving :11.500 zones: : : PID USERNAME PRI

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
:On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) : John Baldwin [EMAIL PROTECTED] wrote: : : What does that have to do with overcommit? I student administrate a undergrad : CS lab at a university, and when student's programs misbehaved, they generate a : fault and are killed. The only machines

Re: Reading CIS from kernel?

1999-07-14 Thread Warner Losh
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? That's (I hope) the only thing stopping it : from working. At least that way only my code will be bogus :-) Believe : me, I know it's

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Wed, 14 Jul 1999 12:43:07 + Niall Smart [EMAIL PROTECTED] wrote: Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:52:11 +0900 "Daniel C. Sobral" [EMAIL PROTECTED] 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

Re: dbm_* manpages for review

1999-07-14 Thread Nik Clayton
On Thu, Jul 08, 1999 at 10:22:47PM +0100, Nik Clayton wrote: Tim Singletary has written some man pages for the dbm_* functions in libc, which are currently undocumented -- we know they are written in terms of dbopen(), but it's nice to have them documented anyway. Could anyone who knows

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:59:12 +0900 "Daniel C. Sobral" [EMAIL PROTECTED] wrote: 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? When the code to do it is implemented (not that hard, really,

Re: Swap subsystem overhead (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Nik Clayton
On Tue, Jul 13, 1999 at 05:12:30PM -0700, Matthew Dillon wrote: Ok, I will be more specific. Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata structures that scale to the amount of swap space assigned to the system. However, it is not *precisely* the

Re: a BSD identd

1999-07-14 Thread Harold Gutch
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 should be using

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: :One option is to special-case overcommit the stack. Another is to :set the default stack limits to something more reasonable on a system :where overcommit is disabled. : :-- Jason R. Thorpe [EMAIL PROTECTED] Try setting all the resource limits to something reasonable on general

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Nate Williams
[ Trimmed CC list a bit ] :* even if you are not willing to pay that price, there _are_ people :who are quite willing to pay that price to get the benefits that they :see (whether it's a matter of perception or not, from their :perspective they may as well be real) of such a scheme.

Re: docs/12377: doc patch for login_cap.

1999-07-14 Thread Nik Clayton
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote: On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? This looks much better. :-)

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: : Quite true. In the embedded world we preallocate memory and shape : the programs to what is available in the system. But if we run out : of memory we usually panic and reboot - because the code is designed : to NOT run out of memory and thus running out of memory is a

Re: tcp windowsize query?

1999-07-14 Thread Mike Smith
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: delayed ack sounds interesting Turning that off disables TCP slow-start. It's a huge performance booster for things like SMB service, where you have lots of short-lived TCP connections on a local net. Mike

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: :Most of the work we've done wouldn't allow this, especially if we were :using an OS like FreeBSD with a fairly long bootup time. Especially if :it can be avoided. : :Yes, we could (and did) do our own memory management, but it seems to me :that the kernel has alot more information available

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Nate Williams
:Most of the work we've done wouldn't allow this, especially if we were :using an OS like FreeBSD with a fairly long bootup time. Especially if :it can be avoided. : :Yes, we could (and did) do our own memory management, but it seems to me :that the kernel has alot more information

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Nate Williams
: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, it

misc/12633: CMI8330 chip based integrated sound card produce no output

1999-07-14 Thread Maksim Yevmenkin
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Kevin Schoedel
On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" [EMAIL PROTECTED] 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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Sergey Babkin
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 killed

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Garance A Drosihn
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 worthwhile to

Re: a BSD identd

1999-07-14 Thread Brian F. Feldman
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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
: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

Re: changing argv[0] after fork()

1999-07-14 Thread Warner Losh
In message [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit

1999-07-14 Thread Mark Newton
[EMAIL PROTECTED] 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.

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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're

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
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 what

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Daniel C. Sobral
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 stack.

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
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 lowest

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
: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

Re: Swap overcommit

1999-07-14 Thread Matthew Dillon
: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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: 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

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
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 arbitrary

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
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 was

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
[EMAIL PROTECTED] 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 one

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Daniel C. Sobral
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Mike Smith
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

Re: gdb instead of adb

1999-07-14 Thread Mike Smith
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,

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Tim Vanderhoek
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 exactly

Re: more amd hangs: problem really in syslog?

1999-07-14 Thread Mike Smith
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

Re: seg fault in mutex_queue_enq

1999-07-14 Thread Thomas Gellekum
Daniel Eischen [EMAIL PROTECTED] 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

Re: Reading CIS from kernel?

1999-07-14 Thread Warner Losh
In message 19990713182203.a68...@nuxi.com 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

Re: Reading CIS from kernel?

1999-07-14 Thread Warner Losh
In message 19990713210337.h85...@remarq.com 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 majord...@freebsd.org with unsubscribe freebsd-hackers in

Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)

1999-07-14 Thread Seigo Tanimura
On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson d...@nlsystems.com 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+

Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)

1999-07-14 Thread Seigo Tanimura
On Wed, 14 Jul 1999 15:54:22 +0900, Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp said: tanimura Thus a callout will have an average delay of 0.5/hz = 50ms. This is 5ms, I mean... Seigo Tanimura tanim...@naklab.dnj.ynu.ac.jp To Unsubscribe: send mail to majord...@freebsd.org with

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Doug Rabson
On Tue, 13 Jul 1999, Jon Ribbens wrote: Alfred Perlstein bri...@rush.net 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 sparse use of

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: 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

Re: Which device should I make with this error?

1999-07-14 Thread Reinier Bezuidenhout
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Kris Kennaway
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 implementation

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Gregory Sutter
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 what I

WaveLAN broken (repost)

1999-07-14 Thread FreeBSD MAIL
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

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jon Ribbens
Doug Rabson d...@nlsystems.com 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 TIME

  1   2   3   >