I've just removed a PCI NIC from my PC, re-booted and enabled the onboard ethernet device on my ABit NF7-S in the BIOS and proceeded to boot Mandriva 2007.

The onboard device was recognised in hardware, I configured it via the MCC, added "forcedeth" to my modprobe.preload ( I wasn't sure if that was needed), "alias eth0 forcedeth" was automatically added to the modprobe.conf file. The device works.

But after close down and re-boot the device is no longer recognised and I get this error message:

"Bringing up interface eth0: forcedeth device eth0 does not seem to be present, delaying initialization."

If I try to delete this device and re-configure the device, it is now numbered eth2 (another NIC eth1 already exits) , on re-boot the same problem occurs and if I try to re-configure the forcedeth device agin it is now numbered eth3 and so on. So after each re-boot the system is giving the forcedeth device the last ethernet interface number used plus one.

I don't believe this is a hardware fault. The forcedeth device is recognised and works. It's the configuration that doesn't survive a re-boot and is getting screwed up in some way.

Any ideas as to what is going on?

This is what seems to be happening:

1. Logs show that on my ABit NF7-S m/board the forcedeth driver cannot obtain a valid mac address, or at least returns an error message to that effect:



2. Udev interprets this as a new net interface and assigns a new interface name, i.e last assigned plus one. So every time the forcedeth driver is loaded a new interface is added to the system. One of the Udev rules file is filing up with junk.



I've no idea how to solve this. Is there an errata/bug report about it? It seems odd to me I have not seen other users of nforce2 boards complaining of the same problem.

Do you have a firewire (IEEE1394) card installed? (or a second NIC)

My guess it either its "not ready" when its asked for the Mac address or another card is detected as a NIC (firewaire can be used as a NIC)

You might be able to add the MAC (59:f0:00:e7:39:f0) to the hints

The follwong works for me in Debian

Sorry, it's not as simple as trying to add the "invalid mac address" to a udev rule. The problem really is the Abit BIOS returning a duff mac address in the hardware detection routine within the forcedeth.c driver, which is then substituted for a random (well two digits of it are random) mac address, hence the chaos on subsequent boots of the machine, or restarts of network service.

Possible solutions are:

1. Check if a BIOS flash can reset the mac address to a valid value.

2. Patch forcedeth.c driver to return a fixed valid address.

3. Somehow change udev rules.

4. Don't bother, a get another PCI NIC.

I'm researching option 1.

As to option 2, I'm not a programmer, which is a pity as looking at the code for forcedeth.c as shown here:

http://lxr.free-electrons.com/source/drive...deth.c?v=2.6.18

There may only be one line of code to fix at 4305. Any offers?

Option 3 looks like a mine field.

Maybe I'll find an answer in a BIOS flash, but I really don't want to have to enter all my BIOS settings again. BIOS flashing makes me nervous.

So, no surprise, I've taken the easy route and bought another FA311 on Ebay for £3.

You can find a list of valid ones here http://standards.ieee.org/regauth/oui/oui.txt

I can't exactly see why the Mac is invalid? Other than
00-18-37 (hex) Universal ABIT Co., Ltd.

but even thought its not correct for the vendor Im not sure why its invalid??


anyway a £3 solves the problem but Im wondering of you couldn't have just bypassed udev completely?

http://www.irongeek.com/i.php?page=security/changemac
see

but of course you would need to exclude this from failing on udev by excluding it or you are still left with the escalting number problem...?

From what I have found on an Abit forum the mac address probably started out OK when the m/board left the factory but got screwed up in an earlier BIOS flash, Windows doesn't seem to care about it but the forcedeth.c driver certainly objects.

Thanks for the interesting links. To be honest I've given up on this. I have no intention of re-flashing my BIOS and don't feel that inclined to spend hours trying to figure how udev works and might be by-passed or otherwise fudged.

I stumbled on the same problem with an Asus T3 barebone, with 2007.1, 2.6.17 kernel.

Actually some nforce based mb's seem to give the mac address in reverse order, and forcedeth.c sputters, and udev allocates a bogus mac address.

This is all fixed in latest forcedeth.c (0.60 at time of writing, fix went first to 0.57). Installing for instance one of the later kernel-tmb's fixes this problem.
It would be nice to have it backported though, like they did for Ubuntu: see https://bugs.launchpad.net/ubuntu/+source/l...6.15/+bug/76346

Hi,

I can't believe it... this is exactly the same problem as I'm experiencing... I've just installed Mandriva PowerPack 2008 on my machine, replacing OpenSuSe 10.3.

OpenSuSe 10.3 was getting a little sluggish and so I tried the Mandriva live cdrom, it was very impressive and so I thought I'd install it fully.

Oh boy, I can't believe the network card cannot be remembered over the reboot... It sounds so simple and is very annoying.

I researched around and found it hard to come up with something useful, other than how to clear down the numerous ethx entries...

It doesn't seem to make any different though, I've not been able to fix it.

As this is the latest version of Mandriva (2008) I figured the forcedeth would be fine, I've certainly carried out all updates...

The work around is to run the network manager once in X windows and setup a new eth connection...

OpenSuSe never had this trouble... is there a fix out there???

Cheers for the information already on this thread and I'd appreciate if somebody has a good solution (will probably need some simple steps though ;-) )

Here's my card (integrated with m/board) details:

That darn mac address... I don't understand why it's fine in OpenSuSe (and Fedora!) but not in Mandriva... any ideas?

If it's going to go on then I'll be forced(eth) (pun in tended!) to re-install either OpenSuSe or Fedora, which are both great too... but I would like to give Mandriva a good go first!

Thank you,

Okay, I've put in place an automated work-around... I've only rebooted once and so will need to try it again in a min :-)

[system: Mandriva PowerPack 2008]

My fix (not sure if part 2 is required)

1. clean up all entries regarding ethx interfaces and removing any reference to forcedeth from the modprobe.conf
- in '/etc/sysconfig/network-scripts/'remove all 'ifcfg-eth*' files
- in '/etc/udev/rules.d/' edit the 61_net_config.rules file and remove all entries (you can leave the comments ;-) )
- in '/etc/modprobe.conf' edit and remove any references to forcedeth or ethx

2. insert a blacklist entry in the '/etc/modprobe.d/' directory by creating a new file and adding the line 'blacklist forcedeth' in to it

3. edit '/etc/rc.local' and insert the following two lines (the first line to remove forcedeth if it's loaded, the second to (re-)load it)
- modprobe -r forcedeth
- modprobe forcedeth
* no need to insert the '-' at the beginning of the lines

Okay, well after first boot it was a success... I didn't notice any failed entries in the log and eth0 appeared connected.

I expect one of two things to happen on next boot (about to try it next)
- eth0 will come up again without any issues
- or eth1 will be created by udev, but I guess it should still come up successfully

I'll post a response in just a mo.

Okay well, it incremented the ethx number... hmmm... I played around a little more and ended up with the following changes:

1. Edited the '/etc/rc.local' file and replaced the earlier added modprobe lines with the following:

2. Edited the '/etc/init.d/network' file and inserted the following lines just after both the 'start)' and 'stop)' lines:


The result is eth0 connects after each boot, although during the boot process I do still see the eth0 failed message... not bothered though.

Hope this helps somebody else... shame Mandriva haven't got this right though... :-\

binarybasher

I also found that I had to configure the network (eth0) interface to use a static IP (my router was issuing a new IP after each boot, because it would tie the IP to the mac, which was changing), this was required to allow me to setup firewall rules for incoming ports...

Also, I've created a bug on the Mandriva bug report site: http://qa.mandriva.com/show_bug.cgi?id=37531

binarybasher

binarybasher, I'd like to thank you for posting the bug with the Mandriva team, it was how I found out that I was not alone with the exact same problem.

FWIW, I can reproduce the problem by dual booting into Windows, shutting down and then logging into Mandriva 2008. I can restore the MCP61 NIC by following a clue that I found in the Mandriva bug thread, I shutdown from Linux, wait for ACPI powerdown, then -*IMPORTANT STEP*- Remove the power from the motherboard by pulling the power cable. On next reboot, I've got eth0 after a reconfig of the network connection.

I would love to be able to code out the problem but it looks a little over-my-head so I await the Mandriva Team or HP/Compaq for either a new kernel, new forcedeth or new BIOS flash.

Thanks, I sent an email to the Mandriva team who recommended that I create a bug entry, I think it was definitely worth while. Now I know that somebody is assigned to it and working on a resolution for those affected.

That's very interesting... you seemed to have gone to a lot of effort, thank you.

I believe the problem is likely to be with the network card issuing the mac in reverse, this is then interpreted as an incorrect/faulty mac by forcedeth and so a new/random mac is automatically created.

Unfortunately, this causes a number of problems (having a different mac after each boot).

One problem (a big one) is that udev creates a new config entry for the new mac, therefore issuing it as a new ethX interface - I resolve by deleting the udev config for ethX interfaces. The good thing about doing it this way is that the network config for eth0 is retained and therefore you don't have to configure the network after each boot.

Another issue is that if like me your modem/router/dhcp-server issues you an IP Address based on your mac, you're going to receive a new IP Address after each boot... to resolve I had to assign a static IP Address in the network config for eth0. (not the best solution, but it works for me)

OpenSuSe and Fedora both work fine with this network card, which brings me to believing that it is fixable... I would guess that if the forcedeth detects a faulty mac then it could try reversing the mac before issuing a random mac...

Unfortunately, like you I do not really have enough experience at this time to edit the forcedeth source, recompile etc... but I'm sure the Mandriva team are looking in to this as a solution...

Thanks Lizard,
binarybasher