[6867] in SIPB bug reports
exmh bug
daemon@ATHENA.MIT.EDU (Kevin L. Mitchell)
Sat Jun 20 21:52:22 1998
To: bug-sipb@MIT.EDU
Date: Sat, 20 Jun 1998 21:51:55 EDT
From: "Kevin L. Mitchell <klmitch@MIT.EDU>" <klmitch@MIT.EDU>
version 2.0.2 2/24/98
SunOS x15-cruise-basselope.mit.edu 5.6 Generic_105181-04 sun4u sparc SUNW,Ultra-1
Tk 8.0 Tcl 8.0
Exmh is refusing to display the following message (sorry about length):
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA22782; Sat, 20 Jun 98 21:44:55 EDT
Received: from entropy.muc.muohio.edu by MIT.EDU with SMTP
id AA06284; Sat, 20 Jun 98 21:44:54 EDT
Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2])
by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id VAA30404;
Sat, 20 Jun 1998 21:43:36 -0400
Received: by vger.rutgers.edu id <970949-2981>; Sat, 20 Jun 1998 21:24:59 -0400
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #2117
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id: <19980621012502Z970949-2981+1913@vger.rutgers.edu>
Date: Sat, 20 Jun 1998 21:24:59 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by entropy.muc.muohio.edu id VAA30404
linux-kernel-digest Saturday, 20 June 1998 Volume 01 : Numbe=
r 2117
In this issue:
Re: LM78 Kernel Support?
[Fwd: Shapecfg and cpu speeds]
2.1.106 boot failure ??
Re: [{patch} print_eip for 2.0.34] Re: 2.0.34 hangs
Re: Thread implementations...
Re: Use tmpfs for shm_open()?
Re: 3000 fd patch question
Re: 3000 fd patch question
Re: Major 2.1.x problem index
Re: undeletable files in /lost+found
Re: Thread implementations...=20
Re: Header files and interfaces
Re: Sound Blaster AWE 64.
keyboard raw mode?
Re: Header files and interfaces
Re: Thread implementations...
Re: Header files and interfaces
Re: How much kernel stack do we need?
Re: OFFTOPIC: e2fsprogs and +2Gb partitions=20
Re: Thread implementations...
Re: Use tmpfs for shm_open()?
Re: Thread implementations...=20
fork() memory corruption... is this glibc2 or kernel?
Re: OFFTOPIC: e2fsprogs and +2Gb partitions=20
Re: How much kernel stack do we need?
v2.1.106 compilation error
Re: How much kernel stack do we need?
eth0 and eth1, how to get all packets to use the right source-adress?
PCI sound cards
Re: PCI sound cards
Re: PCI sound cards
Re: PCI sound cards
Re: (reiserfs) Re: LVM / Filesystems / High availability
Limits in the kernel
Re: Thread implementations...
Re: undeletable files in /lost+found
Re: Thread implementations...=20
See the end of the digest for information on subscribing to the linux-ker=
nel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Sat, 20 Jun 1998 16:44:38 +0200 (CEST)
Subject: Re: LM78 Kernel Support?
On Sat, 20 Jun 1998, Andrea Arcangeli wrote:
>You can find my old lm78 hack (that not generate the SMI interrupt) for
>2.1.x at:
The server is misconfigured (thanks to Shaw Carruthers for reporting
this)...
> http://caristudenti.cs.unibo.it/~arcangel/kernel-patch
I am forced to move outside the University since there servers are most o=
f
the time misconfigured or down...
The new site is:
ftp://e-mind.com/pub/linux/kernel-patch
Andrea[s] Arcangeli
------------------------------
From: Vince Lo Faso <vincelofaso@earthlink.net>
Date: Sat, 20 Jun 1998 10:22:31 -0500
Subject: [Fwd: Shapecfg and cpu speeds]
This is a multi-part message in MIME format.
- --------------FC8AB4FC3AE93BA058759F90
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
Originally posted to netdev list but
that list seems to be down.
VL.
- --------------FC8AB4FC3AE93BA058759F90
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <358BB8D7.8C3B2F45@earthlink.net>
Date: Sat, 20 Jun 1998 08:27:51 -0500
From: Vince Lo Faso <vincelofaso@earthlink.net>
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
To: "netdev@nuclecu.unam.mx" <netdev@nuclecu.unam.mx>
Subject: Shapecfg and cpu speeds
Content-Type: text/plain; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
I have set up shaper and used shapecfg
to configure two PCs at speed 57600.
My question is does shaper adjust itself
to the different cpu speeds. For
example, one PC is a Pentium 166Mhz and
the second is a PII 233Mhz. Does the
same speed setting on both pcs produce
the same delay?
thanks in advance,
Vince.
- --------------FC8AB4FC3AE93BA058759F90--
------------------------------
From: scoffin@netcom.com
Date: Sat, 20 Jun 1998 09:34:29 -0600
Subject: 2.1.106 boot failure ??
I got the following boot-time message twice recently with 2.1.106,
in about 20 successful boots. Never had this before with any previous ke=
rnel.
I have made no config changes since 2.1.8x, 2.1.9x. 2.1.10x, etc etc.
Any comments appreciated....
ps=3D machine is PPro 200, 2940 SCSI controller, boot disk is 4.2 GB on s=
da
=3DS.Coffin
scoffin@netcom.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Partition check:
sda: scsidisk I/O Error: dev 08:00, sector 0
unable to read partition table
Drive not ready. Make sure there is a disk in the drive
sda: read capacity failed.
sda: status=3D1, message=3D00, host=3D0, driver=3D28
sda: extended sense code=3D2
sda: block size assumed to be 512 bytes, disk size 1GB
sda: scsidisk I/O Error: dev 08:00, sector 0
unable to read partition table
VFS: cannot open root device 08:02
Kernel panic: VFS: unable to mount root fs on 08:02
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Sat, 20 Jun 1998 17:44:53 +0200 (CEST)
Subject: Re: [{patch} print_eip for 2.0.34] Re: 2.0.34 hangs
On Sat, 20 Jun 1998, Andrea Arcangeli wrote:
>If you need the sysctl to enable/disable the box at runtime I can do tha=
t.
I have just implemented the sysctl entry to enable/disable the box:
ftp://e-mind.com/pub/linux/kernel-patch/print_eip-2.0.34-3.diff.gz
Andrea[s] Arcangeli
------------------------------
From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
Date: Sun, 21 Jun 1998 01:51:31 +1000
Subject: Re: Thread implementations...
Alex Belits writes:
> On Fri, 19 Jun 1998, David S. Miller wrote:
>=20
> > I look at it this way.
> >=20
> > If you can divide the total set of fd's logically into seperate
> > groups, one strictly to a particular thread. Do it this way.
> > The problem with one thread polling all fd's and passing event
> > notification to threads via some other mechanism has the problem that
> > this one thread becomes the bottle neck.
>=20
> I realize that every operation, performed indide that process/thread,=
if
> takes any noticeable time, will hold back everything that depends on an=
y=20
> fd status change. But what if the code is optimized to reduce the time =
in
> loop to the absolute minimum possible? Will poll() take more time by
> itself (and indeed become a bottleneck) in one thread vs. multiple
> poll()'s made at the same time in multiple threads? If the time spent i=
n
> the loop is minimal, is there any difference between waking up one of
> looping threads, searching through its poll array and performing some
> action, and with one thread waking up every time, searching larger arra=
y
> (IMHO not a significant time compared to time spent by system while
> processing those sockets) and then performing the same action, if that
> action takes some insignificant time, comparable with time, spent in
> buffers handling in the kernel itself? As I understand, with multiple
> threads ot not, kernel still needs a time to process file descriptors
> and choose thread to wake up even if threads already divided fds among
> themselves, so the total amount of fd lists scanning won't change.
Assuming that most FDs are inactive, the time spent scanning a list of
FDs is 2-3 us per FD. So for 1000 FDs, we are looking at milliseconds,
which is quite a bit compared to some simple datagram processing in
userspace. So the time for select(2) or poll(2) of large numbers of
FDs is significant.
Splitting this work across many threads (say 10) reduces the
probability that more than one thread needs to be woken up during any
timeslice, hence far fewer FDs need to be scanned each time (only 100
in this example).
Unfortunately splitting the work amongst many threads is not always
easy. We can improve the speed of select(2) and poll(2) by a factor of
3 by changing the way they are implemented (API remains the same, of
course:-). This will buy us more in the scalability stakes.
> > The problem, for one, with web etc. servers is the incoming connectio=
n
> > socket. If you could tell select/poll "hey, when a new conn comes in=
,
> > wake up one of us", poof this issue would be solved. However the
> > defined semantics for these interfaces says to wake everyone polling
> > on it up.
>=20
> This is why I do that in userspace -- one process is always waking up=
,
> connection is placed in its internal queue, its fd is added to the
> polling list, and after request is received and parsed asynchronously, =
fd
> is immediately passed to another process through the AF_UNIX socket. Wh=
ile
> main process is doing nonblocking I/O on multiple connections, there is=
no
> I/O in the same loop except opening new connections, reading from them =
and
> passing to other processes fds/data of connections that have sent their
> requests and expect the response. Kind of userspace "multithreading",
> optimized for the particular operation.
People seem to be very interested in the new connection case. This
doesn't seem all that exiting or interesting to me (just have one
thread blocking in accept(2) and store the new FD in a global
array). To me the problem of processing data on existing connections
is more interesting (and harder to solve: hence more interesting:-).
Is there something deep I'm missing here?
Regards,
Richard....
------------------------------
From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
Date: Sun, 21 Jun 1998 01:57:37 +1000
Subject: Re: Use tmpfs for shm_open()?
Eric W. Biederman writes:
> >>>>> "RG" =3D=3D Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
>=20
> RG> Hi, all. A random thought just popped into my head today: how abo=
ut
> RG> implementing a tmpfs which could then be used as the basis of a sim=
ple
> RG> userspace (libc) implementation of POSIX shared memory, aka.
> RG> shm_open().
>=20
> RG> We could kill two birds with one stone, giving a tmpfs to those who
> RG> believe it's faster than ext2fs :-), and giving us POSIX SHM too.
>=20
> Plus resource limits could be quotas.
> I called it shmfs because the emphasis is on being able to do shm_open..
>=20
> Look at http://www.npwt.net/~ebiederm/files
> and get
> shmfs-0.1.009.tar.gz
> and code me that user space implementation please.
Oh. Well done. I must have missed this bit of signal amongst all the
noise. Looks like my idea was sensible (just not original:-).
When do you plan to submit shmfs (somehow I think it's better
described as a memfs or a vmfs, I think shmfs is a bit too specific,
like tmpfs) to Linus?
Regards,
Richard....
------------------------------
From: Brian <signal@shreve.net>
Date: Sat, 20 Jun 1998 12:41:27 -0500 (CDT)
Subject: Re: 3000 fd patch question
On Fri, 19 Jun 1998, Jimmie Farmer wrote:
>=20
> I grabbed the updated 3000 fd patch for 2.0.34 from Alan Cox's Web
> page, and tried to apply it to a virgin 2.0.34 source tree. It failed,
> and badly. =3D-\
>=20
> Has anyone got a working patch for 2.0.34? I just though I would
> ask before doing it all by hand. =3D-)
>=20
use "patch -l", the whitespaces are probably munged.
> Thanks in advance!
>=20
> Sincerely,
> Jimmie Farmer
>=20
> Jimmie Farmer | It is by the fortune of God that, in this co=
untry,
> Techno Geek/Musician | we have three benefits: freedom of speech, f=
reedom
> calvin@malchick.com | of thought, and the wisdom never to use eith=
er.
> http://www.malchick.com/ | -- Mark Twain
>=20
>=20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
> the body of a message to majordomo@vger.rutgers.edu
>=20
/-------------------------- signal@shreve.net ---------------------------=
--\
| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638=
|
| Network Administrator | Perl, Linux | Web hosting, online stores, =
|
| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LAN=
s |
| 89 CRX DX w/MPFI, lots of |-=3D*:Quake:*=3D-| http://www.shreve.net/ =
|
| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 =
|
\-------------------------- 318-222-2638 x109 ---------------------------=
--/
------------------------------
From: Jimmie Farmer <calvin@malchick.com>
Date: Sat, 20 Jun 1998 11:21:08 -0700 (PDT)
Subject: Re: 3000 fd patch question
On Sat, 20 Jun 1998, Brian wrote:
> On Fri, 19 Jun 1998, Jimmie Farmer wrote:
>=20
> >=20
> > I grabbed the updated 3000 fd patch for 2.0.34 from Alan Cox's Web
> > page, and tried to apply it to a virgin 2.0.34 source tree. It faile=
d,
> > and badly. =3D-\
> >=20
> > Has anyone got a working patch for 2.0.34? I just though I would
> > ask before doing it all by hand. =3D-)
> >=20
>=20
> use "patch -l", the whitespaces are probably munged.
THANk YOU! This was the trick I needed to try. =3D-)
Sincerely,
Jimmie Farmer
Jimmie Farmer | It is by the fortune of God that, in this coun=
try,
Techno Geek/Musician | we have three benefits: freedom of speech, fre=
edom
calvin@malchick.com | of thought, and the wisdom never to use either.
http://www.malchick.com/ | -- Mark Twain
------------------------------
From: hpa@transmeta.com (H. Peter Anvin)
Date: 20 Jun 1998 19:07:44 GMT
Subject: Re: Major 2.1.x problem index
Followup to: <m11zskwucz.fsf@flinx.npwt.net>
By author: ebiederm+eric@npwt.net (Eric W. Biederman)
In newsgroup: linux.dev.kernel
>=20
> I sent mail to H. Peter Anvin <hpa@zytor.com> who I believe is
> responsible to:
> a) see if I could understand the change in 2.1.93 (where this
> appeared) The moving of the super block locking puzzles me a lot.
> b) to hopefully coordinate a fix for this problem.
>=20
> So far he hasn't replied. And I'm not totally confident I can fix the
> code right until I understand why we moved the lock super calls. If I
> don't get some feed back soon I'll try anyway.
>=20
I'm not responsible to make you understand anything. I'm trying to
coordinate a fix for it, on the other hand, but I have been on
vacation.
-hpa
- --=20
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah=E1'=ED -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis=E9rable=
s
------------------------------
From: Pierfrancesco Caci <ik5pvx@penny.ik5pvx.ampr.org>
Date: 20 Jun 1998 18:25:20 +0200
Subject: Re: undeletable files in /lost+found
Joseph Skinner <joe@snail.earthlight.co.nz> writes:
>=20
> Thank for all the suggestions.
>=20
> The rm command from debugfs seems to have done the job [fingers
> crossed].
>=20
> For those interested in the gory details I used the -f switch with all
> the commands stored in a file to save time ie.
>=20
> debugfs -w -f commandfile /dev/hda2
>=20
> Where commandfile contained
>=20
> cd /lost+found
> rm filename
> ...
> close
> quit
>=20
>=20
Ok, does someone know how to get rid of these:
root@penny:/home/lost+found # ls -lasR
total 75
10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 #101601
2 drwxrwxr-x 3 ik5pvx staff 2048 Dec 24 19:48 #34548
62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 .
1 drwxrwxr-x 8 root root 1024 Dec 13 1997 ..
#101601:
total 82
10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 .
10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 .
62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
#34548:
total 126
2 drwxrwxr-x 3 ik5pvx staff 2048 Dec 24 19:48 .
62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
root@penny:/home/lost+found #=20
the double "." and ".." entries prevent the directory to be deleted.
Pf
- --=20
- -----------------------------------------------------------------------=
--------
Pierfrancesco Caci | mailto:ik5pvx@infogroup.it - http://gusp.infogroup=
.it
ik5pvx | http://www.geocities.com/SoHo/Lofts/8999
Firenze - Italia | Office for the Complication of Otherwise Simple Af=
fairs=20
Linux penny 2.1.106 #8 Fri Jun 19 19:53:23 CEST 1998 i586 unknown
------------------------------
From: lm@bitmover.com (Larry McVoy)
Date: Sat, 20 Jun 1998 12:51:43 -0700
Subject: Re: Thread implementations...=20
: Even with the debugging problems solved, linuxthreads are heavier
: than solaris pthreads or NT fibers. =20
So how about quantifying that a bit and show us some numbers and how they
affect things in real life?
: Unix multiplexing facilities -- select and poll -- are wake-all
: primitives. When something happens, everything waiting is awakened
: and immediately starts fighting for something to do. What a waste.
: They make a lot of sense for processes though. On NT completion
: ports provide wake-one semantics... which are perfect for threads.
:=20
: Yes, this does in fact suck. However, the path to go down is not to
: expect the way select/poll work to change, rather look at other
: existing facilities or invent new ones which solve this problem.
: Too much user code exists which depends upon the wake-all semantics,
Hmm. SGI changed accept() from wakeup-all to wakeup-one with no problem.
I'd be interested in knowing which programs depend on the race.
------------------------------
From: Danek Duvall <duvall@campusclub.princeton.edu>
Date: Sat, 20 Jun 1998 16:11:02 -0400
Subject: Re: Header files and interfaces
In the specific case of ext2 tools, wouldn't it do to split e2fslibs from
the e2fsprogs package? Any kernel headers could be appropriately munged
and copied into the libs package, which would be installed as a
prerequisite to compiling any of the tools.
That way, Linus doesn't have to worry about kernel headers, there's only
one copy going on (and only one person who needs to worry about it), and =
it
can change whenever it needs to, without waiting for the glibc people to =
do
something that, admittedly, is specific to a very small sector of program=
s.
I can see that this wouldn't work in all cases ... if there's only one
header in question, and there isn't really a body of library code that ca=
n
be distributed as a package. But is it a workable solution for larger
interfaces?
Danek
------------------------------
From: Krzysztof Halasa <khc@intrepid.pm.waw.pl>
Date: 20 Jun 1998 16:40:32 +0200
Subject: Re: Sound Blaster AWE 64.
Jason Saggers <psyclone@darknight.gen.nz> writes:
> I am having trouble getting the system to reckonize the Midi Chips etc =
of
> the AWE 64 card.
>=20
> THis is what I get at Startup
>=20
> Sound initialization started
> <Sound Blaster 16 (4.16)> at 0x220 irq 5 dma 1,5
> <Sound Blaster 16> at 0x330 irq 5 dma 0
> <Yamaha OPL3 FM> at 0x388
> AWE32: not detected
[]
> When using the pnpplay config tools, isapnp and pnpdump, the configurat=
ion
> file works fine, but when running the config I get the error message
>=20
> LD setting verify failed, this may not be a problem
> Try adding (VERIFYLD N) to the top of your script
> Error occurred executing request 'LD 2' on or around line 25 --- furthe=
r \
> action aborted
I got this when I set joystick I/O port on SB46 to 0x200. Changing "readp=
ort"
addr to 0x20B (in isapnp.conf file) solves this:
(READPORT 0x020B)
(ISOLATE)
(IDENTIFY *)
Then you need to add 2 IO addresses (IO 1 and IO 2 - the card doesn't sho=
w
them in pnpdump, but they are required for synth operation):
(CONFIGURE CTL00e4/372725497 (LD 2 # ANSI string -->WaveTable<--
(IO 0 (BASE 0x0620)) # 4 addresses
(IO 1 (BASE 0x0A20))
(IO 2 (BASE 0x0E20))
(ACT Y)))
- --=20
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw
------------------------------
From: Mathieu Bouchard <boum01@UQAH.UQuebec.CA>
Date: Sat, 20 Jun 1998 16:30:12 -0400 (EDT)
Subject: keyboard raw mode?
afaik, there is nothing at the kernel level to prevent a crash of the=20
keyboard when running root or suidroot programs such as the X Server,=20
DosEmu, SvgaLib-based programs (mostly games and demoscene stuff)...
i think i understood that those programs do not use the keyboard directly=
=20
but rather ask the kernel to put it in "raw mode"? which prevents the=20
kernel from responding to Alt+Fn, Ctrl+ScrollLock, Ctrl+Alt+Del, and the=20
like. shouldn't we insert an exception to this to unlock the keyboard in=20
case of emergency? Like, Ctrl+Alt+Ins or Ctrl+Alt+ScrollLock would=20
*ALWAYS* put the keyboard back into normal mode. This could be=20
user-configured in /proc if this doesn't bloat the kernel too much :-)
I saw the XServer crash, especially when running betas or alphas of=20
Enlightenment and The GIMP. When it crashes, there is no way of restoring=
=20
the display (e.g. by restarting it and then quitting normally??) because=20
there is no keyboard anymore, and no mouse either because X overrides GPM=
=20
(GPM has a feature for rebooting the system in case of keyboard lock, but=
=20
if GPM is disabled by X, it's worthless, and anyway, the mouse is not the=
=20
responsibility of the kernel).
matju
------------------------------
From: Raul Miller <rdm@test.legislate.com>
Date: Sat, 20 Jun 1998 16:28:39 -0400
Subject: Re: Header files and interfaces
tytso@mit.edu <tytso@mit.edu> wrote:
> We could define the ext2fs structures in the glibc header files, but
> David Miller pointed out, glibc changes too slowly. It also doesn't
> make sense because glibc doesn't define the ext2fs interfaces ---
> neither the ioctl numbers nor the ext2 structures. So moving them
> there simply doesn't make sense either.
This is a glibc problem, not a kernel issue.
- --=20
Raul
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Sat, 20 Jun 1998 13:49:50 -0700 (PDT)
Subject: Re: Thread implementations...
On Sat, 20 Jun 1998, Richard Gooch wrote:
> Dean Gaudet writes:
> >=20
> > On Fri, 19 Jun 1998, Richard Gooch wrote:
> >=20
> > > On the other hand you could say that the UNIX semantics are fine an=
d
> > > are quite scalable, provided you use them sensibly. Some of these
> > > "problems" are due to applications not being properly thought out i=
n
> > > the first place. If for example you have N threads each polling a
> > > chunk of FDs, things can run well, provided you don't have *each*
> > > thread polling *all* FDs. Of course, you want to use poll(2) rather
> > > than select(2), but other than that the point stands.
> >=20
> > You may not be able to exploit the parallism available in the hardwar=
e
> > unless you can "load balance" the descriptors well enough...
>=20
> Use 10 threads. Seems to me that would provide reasonable load
> balancing. And increasing that to 100 threads would be even better.
No it wouldn't. 100 kernel-level threads is overkill. Unless your box
can do 100 things at a time there's no benefit from giving the kernel 100
objects to schedule. 10 is a much more reasonable number, and even that
may be too high. You only need as many kernel threads as there is
parallelism to exploit in the hardware. Everything else can, and should,
happen in userland where timeslices can be maximized and context switches
minimized.=20
> The aim is to ensure that, statistically, most threads will remain
> sleeping for several clock ticks.
What? If I am wasting system memory for a kernel-level thread I'm not
going to go about ensuring that it remains asleep! no way. I'm going to
use each and every time slice to its fullest -- because context switches
have a non-zero cost, it may be small, but it is non-zero.
> With a bit of extra work you could even slowly migrate consistently
> active FDs to one or a few threads.
But migrating them costs you extra CPU time. That's time that strictly
speaking, which does not need to be spent. NT doesn't have to spend this
time when using completion ports (I'm sounding like a broken record).=20
Look at this another way. If I'm using poll() to implement something,
then I typically have a structure that describes each FD and the state it
is in. I'm always interested in whether that FD is ready for read or
write. When it is ready I'll do some processing, modify the state,
read/write something, and then do nothing with it until it is ready again=
.=20
To do this I list for the kernel all the FDs and call poll(). Then the
kernel goes around and polls everything. For many descriptors (i.e. slow
long haul internet clients) this is a complete waste. There are two
approaches I've seen to deal with this:
- - don't poll everything as frequently, do complex migration between
different "pools" sorted by how active the FD is. This reduces the numbe=
r
of times slow sockets are polled. This is a win, but I feel it is far to=
o
complex (read: easy to get wrong).=20
- - let the kernel queue an event when the FD becomes ready. So rather t=
han
calling poll() with a list of 100s of FDs, we tell the kernel on a per-FD
basis "when this is ready for read/write queue an event on this pipe, and
could you please hand me back this void * with it? thanks". In this
model when a write() returns EWOULDBLOCK the kernel implicitly sets that
FD up as "waiting for write", similarly for a read(). This means that no
matter what speed the socket is, it won't be polled and no complex
dividing of the FDs into threads needs to be done.=20
The latter model is a lot like completion ports... but probably far easie=
r
to implement. When the kernel changes an FD in a way that could cause it
to become ready for read or write it checks if it's supposed to queue an
event. If the event queue becomes full the kernel should queue one event
saying "event queue full, you'll have to recover in whatever way you find
suitable... like use poll()".=20
Dean
------------------------------
From: Raul Miller <rdm@test.legislate.com>
Date: Sat, 20 Jun 1998 16:35:32 -0400
Subject: Re: Header files and interfaces
tytso@mit.edu <tytso@mit.edu> wrote:
> The same arguments generalize to other header files and applications.
> For example, multiple programs need linux/serial.h --- maintaining n
> different copies of the manifest constants for the n programs that
> need to make serial ioctl's simply makes no sense. And again, it
> doesn't seem to make any sense to copy them to the glibc header files
> since they are extremely Linux kernel specific, and the interface is
> defined by the Linux kernel, not by glibc.
Last time I checked, ioctl was defined in libc. Yeah, it's just a
lightweight cover for a kernel call, but that's hardly unusual.
There does need to be a systematic way of getting the defined constants
for ioctl, but that's different from removing ioctl from libc.
[And, in principle, libc *could* map constants from one set of values to
another...]
- --=20
Raul
------------------------------
From: Mathieu Bouchard <boum01@UQAH.UQuebec.CA>
Date: Sat, 20 Jun 1998 16:42:02 -0400 (EDT)
Subject: Re: How much kernel stack do we need?
> > In 2.1.x kernels, the kernel stack size is 8192 bytes (2 pages) on th=
e i386,
> > minus the size of the task structure (around 1000). This means the st=
ack is
> > more than 3000 bytes larger than in 2.0.x where it used to be one pag=
e. My
> > question is: do we really need this?
> This is a _very_ good question, since it could save us one
> unswappable page _per process_. This might not seem like
> an awful lot of memory, but with the current fragmentation
> problems this patch could save our butt...
> (at least until the zone allocator is ready)
When I first read this I didn't take it seriously, but if you say that 1.=
=20
it's one per process and 2. it's unswappable, then it's definitely=20
worth it. Imagine something like a webserver trying to fill 2000 requests=
at=20
once. just saved 8 MB of unswappable memory. This allows for 100-200 more=
=20
requests at once, possibly.
and 3rd reason: it was 4k in v2.0.*; going to 8k is a regression. This is=
=20
a word from a once-was asm freak and I had 16k RAM on my first puter.=20
getting it back to 4k and making further optimisations beyond this will=20
help making processes more lightweight, which is always a Good Thing (tm)=
=20
imho.
Now what is (briefly) the zone allocator? is there any info i can get on=20
this?
matju
------------------------------
From: Gordon Oliver <gordo@telsur.cl>
Date: Fri, 19 Jun 1998 16:18:47 -0400
Subject: Re: OFFTOPIC: e2fsprogs and +2Gb partitions=20
... Mark H. Wood said ...
>"Duplication" tends to be read as "we have multiple copies of the
>information and they are maintained in parallel by hand". "Replication"=
=20
>tends to be read as "we have multiple copies of the information and some
>automatic mechanism keeps them consistent within a few
>{seconds|minutes|hours}". Given what I know about my own ability to kee=
p
>things consistent manually, I much prefer replication to duplication.=20
>Does that help?
perhaps then, someone should go about putting together a perl script to
extract useful definitions from the kernel and put them in a "public" set
of headers. This satisfies Linus' problem (stifling kernel changes), and
the problem of others (slow migration of constants to copies/packages).
The extracted headers could then be published as a separate set of header=
s
that would go with each kernel. They would probably (hopefully) not chang=
e
all that often. This would change the current state of duplication into
replication.
NOTE: The separate headers should _not_ be part of the kernel distributio=
n!
and they should probably be minimalist (i.e. put something in if it is _u=
sed_
but only then)
-gordo
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Sat, 20 Jun 1998 14:13:30 -0700 (PDT)
Subject: Re: Thread implementations...
On Sun, 21 Jun 1998, Richard Gooch wrote:
> People seem to be very interested in the new connection case. This
> doesn't seem all that exiting or interesting to me (just have one
> thread blocking in accept(2) and store the new FD in a global
> array). To me the problem of processing data on existing connections
> is more interesting (and harder to solve: hence more interesting:-).
> Is there something deep I'm missing here?
The new connection case is actually pretty much the same as all the other
cases, but maybe just easier to explain.=20
Suppose you do what you suggest. Have a single accept() thread which
plops FDs into a global queue. It also presumably tweaks a condition
variable to awake a waiting processing thread. To start processing a new
socket there are two context switches, one into the accept thread, and on=
e
into a processing thread.
That second switch is a waste. Instead you could mutex protect accept()=20
and go into it with the processing thread, and release the mutex on the
way out. Then you have only one context switch for each new socket. This=
,
incidentally, is almost what happens inside the kernel... except the
kernel uses wake-all semantics (freebsd seems to have solved this for
accept... alan and linus say there are difficulties in solving it, so it
hasn't been solved in linux yet). So you can actually drop the mutex.=20
Back to the single thread/accept queue. There's only a single thread in
accept(), and if the box you're running on has two processors you're not
exploiting the parallelism available. You could do some fun gymnastics a=
t
the user level to put multiple threads waiting on accept() ... but that's
overkill because usually the kernel is the best judge of the parallelism
available. So just putting a collection of threads into accept() and
letting the kernel sort it out solves this.
But does it? Now you have to figure out how many threads you should have
waiting in accept at any one time. (In Apache, this is the joyful
nonsense of deciding the right MinSpareServers and MaxSpareServers
settings to handle load spikes and parallelism and all that fun stuff.)=20
And your threads waiting in accept are kernel scheduled resources
consuming kernel ram.
If all your program did was call accept() you'd be able to figure this al=
l
out pretty easily. But presumably you do more than that.
accept() is interesting because it is actually an event queue... it's a
queue of new connections arriving on a single socket. The kernel has all
the knowledge it needs to multiplex the socket connections in a way
suitable to the hardware.
But accept() is limiting because it only handles a single listening
socket. If your web server has both port 80 and port 443, you need some
way to accept connections on both. You prefer to run a single web server
to take advantage of shared configuration memory and other resources. No=
w
you need some method of accepting connections on multiple sockets. You
could just implement two pools of threads, one for each socket. But that
doesn't scale to many many sockets (which some people actually do use, fo=
r
better or for worse) ... and now you have to tune min/maxspare parameters
for multiple pools, what a headache.=20
What you'd really like is a way to say "accept a connection on any of
these sockets" so that you can continue to maintain a single pool of
threads. The single pool is not only easier to configure, it has the
benefits of cache locality. Presumably everything in the pool is
identical -- all the threads are capable of handling the returned socket.
The kernel can use LIFO on the waiting threads because the last-in thread
is most likely to still have data in L1.
But really the same can be said for read/write as well as accept. Suppos=
e
you had a hybrid user/kernel threads package which uses co-operative
pre-emption, i/o points are pre-emption points. When a user-thread does
an i/o the package just notes that the user-thread is blocked. Then it
asks the kernel "give me an FD which is ready for I/O". It determines wh=
ich
user-thread is waiting for that FD and dispatches that user-thread. In
this model you need as many kernel threads as there is parallelism to
exploit. The user-threads are written in the standard procedural manner,
which is easy to program (rather than the stateful manner of something
like squid where all the state transitions for i/o state are explicit
and in the control of the programmer).
Central to that is the "give me an FD which is ready for I/O" step. This
is where select/poll are traditionally used... but the question is really
a wake-one question, and select/poll are wake-all primitives. The
kernel-threads in this example are all equivalent, any one of them can
switch to any of the user-threads. Can you see how read/write are
pretty similar to accept and how all the problems are related?
Dean
------------------------------
From: ebiederm+eric@npwt.net (Eric W. Biederman)
Date: 20 Jun 1998 16:16:00 -0500
Subject: Re: Use tmpfs for shm_open()?
>>>>> "RG" =3D=3D Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
RG> Eric W. Biederman writes:
>> >>>>> "RG" =3D=3D Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
>>=20
RG> Hi, all. A random thought just popped into my head today: how about
RG> implementing a tmpfs which could then be used as the basis of a simpl=
e
RG> userspace (libc) implementation of POSIX shared memory, aka.
RG> shm_open().
What lead me here original is minimizing the number of system calls
needed.
>>=20
RG> We could kill two birds with one stone, giving a tmpfs to those who
RG> believe it's faster than ext2fs :-), and giving us POSIX SHM too.
>>=20
>> Plus resource limits could be quotas.
>> I called it shmfs because the emphasis is on being able to do shm_open=
..
>>=20
>> Look at http://www.npwt.net/~ebiederm/files
>> and get
>> shmfs-0.1.009.tar.gz
>> and code me that user space implementation please.
RG> Oh. Well done. I must have missed this bit of signal amongst all the
RG> noise. Looks like my idea was sensible (just not original:-).
RG> When do you plan to submit shmfs (somehow I think it's better
RG> described as a memfs or a vmfs, I think shmfs is a bit too specific,
RG> like tmpfs) to Linus?
There is a little more vm work to be done. I have also been working
on a third area that of dirty pages in the page cache, which when it
works should be quite usefull in a lot of ways. I have a working hack
at the minute, and some good code in progress. =20
If I'm really lucky before 2.2 but otherwise early in 2.3, because of
the dirty pages in the page cache issue.
I could really use someone to write the shm_open user space code.
Working through all of the kernel issues is taking a lot of work, so I
don't think I'll have time for a while.
Eric
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Sat, 20 Jun 1998 14:37:36 -0700 (PDT)
Subject: Re: Thread implementations...=20
On Sat, 20 Jun 1998, Larry McVoy wrote:
> : Even with the debugging problems solved, linuxthreads are heavier
> : than solaris pthreads or NT fibers. =20
>=20
> So how about quantifying that a bit and show us some numbers and how th=
ey
> affect things in real life?
As a matter of fact I can quantify this somewhat.=20
NSPR provides two modes of operation on linux -- one uses pthreads, the
other users a portable userland threads library (the standard
setjmp/longjmp deal although it uses sigsetjmp/siglongjmp, and needs a
little more optimization). I've ported apache 1.3 to NSPR as an
experiment for future versions of apache. I built the non-debugging
versions of the NSPR library, linked my apache-nspr code against it, and
set up a rather crude benchmark.=20
% dd if=3D/dev/zero of=3Dhtdocs/6k bs=3D1024 count=3D6
(the squid folks used to tell me 6k was the average object size on the
net, maybe the number is different these days)
% zb 127.0.0.1 /6k -p 8080 -c 10 -t 10 -k
(this is zeusbench asking for the 6k document, 10 simultaneous clients (i=
t
uses select to multiplex), run for 10 seconds, use keep-alive persistent
http connections)
With pthreads it achieves 811 req/s.
With user threads it achieves 1024.40 req/s.
The machine is a single cpu ppro 200 with 128Mb of RAM running 2.1.104.=20
Caveats: While NSPR has been designed extremely well, and the interfaces
don't show any immediate problems with doing underlying optimizations,
it's certainly not top speed yet. This applies in both cases however.=20
NSPR has a hybrid user/system model that lives on top of pthreads, I
haven't tried it yet (it's not ported to linux according to the docs).=20
I can do comparisons with the process-model based apache, and I used to
have a native pthreads port of apache... but the latter is out of date no=
w
because I switched my efforts to NSPR in order to have greater portabilit=
y
(including win32).=20
Larry does lmbench have a threads component that can benchmark different
threads libraries easily? I have to admit I'm not terribly familiar with
lmbench... but if you've got some benchmarks you'd like me to run I can
try them. Or you can try them -- NSPR comes with mozilla, after
downloading the tarball, "cd mozilla/nsprpub", then do "make BUILD_OPT=3D=
1"=20
to get the user-threads version, and do "make BUILD_OPT=3D1 USE_PTHREADS=3D=
1"=20
to get the pthreads version.
Dean
------------------------------
From: tbittih@pal.xgw.fi
Date: Sat, 20 Jun 1998 21:46:49 +0000 (GMT)
Subject: fork() memory corruption... is this glibc2 or kernel?
This message is in MIME format. The first part should be readable text=
,
while the remaining parts are likely unreadable without MIME-aware tool=
s.
Send mail to mime@docserver.cac.washington.edu for more info.
- --17433104-719617946-898378338=3D:17938
Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII
Content-ID: <Pine.LNX.3.96.980620213244.17939B@bx1.bx.fi>
While coding some network apps I noticed that fork() seemed to corrupt
memory... so I ripped 95% of the program out and changed some things so
that the bug hit the "critical" memory area around 10x more frequently...
I'd want to know whether this can be seen with libc's other than
2.0.7pre1/2.0.7pre3... and arch's other than x86...
... and after that I'd want to get rid of this bug for good ;)
- --17433104-719617946-898378338=3D:17938
Content-Type: APPLICATION/x-gzip; name=3D"fork_debug.tar.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.980620214649.17967A@bx1.bx.fi>
Content-Description: fork_debug.tar.gz
H4sIAAcqjDUAA+0baXfbNjJfjV8xlZM16UgyD0lOrKitD8XRPsf289FsNsnT
o0hQQkyRLI/Ial72t+8MSOqyE2f7bDfeCjlEAoM5MMBgBhy4QXTRdXgv7W88
uqsCNWNzsw6PAPTNujb7WxQNoFGvmZpRMzcb2GzUjcYjqN8ZRzMljRMrAniU
9ESSiMFX4W5qf6DFneo/FsPQ41X71mnomtao1b6qf9PUJ/o3jQbpv2bUUP/a
rXNyTfmb639jncE67AbhOBL9QQLKrgr68+fP4CwNhlYMr7jwA3iRS/9raHnV
y/6o6oqfy7B/fACfeBSLwAcDggg8K+ER4TsbiBhc4XHA3zAKPgmHO/Cmc/bq
6PwMtg/fwpvtk5Ptw7O3TYg5Qvm2lxKIPWFE9sbZCcMg4ohzg7HVHAxexON4
IxmHPK4Ofp6tThwRzFelvsDaRbBI+P0rXT3Rm6sr5QtiUJqpc3r0zlYd7gqf
w54RIq5E8cqX5XG1WlXhPXMC+CxcxXvR2mvvnO93je5B+7f2gQquhHUVpBWk
SRkuoQyrqzBWm19gNEB5FU1l7FMgHHAEVxAWeBSp7DNbQXz0GOJ/QaSUaNWC
a2EXp6Q22Qq/FIkEaLIvjFHHoSV8hVDJ7i87B21Yd0MEjXgfR4RHQFACK+g3
HHUjnqSR/8nyUt7SykS4G2GrPcDVMeK90Orzd2/aO8fb++3Tf39oMraysQ58
mKLOcTDBgkGShKg/3+d2QjNiJJIBDLjl4AyBSIRrDqDUpEiUBhTFDVtuEHJf
KSU8TkjdpXIpKqlqq3V4fnCgshVkfCWTGJRcGVLaLyiwF/MMQA4cKKC4fZ7E
Ss5qecJq2Q1VFX5qQY5UdqLxVEQLJ4KHDOR9iPKkW0Un2JXPgFKKvo9zEAI5
1//AWeqh6mMpycoMA6JFLNgKESzT+0+t9tFL9R/0sPbeX1MB/zRlH9HS5AMq
SzJD3ZXUj5ESd1ShwgswERpHEwc35U0JVmhBVFrGB0RArFWMrbX30VoZKvoW
0YAK0OwOQ9JJ4LpQeh+990ty+SCKGJViD5R5dWeCSr5sK+agbdHwIBp7GE7G
E0qVSmWnvd85hL3ts218KeFwabJv0Ru1NYf46dNmXl8sE5xYpR2cgD44VmIh
Y2oBQQqRc65Fc1tR1Re6SotA1qlS1tft10cnb2H36OTk/Pisc3QIDk9wsqFC
Bhz1U8F3nE9ODDj7/HTYw0keuJAMcCxiXJuFwlDMybjK1y/ZTy/i1kVzOg76
FvuWUIvgRg7+lbFrH+59/8jl02Nh5Nq+QwItDt2iNECLAz5//8AmA45TLYrS
MF+4ngdWGHIrM7443S+4N84GGeeqH6Dh8GUvV0RxgsPN54Z3lud3T+IPyGy5
sCHqV8ccLaqVekk+itKimWq+SuS/L2S8aIgW5y8Zvb96H32oZcb/m+y9t02D
/L/G1/0/vWbquf+nb5pGjWrqS//vfspU/2g/LfLV+pE1JHfEHkA8CFLPAdxQ
+n00phZkJgSGHO3CeNZmYH92jRN5sxfJmPQVC7rkNkboEMaBm4ysiDdhHKRg
Wz5E3BG0tfXSBK1QApbvbEjv0BHumGFF6qOnIa0SejfDODP9HPYPz2Gf+zyy
PDhOe56w4UDY3EcTiYyFVBMPcAvpjRmBvyTqpzl1eBkgVoskbAJHfwYJzDi8
GYEcWxkdYKZYCTGM+44cFhW5HGdecdGvelXgqVxOYVcH6BjhA2JDwaQ97nFI
Y+6mXpkh5FdcaXK5yMfin3iGh3wmgWhRmMjykzHyzF63T3ZfIfz2Tuegc/aW
/PaXnbPD9ukpvDw6gW043j456+yeH2yfwPH5yfHRabsKcMqJIc6+MZyFs07b
MrqmMYr6Nlce+kU4e8jAfIdaemNU9u8pOoXkxOAAuFEwZENOnGLbKBKyIQng
WworQ8e3q2VWfw5nnFxHOPYsG9V0mgqcQaaJu9NOECcE+XobQDN0Xa/oprYJ
cH66/XfZUK7G/7dv4m6y/4ZWL+J/zajVZfxf15b2/z7KA4r/capgIO6inwjd
7u5Bp3141n3FVnHd+2QPnBRtnW1lVhTRSbbQ2thoAf2kOmCrMmgsIvcZFNNo
fjZeX9EowtW2ZCgNXhCETQwJwEJjTC9xEz1+6YsTb/MY3rx5U2A3CYmUpYdB
Agb2tNT6xO9Mr0nUiaugbjbopMP1Sc7X2//qHp8c7aJxbp9OwOdqV4yNdV0n
ZBj6CDeL/tHednG7iLo4uZMYFAwR0E+Xsfw6+Bgnowksw1wtRzG9hTrc5zGI
6goHXewCbcKt4bfQzoDmUPIUAkPYjEEKOH6aDr6MTP/qRfA3LjP2/7V1wWmm
3jqNG85/da2+Wdh/w6D9l+y/vrT/91FWb9f2r96+6UcOd1sbaRxtiNqzRsUT
fnrpiZ6tb/SEv9G3bbbTOTxtZd4LdgvY0c4/i/dqAPlpbwBOrxqwg87OaWsV
Kh53uW9ztvfyYHv/tFXpA1buZeZ7b4cd5PVYSVYMvVN6Yrs59BvaBSpHBjxW
MkCVseL8AuuIIZWtVDeQG/gZivNNxjKmCIR4RJDHyi4O+mMlp6dOEVIl8qpC
JYDHv056sEKuLSj8tckDK0TdKoQeMBJ6i0QfMGZ73PK32Eo0hIo7xUjxR9YE
8mcKIOWA9f9MJfirp+uy3HKZsf84SW7/2x+VG+w/1LXaxP83TTr/MU29vrT/
91EekP//7S94paKuhIZOeqTkgk482HlnlcuvYvlpskgCS3n+XJ1+PKOenhWj
Dx06FFB8tS9oD/3seX793830vsn/qze06frXTbn+a8Zy/d9HeUjrX34Zj3/3
ujyKsq/jlyKxA6eIOakp/wA9t2IHQZzMR7YUG8/XhFYcz9c4vVm0XhBzBSuu
MS3z1oHCaISTvPp8lINdhSlnH+CL0Drz4bq/pzwazwGH+jUQXSNcAFqQxriu
k3lTp4V3U0bt+aHDSfuse/b2uK3gQ5keyi+PjlSqBnxQqEadAO8ed3d3j5VL
ddotwzlPoQyX0z6dw7MrnVCEa3qwHL094PZFN7F6HvetIe8K3xE401KLFPAV
GDq+mLbO6RGrCx4mG8Al2f/rGvKdQY5QKs9qcpDiNaNQvBUS/XB7xYz9zz/z
4CZKq8gRdIoe3waNG85/Kdwvvv/VtDr5f5u6Zi7t/30UVL2wfAgt+8Lq8xhG
8it/EtAXPRjhBvBJxAIXzxbDSLtrVDerRtWs1Krv6o3ND4zi8AbWatXNMOJ6
pbZQY1b0H27GL8tsmf3+kznQ957/CZu6Pv3+s5nnfy7X/72Uh+T/fW/8982s
zuuSRBMx5FSTe3cyIJTemQz1sspkGLaGlucFtqLrWd5USjCO6IskfqrL9Kcs
vw6U2M9TPbFXGXR0tEpP0hK6fGqe1pgn2lF2Ux5JKjI/sVm0VbLsM+z/Ttc+
ZPlgsxlSeS9slwmRfzoIvbr+7+b77zfWv6HVpuvfNPTs/H95/nMv5UGt/zxS
wImKfymoiZWBNUYF2hdln3PH42rROBKes9hYXvtlrayri3hoAvyPeNbXyoaa
W4tZwLmos+g0F8DkGGbrqCc9FJVkVfzA/4NHwSTgRAq+HY794RyJOLLLQCnJ
XeyR2aTcuskMGhFx5xcauQmOa1HMErGthACyAJgvhs0SmKhQEwxx6VBekh1x
+dVdJnwXRDYyWzlPnZCb38JuXKkx/zTBGSuexcIUsHWToEvPORMU2ucRHuJJ
bQyYQ08kGP8Mh1am2um7MhEki9397+rVTf2Lac/iZICS3LqzvZTrMLlBkPNu
B6mfV8fz+pM4Zcb/xYCSbguJs2YrtvtD2t4mX+Gv0pH3C0ieIt1/fT3iMW40
TfaluXTf/7/LzP5/0t7ee92+Axo3xP+m1qhP7//Vaf83a5vL/N97KXPJqPkJ
UAzW9Sm+EAdDLk8IqtUqm9y+kHa4T5G/AUp2oLAWw5WzgY3sQEBldFmALhHM
IyD4erVWNZ8BYT9Di49NSDjmn2Sa6OWzBvIzDNOEWMz7+OklXPDI514MSKti
VPWqrjUkhgGfSJZnMuPG4Uw+ZiNum1MeMUhnPb/V0+PJiHOfzdxTKUkgef0i
e61QVqoTILTM0S3SbpFYz+PDGFLf43GcZ0szupcENu5O3CHJhatkDS90Vd5y
0HCL62YM+mtJFyzXxWEB4t6KuC8vW1Ae8cgay9xfpI0+E5KhU5rpzQ2/nyuN
iHQoR+0Cxw/ZoyxZqR1UXxrZJGOaMEcQNel9IXJ5SSbLG44QSUL3PejaB86E
TO9EdSgdsx65a/mY0zCfBkiN+l8gDOqddpssDzjkAaVkTLLIx8SxK/opXaZC
QUY4eNhhFAUYdjCWxlafU7rdBW9CNU9HZaxDMAiOei9QkWySPTZVEnunafCb
5QlnD99u6+EDotXvAi2N3LuGeReoi3kq1xk60MKV01UutljOBlIp/crsxSK9
vG9FvXyKpnGK03UM09HN7wPFbIh+gSCtkppjuTAmmFBJMTr6GQnqusGxeWhF
F3HRH2dAQBQWlXf94w+v0vP9neJvptIF5qmK5baCVtvIwvWuyrDGHqDbj8ub
biFIK5IvSJr+crk7wnVpqCj7XQ5pZg1i9knwURiQxUJTnOX559ZaSCJob6Q1
yA0Dd/KbBPIOHC5RVDdaKtLvQEjrwPDVJoO1inoZYp1wZ7Fm9muCrKkufcL/
nzLj/2G0cTcJQDfl/+vmJP/TrMn7/2Z9mf95P+VBnf9cPcO9etV9/n57+SMG
tYhF+djSmh9fGPjf06f5GSxV00VsQdUCqyE/tC2hOc+u1xYV8hJ1fvW8qFu8
D00wnf3Do5P2Xvegc9ie9JmSx4UwQ79A9OTyySWUyh839Eb54xO9ISlPmXs+
z9tkC/ouDmduHV/Dj3EdO2gKSgssLI7PBOQ66nlWlba8lrssy7Isy7Isy7Is
y/Ijlv8Cm+tQHgBQAAA=3D
- --17433104-719617946-898378338=3D:17938--
------------------------------
From: "Nicholas J. Leon" <nicholas@binary9.net>
Date: Sat, 20 Jun 1998 17:56:53 -0400 (EDT)
Subject: Re: OFFTOPIC: e2fsprogs and +2Gb partitions=20
On Fri, 19 Jun 1998, Gordon Oliver wrote:
# perhaps then, someone should go about putting together a perl script t=
o
# extract useful definitions from the kernel and put them in a "public" =
set
# of headers. This satisfies Linus' problem (stifling kernel changes), a=
nd
# the problem of others (slow migration of constants to copies/packages).
This is precisely what I was thinking. Except that unlike you, who doesn'=
t
think these minimal headers should be distributed with the kernel, I do.
In fact, we could "build" the headers during the make process and copy
them into /usr/include/{linux/scsi/asm} during the install (_does_ anyone
use "make install" ? ... I do :)=20
1. No more symlinks from /usr/include -> /usr/src
2. Same header files originally, just perhaps piped through gcc -E or
something with the appropriate defines to get what we want to be
visible to userspace.=20
3. We could stop people dead in their tracks from using stuff inside
#ifdef KERNEL by simply not having those sections in the /usr/include
headers.
4. We would abstract some of the changes that _shouldn't_ visible to
userspace programs.
Granted, I don't know the ins-and-outs of this, but thats basically my
thought.
- -----------------------------------------------------------------------=
------
Nicholas J. Leon "Elegance Through Simplici=
ty"
nicholas@binary9.net - - http://mrnick.binary9.n=
et
8 4 9 1 7 3 <-- what is the pattern?
------------------------------
From: Mathieu Bouchard <boum01@UQAH.UQuebec.CA>
Date: Sat, 20 Jun 1998 18:07:19 -0400 (EDT)
Subject: Re: How much kernel stack do we need?
> > You could experiment by initializing the stack such that only a porti=
on
> > was used. For example, allocate 4K, allocate kernel stuff, and then s=
et
> > the pointers such that only 1K is available for use. That would expos=
e
> > the memory hogs quickly. That is a pure debug case, of coruse.
> Don't forget about nested ``slow'' interrupts and bottom half handlers.
> I think we don't have enough stack to be able to deal with the worst
> case.
can't this size just be variable? like, auto-extend to 8K when necessary?=
=20
if swapping issues are a problem, well, something like 1% of RAM or 256k=20
whichever the smallest is (just change my constants that probably aren't=20
very good) could be reserved in case of big problem. this could be tuned=20
through /proc.
matju
------------------------------
From: Alex Buell <alex.buell@tahallah.demon.co.uk>
Date: Sat, 20 Jun 1998 17:59:46 -0400 (EDT)
Subject: v2.1.106 compilation error
Hi guys,
I finally took the chance to compile v2.1.106 today, but just got an
compile error: (see following output)
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -=
fomit-frame-pointer -pipe -fno-strength-reduce -m486 -DCPU=3D486 -DUTS_MA=
CHINE=3D'"i386"' -c -o init/version.o init/version.c
set -e; for i in kernel drivers mm fs net ipc lib arch/i386/kernel arch/i=
386/mm arch/i386/lib; do make -C $i; done
make[1]: Entering directory `/usr/src/linux-2.1.106/kernel'
[ snip ]
make[1]: Leaving directory `/usr/src/linux-2.1.106/lib'
make[1]: Entering directory `/usr/src/linux-2.1.106/arch/i386/kernel'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -=
fomit-frame-pointer -pipe -fno-strength-reduce -m486 -DCPU=3D486 -c -o =
process.o process.c
{standard input}: Assembler messages:
{standard input}:632: Error: operands given don't match any known 386 ins=
truction
make[1]: *** [process.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.1.106/arch/i386/kernel'
make: *** [linuxsubdirs] Error 2
I'm using egcs-1.0.3a, binutils-2.9.1.0.6 with this kernel. What gives? I=
s
there something I've forgotten?!
Cheers,
Alex
- --
/\_/\ Legalise cannabis now!=20
( o.o ) Smoke some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk
------------------------------
From: jalvo@cloud9.net (John G. Alvord)
Date: Sat, 20 Jun 1998 22:14:47 GMT
Subject: Re: How much kernel stack do we need?
On Sat, 20 Jun 1998 18:07:19 -0400 (EDT), Mathieu Bouchard
<boum01@UQAH.UQuebec.CA> wrote:
>> > You could experiment by initializing the stack such that only a port=
ion
>> > was used. For example, allocate 4K, allocate kernel stuff, and then =
set
>> > the pointers such that only 1K is available for use. That would expo=
se
>> > the memory hogs quickly. That is a pure debug case, of coruse.
>> Don't forget about nested ``slow'' interrupts and bottom half handlers.
>> I think we don't have enough stack to be able to deal with the worst
>> case.
>
>can't this size just be variable? like, auto-extend to 8K when necessary=
?=20
>if swapping issues are a problem, well, something like 1% of RAM or 256k=
=20
>whichever the smallest is (just change my constants that probably aren't=
=20
>very good) could be reserved in case of big problem. this could be tuned=
=20
>through /proc.
I have seen code that does this on another system. Linkage assist entry
(roughly 20 instructions on a non-extend path) and linkage assist exit
(roughly 10 instructions) was needed. That seems pretty excessive to add
to kernel overhead.
john alvord
------------------------------
From: Tomas Lund <tlund@nxs.se>
Date: Sun, 21 Jun 1998 00:46:43 +0200 (MET DST)
Subject: eth0 and eth1, how to get all packets to use the right source-ad=
ress?
A friend of mine has a problem with routing on a Linux box. The network
looks something like this:
real real
adress _____________ 192.168 _______ adress
______| isdn-router |_______| Linux |_______| Rest of
|_____________| |_______| | network
The interface on the "far side" of the isdn-router has an ip-adress from
the ISP, and the rest of the network is using a class C-network that is
routed to the ISDN-router. The Linux-box and the ethernet interface on th=
e
ISDN-router use 192.168 adresses. Everything works great except one thing=
,
You cannot access the internet from the Linux-box since all packets sent
out gets a source-adress from the 192.168-net. This i perfectly normal I
assume, since the default route is out trough that interface :)
The question is, how do you get it to ALWAYS use the ip-adress on the
other interface?
Best Regards, Tomas.
- --
"I'm not a vegetarian because I love animals, but because I hate plants"
------------------------------
From: Wakko Warner <wakko@ani.animx.ml.org>
Date: Sat, 20 Jun 1998 20:04:24 -0400
Subject: PCI sound cards
When will linux support PCI sound cards? Creative has their SB64 PCI car=
d
available. It says it will support DOS, so I would assume that linux can
support it in some way.
------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun, 21 Jun 1998 01:34:01 +0100 (BST)
Subject: Re: PCI sound cards
> When will linux support PCI sound cards? Creative has their SB64 PCI c=
ard
> available. It says it will support DOS, so I would assume that linux c=
an
> support it in some way.
Assuming its ES1370/1371 based then 2.1.106ac3 should support it fine. Th=
omas
Sailer wrote the drivers.
------------------------------
From: Wakko Warner <wakko@ani.animx.ml.org>
Date: Sat, 20 Jun 1998 20:51:09 -0400
Subject: Re: PCI sound cards
> > When will linux support PCI sound cards? Creative has their SB64 PCI=
card
> > available. It says it will support DOS, so I would assume that linux=
can
> > support it in some way.
>=20
> Assuming its ES1370/1371 based then 2.1.106ac3 should support it fine. =
Thomas
> Sailer wrote the drivers.
On their page under PCI64, it is identified as ES1370. The real reason I
was asking was the fact that on the PCI bus, as far as I've seen, all the=
IO
ports and IRQs are selected at boot time by the PCI bios and the io ports
are usually > 0x6000
On SB's page, it said it's 0x220/240
------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun, 21 Jun 1998 01:55:41 +0100 (BST)
Subject: Re: PCI sound cards
> > Assuming its ES1370/1371 based then 2.1.106ac3 should support it fine=
. Thomas
> > Sailer wrote the drivers.
>=20
> On their page under PCI64, it is identified as ES1370. The real reason=
I
> was asking was the fact that on the PCI bus, as far as I've seen, all t=
he IO
> ports and IRQs are selected at boot time by the PCI bios and the io por=
ts
> are usually > 0x6000
>=20
> On SB's page, it said it's 0x220/240
The soundblaster emulation facilities in those cards won't work with Linu=
x.
You need Thomas current driver, and that drives it directly via the PCI
as the gods intended
------------------------------
From: Simon Richter <geier@psi5.com>
Date: Sat, 20 Jun 1998 16:48:52 +0200
Subject: Re: (reiserfs) Re: LVM / Filesystems / High availability
greg@nightshade.ml.org wrote:
> > find / -package glibc2 -bdate 15-06-98
>
> That sounds *alot* like the stuff rpm can do without bloating the kerne=
l.
rpm can't do that, since it would require heavy magic to find files that =
came out
of a tgz rather than a rpm... :-) "install", however, could certainly set=
those
> Perhaps an intelgent thing to do would be to have the FS support 'exten=
ded
> metadata'.
I think this is the way to go. I would be glad if I knew which libraries =
I can
safely remove... I'm currently working on a script that scans my harddisk=
s for
executables, builds a list of libraries that are not linked by any execut=
able, and
sends me this list by eMail. It would be nice if the script could also te=
ll me the
header files that came with the libraries and anything else related to th=
em.
CU
Simon
------------------------------
From: Ralf Wierzbicki <rafal@boa1.dcss.McMaster.CA>
Date: Sat, 20 Jun 1998 21:05:43 -0400 (EDT)
Subject: Limits in the kernel
Hi,
Is it possible to configure the kernel in the same manner as a
solaris/sunos kernel (/etc/system)? It is very easy for a regular user t=
o
make a linux box unresponsive and crash eventually.
This simple program will do that:
main ()
{
fork();
main();
}
I'm sure you all know that, now the question is, how do I prevent
something like that from happening, and is it possible to set some sort o=
f
limits in the kernel?
Thanks in advance.
------------------------------
From: Nathan Hand <nathanh@chirp.com.au>
Date: Sun, 21 Jun 1998 10:08:46 +1000 (EST)
Subject: Re: Thread implementations...
<<< No Message Collected >>>
------------------------------
From: "Anthony Barbachan" <barbacha@mail.cis.fordham.edu>
Date: Sat, 20 Jun 1998 21:30:43 -0400
Subject: Re: undeletable files in /lost+found
Try rm -r first. If that doesn't work you can unlink the directories.
Remember to run fsck after if you unlink.
- -----Original Message-----
From: Pierfrancesco Caci <ik5pvx@penny.ik5pvx.ampr.org>
To: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Date: Saturday, June 20, 1998 2:41 PM
Subject: Re: undeletable files in /lost+found
>Joseph Skinner <joe@snail.earthlight.co.nz> writes:
>
>>
>> Thank for all the suggestions.
>>
>> The rm command from debugfs seems to have done the job [fingers
>> crossed].
>>
>> For those interested in the gory details I used the -f switch with all
>> the commands stored in a file to save time ie.
>>
>> debugfs -w -f commandfile /dev/hda2
>>
>> Where commandfile contained
>>
>> cd /lost+found
>> rm filename
>> ...
>> close
>> quit
>>
>>
>
>Ok, does someone know how to get rid of these:
>
>root@penny:/home/lost+found # ls -lasR
>total 75
> 10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 #101601
> 2 drwxrwxr-x 3 ik5pvx staff 2048 Dec 24 19:48 #34548
> 62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 .
> 1 drwxrwxr-x 8 root root 1024 Dec 13 1997 ..
>
>#101601:
>total 82
> 10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 .
> 10 drwxrwxr-x 3 jnos staff 10240 Dec 24 19:48 .
> 62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
>
>#34548:
>total 126
> 2 drwxrwxr-x 3 ik5pvx staff 2048 Dec 24 19:48 .
> 62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
> 62 drwxrwxr-x 4 root root 62464 Jun 7 18:33 ..
>root@penny:/home/lost+found #
>
>
>the double "." and ".." entries prevent the directory to be deleted.
>
>Pf
>
>--
>
>------------------------------------------------------------------------=
---
- ----
> Pierfrancesco Caci | mailto:ik5pvx@infogroup.it -
http://gusp.infogroup.it
> ik5pvx | http://www.geocities.com/SoHo/Lofts/899=
9
> Firenze - Italia | Office for the Complication of Otherwise Simple
Affairs
> Linux penny 2.1.106 #8 Fri Jun 19 19:53:23 CEST 1998 i586 unknown
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" =
in
>the body of a message to majordomo@vger.rutgers.edu
>
------------------------------
From: lm@bitmover.com (Larry McVoy)
Date: Sat, 20 Jun 1998 18:28:22 -0700
Subject: Re: Thread implementations...=20
: This demonstrates the point that select and poll are workarounds for
: the lack of threading support in Unix. They aren't needed if you use
: a threads facility (or a separate process for each thread you need).
:=20
: Once you have threads you can stick to the intuitive synchronous model
: of system calls, which has always effectively handled waking one of
: multiple waiters.
There are a number of people, usually systems / kernel types, who realize
that multiple threads/processes can have a severe negative effect
on performance, especially when you are trying to make things fit in
a small processor cache. Event driven programming tends to use less
system resources than threaded programming.
------------------------------
End of linux-kernel-digest V1 #2117
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".
--
Kevin L. Mitchell <klmitch@mit.edu>
------------------------- -. .---- --.. ..- -..- -------------------------
http://web.mit.edu/klmitch/www/ (PGP Key AE87D37D availiable here)
DE EA 1E 99 3F 2B F9 23 A0 D8 05 E0 6F BA B9 D2
