Second Ethernet interface

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

John Chambers as root wrote in a message to Mike Bilow:

 JCar> Well, they weren't. But I've essentially given up on the
 JCar> 3Com card as something that is too tricky for a dummy like
 JCar> me.  Various people had various suggestions, such as using
 JCar> F8 during the boot to get  a  real DOS  (not  DOS  under
 JCar> W95).  The 3Com manual actually said to use F4. Neither
 JCar> works.  No matter what I do, when  I  run  any  of  the 
 JCar> 3Com install  progs  (install or 3c5x9cfg or whatever), all
 JCar> of them simply hang and I have to reboot. I tried it with
 JCar> all of the menu items that F4  and F8 give me, and nothing
 JCar> got anything more than hung programs. Maybe the card is
 JCar> hosed.  Maybe I  just  don't  understand  something (more
 JCar> likely).

The card is configured in such a way that it will not work in your system. 
This is most likely because the memory aperture is overlaying a critical ROM
region in your machine.  If you put that 3Com card into another machine and
move the memory aperture to a safe place, it might work in your machine and the
configuration tools probably would no longer crash.

 JCar> But anyhow, the other card is a Digital DC21041 (tulip),  so
 JCar> we  got another one of those.  These seem to get a bit
 JCar> farther: I can boot up DOS and talk to either of them via
 JCar> the diskette's install progs.  And linux can talk to either
 JCar> one of them just fine.  But it can't talk to both of them. 

Well, I think the Linux Tulip driver is techically experimental, so it may get
confused with multiple cards.  I really don't know what the status is, but I
think most of its remaining problems have to do with particular brands of cheap
imitations, such as the "Lite-On" 82c168 chips.  If you have a better card with
real DEC chips, then I think the driver should be OK.

 JCar> I checked the hardware numbers with W95, and added the line:
 JCar> append="ether=10,0xfc80,eth0 ether=9,0xfc00,eth1 mem=128M" to 
 JCar> the start of /etc/lilo.conf, ran lilo,

If you do this, I hope you really have 128 MB RAM in the machine!

 JCar> and rebooted with  both  of the  cards  in the machine.  It
 JCar> failed as the log excert below shows. Note that the eth0
 JCar> card doesn't respond to the dhcp queries,  so  the mediaone 
 JCar> link is dead.  If I then remove the second card and reboot,
 JCar> the first card comes up and connects just fine.  So plugging
 JCar> in  the second  card  and  configuring  it  as above causes
 JCar> the first card to fail.

That's interesting.

 JCar> Here's the relevant part of the boot log for  the 
 JCar> two-DC21041  case. Anyone  have  any idea what I might be
 JCar> doing wrong? 

 JCar> Jul  2 20:36:02 minya kernel: tulip.c:v0.88 4/7/98
 JCar> becker at cesdis.gsfc.nasa.gov

 JCar> Jul  2 20:36:02 minya kernel: eth0: Digital DC21041 Tulip at 
 JCar> 0xfc80, 21041 mode, 00 e0 29 11 d3 1c, IRQ 10.

 JCar> Jul  2 20:36:02 minya kernel: eth0:21041 Media information
 JCar> at 30, default media 0001 (10base2).

 JCar> Jul  2 20:36:02 minya kernel: eth0:  21041 media #0, 10baseT.

 JCar> Jul  2 20:36:02 minya kernel: eth1: Digital DC21041
 JCar> Tulip at 0xfc00, 21041 mode, 00 00 c0 5d e4 c8, IRQ 9.

 JCar> Jul  2 20:36:02 minya kernel: eth1:21041 Media information
 JCar> at 30, default media 0800 (Autosense).

 JCar> Jul  2 20:36:02 minya kernel: eth1:  21041 media #0, 10baseT.

 JCar> Jul  2 20:36:02 minya kernel: eth0: No 21041 10baseT link beat, 
 JCar> Media switched to 10base2.
 JCar>                               ^---- Here's where eth0 fails to 
 JCar> connect

As an obvious first step, you might try changing the default media types on the
cards to agree with reality.  The driver is clearly establishing communication
with something, since you are getting what look like hardware addresses.  These
addresses look a little strange, since the "00000c" prefix is the old Western
Digital series and I have never seen it used on a PCI card. (These must be PCI,
becuase the Tulip chipset is PCI.)

A few other suggestions.  If you have like PCI cards in the machine, then you
should try running them on the same IRQ in "level-triggered" shared mode; this
makes life a lot easier for most drivers.  See if you can externally confirm
the hardware addresses Linux is reporting, as many cards have white printed
labels or something like that.  Are the cards really identical models?

I think that the Tulip driver can be recompiled with some more thorough
debugging enabled, but I really don't remember.  I have a hunch that the "card"
being reported as "eth1" is not really being found by the driver, and your Lilo
arguments are forcing the driver to bypass recognition of it.  With PCI cards,
you usually should not have to force recognition of devices by supplying Lilo
arguments at all.

 JCar> Jul  2 20:36:21 minya login[399]: ROOT LOGIN ON tty1

 JCar> Jul  2 20:36:39 minya kernel: eth0: Promiscuous mode enabled.

 JCar> Jul  2 20:36:39 minya dhcpcd[183]: no DHCPOFFER messages
 JCar>                       ^---- Here's where dhcpcd fails 

Well, if the driver can't figure out media type, DHCP is hopeless.
 
-- Mike