I am trying to install DEBIAN ETCH on to a new GA-M61VME-S2 based machine, the NIC uses the RTL8201 chipset.

I have used both the AMD64 & i386 images as well as an Ubuntu image and have the same problem...

The install process finds all hardware, including the SATA drive, expect the MOBO NIC.

I have search forums and googled the problem, but to date have found no solution.

I am aware that I can install a separate NIC but would prefer using the onboard.

An help would be appreciated.

Nick

In the kernel source (2.6.17.11) the RTL8201 is cited in the code for the sis190 and sis900 modules. The sis190 is Gigabit ethernet. I think the sis900 is usual 10/100Mb. Have you tried 'modprobe sis900'?

maroonbaboon,

I tried modprobe sis900. Return values appeared to be OK, but failed to recognise eth0, after reboot.

Do you have any further pointers as to where I should go from here?

Regards
Nick

It sounds from your reply that you modprobed and then rebooted. To load the module on startup you need to list it in /etc/modules, otherwise it will not be there when you reboot.

Alternatively modprobe and if 'dmesg' command shows eth0 is there you can do '/etc/init.d/networking restart' (as root).

Sorry if I misunderstood and am underestimating your level of expertise.

maroonbaboon,

Thanks for the information, I will have another go this evening.

As to my level of experience, I have been using DEBIAN for the last couple of year as the OS of choice for a web server, with all the usual extras added. Whilst I have installed, configured and tailored to suit and can script happily. I know little about the lower level 'stuff' so your assistance is appreciated.

Regards
Nick

Hi

I added sis900 to /etc/modules and re-booted. Start-up returned eth0 not valid.

I then removed sis900 and added forcedeth to /etc/modules and re-booted. Start-up again returned eth0 not valid.

I have no idea where to do from here so any help would be appreciated.

What I don't understand is that, during the Debian install process, it finds and recognises the on-board NIC and uses it to validate the apt-get respositories selected (debian ftp). Why isn't the module, that it uses, added and loaded subsequently?

Regards
Nick

Looks like sis900 is the wrong module. Try sis190 also? RTL8201 is in the driver source for that module also. How do you know this is the ethernet chip? Have you checked the output of command 'lspci' to see what ethernet controller it reports?

As to why the installation did not figure out automatically what to use - I don't know if hardware detection is Debian's strong point (my install is years old).

Debian-based distros like Ubuntu and Knoppix may be better. If no luck with anything else you can always boot off a Knoppix live CD and see what it thinks of the situation.

You could try the really common ones also: 8139too, e100, eepro100, tulip, ne2k-pci.

Hi maroonbaboon

The output from lspci | grep Ethernet is:

00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
01:07.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)

The D-Link card is a temporary solution whilst I resolve the MCP61 issue.

Thanks

Regards
Nick Adie

OK, so according to nvidia the charmingly named 'forcedeth' driver could be the one to use, and this has been in the kernel since 2.6.17. But you say you already tried that.

Does 'grep eth0 /etc/modules.conf' return anything?

If there is a line

alias eth0 forcedeth

in /etc/modules.conf then the driver should be autoloaded when the networking is configured.

You could try adding the line, starting the network manually with '/etc/init.d/networking start' (as root, or try 'restart' instead of 'start') and checking the output of 'dmesg' for anything interesting.

Otherwise there is the live CD approach, if you have the bandwidth to get an ISO.

Good Day to you all,

I did several things last night, which I will detail below, but no joy, the Kernel is not talking to 'forcedeth' or 'forcedeth' is not talking the the port.

Whilst running these tests I downloaded Knoppix Live CD, more about that below also.

I am beginning to wonder if there is a problem with the DEBIAN version of 'forcedeth', if so, how easy is it to get the information to the developer(s) and for them to sort the problem. I don't however want to put in a report prematurely and waste their time.

On that basis any further help or advise would be very welcome.

Thank you

Regards
Nick

------------------------------------------------------------------------------

I ran the series of tests with and without 'alias eth0 forcedeth' in the /etc/modules file.

I have checked /etc/udev/rules.d/z25_persistent-net.rules, this shows the correct details, that is the card definition, driver and correct MAC address.

I ran: modprobe -l |grep forcedeth
The response was : /lib/modules/2.6.18-4-amd64/kernel/drivers/net/forcedeth.ko

I ran: lsmod |grep forcedeth
The response was: forcedeth 46340 0

I ran: dmsg | grep eth

The response was:
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:07.0
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present

------------------------------------------------------------------------------

Knoppix Live CD

I booted up the machine with the Knoppix live CD. It identified both the NIC cards as per DEBIAN.

I ran: dmesg | grep eth

Knoppix used exactly the same named drivers as DEBIAN but was reporting the link down on eth0.

I then ran out of time and had too head for bed, so will do more with Knoppix tonight.

What's the output of 'ifconfig' on the Debian system with the eth0 link up?

Forgot to look at that, will report back later.

Nick

Hi

ifconfig returns localhost information, no ip address etc.

Further Work / Testing

Last night I installed the AMD64 linux-image-2.6.21 from backport...
Configured eth0; forcedeth

and guess what, it failed

I then cleaned up /etc/udev/rules.d/z25_persistent-net.rules leaving only a single entry for eth0 and eth1 and rebooted.

and guess what, it failed but I did find another problem!

eth2 'forcedeth' had been added in, /etc/udev/rules.d/z25_persistent-net.rules, with a different MAC address; so I goggled and found the following:

+-------------------------------------------------------------------------------+

bugs.centos.org/view.php?id=1949

Incorrect MAC address for ebedded NIC for NVidia nforce 430 MCP chipsets.
Run: dmesg

url: bugs.centos.org/view.php?id=1949

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LMAC] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:07.0 to 64
forcedeth: using HIGHDMA
0000:00:07.0: Invalid Mac address detected: c5:54:51:f3:18:00
Please complain to your hardware vendor. Switching to a random MAC."

+-------------------------------------------------------------------------------+

So where do I go from here?

Regards
Nick

Just found this on http://www.debian-administration.org/articles/501 how to deal with random MAC Addresses.

Wonder if this will solve the problem?

Regards
Nick[/QUOTE]

Alternatively can you put in a 'default' udev rule that matches any MAC address and assigns it to eth0? Perhaps after testing for the D-link MAC, if it's still in there.

I'm in unfamiliar territory here.