Linux-Development-Sys Digest #711, Volume #8 Thu, 10 May 01 19:13:23 EDT
Contents:
Re: 2.4.4 Kernel, Something Seriously Wrong. David Hinds can you read in please to!
("SilentNight")
Re: UDF write on MO ("SilentNight")
SIGSEGV is not blocking (Saurabh Desai)
segfault in module, how can I remove it ? (Roman Himmes)
Re: SIGSEGV is not blocking (David Schwartz)
Re: SIGSEGV is not blocking ("Arthur H. Gold")
Re: 2.4.4 Kernel, Something Seriously Wrong. David Hinds can you read in please to!
("E-mu")
Re: segfault in module, how can I remove it ?
Re: SIGSEGV is not blocking ("Arthur H. Gold")
Re: why a separate process for each thread on Linux (Alexander Viro)
David Hinds ,APA 1480 PCMCIA Support in kernel 2.4.4 Question? ("E-mu")
Re: C++ Shared libraries on Linux - problem, HELP! (Steve Connet)
Re: Guid generator for unix. (Steve Connet)
Re: cache coherency, threads, SMP ("D. Stimits")
Re: cache coherency, threads, SMP ("D. Stimits")
abort() doesn't generate a core dump? (Rob Yampolsky)
----------------------------------------------------------------------------
From: "SilentNight" <[EMAIL PROTECTED]>
Subject: Re: 2.4.4 Kernel, Something Seriously Wrong. David Hinds can you read in
please to!
Date: Fri, 11 May 2001 04:28:47 +0900
well, i begin to doubt if the kernel 2.4.4 is what it is named.
After compiling and recompiling about 20 times on 3 different hard disks, 2
different
motherboards, and 2 different language version (Japanese and English), the
check shows
that the kernel is still 2.4.2-2.
Also, the USB support is not working with devices other than mouse. I do not
try
keyboard so I cannot say.
SN
---
"E-mu" <[EMAIL PROTECTED]> wrote in message
news:9dci43$[EMAIL PROTECTED]...
> I know its the kernel, because I configured it exactly like 2.4.2.
>
> It compiles fine, but when I run lilo -v it hangs when it writes to the
boot
> sector, or if I run mkinitrd it hangs.
>
> Another problem, my adaptec 1480 slim SCSI bombs out when the kernel boots
> up. I noticed they removed adaptec 1480 from the section, SCSI>PCMCIA.
>
> Is it because it no longer is a seperate choice, but rather the drivers
are
> now part of the PCMCIA (y) choice?
>
> Either way my slim scsi aha1480 bombs out. Kernel won't go through a
> successfull boot with the SCSI card bus card installed.
>
> I could not catch the error messages on boot up, but there are also
looping
> error messages to that do not stop, then a get a stack dump at the end.
>
>
> RH Linux 7.1 Up to date patches
> ximian's gnome 1.4-all up to date patches
> kernel 2.4.2-2, monolithic, except for AHA 1480 which only had a choice of
> (m) in kernel.
> Dell Inpiron 7500
>
>
------------------------------
From: "SilentNight" <[EMAIL PROTECTED]>
Subject: Re: UDF write on MO
Date: Fri, 11 May 2001 04:33:39 +0900
I use a USB externeal MO, 640mb, yet the device is not recognized or not
assigned
any name.
Recompiling kernel never gives the same result. Sometimes it recognizes,
sometimes
it says usb modules and scsi modules cannot be found, although one Adaptec
2940W
is in the system, and the scsi-cdrom works fine.
Is there any way to assign device name, or node in any config. file ?
I appreciate any input / info.
SN
----
"Alessandro Bietresato" <[EMAIL PROTECTED]> wrote in message
news:9dcj4s$h29$[EMAIL PROTECTED]...
>
> "Massimiliano Caovilla" <[EMAIL PROTECTED]> ha scritto nel
messaggio
> news:[EMAIL PROTECTED]...
> > Hi
> > I'm trying to use the UDF filesystem on a MO scsi drive (/dev/sda):
> > actually I'm using the module version 0.9 I downloaded from trylinux,
> > but in write it doesn't work well: I must debug it by myself or there is
> > a better version somewhere?
> >
> > Ciao
>
> Are you using 2048/bytes media (like 3.5"/640MByte MO disk)?
>
>
>
------------------------------
From: Saurabh Desai <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: SIGSEGV is not blocking
Date: Thu, 10 May 2001 14:55:41 -0500
Hi,
I am trying to run this small program, which suppose
to block the SIGSEGV, but it doesn't work under Linux.
It returns with segmentation fault and that should not
happen because it is blocked.
Thanks in advance.
=======================================
#include <signal.h>
main(int argc, char **argv)
{
sigset_t sigs_to_block;
char *p = 0;
int id;
sigemptyset(&sigs_to_block);
sigaddset(&sigs_to_block, SIGSEGV);
sigprocmask(SIG_BLOCK, &sigs_to_block, 0);
*(int *)p = id;
sleep(1);
}
------------------------------
From: Roman Himmes <[EMAIL PROTECTED]>
Subject: segfault in module, how can I remove it ?
Date: Thu, 10 May 2001 22:45:09 +0200
Hello,
I try to write an driver for a Webcam for USB. During this work the driver
segfaults during the probe function while initializing. If I want to remove
the module after this, the system tells me that the device is busy.
/proc/module tless me the driver is initializing. After the kernel oops
the system seems to be ok. is there a way to remove the driver againm or do
I have to reboot ?
Thanks,
Roman
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 10 May 2001 13:21:11 -0700
Saurabh Desai wrote:
> I am trying to run this small program, which suppose
> to block the SIGSEGV, but it doesn't work under Linux.
> It returns with segmentation fault and that should not
> happen because it is blocked.
What would be a reasonable thing to happen in this case? You have left
no place to go.
DS
------------------------------
Date: Thu, 10 May 2001 15:34:46 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Saurabh Desai wrote:
> =
> Hi,
> I am trying to run this small program, which suppose
> to block the SIGSEGV, but it doesn't work under Linux.
> It returns with segmentation fault and that should not
> happen because it is blocked.
> =
> Thanks in advance.
> =
> ---------------------------------------
> =
> #include <signal.h>
> =
> main(int argc, char **argv)
> {
> =
> sigset_t sigs_to_block;
> char *p =3D 0;
> int id;
> =
> sigemptyset(&sigs_to_block);
> sigaddset(&sigs_to_block, SIGSEGV);
> sigprocmask(SIG_BLOCK, &sigs_to_block, 0);
> =
> *(int *)p =3D id;
> sleep(1);
> }
=46rom the Linux man page:
According to POSIX, the behaviour of a process is unde=AD
fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
that was not generated by the kill() or the raise() func=AD
tions. =
What do you think the semantics should be in this case?
[IOW, what you're trying to do makes no sense.]
[followups trimmed]
HTH,
--ag
-- =
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more
info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
Clone Bernie!
------------------------------
From: "E-mu" <[EMAIL PROTECTED]>
Subject: Re: 2.4.4 Kernel, Something Seriously Wrong. David Hinds can you read in
please to!
Date: 10 May 2001 20:54:20 GMT
I didn't know 2.4.4 was 2.4.2-2. Ithink that is incorrect because RH 7.1 was
released with 2.4.2-2 way before 2.4.4 was out.
I don't have any problems with my Zip USB, nor my Sony Camera memory stick.
That all works fine for me.
I got 2.4.4 to run ok as long as my APA1480 Slim Scsi Adaptec card bus card
is not installed. Dunno whats wrong with PCMCIA card bus, but I htink the
1480 driver was either left out this time or is not working properly.
And I got lilo -v to work but mkinitrd still hangs but I was able to figure
out how to kill it.
Here is the real problem, when I run mkinitrd followed by lilo -v, then the
system hangs and I cannot kill lilo, no matter what. System then has to be
power'd down at that point!
"SilentNight" <[EMAIL PROTECTED]> wrote in message
news:9deq9b$m1p$[EMAIL PROTECTED]...
> well, i begin to doubt if the kernel 2.4.4 is what it is named.
>
> After compiling and recompiling about 20 times on 3 different hard disks,
2
> different
> motherboards, and 2 different language version (Japanese and English), the
> check shows
> that the kernel is still 2.4.2-2.
>
> Also, the USB support is not working with devices other than mouse. I do
not
> try
> keyboard so I cannot say.
>
> SN
>
> ---
>
> "E-mu" <[EMAIL PROTECTED]> wrote in message
> news:9dci43$[EMAIL PROTECTED]...
> > I know its the kernel, because I configured it exactly like 2.4.2.
> >
> > It compiles fine, but when I run lilo -v it hangs when it writes to the
> boot
> > sector, or if I run mkinitrd it hangs.
> >
> > Another problem, my adaptec 1480 slim SCSI bombs out when the kernel
boots
> > up. I noticed they removed adaptec 1480 from the section, SCSI>PCMCIA.
> >
> > Is it because it no longer is a seperate choice, but rather the drivers
> are
> > now part of the PCMCIA (y) choice?
> >
> > Either way my slim scsi aha1480 bombs out. Kernel won't go through a
> > successfull boot with the SCSI card bus card installed.
> >
> > I could not catch the error messages on boot up, but there are also
> looping
> > error messages to that do not stop, then a get a stack dump at the end.
> >
> >
> > RH Linux 7.1 Up to date patches
> > ximian's gnome 1.4-all up to date patches
> > kernel 2.4.2-2, monolithic, except for AHA 1480 which only had a choice
of
> > (m) in kernel.
> > Dell Inpiron 7500
> >
> >
>
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: segfault in module, how can I remove it ?
Date: Thu, 10 May 2001 21:20:44 -0000
In article <9detpo$bcc$[EMAIL PROTECTED]>,
Roman Himmes <[EMAIL PROTECTED]> wrote:
>I try to write an driver for a Webcam for USB. During this work the driver
>segfaults during the probe function while initializing. If I want to remove
>the module after this, the system tells me that the device is busy.
> /proc/module tless me the driver is initializing. After the kernel oops
>the system seems to be ok. is there a way to remove the driver againm or do
>I have to reboot ?
I'd reboot.
--
http://www.spinics.net/linux
------------------------------
Date: Thu, 10 May 2001 16:34:23 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Saurabh Desai wrote:
> =
> Well, this is part of a big program. In AIX, it blocks
> means I don't see the "segmentation fault" and the program
> doesn't return. I am expecting that on Linux.
> I know it looks like a strange program, but trying to
> understand the concept and behavior.
First of all, once you've entered the "land of undefined behavior"
just about anything can happen (and you can only depend upon a
particular outcome at great peril).
That said, perhaps you could more clearly explain what it is
you're trying to accomplish. =
If all you want to do is have a thread block -- forever -- on a
SIGSEGV (as, modulo memory protection isues there's really nothing
you can do to fix a SIGSEGV), you could set up a handler for
SIGSEGV that loops on, say, a nanosleep() call. In general,
though, without further explanation, it really makes no sense.
HTH,
--ag
> =
> Thanks.
> =
> "Arthur H. Gold" wrote:
> >
> > Saurabh Desai wrote:
> > >
> > > Hi,
> > > I am trying to run this small program, which suppose
> > > to block the SIGSEGV, but it doesn't work under Linux.
> > > It returns with segmentation fault and that should not
> > > happen because it is blocked.
> > >
> > > Thanks in advance.
> > >
> > > ---------------------------------------
> > >
> > > #include <signal.h>
> > >
> > > main(int argc, char **argv)
> > > {
> > >
> > > sigset_t sigs_to_block;
> > > char *p =3D 0;
> > > int id;
> > >
> > > sigemptyset(&sigs_to_block);
> > > sigaddset(&sigs_to_block, SIGSEGV);
> > > sigprocmask(SIG_BLOCK, &sigs_to_block, 0);
> > >
> > > *(int *)p =3D id;
> > > sleep(1);
> > > }
> >
> > From the Linux man page:
> >
> > According to POSIX, the behaviour of a process is unde=AD
> > fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
> > that was not generated by the kill() or the raise() func=AD
> > tions.
> >
> > What do you think the semantics should be in this case?
> > [IOW, what you're trying to do makes no sense.]
> >
> > [followups trimmed]
> >
> > HTH,
> > --ag
> > --
> > Artie Gold, Austin, TX (finger the cs.utexas.edu account for more
> > info)
> > mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
> > --
> > Clone Bernie!
-- =
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more
info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
Clone Bernie!
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why a separate process for each thread on Linux
Date: 10 May 2001 17:51:57 -0400
In article <[EMAIL PROTECTED]>,
Kasper Dupont <[EMAIL PROTECTED]> wrote:
>> Huh? Don't set CLONE_FS in flags and you have independent chdir for child.
>
>Wouldn't it be nice to be able to share file descriptors
>without having to share working directory. I bet it
>wouldn't require many changes in the kernel to implement
>that, the only problem is what flags should be used as
>arguments to clone().
Kernel changes: none. Flags: CLONE_FILES on, CLONE_FS off. Guys, how about
reading the fscking manpage? You'd see (among other useful information)
CLONE_FS
If CLONE_FS is set, the parent and the child pro-
cesses share the same file system information.
This includes the root of the file system, the cur-
rent working directory, and the umask. Any call to
chroot(2), chdir(2), or umask(2) performed by the
parent or child process also takes effect in the
other process.
and
CLONE_FILES
If CLONE_FILES is set, the parent and the child
processes share the same file descriptor table.
File descriptors always refer to the same files in
the parent and in the child process. Any file
descriptor created by the parent process or by the
child process is also valid in the other process.
Similarly, if one of the processes closes a file
descriptor, or changes its associated flags, the
other process is also affected.
And yes, it really works.
FreeBSD equivalents also exist - read their manpage (rfork()
flags have opposite meaning - there you say what should _not_ be shared).
Don't try it on OpenBSD, though - their handling of shared descriptor
tables is race-ridden (as in "put me in empty chroot jail, take away
all permissions, give me UID/GID nobody and I'll panic the box in a
minute or two with nothing but rfork(), pipe() and close()") ;-/
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "E-mu" <[EMAIL PROTECTED]>
Subject: David Hinds ,APA 1480 PCMCIA Support in kernel 2.4.4 Question?
Date: 10 May 2001 22:36:47 GMT
WHat happend to the choice for APA 1480 in kernel 2.4.4. Is it now a built
in driver to PCMCIA(y) or (m).
Anyhow when I boot up kernel 2.4.4, with the AHA 1480 Adaptec Slim SCSI the
kernel goes through some weird error. Some kinda loop after loop during the
initiation of the PCMCIA device. Then it ends up with a dump stack at the
end.
I was unable to capture all the errors , since the the file system nor hard
drive ever gets mounted.
And I have contacted the maintainter for Firewire support "Andreas Bombe "
and he said gave me a web site to check out the "CVS". He said ther is some
support for PCMCIA Firewire support since its OCHI. Along with sbp-2.
Anyhow doesn't this involve you to since this is cardbus. In other words
will there be some kinda low level or whatever driver to drive this PCMCIA
card then, take off from there as far as "Andreas Bombe " , working on the
rest of the drivers.
------------------------------
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: C++ Shared libraries on Linux - problem, HELP!
From: Steve Connet <[EMAIL PROTECTED]>
Date: Thu, 10 May 2001 22:39:05 GMT
"Nick Lockyer" <[EMAIL PROTECTED]> writes:
> > More precisely, gdb displays just:
> > (gdb) run
> > Starting program: /work/src/testbin/testbin/.libs/testbin
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x4000c1b6 in ?? ()
> > (gdb) bt
> > #0 0x4000c1b6 in ?? ()
> > #1 0x40002855 in ?? ()
> > #2 0x4001048f in ?? ()
> > #3 0x40002382 in ?? ()
> > #4 0x400020ae in ?? ()
> > (gdb)
Well from what that looks like, your app isn't built in debug mode
(ie. -g option). If it was, you'd see your source. In addition, the
lib you are linking against may have blown up and you can't backtrace
into it because it wasn't built in debug mode either.
Build both lib and your source in debug mode... then break at main
(ie. b main) and run. Step through each line until you find the
SIGSEGV.
--
Steve Connet Remove USENET to reply via email
[EMAIL PROTECTED]
------------------------------
Subject: Re: Guid generator for unix.
From: Steve Connet <[EMAIL PROTECTED]>
Date: Thu, 10 May 2001 22:48:41 GMT
[EMAIL PROTECTED] (Nick Andrew) writes:
> ... merely reduces the chance of collision, and does not eliminate it.
> I thought GUIDs were supposed to be nominally globally unique, not just
> show low chance of collision.
>
> I'd suggest adding to the 8 random bytes, the FQDN of the local host
> and return values from time() and getpid().
The way Microsoft creates GUIDs (if the box has a NIC), is it obtains
the MAC address and the current system time and munges those into a
128-bit universally unique identifier. It is gauranteed to not be
duplicated anywhere in the universe, forever and ever.
--
Steve Connet Remove USENET to reply via email
[EMAIL PROTECTED]
------------------------------
Date: Thu, 10 May 2001 17:07:33 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: cache coherency, threads, SMP
Norman Black wrote:
>
> What the P6 architecture does is bus snooping. When a processor places an
> address on the bus for a read others processors snoop this and if their
> cache contains an updated value that process will drive the data onto the
> bus and not the memory controller. IF the address pushed on the bus is for a
> write other processors invalidate that memory location within their cache.
>
> The processor caches all operate on a cache line. Therefore a one byte write
> to memory from one processor invalidates an entire cache line in other
> processors caches.
>
> The cache line has been 32-bytes since the Pentium. The cache line is 4
> times the width of the processor data bus, which is 64-bits. Cache lines
> begin on addresses modulo 32.
>
> Therefore if you have spinlock variables it is best if the lock variable not
> exist in the same cache line as other data used by various threads.
> Actually any data that two or more threads will be simultaneously accessing
> should be in unique cache lines so that multiple processors do thump each
> others caches.
This is exactly what I was looking for, thanks!
D. Stimits, [EMAIL PROTECTED]
>
> --
> Norman Black
> Stony Brook Software
> the reply, fubar => ix.netcom
>
> "D. Stimits" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Rik van Riel wrote:
> > >
> > > D. Stimits wrote:
> > >
> > > > In an effort to write more efficient threaded code (x86), and
> > > > considering cache thrashing, I'm interested in finding out
> > > > more about the cache coherency scheme used in 2.2 and 2.4
> > > > kernels. Is it a simple write-invalidate scheme?
> > >
> > > > On a minor note, I'm curious how closely linux x86 SMP cache
> > > > schemes are to other x86 UNIX style systems?
> > >
> > > Cache coherency between different CPUs is completely done in
> > > hardware (on x86). This means Linux and other Unices will be
> > > using the same cache coherency scheme ;)
> >
> > I assume some of the motherboards capable of dual celeron do not have
> > the ability to follow direct cache-to-cache writes when one cpu cache is
> > shared with another and the first is modified relative to main memory?
> > Basically I'm wondering which, of the "oddball" x86 cpu's, including
> > celeron, thunderbird, duron, etc, cannot do an efficient cache-to-cache
> > update?
> >
> > >
> > > Btw, this is happening no a per-cacheline basis, using the MESI
> > > protocol between CPUs.
> >
> > To improve performance, it would still be nice to know the exact size of
> > a cache line in order to keep two areas of global data from splitting up
> > ownership of a given cache line. Are all x86 cpu's using the same size
> > cache line? Is this 32 bytes, or some other known size (and if not is
> > there a way to find out through hardware detection)?
> >
> > D. Stimits, [EMAIL PROTECTED]
> >
> > >
> > > --
> > > Rik
> > > --
> > > Virtual memory is like a game you can't win;
> > > However, without VM there's truly nothing to lose...
> > >
> > > http://www.surriel.com/ http://distro.conectiva.com/
> > >
> > > Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
------------------------------
Date: Thu, 10 May 2001 17:09:17 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: cache coherency, threads, SMP
Paul Repacholi wrote:
>
> "D. Stimits" <[EMAIL PROTECTED]> writes:
>
> > I assume some of the motherboards capable of dual celeron do not
> > have the ability to follow direct cache-to-cache writes when one cpu
> > cache is shared with another and the first is modified relative to
> > main memory? Basically I'm wondering which, of the "oddball" x86
> > cpu's, including celeron, thunderbird, duron, etc, cannot do an
> > efficient cache-to-cache update?
>
> Cache to cache protocols are death to performance unless it is a VERY
> odd HW implementation. It seems to be a good idea, but for it to work,
> the clocking domain must cover both CPUs, and the external caches and
> bus interfacce to memory and the system. It can take forever to sync
> up for the transfer. Been tried, and it is horrid. Much faster to just
> dump the value to memory and the other CPU reads it, or it stalls its
> interface waiting for the write and steals the data during the write.
Caching seems to be a pretty important topic in general for performance,
SMP versus uniprocessor, and single versus threaded complicates it that
much more :(
The article that I found which seems to actually study the issue some,
which I found useful, is:
http://www.ece.cmu.edu/~ee742/proj_s98/slater/
D. Stimits, [EMAIL PROTECTED]
>
> --
> Paul Repacholi 1 Crescent Rd.,
> +61 (08) 9257-1001 Kalamunda.
> West Australia 6076
> Raw, Cooked or Well-done, it's all half baked.
> Spam-To: [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],
> [EMAIL PROTECTED],[EMAIL PROTECTED]
------------------------------
From: Rob Yampolsky <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: abort() doesn't generate a core dump?
Date: Thu, 10 May 2001 19:10:07 -0400
Hi. I don't seem to be getting core dumps from my apps, and I'm not
sure why. System is Mandrake 7.2.
I have an ErrorLogger() function that attempts to maintain a history of
core dumps in a particular directory by
1. chdir'ing there
2. running a 'renamecore' script (to rename the prior core file(
3. calling abort() to generate a new core file.
I use this ErrorLogger() so that I can get a backtrace of apps whenever
they detect situations that should not arise. I also trap several
signals (SIGSEGV, etc) and do the same trick so I can backtrace a
history of segfaults.
This whole scheme works very nicely on AIX, but under linux, abort()
doesn't seem to be generating a core file at all. I've allso tried
sending SIGSEGV signals to other running processes that do not trap the
signal, and I don't seem to get core files for them either.
Is core dumping optional? I didn't think so, but maybe there's some
/proc/... flag you need to set to enable them.
Rob Yampolsky
[EMAIL PROTECTED]
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
