Forum Home
Press F1
Thread ID: 32778	2003-04-28 01:46:00	Linux RH 9.0 / Mandrake 9.1 NIC troubles	chrispy (3686)	Press F1

Post ID	Timestamp	Content	User
139466	2003-04-28 01:46:00	Hello peoples... I upgraded my work machine (Celeron 1.7) from Redhat 8.0 to Redhat 9.0 and now the network cards don't work. The network comes up, and the cards get IP addresses, but I can't ping or do anything. NIC's were Realtek cards, now have swapped for CNet cards (Davicom chipset) with the same result. I can't ping out, and if I plug it into our DHCP server and tell it to get an address from there, it comes up with an address that's nothing like the local address pool, and stubbornly refuses to work. The machine is a Celeron 1700, with a very recent Gigabyte GA-8SIMLH motherboard, with SIS chipset/video/audio. The onboard Realtek nic doesn't work either. I REALLY don't want to go back to RH 8.0 / Mdk 9.0 because they don't support the onboard SIS 651 video chipset, and the refresh rate is horribly low using the VESA driver. Any ideas???? Any help would be appreciated. TIA Chris Nielsen	chrispy (3686)
139467	2003-04-28 02:29:00	Try Disabling the OnBoard NIC and see what it comes up with from there.. and if it works like that, then re-enable the OnBoard if needed:-)	Chilling_Silently (228)
139468	2003-04-28 02:56:00	Yeah, I initially had the onboard Realtek going with Redhat 8.0, plus a PCI Realtek card using the same driver - sweet as meat. Now with the upgrade it didn't work, so the first thing I did was I disabled the onboard nic, and swapped the PCI realtek for a Cnet. That don't work either :-( Ta Chris	chrispy (3686)
139469	2003-04-28 03:03:00	Use the dmesg command to see what the system sees as it boot up.	Graham L (2)
139470	2003-04-28 03:17:00	Dmesg gives me the following: dmfe: Davicom DM9xxx net driver eth0: Davicom DM9102 at pci00:09.0, 00:08:a1:2c:13:5b, irq17. Then lots and lots of: eth0: TX timeout, resetting Any clues from this? chris	chrispy (3686)
139471	2003-04-28 03:29:00	And I should point out that when it tries to talk to the DHCP server, I can see the link light flashing - so it's doing something, and my old Celeron 333 with a Intel Etherexpress 10/100 with exactly the same config of RH 9 *AND* Mandrake 9.1, works as advertised. Also, on the computer in question, the only change I made was the upgrade to RH 9.0, no hardware changes were made. Leads me to think maybe it's the motherboard it doesn't like. Ta Chris	chrispy (3686)
139472	2003-04-28 04:15:00	I don't like those "eth0: TX timeout"s. That shows that something is wrong. "davicom cnet redhat" to google finds links to some people having problems, but mostly RH 6 and 7. Umm. There is something about different driver modules (dmfc, dmfe) being available. Don Becker (the ethernet card driver man) recommends using the Davicom dmfX ones, because there is ugly code in those that he's not prepared to include in his drivers. :D Does ifconfig show a sensible setup for the card? When you try the DHCP, what do you get from tail -20 /var/log/messages?	Graham L (2)
139473	2003-04-28 05:11:00	Alright, here it is: Apr 28 16:08:40 excelsior zcip[9326]: probing for 169 . 254 . 242 . 166 Apr 28 16:08:40 excelsior zcip[9326]: sending probe 1 for 169 . 254 . 242 . 166 Apr 28 16:08:40 excelsior kernel: device eth0 entered promiscuous mode Apr 28 16:08:40 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:42 excelsior zcip[9326]: sending probe 2 for 169 . 254 . 242 . 166 Apr 28 16:08:42 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:44 excelsior zcip[9326]: sending probe 3 for 169 . 254 . 242 . 166 Apr 28 16:08:44 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:46 excelsior zcip[9326]: sending probe 4 for 169 . 254 . 242 . 166 Apr 28 16:08:46 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:48 excelsior zcip[9326]: claiming ownership of address 169 . 254 . 242 . 166 Apr 28 16:08:48 excelsior kernel: device eth0 left promiscuous mode Apr 28 16:08:48 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:50 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:52 excelsior zcip[9326]: Stored address 169 . 254 . 242 . 166 for eth0: 9 Apr 28 16:08:52 excelsior zcip[9329]: watching for collisions Apr 28 16:08:52 excelsior kernel: eth0: Tx timeout - resetting Apr 28 16:08:58 excelsior last message repeated 3 times Apr 28 16:09:00 excelsior CROND[9333]: (mail) CMD (/usr/bin/python -S /var/lib/mailman/cron/qrunner) Apr 28 16:09:00 excelsior kernel: eth0: Tx timeout - resetting How's that grab you? The DHCP server is set for 10 . 225 . 0 . x addresses - I dunno where that IP address comes from rgds Chris	chrispy (3686)
139474	2003-04-28 05:13:00	Sorry, forgot to include ifconfig's output: eth0 Link encap:Ethernet HWaddr 00:08:A1:2C:13:5B UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:17 Base address:0xe000 eth0:9 Link encap:Ethernet HWaddr 00:08:A1:2C:13:5B inet addr:169.254.242.166 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:17 Base address:0xe000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:730 errors:0 dropped:0 overruns:0 frame:0 TX packets:730 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:61882 (60.4 Kb) TX bytes:61882 (60.4 Kb) Rgds Chris	chrispy (3686)
139475	2003-04-28 05:30:00	That 169 address is saved somewhere ... so it's asking the DHCP server to confirm it lease of it. Your DHCP doesn't know anything about it, so it ignores it. The 169.blah is not on the 10.blah network, so it's not accessible. That is not a routable address, so there's no request for it "out there". So that computer can't talk to your network. (Or it can talk, but they won't listen.) The eth0:9 indicates that it has been "multihosted" ... but that shouldn't hurt . try ifconfig eth0 down ifconfig eth0 up ifconfig and see if that loses the 169 IP address. You could try grep 169.254.242.166 /etc/* and see if it's stored in a top level /etc file. There may be a linuxconf area which will let you delete any such address ... or whatever Control Centre section of the GUI does this.	Graham L (2)
1 2