Jump to content
Krisbee

Mandriva 2007 and Forcedeth Ethernet problem

Recommended Posts

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?

Edited by Krisbee

Share this post


Link to post
Share on other sites

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:

 

 kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.54.
kernel: ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 10
kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LMAC] -> GSI 10 (level, low) -> IRQ 10
kernel: 0000:00:04.0: Invalid Mac address detected: 59:f0:00:e7:39:f0
kernel: Please complain to your hardware vendor. Switching to a random MAC.
kernel: eth0: forcedeth.c: subsystem: 0147b:1c00 bound to 0000:00:04.0
ifplugd(eth6)[3813]: ifplugd 0.28 initializing.
kernel: eth6: no link during initialization.

 

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.

 

# udev persistent rules for net subsystem
# Generated by Mandriva udev rules
# See /etc/udev/rules.d/62-create_persistent.rules

SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:02:44:3b:23:56", NAME="eth0", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:02:e3:1f:ed:6e", NAME="eth1", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:00:6c:5c:85:aa", NAME="eth2", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:00:6c:b1:b1:ee", NAME="eth3", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:00:6c:ee:dc:47", NAME="eth4", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:00:6c:4a:64:f2", NAME="eth5", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:00:6c:e9:12:53", NAME="eth6", ENV{MDV_CONFIGURED}="yes"

 

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.

Edited by Krisbee

Share this post


Link to post
Share on other sites

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

sl@sidux32:/etc/udev/rules.d$ more z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# PCI device 0x10de:0x00d6 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:30:1b:b1:6a:85", NAME="eth0
"

# Firewire device 00301bb100006aeb (ohci1394)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:30:1b:b1:00:00:6a:eb", NAME
="eth1"

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Invalid Mac address detected: 59:f0:00:e7:39:f0

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 :D but Im wondering of you couldn't have just bypassed udev completely?

 

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

see

ifconfig eth0 down hw ether 00:00:00:00:00:01

ifconfig eth0 up

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...?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest Rokka

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

Share this post


Link to post
Share on other sites

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:

Identification
Vendor: ‎nVidia Corporation
Description: ‎MCP61 Ethernet
Media class: ‎Bridge
Connection
Bus: ‎PCI
PCI domain: ‎0
Bus PCI #: ‎0
PCI device #: ‎7
PCI function #: ‎0
Vendor ID: ‎0x10de
Device ID: ‎0x03ef
Sub vendor ID: ‎0x1849
Sub device ID: ‎0x03ef
Misc
Module: ‎forcedeth

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,

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

#tidy udev eth
if [ -f /etc/udev/rules.d/61-net_config.rules ]; then
rm -f /etc/udev/rules.d/61-net_config.rules
fi
modprobe -r forcedeth
modprobe forcedeth
sleep 2s
#tidy udev eth
if [ -f /etc/udev/rules.d/61-net_config.rules ]; then
rm -f /etc/udev/rules.d/61-net_config.rules
fi

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

#tidy udev eth
if [ -f /etc/udev/rules.d/61-net_config.rules ]; then
rm -f /etc/udev/rules.d/61-net_config.rules
fi

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest Lizard King

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.

Share this post


Link to post
Share on other sites
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.
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.

 

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.
That's very interesting... you seemed to have gone to a lot of effort, thank you.

 

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.
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...