Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Second Ethernet interface



| I apologize if this has been discussed, but are the two ethernet cards the
| SAME.  Are they both 3C509's?
| 
| If so, I have done it by using the config utility in DOS realmode (F8 as
| Mike pointed out) and assigning them each a unique I/O and IRQ (to the
| system as well as the cards themselves) and writing the info down.  Then,
| boot the machine into Linux and make sure it sees one of the cards and
| calls it eth0.  Then append the parameters calling the second card eth1 to
| lilo.conf, re-install Lilo and reboot into linux.  When the kernel gets
| the new parameters, it loads the devices and you see the messages on the
| console during boot-up.  With two cards, you have to pass parameters.  

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

But anyhow, the other card is a Digital DC21041 (tulip),  so  we  got
another one of those.  These seem to get a bit farther: I can boot up
DOS and talk to either of them via the diskette's install progs.  And
linux can talk to either one of them just fine.  But it can't talk to
both of them.  I checked the hardware numbers with W95, and added the
line:
   append="ether=10,0xfc80,eth0 ether=9,0xfc00,eth1 mem=128M"
to the start of /etc/lilo.conf, ran lilo, and rebooted with  both  of
the  cards  in the machine.  It failed as the log excert below shows.
Note that the eth0 card doesn't respond to the dhcp queries,  so  the
mediaone  link is dead.  If I then remove the second card and reboot,
the first card comes up and connects just fine.  So plugging  in  the
second  card  and  configuring  it  as above causes the first card to
fail.

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


Jul  2 20:36:02 minya kernel: tulip.c:v0.88 4/7/98 becker at cesdis.gsfc.nasa.gov
Jul  2 20:36:02 minya kernel: eth0: Digital DC21041 Tulip at 0xfc80, 21041 mode, 00 e0 29 11 d3 1c, IRQ 10.
Jul  2 20:36:02 minya kernel: eth0:21041 Media information at 30, default media 0001 (10base2).
Jul  2 20:36:02 minya kernel: eth0:  21041 media #0, 10baseT.
Jul  2 20:36:02 minya kernel: eth1: Digital DC21041 Tulip at 0xfc00, 21041 mode, 00 00 c0 5d e4 c8, IRQ 9.
Jul  2 20:36:02 minya kernel: eth1:21041 Media information at 30, default media 0800 (Autosense).
Jul  2 20:36:02 minya kernel: eth1:  21041 media #0, 10baseT.
Jul  2 20:36:02 minya kernel: eth0: No 21041 10baseT link beat, Media switched to 10base2.
                              ^---- Here's where eth0 fails to connect
Jul  2 20:36:05 minya named[274]: starting.  named 4.9.6-REL Tue May  5 19:03:42 EDT 1998 ^Iroot at porky.redhat.com:/usr/src/bs/BUILD/bind-4.9.6/named
Jul  2 20:36:05 minya named[274]: cache zone "" loaded (serial 0)
Jul  2 20:36:05 minya named[274]: primary zone "0.0.127.in-addr.arpa" loaded (serial 1997022700)
Jul  2 20:36:05 minya named[275]: Ready to answer queries.
Jul  2 20:36:21 minya login[399]: ROOT LOGIN ON tty1
Jul  2 20:36:39 minya kernel: eth0: Promiscuous mode enabled.
Jul  2 20:36:39 minya dhcpcd[183]: no DHCPOFFER messages
                      ^---- Here's where dhcpcd fails 





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org