Linux-Development-Sys Digest #325, Volume #6 Sun, 24 Jan 99 10:19:19 EST
Contents:
Re: TAO: the ultimate OS (Jeremy Crabtree)
Modest next goal for Linux (Liang-Shing Ng)
Re: Modest next goal for Linux (Leslie Mikesell)
Re: Modest next goal for Linux (Christopher B. Browne)
Re: disheartened gnome developer (David M. Cook)
Re: disheartened gnome developer (John Hasler)
Re: Modest next goal for Linux (Tim Smith)
Re: Modest next goal for Linux (Chris Lee)
Re: Modest next goal for Linux (Leslie Mikesell)
Re: Modest next goal for Linux (mlw)
Re: Modest next goal for Linux (Christopher B. Browne)
Re: 2.2pre9 won't compile (Antoni Lapinski)
test box
Re: problems with 2.2.0-final and export of NFS mounted file systems (Mumit Khan)
New driver, need help with skb's... (Mike Ireton)
test box login
Re: kernel: VFS: No free inodes - contact Linus (Paul Martin)
test box
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jeremy Crabtree)
Crossposted-To:
alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.sys.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 23 Jan 1999 18:30:27 GMT
Reply-To: [EMAIL PROTECTED]
[Once again my news server was slower than my mail server...you'll get this,
and a reply by email]
steve mcadams allegedly wrote:
>[Snipped for brevity, quoted material marked with ">"]
>On 22 Jan 1999 23:26:32 GMT, [EMAIL PROTECTED] (Jeremy Crabtree)
>wrote:
>
>>Better yet, show us the agreement you made with Tao Systems that let's you
>>use the name of /their/ OS
>
>I doubt they can prevent it. It's not like they invented the word Tao
>ya know, it's been around for what, 4,000 years?
Maybe, but that doesn't mean they can't send in the "Laeyrs that wouldn't die!"
<insert cheesy horror flick music> to hassle you. I was just trying to warn you
in advance.
Best of luck with the OS.
--
"Being myself a remarkably stupid fellow, I have had to unteach myself
the difficulties, and now beg to present to my fellow fools the parts
that are not hard" --Silvanus P. Thompson, from "Calculus Made Easy."
------------------------------
From: [EMAIL PROTECTED] (Liang-Shing Ng)
Crossposted-To: comp.os.linux.advocacy
Subject: Modest next goal for Linux
Date: 23 Jan 1999 19:17:19 -0000
Maybe Linux still has a long way to go to catch up with "modern" OS like
Be in handling real time data and events.
But I just have a modest request to all you great kernel hackers out there:
Is it possible to achieve my modest requirement of "guanranteed limited
time response" in X window? i.e. When my Netscape started swapping, I
want my cursor can still be responsive and move on to other windows and
do some things.
I think if this problem can be solved, then most of the perceived
sluggishness of GTK and KDE (mem hog etc) will be bypassed (if not
solved). Then I will be really happy.
By the way, I am using an VOP5PC (Very Old Pentium Class Personal
Computer) P75 with 24MB ram. Don't laugh. The guanranteed response
problem has to be solved, and has to be solved especially on old
systems!
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: 23 Jan 1999 14:25:48 -0600
In article <78d77v$[EMAIL PROTECTED]>,
Liang-Shing Ng <[EMAIL PROTECTED]> wrote:
>
>Maybe Linux still has a long way to go to catch up with "modern" OS like
>Be in handling real time data and events.
>
>But I just have a modest request to all you great kernel hackers out there:
>
>Is it possible to achieve my modest requirement of "guanranteed limited
>time response" in X window? i.e. When my Netscape started swapping, I
>want my cursor can still be responsive and move on to other windows and
>do some things.
Even if you gave the screen display priority and kept the X code
from being swapped out, this request doesn't make much sense.
Why would you expect those 'other things' that you want to
display to work any faster while the RAM to run them is also
swapped to disk?
>I think if this problem can be solved, then most of the perceived
>sluggishness of GTK and KDE (mem hog etc) will be bypassed (if not
>solved). Then I will be really happy.
>
>By the way, I am using an VOP5PC (Very Old Pentium Class Personal
>Computer) P75 with 24MB ram. Don't laugh. The guanranteed response
>problem has to be solved, and has to be solved especially on old
>systems!
The easy way is to run two machines. Run nothing but the Xserver
on the box in front of you and run the apps all on another box
over the network. The swapping activity of the apps box will
then be unable to affect your display, which might also have
windows connected to more reponsive machines at the same time.
Doing everything on one box with insufficient RAM is really
impossible, especially on a box where the disk controller is
CPU driven like most IDE drives. With busmastering DMA SCSI
drives,you could theoretically keep the CPU servicing high
priority jobs while the RAM/disk swapping happened, but when
the CPU has to handle this job you don't have anything left.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Reply-To: [EMAIL PROTECTED]
Date: Sun, 24 Jan 1999 00:01:20 GMT
On 23 Jan 1999 14:25:48 -0600, Leslie Mikesell <[EMAIL PROTECTED]> posted:
>In article <78d77v$[EMAIL PROTECTED]>,
>Liang-Shing Ng <[EMAIL PROTECTED]> wrote:
>>
>>Maybe Linux still has a long way to go to catch up with "modern" OS like
>>Be in handling real time data and events.
>>
>>But I just have a modest request to all you great kernel hackers out there:
>>
>>Is it possible to achieve my modest requirement of "guanranteed limited
>>time response" in X window? i.e. When my Netscape started swapping, I
>>want my cursor can still be responsive and move on to other windows and
>>do some things.
>
>Even if you gave the screen display priority and kept the X code
>from being swapped out, this request doesn't make much sense.
>Why would you expect those 'other things' that you want to
>display to work any faster while the RAM to run them is also
>swapped to disk?
Note that *true* real time OSes (QNX being a good case in point) tend
to reject the notion of swapping out unused pages. As a result, you
need to have enough RAM to run the applications you want to run.
It seems probable that the situation described involves having
insufficient RAM; the RT approach would be to say "Add RAM. We
won't allow you to proceed until you do so."
The point is that that "modest requirement" is really not so modest;
it requires adding *considerable* intelligence to the system to overcome
(likely inadequately) starvation due to inadequate resources.
>The easy way is to run two machines. Run nothing but the Xserver
>on the box in front of you and run the apps all on another box
>over the network.
This is another valid approach. It guarantees availability of resources
on the local host, and allows other hosts to degrade without directly
degrading performance on the local host.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (David M. Cook)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Sun, 24 Jan 1999 00:06:08 GMT
On Sat, 23 Jan 1999 14:40:22 GMT, steve mcadams <[EMAIL PROTECTED]>
wrote:
>Not using desire/competition as the motivating force in an economic
>system is what put the USSR in its current condition.
The Russian Federation is in much worse shape after years of free market
reforms.
Dave Cook
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Sun, 24 Jan 1999 01:36:51 GMT
Dave Cook writes:
> The Russian Federation is in much worse shape after years of free market
> reforms.
Few if any of which have been implemented. Handing out monopolies to the
corrupt cronies of corrupt politicians while the State keeps a tight grip
on all major industries and manages them even more poorly than did the
bolsheviks has nothing to do with the free market.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
From: [EMAIL PROTECTED] (Tim Smith)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: 23 Jan 1999 17:02:31 -0800
Liang-Shing Ng <[EMAIL PROTECTED]> wrote:
>By the way, I am using an VOP5PC (Very Old Pentium Class Personal
>Computer) P75 with 24MB ram. Don't laugh. The guanranteed response
>problem has to be solved, and has to be solved especially on old
>systems!
I'm using a PII 266 with 64 MB of RAM, and I see the cursor freeze, too.
A good way to get it to happen is to go to slashdot, find some story with
a lot of comments, view it in flat mode, and then ask Navigator to search
on that page. The swapping light goes on for anywhere from 10 seconds to
a minute or so, and the system becomes to all appearences (except for the
disk light) dead.
According to "top", the thing that is using a huge amount of RAM when this
happens is not Navigator, but rather X itself.
--Tim Smith
------------------------------
From: [EMAIL PROTECTED] (Chris Lee)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: 24 Jan 1999 03:04:53 GMT
In article <78dro7$qs5$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>In article <78db8c$g43$[EMAIL PROTECTED]>, Leslie Mikesell <[EMAIL PROTECTED]>
wrote:
>>The easy way is to run two machines. Run nothing but the Xserver
>
>Another easy way to solve the problem is to run NT, which seems to handle
>running out of memory better than Linux 2.0.x does.
NT does handle running out of memory better than Linux 2.0.x does. NT
crashes and locks up your computer.....
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: 23 Jan 1999 21:11:43 -0600
In article <78dro7$qs5$[EMAIL PROTECTED]>,
Tim Smith <[EMAIL PROTECTED]> wrote:
>In article <78db8c$g43$[EMAIL PROTECTED]>, Leslie Mikesell <[EMAIL PROTECTED]> wrote:
>>The easy way is to run two machines. Run nothing but the Xserver
>
>Another easy way to solve the problem is to run NT, which seems to handle
>running out of memory better than Linux 2.0.x does.
Maybe in terms of the occasional time lag you see when Linux needs
to swap a big chunk into RAM, but overall I find Linux fairly
comfortable to use in 32K RAM but NT painful with less than 64.
These days it doesn't really matter that much. Just watch for
a sale if you need more.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Date: Sun, 24 Jan 1999 04:26:59 +0000
Liang-Shing Ng wrote:
>
> Maybe Linux still has a long way to go to catch up with "modern" OS like
> Be in handling real time data and events.
I am not familiar with Be, however, real time operating systems are a
pain.
>
> But I just have a modest request to all you great kernel hackers out there:
>
> Is it possible to achieve my modest requirement of "guanranteed limited
> time response" in X window? i.e. When my Netscape started swapping, I
> want my cursor can still be responsive and move on to other windows and
> do some things.
X is not in the kernel and should not be. Linux is not a real time
computer and swapping memory to disk does take time. X is a hog, but
seeing as it runs the display and UI, it has the right to be. Netscape
is a hog but has no excuse. Don't worry, when Netsape goes to Be it will
cause it to swap as well.
>
> I think if this problem can be solved, then most of the perceived
> sluggishness of GTK and KDE (mem hog etc) will be bypassed (if not
> solved). Then I will be really happy.
I have a K6-32 266, 64M of ram, I see no sluggishness.
>
> By the way, I am using an VOP5PC (Very Old Pentium Class Personal
> Computer) P75 with 24MB ram. Don't laugh. The guanranteed response
> problem has to be solved, and has to be solved especially on old
> systems!
Here is the paradox. By the time any hard core optimization can be done,
a really fast machine (now) will be an old system and the optimizations
may be a wasted effort that could have been spent making improvements.
Do you want guys optimizing for the 80486? or even the 80386? Granted
they are out there, but, hardly represent the future.
Yes, Linux should run on a 386, but, IMHO, it should be made the best
OS. There are aspects of optimization that goes along with this, but,
the focus is should remain stability and usability for late model
computers.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Modest next goal for Linux
Reply-To: [EMAIL PROTECTED]
Date: Sun, 24 Jan 1999 05:11:17 GMT
On Sun, 24 Jan 1999 04:26:59 +0000, mlw <[EMAIL PROTECTED]> posted:
>Liang-Shing Ng wrote:
>> Maybe Linux still has a long way to go to catch up with "modern" OS like
>> Be in handling real time data and events.
>
>I am not familiar with Be, however, real time operating systems are a
>pain.
Be may have fewer layers between kernel and GUI than Linux provides, which
may improve performance.
(On the other hand, if extra layers allow more use of queueing and
reordering of operations, it ain't necessarily obvious what wins...)
>> But I just have a modest request to all you great kernel hackers out there:
>>
>> Is it possible to achieve my modest requirement of "guanranteed limited
>> time response" in X window? i.e. When my Netscape started swapping, I
>> want my cursor can still be responsive and move on to other windows and
>> do some things.
>
>X is not in the kernel and should not be. Linux is not a real time
>computer and swapping memory to disk does take time. X is a hog, but
>seeing as it runs the display and UI, it has the right to be. Netscape
>is a hog but has no excuse. Don't worry, when Netsape goes to Be it will
>cause it to swap as well.
The "other" problem with pushing X into the kernel is that it forces the
*whole* set of code to stay in the kernel.
The X instance I have running is consuming 10MB. It's on a machine with
about 30MB free, so none of it's swapped out.
Supposing X were pushed into the kernel, that means that none of the code
gets to get swapped out. There's probably a couple or 3 MB of code that
could sit happily in swap.
Unfortunately, pushing X in with the kernel exacerbates the very problem
that it was intended to solve:
- We're in a low memory situation.
- By pushing X in with the kernel, we consume *more* memory.
Bad situation.
>> I think if this problem can be solved, then most of the perceived
>> sluggishness of GTK and KDE (mem hog etc) will be bypassed (if not
>> solved). Then I will be really happy.
>
>I have a K6-32 266, 64M of ram, I see no sluggishness.
>>
>> By the way, I am using an VOP5PC (Very Old Pentium Class Personal
>> Computer) P75 with 24MB ram. Don't laugh. The guanranteed response
>> problem has to be solved, and has to be solved especially on old
>> systems!
>
>Here is the paradox. By the time any hard core optimization can be done,
>a really fast machine (now) will be an old system and the optimizations
>may be a wasted effort that could have been spent making improvements.
>Do you want guys optimizing for the 80486? or even the 80386? Granted
>they are out there, but, hardly represent the future.
>
>Yes, Linux should run on a 386, but, IMHO, it should be made the best
>OS. There are aspects of optimization that goes along with this, but,
>the focus is should remain stability and usability for late model
>computers.
My thinking is that it makes relatively little sense to optimize X for the
smallest configurations.
- It would cost a great deal of effort.
- Effort that could be used to add other functionality.
- I would argue that this may be a matter that economically is worth many
millions of dollars, with amounts in favor of each outcome (e.g. "spend
effort on low-RAM GUI" versus "spend effort on more functionality in GUI").
- Note that pricing of hardware has been *imploding* over the last year.
There are vendors selling new systems that are *better* than what I used to
run Linux and X on five years ago, selling for under $400 USD.
- Prices are getting low enough that lower power consumption of newer
hardware starts being an issue worth considering. I remember when
WatDragon, a full-sized VAX 11/785, got replaced by a MicroVAX, because the
cost of the annual *power bill* for Dragon exceeded the price of the
far-cheaper-to-run MicroVAX... This principle may now be hitting
microcomputers...
It is a reasonable idea to continue development on console-based application
frameworks, as that allows the 8MB 386 box to remain useful. The notion
that that sort of machine is still a feasible platform for GUIed computing
seems to me to be misguided.
Third World nations may have to use such stuff.
A few weeks ago, I got email from someone in the Vancouver area that was
trying to continue maintaining "dumb terminal" desktops; apparently their
organization "couldn't afford" anything better. With the prices of land in
that region, I have to wonder if an organization that "can't afford better"
there can grapple successfully with general survival in their "marketplace."
Vancouver is not quite "Silicon Valley" expensive, but it's not far off, as
regions go.
It's a whole lot easier to attract interest to free software application
efforts that are somewhat "promiscuous" in their use of resources.
There are those that would like a version of Mozilla that is tiny;
unfortunately, the compromises that result from a bunch of people trying to
work together with a desire to have some "sexy" functionality (which
parallels "promiscuous" use of resources...) tends to compromise the
tininess of the results.
One person may be willing to give up GIF support; another doesn't care for
PNGs; another can't live without CSS; some *want* Java hooks, others don't
mind if ECMAScript gets dropped, ...
The end result is liable to be smaller than the monstrosities that
Communicator was turning into, but is not likely to fit on a floppy with
room to spare for an OS (as with the QNX demo disk).
There's *not* a clear minimum set of web browser functionality. Some can
live with text only. There's the question of which HTML variation(s) to
support. CSS? JavaScript? Java? Which graphics formats? Tables? SSL?
Frames? One window or many? Bookmark support? Page composition? XML?
Font support? CORBA? Any given one of these features is negotiable to
most, but will be critical to some. From whence Mozilla isn't likely to be
*tiny.*
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: Antoni Lapinski <[EMAIL PROTECTED]>
Subject: Re: 2.2pre9 won't compile
Date: Sat, 23 Jan 1999 21:11:09 +0100
Reply-To: [EMAIL PROTECTED]
I got a similar error when trying to compile the latest pcmcia-3.0.8 package with
2.2pre9.
Have a look at usr/src/kernel/linux/include/asm/smp.h.
I think what happens is <linux/config.h> does not get expanded and so
CONFIG_X86_LOCAL_APIC does not get defined, and therefore this ifdef ... endif below
does not get expanded either, and so at the end we get those errors.
#ifdef CONFIG_X86_LOCAL_APIC
#ifndef ASSEMBLY
#include <asm/fixmap.h>
#include <asm/i82489.h>
#include <asm/bitops.h>
#endif
One (crude) way to fix is to add:
#include <linux/autoconf.h>
at the top of /usr/src/kernel/linux/include/asm/smp.h
In my case, I fixed the pcmcia/Configuration script instead to cover for this.
-Antoni
[EMAIL PROTECTED] wrote:
> I tried compiling 2.2pre9, this is what I got:
>
> [ivo@one linux]$ make bzImage
> gcc -D__KERNEL__ -I/usr/src/kernel/linux/include -Wall -Wstrict-prototypes -O2
>-fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2
>-malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o init/main.o init/main.c
> /usr/src/kernel/linux/include/asm/smp.h: In function `hard_smp_processor_id':
> In file included from /usr/src/kernel/linux/include/linux/smp.h:11,
> from /usr/src/kernel/linux/include/linux/sched.h:20,
> from /usr/src/kernel/linux/include/linux/mm.h:4,
> from /usr/src/kernel/linux/include/linux/slab.h:14,
> from /usr/src/kernel/linux/include/linux/malloc.h:4,
> from /usr/src/kernel/linux/include/linux/proc_fs.h:5,
> from init/main.c:15:
> /usr/src/kernel/linux/include/asm/smp.h:209: warning: implicit declaration of
>function `GET_APIC_ID'
> /usr/src/kernel/linux/include/asm/smp.h:209: `APIC_BASE' undeclared (first use this
>function)
> /usr/src/kernel/linux/include/asm/smp.h:209: (Each undeclared identifier is reported
>only once
> /usr/src/kernel/linux/include/asm/smp.h:209: for each function it appears in.)
> /usr/src/kernel/linux/include/asm/smp.h:209: `APIC_ID' undeclared (first use this
>function)
> make: *** [init/main.o] Error 1
>
> (/usr/src/linux is linked to /usr/src/kernel/linux)
>
> It looks like someone made some changes and didn't try them with SMP
> support turned on?
>
> Am I doing something wrong? Should I upgrade something first (don't think
> so, this error really seems to be in the kernel source).
>
> I've been compiling each kernel from 2.1.127 without any problems.
>
> Currently I'm working remotely. When I'm back home I'll try to fix the
> error myself but I'm still curious if I'm the only one experiencing this
> problem.
>
> Ivo
>
> --
> ------------------------------------------------------------------------
> Name: Ivo van der Wijk
> Please replace '-' with '.' and remove '.mil' in my reply address.
> ------------------------------------------------------------------------
--
Antoni Lapinski
email:[EMAIL PROTECTED]
------------------------------
From: <@maine.rr.com>
Subject: test box
Date: Sat, 23 Jan 1999 15:26:55 -0500
hey all i have a test box on the wire.. 204.210.86.79 its a project.. feel
free to hack/do whatever....
------------------------------
From: [EMAIL PROTECTED] (Mumit Khan)
Subject: Re: problems with 2.2.0-final and export of NFS mounted file systems
Date: 23 Jan 1999 21:04:28 GMT
In article <[EMAIL PROTECTED]>,
Antoni Lapinski <[EMAIL PROTECTED]> wrote:
>What I use:
>kernel 2.2.0-final + patched RedHat 5.2 with rpm's from
>rawhide.redhat.com
>knfsd-981204-1 (nfs related stuff including exportfs)
>
>The problem: I cannot properly export NFS mounted directories and
>therefore the mount on a remote machine fails with "reason given by
>server: Permission denied".
If you haven't upgraded to util-linux-2.9g, that may be the problem.
The only change I made going from 2.2.0-pre8 to pre9 was this, and
my exports never stopped working.
http://www.rpmfind.net/ should help you find util-linux-2.9g if you
don't have it already. The source RPM (don't use the binary one!) on
rufus.w3.org has a few non-printable characters (8-bit; damn those
Europeans ;-) in the SPECS Summary that you may need to edit out
first.
Regards,
Mumit
------------------------------
From: Mike Ireton <[EMAIL PROTECTED]>
Subject: New driver, need help with skb's...
Date: Sat, 23 Jan 1999 19:41:55 +0000
Reply-To: [EMAIL PROTECTED]
Howdy,
I have a add-on driver that is supplementing an existing ethernet
driver (tulip, in this case), and pirates the hard_start_xmit function.
What I want to know is, when this function received an skbuff from the
kernel, how many of the fields can I rely on to be 'filled out' and
accurate? I have caught a problem that was driving me batty wherein the
skb->mac.raw field was null or invalid. I was trying to use this
information and got stung pretty hard. I've seen Alan Cox's page on
device programming and, while good, it doesn't document this behavior at
all.
I'd also like to know under what circumstances it's appropriate to
return a 1 to the kernel in response to it's call of hard_start_xmit. It
seems to me that the kernel will simply backoff and retry the packet. Is
there any way to communicate that I'm going to drop the packet or should
I just drop it and return 0 anyways?
Thanks.
Mike-
------------------------------
From: <@maine.rr.com>
Subject: test box login
Date: Sat, 23 Jan 1999 17:28:57 -0500
i've setup a login test/test to again the ip is 204.210.86.79
have fun
------------------------------
From: [EMAIL PROTECTED] (Paul Martin)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: kernel: VFS: No free inodes - contact Linus
Date: 24 Jan 1999 00:43:25 GMT
In article <[EMAIL PROTECTED]>, Matt Corddry wrote:
>Well... the subject really explains my problem. I get hundreds of
>thousands of these at console and in /var/log/messages.
I traced this in Diablo 1.21's expire program to being an MMAP leak. I'd
suggest that you check your chatserver software.
Look at /proc/sys/fs/inode-*
It's the internal kernel inode-in-use list.
A program may open a file, mmap a range of it into memory, then close the
file. The file is not open in the "number of files open" sense, but the
inode is open (and the memory mapped in) until the area is munmapped or
the program ends.
--
Paul Martin <[EMAIL PROTECTED]>
at home, swap dash to dot to email.
------------------------------
From: <@maine.rr.com>
Subject: test box
Date: Sat, 23 Jan 1999 19:44:27 -0500
hey guys there a box up at 204.210.86.79 i've setup a user test/test to
assit your tasks... telnet in see what u can do .. root it whatever
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
