View Full Version : Linux RH 9.0 / Mandrake 9.1 NIC troubles

28-04-2003, 12:46 PM
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.


Chris Nielsen

28-04-2003, 01:29 PM
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:-)

28-04-2003, 01:56 PM
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 :-(



Graham L
28-04-2003, 02:03 PM
Use the dmesg command to see what the system sees as it boot up.

28-04-2003, 02:17 PM
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?


28-04-2003, 02:29 PM
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.


Graham L
28-04-2003, 03:15 PM
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?

28-04-2003, 04:11 PM
Alright, here it is:

Apr 28 16:08:40 excelsior zcip[9326]: probing for
Apr 28 16:08:40 excelsior zcip[9326]: sending probe 1 for
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
Apr 28 16:08:42 excelsior kernel: eth0: Tx timeout - resetting
Apr 28 16:08:44 excelsior zcip[9326]: sending probe 3 for
Apr 28 16:08:44 excelsior kernel: eth0: Tx timeout - resetting
Apr 28 16:08:46 excelsior zcip[9326]: sending probe 4 for
Apr 28 16:08:46 excelsior kernel: eth0: Tx timeout - resetting
Apr 28 16:08:48 excelsior zcip[9326]: claiming ownership of address
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 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



28-04-2003, 04:13 PM
Sorry, forgot to include ifconfig's output:

eth0 Link encap:Ethernet HWaddr 00:08:A1:2C:13:5B
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: Bcast: Mask:
Interrupt:17 Base address:0xe000

lo Link encap:Local Loopback
inet addr: Mask:
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)



Graham L
28-04-2003, 04:30 PM
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 /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.

28-04-2003, 05:36 PM
Yeah, I've tried that - when it's coming up, eth0 picks the same ip address again. I also re-enabled the onboard Realtek as eth1, and it did the same thing but with a similar IP address in the same 169. range.

I did a grep as you requested and it didn't find anything. I checked linuxconf and didn't find anything either.

This machine is required, so I unfortunately am forced to revert to Mandrake 9.0 and purchase a Geforce 4 video card. I did a search and it appears XFree 4.2 will support this video card. I wouldn't have to buy a new video card if it supported my SIS 651 onboard video, but that's why I went to Mandrake 9.1

Oh well....

Graham L
29-04-2003, 03:38 PM
Try forcing an IP address in the "ipconfig eth0 up" command ... that should work. Thinking about it, it will definitely be in a lower level directory of /etc ... "find /etc -name network" might get you to the one.

30-04-2003, 02:42 PM

I took the machine home and reverted to Mandrake 9.0, and that didn't work either. That got me thinking that it didn't work the first time under Mandrake 8.2, so I installed Redhat 9.0 on it, and voila! The bugger works now! It even detects my video card properly so I've got a decent refresh rate.

I don't know why, but Mandrake just doesn't like this machine.

I would have replied yesterday but I was busy catching up on the work I couldn't do while this machine was down :-)



Graham L
30-04-2003, 03:05 PM
I like Red Hat. Mandrake seem to be proud of being at the bleeding edge. RH have the attitude that it's better to have it working than the latest. :D

But network stuff is nice when it works. When it doesn't ...

30-04-2003, 04:03 PM
Yes. I've been bitten by their bleeding edge stuff before. The version of reiserfsck that came with mdk8.0 was an ALPHA version.
And the kernel that ships with mdk9.1 is prerelease (IIRC its not even a release candidate), not that its given me any problems yet.

Did you enable ACPI when you installed mdk9.1?

I found it stopped some of my recently supported hardware from working.

02-05-2003, 12:10 AM
I have had similar problems with Mandrake 7.1 & 8.2
First I had an AMD K7 3D cpu, then a Celleron 1.7, still no joy.
Mandrake toldme that the AMD K7 was not suitable, but it is still the same.