Linux-Development-Sys Digest #15, Volume #8 Wed, 12 Jul 00 10:13:08 EDT
Contents:
Unresolved symbols on module under 2.2.14-5.0 (Brad Benson)
Re: NFSRoot problems ("Quiney, Philip [HAL02:HH00:EXCH]")
Re: processes with status <defunct> ([EMAIL PROTECTED])
Re: Why Does Linux Arp All The Time? ([EMAIL PROTECTED])
Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC (Charles Eicher)
Re: Possible bug in insmod (RH5.2) (Robert Kaiser)
2.2.15-Lockup with PLX9050-based PCI card (Andy Thaller)
Re: are PCI drivers char drivers? (Marc SCHAEFER)
Re: are PCI drivers char drivers? (Zoran Cutura)
Re: Possible bug in insmod (RH5.2) (Villy Kruse)
Re: Unresolved symbols on module under 2.2.14-5.0 (Toby Haynes)
Install new gcc ("Chun Seong Ng")
Re: 2.4.0test2 and pppd (Johan Kullstam)
Re: are PCI drivers char drivers? (Grant Edwards)
----------------------------------------------------------------------------
From: Brad Benson <[EMAIL PROTECTED]>
Subject: Unresolved symbols on module under 2.2.14-5.0
Date: Wed, 12 Jul 2000 07:09:46 GMT
I'm trying to install a kernel module on a 2.2.14-5.0 kernel and I keep
getting unresolved symbol errors. Here's the error message I get:
/sbin/modprobe pwdt
/lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved symbol request_region
/lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved symbol misc_deregister
/lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved symbol release_region
/lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved symbol misc_register
/lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved symbol printk
/lib/modules/2.2.14-5.0/misc/pwdt.o: insmod
/lib/modules/2.2.14-5.0/misc/pwdt.o failed
/lib/modules/2.2.14-5.0/misc/pwdt.o: insmod pwdt failed
Here's the line used to make the module:
gcc -m486 -O2 -Wall -pipe -DMODULE -D__KERNEL__ -DMODVERSIONS -DLINUX -c
pwdt.c
Here's output from /proc/ksyms for request_region, results from grepping
on the other symbols are similar:
cat /proc/ksyms |grep request_region c011c644 request_region_R6d32b2d7
What am I missing here?
Thanks,
Brad Benson
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Quiney, Philip [HAL02:HH00:EXCH]" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,linux.dev.kernel
Subject: Re: NFSRoot problems
Date: Wed, 12 Jul 2000 08:05:24 +0100
Krik Lee wrote:
>
> Hi:
>
> I am trying NFSRoot in 2.4.0-test2-ac1.
> NFS server is executed on a PC running RedHat6.2.
> However I only get the following error message:
>
> eth0: NE2000 found using IRQ 11
> Looking up port of RPC 100003/2 on 140.109.21.108
> Looking up port of RPC 100005/2 on 140.109.21.108
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 68k init
>
> nfs: server 140.109.21.108 not responding, still trying
> nfs: server 140.109.21.108 not responding, still trying
> Device lo is down.
> Device lo is down.
> Device lo is down.
> Device lo is down.
> nfs: task 60 can't get a request slot
> nfs: task 61 can't get a request slot
> nfs: task 62 can't get a request slot
> nfs: task 63 can't get a request slot
>
> Could anyone tell me what's going wrong??
Hi,
Yes I think you are finding the benefits of 'bleeding edge' kernels. The
NFS Root option and also the ability to boot a remote kernel (so
producing a diskless workstation) has been broken & fixed & broken along
the way.
Approximate 'timeline'
<2.3.48 all OK
2.3.48 eth0 device did not remember DHCP IP settings so following
kernel download the system hung
2.3.51 (approx) fixed again
2.3.99pre1 A similar problem to what you reported basically did a kernel
oops after the 'Looking up port of RPC 100005/2 on server_ip' message.
2.3.99pre7 fixed again.
I haven't tried any of the 2.4.0test series but 2.3.99pre7 works OK as
described above.
I am not sure of your setup but you need 'kernel autoconfiguration' if
doing the diskless thing as well as root file system via NFS.
I suggest that you stick to stable kernels unless you have already
proved that your configuration works with the 2.2.14 stock RH6.2 kernel
or you need some feature of the development kernel series.
Regards
Phil Q
--
Phil Quiney CSIP Demonstrator
[EMAIL PROTECTED] Nortel Networks,
Telephone: +44 (1279) 402363 London Rd, Harlow,
Fax: +44 (1279) 402885 Essex CM17 9NA,
United Kingdom.
"This message may contain information proprietary to Northern
Telecom so any unauthorised disclosure, copying or distribution
of its contents is strictly prohibited."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: processes with status <defunct>
Date: Wed, 12 Jul 2000 07:50:11 GMT
On Wed, 12 Jul 2000 01:10:51 GMT Kaz Kylheku <[EMAIL PROTECTED]> wrote:
| On Tue, 11 Jul 2000 23:44:03 GMT, [EMAIL PROTECTED]
| <[EMAIL PROTECTED]> wrote:
|>On Tue, 11 Jul 2000 19:44:16 GMT Kaz Kylheku <[EMAIL PROTECTED]> wrote:
|>
|>| Read the comp.unix.programmer FAQ. A terminated UNIX process must be collected
|>| by one of the wait system calls.
|>
|>Isn't the only thing being held by the process just the wait code? Aren't
|>all the other resources already freed up? If we could make defunct processes
|>not count against quotas, I see no major reason not to usually just ignore
|>them. Of course way too many of them could fill up a fixed sized process
|>table.
|
| I suppose that non-swappable kernel memory being occupied for no good reason
| doesn't bother you. ;)
True. How big is a process table entry? Oh, I'll go look it up.
|>I guess we still need some sort of unified wait-for-anything-to-happen
|>system call. Waiting for multiple different classes of events (file
|>descriptors becoming ready being one, child process state change being
|>another, and signals being yet another) is still something that often
|>has to be done, and is cumbersome with the current mechanisms.
|
| That's one of the things threads are for. If you want to wait for three
| different unrelated things, chances are you can do it with three different
| threads executing in three different subsystems. Writing one big event loop
| that handles everything can calls out in a big switch is a little old
| schoolish. :)
Why do you say that? I could argue UNIX is "old school" too. But it works.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why Does Linux Arp All The Time?
Date: Wed, 12 Jul 2000 07:57:53 GMT
On Wed, 12 Jul 2000 00:32:20 GMT Pete Zaitcev <[EMAIL PROTECTED]> wrote:
|> I would prefer the ARP logic work a little differently. Maybe if I get up
|> enough motive I might go hack the change. The way I might try changing it
|> would be:
|>
|> 1. Record an expiration flag in each ARP entry.
|> 2. After 60 seconds of inactivity mark the entry expired.
|> 3. After 5 minutes of activity mark the entry expired.
|> 4. When an ARP lookup gets an expired entry, broadcast the ARP request,
|> but go ahead and use the expired entry for now.
|> 5. If the ARP response is received, replace the ARP table entry, and
|> clear the expired flag.
|> 6. If the expired entry is still expired after 20 seconds remove it from
|> the ARP table.
| You need to work on your definition of "activity". Suppose a user
| (== any layer that is higher than ARP) sent out a packet, which
| is resolved through an ARP cache hit. Does that constitute an
| "activity"? I think not! If this packet never reaches a station
| that is powered down, you'll never know that.
That's what the ultimate expire is for.
| In my opinion an attempt to cache an "active" ARP entry would be
| misguided. RFC-826 only states that periodic broadcasts are
| undesireable to keep tables up to date at all times. It does not
| prohibit timing entries out.
I didn't describe anything like that. My logic has timeouts. It
just allows using a timed out entry for a _small_ finite time so
that there is no needless gap in ARP coverage. I hate periodic
packet drops, but I don't want to give up timeouts, either. I will
call this scheme "seamless ARP".
| When RFC-826 was written, IP addresses did not travel routinely
| from MAC to MAC, but in these days they do. One case would be a
| DHCP governed network when an IP address can be reallocated, and
| another case is a HA type of environment with standby servers.
So we need timeouts. I think that's obvious. My logic is just a
means to let the expired ARP entry continue to do its thing for a
few (20) more seconds. If a machine goes away entirely, sending
to its MAC address for 20 seconds longer isn't really going to hurt
all that much.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: Charles Eicher <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: 11 Jul 2000 19:14:54 -0700
In article <4DNa5.302455$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>Unless it was posted multiple times that I've not seen, it's not spam.
>It was cross-posted to precisely two newsgroups. The definition of spam
>is of a post that appears on a large number of newsgroups (some
>definitions include a quantification of this) or that are e-mailed,
>unrequested, to a large number of people. This is a widely-accepted
>definition, and as far as I can tell from this one post, it does NOT
>qualify.
>
>Now, whether the message falls within the charter of the groups to
>which it was posted is another matter. A post can be off-topic -- and
>even potentially net abuse -- and not be spam. I haven't checked the
>charters of the relevant newsgroups to see if they allow posts
>announcing beta programs. Even if they don't, though, that makes the
>posts off-topic, but probably not net abuse. Certainly not spam.
I can hardly thing of anything more ON-topic than an announcement in this group
seeking beta testers for PowerPC Linux development tools. I encourage MetroWerks
to keep us informed of CodeWarrior Linux news.
As for the original complaintant, I suggest that he switch to decaffeinated
products.
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Crossposted-To: comp.arch.embedded,linux.redhat.development
Subject: Re: Possible bug in insmod (RH5.2)
Date: 12 Jul 2000 08:32:56 GMT
In article <9qJa5.5581$[EMAIL PROTECTED]>,
"Norm Dresner" <[EMAIL PROTECTED]> writes:
> I'm afraid you didn't understand the question.
Maybe he did (or I didn't either): In Linux, you are supposed to access
memory-mapped devices through a kernel virtual address which you must
obtain by calling a kernel function (phys_to_virt(), I think), passing
the device's physical address to it. Thus, the device's kernel virtual
address is determined at run-time. You can't tell that address at
compile or link time.
> I have full read/write
> access to the memory using either hard-coded addresses or pointers.
That may be true in your particular configuration because phys_to_virt()
happens to be a no-op, so it still works if you don't use it.
But that tends to change between different kernel revisions (even
different configurations of the same kernel revision) and different
architectures. So it is not a portable solution.
> I was
> trying to make a c-module be able to directly access a memory address
> without having to dereference a pointer.
>
> For example (if it worked), I could access the Dual Ported Memory as
> follows:
>
> extern short DPM_Status , DPM_Command;
>
> DPM_Command = LOAD_PROGRAM;
> while( DPM_STATUS == 0 )
> ...
> where (using the segment capability of gcc and ld) I've already specified
> that DPM_Status is at 0x000D0000 and DPM_Command is at 0x000D0002.
What exactly are you trying to achieve with this ? If this worked,
I bet the compiler would still generate code that effectively dereferences
pointers, so it won't be any more efficient.
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
D-55270 Klein-Winternheim / Germany
------------------------------
From: Andy Thaller <[EMAIL PROTECTED]>
Subject: 2.2.15-Lockup with PLX9050-based PCI card
Date: Wed, 12 Jul 2000 11:15:58 +0200
Reply-To: [EMAIL PROTECTED]
Hi,
I'm having severe problems with a PLX9050 based PCI-card featuring a 32
channel A/D.
I'm trying to write a device driver on my 2.2.15 i386 box. I have no problem
initializing the card and reading any of the 32 channels which involves
writing to certain I/O mapped registers and reading from others. The base
address assigned to the card is 0xb400 and the working I/O addresses are in
the range 0xb400..0xb403. To switch the card to another operational mode,
however, it is necessary to write the mode byte to address 0xb40e which always
leads to an immediate system lockup independent of the mode byte value (e.g.
also when setting the very same mode the card has as bootup default)
The card's manufacturer refuses to help me saying they only support DOS but I
need to get this card up and running. The hardware must be ok for the example
DOS programs work as they should.
What could possibly go wrong, here, Does anyone know if te PLX chip needs some
special treatment on initialisation? Any PCI commands to be set or unset? I
followed the hints from Documentation/pci.txt but since this is my first PCI
device driver, I'm at a complete loss at this point.
In case it's of any help: lspci -vv shows the following informations:
00:0a.0 System peripheral: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 02)
Subsystem: PLX Technology, Inc.: Unknown device 9050
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 9
Region 1: I/O ports at b800
Region 2: I/O ports at b400
00:0b.0 System peripheral: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 02)
Subsystem: PLX Technology, Inc.: Unknown device 9050
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 1: I/O ports at b000
Region 2: I/O ports at a800
(00:0a.0 being the card of interest, the other plx-based board has a different
function)
I would greatly appreciate any help I can get, though in return I can only
offer to supply the linux community with a working driver.
Regards,
Andy.
--
Andy Thaller
TU Muenchen, Physikdepartment E11 Tel: ++49 (0)89 289 12860
James Franck Str. Fax: ++49 (0)89 289 12842
85748 Garching // Germany email: [EMAIL PROTECTED]
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: are PCI drivers char drivers?
Date: 12 Jul 2000 08:08:40 GMT
Peter Huang <[EMAIL PROTECTED]> wrote:
: I'm new to the driver development and it seems that PCI drivers are char
: driver and I can initialize it with register_chrdev(...) Can any one confirm
: that with me?
A PCI driver which drives a PCI modem card is a char device. A PCI driver
which drives a network card is a network device. A PCI driver that would
offer a disk drive to the system (e.g. a software/hardware PCI RAID
device) would be a block device. A SCSI PCI board is a SCSI ha.
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: are PCI drivers char drivers?
Date: Wed, 12 Jul 2000 14:59:03 +0200
Marc SCHAEFER wrote:
>
> Peter Huang <[EMAIL PROTECTED]> wrote:
> : I'm new to the driver development and it seems that PCI drivers are char
> : driver and I can initialize it with register_chrdev(...) Can any one confirm
> : that with me?
>
> A PCI driver which drives a PCI modem card is a char device. A PCI driver
> which drives a network card is a network device. A PCI driver that would
> offer a disk drive to the system (e.g. a software/hardware PCI RAID
> device) would be a block device. A SCSI PCI board is a SCSI ha.
Marc,
you shouldn't mix up things like this.
Character drivers and block drivers have their special meanings in
the kernel. A SCSI or Network driver has only a meaning of
functionality.
A SCSI driver will usually be a character driver, which means
that data is written/read character wise buit a filesystem
will be a block device where write/read will be performed in
blocks of a certain size.
Z
--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.arch.embedded,linux.redhat.development
Subject: Re: Possible bug in insmod (RH5.2)
Date: 12 Jul 2000 13:30:32 GMT
On 12 Jul 2000 08:32:56 GMT, Robert Kaiser <[EMAIL PROTECTED]> wrote:
>In article <9qJa5.5581$[EMAIL PROTECTED]>,
> "Norm Dresner" <[EMAIL PROTECTED]> writes:
>> I'm afraid you didn't understand the question.
>
>Maybe he did (or I didn't either): In Linux, you are supposed to access
>memory-mapped devices through a kernel virtual address which you must
>obtain by calling a kernel function (phys_to_virt(), I think), passing
>the device's physical address to it. Thus, the device's kernel virtual
>address is determined at run-time. You can't tell that address at
>compile or link time.
>
Couldn't have said it better myself.
Thanks.
When moving on from the MSDOS world you need to start thinking in terms
of multiple virtual address spaces which are mapped by the memory mapping
unit of the CPU.
The document /usr/src/linux/Documentation/IO-mapping.txt gives the
the details you might need to know.
Villy
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: Unresolved symbols on module under 2.2.14-5.0
Date: 12 Jul 2000 09:25:58 -0400
!! "Brad" == Brad Benson <[EMAIL PROTECTED]> writes:
Brad> I'm trying to install a kernel module on a 2.2.14-5.0 kernel and I keep
Brad> getting unresolved symbol errors. Here's the error message I get:
Brad> /sbin/modprobe pwdt /lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved
Brad> symbol request_region /lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved
Brad> symbol misc_deregister /lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved
Brad> symbol release_region /lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved
Brad> symbol misc_register /lib/modules/2.2.14-5.0/misc/pwdt.o: unresolved
Brad> symbol printk /lib/modules/2.2.14-5.0/misc/pwdt.o: insmod
Brad> /lib/modules/2.2.14-5.0/misc/pwdt.o failed
Brad> /lib/modules/2.2.14-5.0/misc/pwdt.o: insmod pwdt failed
I used to get this sort of message a fair amount and 99% of the time it was due
to not having the kernel and modules compiled in sync. Try rebuilding both the
kernel and the modules so that you end up with a consistent base, and hopefully
any symbol resolving problems will clear up after a reboot (you need to be
running the new kernel to avoid problems).
Cheers,
Toby Haynes
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: "Chun Seong Ng" <[EMAIL PROTECTED]>
Subject: Install new gcc
Date: Wed, 12 Jul 2000 14:52:04 +0100
Hey Mathias,
I suspect my current gcc got problem and I'm trying to upgrade gcc to 2.95.2
version. But the kernel still show gcc version is 2.91.66 after I've
installed 2.95.2 version.
The following are the steps I've gone through:
1) Extract gcc-2.95.2.tar.gz in a directory
2) configure gcc by key in './configure'
3) build gcc by key in 'make bootstrap'
4) then install it by key in 'make install'
5) and type 'gcc -v' to display gcc version
There is no error prompt out during installation.
my question are:
Do I need to uninstall or delete old gcc version before I install the new
one?
Do I need to configure kernel after I've installed new gcc? If yes, how to
do that?
I referred instructions from '/install/index.htm' from gcc-2.95.2, and
'HOW-TO Gcc' as well. Do you have any good reference? Please recommend some
to me if you have.
Thanks.
Regards,
Chun Seong
Chun Seong Ng wrote in message <8kcmb7$tl$[EMAIL PROTECTED]>...
>Hey Mathias, thanks for answering my question. I've replaced the asm/io.h
>with sys/io.h and compiled with
>
>gcc -O -o try try.c
>gcc -O2 try try.c
>
>But the same problem happen, i.e. "In file included from try2.c:3:
>/usr/include/asm/io.h:78: syntax error before `extern'"
>
>By the way, I'm using Red Hat 6.1 with Linux 2.2.12 kernel and egcs-1.1.2
>release.
>
>Regards,
>Chun Seong
>
>Mathias Waack wrote in message ...
>>"Chun Seong Ng" <[EMAIL PROTECTED]> writes:
>>
>>> My problem is I cannot compile simple I/O program. The error message
>>> came out was:
>>>
>>> In file included from try2.c:3: /usr/include/asm/io.h:78: syntax error
>>> before `extern'
>>>
>>> My codes was:
>>[snip]
>>
>>> My questions are: What does it means "syntax error before 'extern'"?
>>
>>Don't know, I don't get this error. On my box the program compiles
>>without errors. I've replaced asm/io.h by sys/io.h. Did you used the
>>-O2 flag for the gcc?
>>
>>Mathias
>
>
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: 2.4.0test2 and pppd
Date: 12 Jul 2000 09:26:51 -0400
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Sorry if you are offended. But when it comes to my privacy/rights there
> is no polite way to say "back the fuck off" after all "give an inch and
> they take a mile".
yes but your policy is to blanket insult everyone. most of the people
who read it have intention of interfering with your privacy. why do
you insult them too?
group punishments suck. i learned that in the first grade when the
teacher would punish the whole class for some few idiots misbehavior.
> I do. And a Firewall. And anything else I can get ahold of. I am
> paranoid because I am tired of being screwed for money.
i understand the sentiment.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
edlhp
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: are PCI drivers char drivers?
Date: Wed, 12 Jul 2000 14:00:05 GMT
In article <[EMAIL PROTECTED]>, Zoran Cutura wrote:
>> A PCI driver which drives a PCI modem card is a char device. A
>> PCI driver which drives a network card is a network device. A
>> PCI driver that would offer a disk drive to the system (e.g. a
>> software/hardware PCI RAID device) would be a block device. A
>> SCSI PCI board is a SCSI ha.
>you shouldn't mix up things like this. Character drivers and
>block drivers have their special meanings in the kernel. A SCSI
>or Network driver has only a meaning of functionality.
Wrong. SCSI and network drivers are neither char nor block
drivers. They are network and SCSI drivers.
Network devices (e.g. eth0, eth1) are created "on the fly" as
needed and don't live in /dev like normal char and block
devices. The interface to a network devices/drivers is also
not the same as for a "normal" block or char driver.
>A SCSI driver will usually be a character driver, which means
>that data is written/read character wise buit a filesystem
>will be a block device where write/read will be performed in
>blocks of a certain size.
You have correctly differentiated char and block devices. Block
devices (e.g. disks) transfer data in fixed sized blocks. Char
devices (e.g. serial ports, printer ports, etc.) model a device
as a stream of bytes.
However, the part about a SCSI driver being a char devices
isn't correct. A SCSI driver (for a PCI board, which is what
we're talking about) is a different animal that is neither a
char nor block device. It's a low-level layer that sits
underneath the "generic" SCSI layer, which in turn sits
undernead both char device drivers (e.g. st) and block device
drivers (e.g. sd).
--
Grant Edwards grante Yow! I will establish
at the first SHOPPING MALL in
visi.com NUTLEY, New Jersey...
------------------------------
** 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
******************************
