Subject: Linux-Development Digest #413
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 27 Jan 94 17:36:54 EST

Linux-Development Digest #413, Volume #1         Thu, 27 Jan 94 17:36:54 EST

Contents:
  CSLIP/SLIP: kernel problem? when linux as server?? (David-Michael Lincke)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (Hamish Macdonald)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (Jerry Shekhel)
  Re: Which is better? 680x0 or 80x86? (Brandon S. Allbery)
  Re: Which is better? 680x0 or 80x86? (Larry Pyeatt)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (David Barr)
  Re: UMSDOS Patch to Use \linux? (Jacques Gelinas)
  Re: ELF binaries (system admin)
  enhanced DIP for SLIP (Michael Hemy)
  AT&T StarLan EN100 driver project (Eric Hollas)
  Re: Which is better? 680x0 or 80x86? (Rob Janssen)
  Re: DAC ADC device driver (Rob Janssen)
  is there a driver for National 8390 Ethernet Chip  (Russell Nelson)
  Mkimage (Olivier MANGON)
  Re: configuration during boot-up ??? (Arnt Gulbrandsen)
  libc 4.5.8 is killing me (Hendrik G. Seliger)

----------------------------------------------------------------------------

From: dlincke@sgcl1.unisg.ch (David-Michael Lincke)
Subject: CSLIP/SLIP: kernel problem? when linux as server??
Date: 26 Jan 94 21:44:31 MET

I'm posting this to the developement group, since I'm slowly getting the 
impression that this problem is due to something lacking or not working in the 
TCP/IP or SLIP/CSLIP part of the kernel.

This was actually an email to Terry Dawson, who is trying to help me with this 
problem.

I'm running the standard 0.99pl14 kernel. My version of dip is 3.3.4.

>>Since dip -i doesn't do it itself as it claims I tried to set up the 
>>interface and the appropriate routing manually after establishing the 
>>SLIP connection, here is what I did:

I've solved the problem with dip -i not setting up the interface and routing. 
The script which Slackware1.1.1 installs the dip package with is buggy and 
doesn't set the SUID bit on dip. Dip -i doesn't set up routing properly though, 
but first here the routing table and ifconfig output before the CSLIP link is 
set up:

The IP-address of the CSLIP Linux-Server (limerick) is 130.82.154.12
netmask is B-Class 255.255.0.0, Server and Client are on the same network:
130.82.0.0

limerick:/# route -n
Kernel routing table
Destination net/address   Gateway address           Flags RefCnt    Use Iface
default                   130.82.1.2                UGN        0     14 eth0
130.82.0.0                *                         UN         0   9395 eth0
127.0.0.1                 *                         UH         0      0 lo

limerick:/# ifconfig
lo        IP ADDR 127.0.0.1  BCAST 127.255.255.255  NETMASK 255.0.0.0
          MTU 2000  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0049 ( UP LOOPBACK RUNNING )

eth0      IP ADDR 130.82.154.12  BCAST 130.82.255.255  NETMASK 255.255.0.0
          MTU 1500  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0043 ( UP BROADCAST RUNNING )


>You didn't give me your dip script. I can't help you with why unless I can
>see what you are doing. It works fine for others. What version of dip are you
>running, what version of kernel ?

I don't have a dip script, because the client isn't a Linux box, it's a Windows 
box running NetManage TCP/IP (ChamaeleonNFS).

>Ok, here is what to do, go through the procedure, and after everything is
>ready, ie after you have added the route to your slip client, perform the
>following commands, and send me the output:
>
>ping 130.82.1.2
>arp -a
>ifconfig -a
>netstat -rn

The IP-address of the CSLIP client is 130.82.154.101 (netmask B-Class: 
255.255.0.0),
Windows CSLIP client's routing table:

Destination              Gateway         Flags          Interface
130.82.0.0               *               UN             CSLIP0
default                  130.82.1.2      UGN            CSLIP0

Ok:

> ping 130.82.1.2 
from the client: results in 100% packet loss
from the linux-box (CSLIP server, 130.82.154.12) works great of course

The only thing I can ping from the client successfully is the CSLIP Server 
(130.82.154.12) and itself. 
I can do everything from the client to the server and from the server to the 
client: telnet, ftp etc., but I can't get on any other host on the local 
network (130.82.0.0), e.g. ping 130.82.154.11 from the client results in 
100% packet loss.

> arp -a

on the CSLIP (dip -i) server:
limerick:/usr/adm# arp -a
IP address              HW type                 HW address
130.82.1.1              10Mbps Ethernet         AA:00:04:00:64:D4
130.82.1.2              10Mbps Ethernet         AA:00:04:00:65:D4
130.82.154.11           10Mbps Ethernet         00:00:0F:00:B6:F9
130.82.1.12             10Mbps Ethernet         AA:00:04:00:02:D4
130.82.1.13             10Mbps Ethernet         AA:00:04:00:03:D4

on the Windows client:  arp table is empty (of course ?)

> ifconifg -a

on the server:
limerick:/usr/adm# ifconfig -a
lo        IP ADDR 127.0.0.1  BCAST 127.255.255.255  NETMASK 255.0.0.0
          MTU 2000  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0049 ( UP LOOPBACK RUNNING )

sl0       IP ADDR 130.82.154.12  BCAST 130.82.255.255  NETMASK 255.255.255.0
          MTU 1500  METRIC 0  POINT-TO-POINT ADDR 130.82.154.101
          FLAGS: 0x0051 ( UP POINTOPOINT RUNNING )

eth0      IP ADDR 130.82.154.12  BCAST 130.82.255.255  NETMASK 255.255.0.0
          MTU 1500  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0043 ( UP BROADCAST RUNNING )

Dip -i set a C-Class netmask of 255.255.255.0 for the sl0 device. This seems to 
be preventing the machine from losing all connectivity to the local net, as it 
happened before when I set up the interface manually. I'm not sure about the 
implications of this netmasl setting for the client configuration though. I 
don't get any difference in results when I set the client's netmask from 
255.255.0.0 to 255.255.255.0. Do I need  to change the IP address as well?
(as an experiment I also set up the cslip link assigning a different IP-address 
(130.82.154.102 and netmask 255.255.0.0) to the sl0 interface, which in the end 
led to the same connectivity results as the procedure descriped here. 
Everything worked with 130.82.154.12 eth0 and 130.82.154.102 sl0 on the server, 
but nothing else)

> netstat -rn

on the server:

limerick:/usr/adm# netstat -rn
Kernel routing table
Destination net/address   Gateway address           Flags RefCnt    Use Iface
default                   130.82.154.101            UGN        0      0 sl0
130.82.0.0                *                         UN         0  17844 eth0
127.0.0.1                 *                         UH         0      0 lo
130.82.154.101            *                         UH         0    153 sl0

Dip -i did a route add 130.82.154.101 sl0, which is ok.
Then it killed my defualt gateway route:and sets the default gateway to the 
CSLIP client (130.82.154.101): route del default gw 130.82.1.2, route add
gw 130.82.154.101 which seems doesn't seem ok to me at all. I'm almost getting
the impression as if Linux SLIP/CSLIP server kernel support only supports l
inks between two machines without forwarding packets out on the net and from 
the net in via sl0 to the client, because only then this route makes any sense 
to me.
I reset the default gateway route back to 130.82.1.2, but that did not change 
anything with the connectivity.

I'm really at the end of my knowledge here. It seems to me as if the kernel 
doesn't know how to forward outgoing ip-packets from the sl0 to the eth0 
interface and incoming packets from the eth0 to the sl0 interface.
I really hope you can help me here.
I got an email today from someone who seems to be having the same problems. He 
stated that he had heard that a patch to the kernel was needed to get that 
Server working, but he didn't know where to get it or further details. He told 
me his site administrator was doing research into the problem and he'd keep me 
updated. I'll forward any info here.

Thanks a lot,

David
-- 
--
David-Michael Lincke
dlincke@sgcl1.unisg.ch, dave@IRC

------------------------------

From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 26 Jan 1994 20:59:54 GMT

>>>>> jerry@msi.com (Jerry Shekhel) wrote:

Jerry> Wrong.  NT runs on three different architectures right now.
Jerry> Linux doesn't.  In fact, no single version of Unix does.

Eh?  What about SunOS 4.x.x ?  I figure that it must have run on x86,
m68k and sparc, no?  What about SVR4?

Jerry> Let's not speculate on Linux's portability (relative to NT's)
Jerry> until Linux is actually ported to as many architectures as NT
Jerry> supports.

------------------------------

From: jerry@msi.com (Jerry Shekhel)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 26 Jan 1994 21:33:25 GMT

Hamish Macdonald (Hamish.Macdonald@bnr.ca) wrote:
:
: Jerry> Wrong.  NT runs on three different architectures right now.
: Jerry> Linux doesn't.  In fact, no single version of Unix does.
:
: Eh?  What about SunOS 4.x.x ?  I figure that it must have run on x86,
: m68k and sparc, no?  What about SVR4?
:

Yep, you're right, I forgot about that.  But is SunOS 4.x.x still a living
OS?  I thought it had been superceded by Solaris.
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL  | Molecular Simulations Inc. | Cowboy Junkies, Phish,    |
| Drummers do it... |     Burlington, MA USA     | Tribe, Guns N' Roses,     |
|    ... In rhythm! |        jerry@msi.com       | TAMA, Zildjian, Linux...  |
+-------------------+----------------------------+---------------------------+

------------------------------

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Thu, 27 Jan 1994 00:58:42 GMT

In article <1994Jan26.113818.5380@pe1chl.ampr.org>, pe1chl@rabo.nl says:
+---------------
| In <ARMB.94Jan25111756@hamsta.setanta.demon.co.uk> armb@setanta.demon.co.uk (Alan Braggins) writes:
| >In article <2i14so$a4a@draco.unm.edu> bantolph@unm.edu (-=| Bantolph |=-) writes:
| >>   with a few questions. Which is a better processor for running a UN*X
| >>   like operating system on, the Motorola 680x0 series or the Intel 80x86
| >>   series? I have heard a few people complain about 68000's not being able
| >>   to multitask well so they switched to Intel chips. Is there any truth 
| >>   to this?
| >from 680x0 to 80x86 are Sun, who replaced the 680x0 with RISC (Sparc) in
| >their own machines, but now support Solaris on 80x86.
| 
| Olivetti moved from Z-8000 to 680x0 to 80x86
+------------->8

The 68000 didn't support demand paging (it couldn't restart instructions).
This was corrected in the 68010 and later processors.

As far as other companies switching from 680x0 to 80x86:

* Tandy (remember the Model 12/16/6000?)
* Altos used to have a line of 680x0 *ix machines; they eventually stopped
supporting them for anything but Pick.  Of course, now that they're really
Acer, the 680x0 machines are pretty well dead.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

------------------------------

From: pyeatt@CS.ColoState.EDU (Larry Pyeatt)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 26 Jan 94 20:35:28 GMT


In article <1994Jan25.182321.2996@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
|> 
|> In fact, lots of registers is a disadvantage to multitasking, as you will
|> have to swap them all on a task switch...
   
It is not really the number of registers that matters.  The x86 registers
are not general purpose, which means lots of swapping all the time.  On
the 680x0, there are twice as many registers, but they are more general
purpose and do not get swapped as often.

|> >On-chip cache, fast bus, and high clock speed all make most things go
|> >faster, but they are just icing.  You can run a full-fledged Un*x on
|> >a 386SX16, or a 10Mhz 68010--you just have to spend a little more time
|> >waiting.
|> 
|> Now you are comparing apples and oranges...  the 68010 would need external
|> memory management hardware to reasonably run UNIX.

I agree.  A 386SX16 falls somewhere betwee a 68010 and a 68020 in
performance and features.

|> In fact, a 80286 is better equipped to run a multitasking system than
|> the 68010 is.  The memory management may suck, but on the 68010 it does
|> not exist at all...

That's funny.  I would have said that the 68010 and 80286 are comparably
equipped for memory management.  They both have very little.  However,
the 68020 pretty well outclasses the 80386, especially if you add a
68888(?) memory management unit to the 68020.  That is why many of the
early workstations were based on the 680x0.  Also the FPU for the
68020 is an order of magnitude better than the 80287 and significantly
better than the 80387.  Running a real operating system, the 68040 
provides marginally better performance overall than an 80486.  Bottom
line is that they are deliver comparable performance, but the 680x0
architecture is "prettier."
-- 
Larry D. Pyeatt                   All standard disclaimers apply.
pyeatt@cs.colostate.edu           Void where prohibited.

------------------------------

From: barr@pop.psu.edu (David Barr)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 26 Jan 1994 23:04:47 -0500

In article <2i6ia8$14q@sol.ctr.columbia.edu>,
Jerry Shekhel <jerry@msi.com> wrote:
>Wrong.  NT runs on three different architectures right now.  Linux doesn't.
>In fact, no single version of Unix does.

Oh come now this is absurd.  Do you realize how many architectures
BSD 4.3 has been ported to?  I've lost count.

>Let's not speculate on Linux's
>portability (relative to NT's) until Linux is actually ported to as many
>architectures as NT supports.

Let's not speculate on NT's portability until it is actually ported to
as many architectures as UNIX supports.  Fair?

>: NT's downfall is that it is hard-coded to little-endian processors.
>
>Your comments are misleading.  True, MS indicated no willingness to port
>NT to big-endian CPUs.  However, that doesn't mean that NT is as you say
>"hard-coded to little-endian processors".  There is no evidence either way
>whatsoever.

Bull.  Why have companies introduced bisexual chips rather than get
NT fixed?

>MS may simply be avoiding binary file incompatibilities and
>byte swapping issues.

Bzzt.  UNIX dealt with endian incompatibilities for 20 years.  Why is
NT crippled?

>As far as a 68K port is concerned, what would be the point?  A 68K version
>of NT would run on what, exactly? Old discontinued Sun workstations?  The
>small percentage of Amigas and Ataris which are equipped with MMUs and at
>least 16MB RAM?  You can't be serious.

Can you say M-a-c-i-n-t-o-s-h?  Hello!

--Dave
-- 
"Liberty means responsibility.  That is why most men dread it."
- George Bernard Shaw

------------------------------

From: jack@solucorp.qc.ca (Jacques Gelinas)
Subject: Re: UMSDOS Patch to Use \linux?
Date: Wed, 26 Jan 94 16:33:49 GMT

steve.mcmahon@lambada.oit.unc.edu (Steve McMahon) writes:

>Is there a patch that would make the umsdos fs use \linux instead of
>the DOS root directory as its mount point for the linux root
>directory? I thin I read about that somewhere, is it availale or just
>a rumor?

There is an easy way of doing that by doing 

        chroot ("/linux");
        chdir  ("/");

in init/main.c. I can send you the patch if you want. The trick
is to defined chroot and chdir as inline function (like many
at the beginning of init/main.c) However, this
means the rest of your partition disapear. You won't have access
to c:\ again. I suggest you wait for Umsdos 0.2.
It should be released pretty soon. To give you a preview, here
is what it does.

-Autosense \linux\etc\rc or \linux\etc\init. If any of these files
is there, it switch in pseudo-root mode. Umsdos is then performing
interesting translation on the File systems. It looks like this.

c:\linux        ->      /
c:\                     ->  /DOS

And of course, if you do

ls /DOS/linux, it tells you the file or directory does not exist.
and cd /DOS/.. gets you back at /

This is done automaticly, only for the root fs.

Another feature of Umsdos 0.2, is the flexible mode. Currently, umsdos
rely on a file --linux-.--- for directory listing. If --linux-.--- is
either empty or missing, umsdos tells you the directory is empty.
Using umssync you can creat --linux-.--- on the fly in any directory.
This could be annoying in many DOS directory. A new semantic has been
introduced. A missing --linux-.--- means the directory is a DOS directory
with all its limitations. This means that right after installing
umsdos 0.2, all you DOS file will be visible in /DOS/...

If for any reason, you need full Unix semantic in a DOS directory (long
name, pipe, owner, etc...), you just apply umssync in that directory
and that's it.

With those two additions, never a Unix system has been so confortable to
DOS users.

Currently, all this is functionnal. I am putting the hand on some more
automated test cases.

Email for more info!


-- 

========================================================
Jacques Gelinas (jacques@solucorp.qc.ca)
Maintainer of US4BINR jacques@us4binr.login.qc.ca

------------------------------

From: gareth@gblinux.demon.co.uk.demon.co.uk (system admin)
Subject: Re: ELF binaries
Date: Tue, 25 Jan 1994 00:49:34 GMT

You need linuxelf-1.2 or better. Don't know where it comes from, mine came
off the LGX CD. Works fine with standard AT&T tools line banner,cat etc...  

------------------------------

From: mhemy+@cs.cmu.edu (Michael Hemy)
Subject: enhanced DIP for SLIP
Date: 27 Jan 94 04:29:46 GMT


I have modified the dip sources to correct for a few bugs and enhance
the script language. Amongst others I have added capability of
specifying multiple phones, autodial, conditional branching, switching
and greatly improved error detection.
Before posting the new sources, I would like to coordinate this with
any other effort going on related to this.

Just to ignite curiosity this is how an enhanced script looks like:
 
  port cua1
  speed 38400
  set_autodial 180 100
  phonelist t6218548 t6213585 t6213671 t6213659 t6213592 t6213633 t6213698 
  autodial
  if $errlvl != 0 goto error1

# We are connected.  Login to the system.
  wait 10 TS2> 
  if $errlvl != 0 goto error2

# this is one of my favorite enhancements since it greatly simplifies
# the script: send_not_jump sends a string and waits for the modem to
# receive a reply string within a specified time. If this string is
# not received within the timeout then execution branches to the
# specified label. The complementary send_jump also exists. 
  send_not_jump 10 hostname: error3 slip\r
  send_not_jump  5 Password: error4 my_machine_name\r
  send_not_jump 30 Header error5 my_machine_password\r

# Set up the SLIP operating parameters.
  get $local magic
  get $remote ts2
  get $mtu 1500
  default

# Notify and and fire up!
  print CONNECTED to address $rmtip
  mode SLIP
  goto exit

# Error Handling
error1:
  print DIP error: failed to dial requested number
  goto exit
error2:
  print DIP error: NO DIALTONE 
  goto exit
error3:
  print DIP error: switch command in script failed
  goto exit
error4:
  print DIP error: Not Connected.
  goto exit
error5:
  print DIP error: did not receive string "IP address or hostname:"
  goto exit
error6:
  print DIP error: did not receive string "Password:"
  goto exit
error7:
  print DIP error: did not receive Remote Welcome string
exit:

#end of script

I have a few more ideas that I want to implement, but then again, I
think this should be coordinated. 

--Michael

------------------------------

From: oraq@cs.utexas.edu (Eric Hollas)
Crossposted-To: comp.os.386bsd.development
Subject: AT&T StarLan EN100 driver project
Date: 27 Jan 94 04:52:31 GMT


        Has anyone written a driver for the AT&T StarLan EN100 ethernet card? 
The last time I saw code for this beast was with 386BSD two years ago.  At that
time the driver was not part of the official 386BSD release package.

        If you have a copy of the old 386BSD code, I would be very grateful 
if you would send me it.  I plan to port the old driver to run with Linux.


Thankyou for your time,

Eric
oraq@cs.utexas.edu


Newsgroups: comp.os.linux.development,comp.os.386bsd.development
Subject: AT&T StarLan EN100 driver project
Summary: First step to an EN100 driver for Linux, get old 386BSD code. 
Followup-To: oraq@cs.utexas.edu
Distribution: world
Organization: CS Dept, University of Texas at Austin
Keywords: en100, StarLan, ethernet, driver
Cc: 

        Has anyone written a driver for the AT&T StarLan EN100 ethernet card? 
The last time I saw code for this beast was with 386BSD two years ago.  At that
time the driver was not part of the official 386BSD release package.

        If you have a copy of the old 386BSD code, I would be very grateful 
if you would send me it.  I plan to port the old driver to run with Linux.


Thankyou for your time,

Eric
oraq@cs.utexas.edu

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Wed, 26 Jan 1994 11:38:18 GMT
Reply-To: pe1chl@rabo.nl

In <ARMB.94Jan25111756@hamsta.setanta.demon.co.uk> armb@setanta.demon.co.uk (Alan Braggins) writes:

>In article <2i14so$a4a@draco.unm.edu> bantolph@unm.edu (-=| Bantolph |=-) writes:
>>   with a few questions. Which is a better processor for running a UN*X
>>   like operating system on, the Motorola 680x0 series or the Intel 80x86
>>   series? I have heard a few people complain about 68000's not being able
>>   to multitask well so they switched to Intel chips. Is there any truth 
>>   to this?

>No. The only people I can think of who might be counted as switching
>from 680x0 to 80x86 are Sun, who replaced the 680x0 with RISC (Sparc) in
>their own machines, but now support Solaris on 80x86.

Olivetti moved from Z-8000 to 680x0 to 80x86

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: DAC ADC device driver
Date: Wed, 26 Jan 1994 11:58:47 GMT
Reply-To: pe1chl@rabo.nl

In <2i3vr0$1et4@hermes.acs.ryerson.ca> jeff@ee.ryerson.ca (Donald Jeff Dionne) writes:

>HENRY WONG (hwong@ee.ryerson.ca) wrote:
>:      Regarding the Voice capabilities for 386 under UNIX ... 

>: Does anyone know anything about the AM79C30A DAC ADC chip used in the
>: audio card in the SUN workstations ?  And is it possible to sue in on
>: the 386 PC's ?  

>:              Info regarding device drivers for the DAC ADC would be most
>: appreciated ...
>I think you would be better off looking at one of the new 16bit Deta Sigma
>CODEC chips from Analog Devices and second sourced from Crystal Semiconductor

>we've used the serial version of it in an instrument, and it has excellent 
>performance, both signal to noise, and dynamic range.  Also, it requires 
>no anti-alias filters, where the AMD part you mention requires significant
>effort in this regard if you are to achieve good results.  As for the
>device driver, have look at the code for I think it is the GUS card.
>The new ones use the same chip I think, and if not, look at the 
>code in the patch for the pc sound driver.  pc-snd0.4-pl14.tar.gz I think.

>I notice that you are in my department, so send me mail, and I'll give you
>the data sheet if I can find it, since it's a new part, and you will not
>find it elsewhere.

The Crystal/AD part is also used in Alef Null's DSP-card-4, which combines
it with a DSP56001, 96KB RAM and 32KB flash EPROM.  Has a serial (RS232)
interface as well.  Nice card...
Indeed the CODEC works well, although you should note that there are
several different versions (with different specs) and the layout of your
PCB board with regard to grounding and supply voltages is very critical.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: nelson@crynwr.com (Russell Nelson)
Subject: is there a driver for National 8390 Ethernet Chip 
Date: Wed, 26 Jan 94 02:27:29 GMT

In article <CK5HJ5.MCF@aston.ac.uk> evansmp@mb48025.aston.ac.uk writes:

   Donald J. Becker (becker@super.org) wrote:

   :       Linux device support is only home-grown: it will be a long time before
   :       vendors include Linux drivers with their hardware.  If they don't
   :       get a driver from us, they won't get it at all.

   The problem is that certain manufactures of both ethercards and
   interfaces on the motherboard are reluctent to release programming
   details.

If you know the right people and have credibility with them you can
get programming details :).

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

------------------------------

From: mangon@gla.ecoledoc.ibp.fr (Olivier MANGON)
Crossposted-To: comp.os.linux.help
Subject: Mkimage
Date: 27 Jan 1994 09:56:21 GMT
Reply-To: mangon@gla.ecoledoc.ibp.fr

Hi every body,
where i can find the file mkimage for GCC for recompile libc.4.5.8

thanks..




------------------------------

From: agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: configuration during boot-up ???
Date: 27 Jan 1994 11:41:32 +0100

In article <d0a666c@p46.f520.n301.z2.fido.imp.com>,
Enrico Scotoni <scoti@p46.keru.chg.imp.com> wrote:
>maybe this is a dumb (ignorant) question but:

Then again, maybe not.

>I have experience with several other operating systems (VMS, PRIMOS, even MS-
>DOS) and they have some kind of configuration file that is read during boot-up
>in order to configure the kernel.

<and goes on to suggest>

>nvc 24          # number of virtual consoles
>nprc 1024       # number of process
>memlimit yes    # limit memory to 16MB

Well, read the kernel source, and see whether lots of slow extra
if's would be needed.  I assume, for instance, that gcc can build a
faster and more efficient kernel if it knows some of these
configuration options at compile time.

Such a performance gain wouldn't have to be very large in order to be
large enough, IMHO:  You don't reconfigure the kernel at all often.

--Arnt

------------------------------

From: hank@Blimp.automat.uni-essen.de (Hendrik G. Seliger)
Subject: libc 4.5.8 is killing me
Date: 27 Jan 1994 09:40:15 GMT
Reply-To: hank@Blimp.automat.uni-essen.de


Hi there!

O.K., I too believe in clean code. But I think these new libraries
have become a little too restrictive. I finally uograded last week,
and a whole bunch of programs quit. Some give spurious segement
violations (like rtin), which are really hard to follow), some leave
me without clue. Xxgdb crashes when XtAppMainLoop is called, which I
can't follow due to lack of sources. Elm crashes on an fclose, but
just after an fopen of anOTHER file (like fopen(A); fclose(A) works,
fopen(A); fopen(B); fclose(A) gives a segm. viol.). 

For some other programs I have been able to track the bugs down, but I
think the libraries should be a bit less restrictive. Why not return
some error code instead of crashing?? I don't know what has been
changed in detail, but I slowly get the impression that I don't like
it. I'd have a look into libc, but I don't have enough space left on
my hard disk to fool around with the libc-sources (and with those for
Xt, and those for whatever causes tin to crash, and whatever is still
to come). At least I have a chance to look at the sources, but
remember, there are many people out there who are just glad if there
machines run and they can play nethack. Having Linux run smoothly
includes not generating too many new problems. So why don't we revert
some changes in libc??? At least in a way existing programs can deal
with???

Just my two cents.

Cheers,

Hank



--
======================================================================
         Hendrik G. Seliger                  Universitaet Essen
     hank@automat.uni-essen.de                Schuetzenbahn 70
      Tel.: +49-201-183-2898                45117 Essen, Germany
======================================================================
             "Handling interrupts is simple." (G. Pajari)
             "Interrupts are an unpleasant fact of life." (A. Tanenbaum)

------------------------------


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
