Hello;

I hope someone can offer some help...

I have this rather old Super micro board http://www.supermicro.com/Aplus/motherboard/Opteron1000/MCP55/H8SMi-2.cfm purchased for a second unraid system (for testing and backup of the 1st one). Rev 1 PCB.

 

After installing the newest unraid release, and rebooting, I couldn't connect to the server, and discovered that the network interface was not up.

I attached here an excerpt from the log, and the full log as an attachment.

I resolved the problem signing in on the console and bouncing down and up the interface with ifconfig: ifconfig eth0 down; ifconfig eth0 up. This fixed the problem. I've checked this a couple of times and this was the only way to get and Ip for the port.

 

ep 22 23:26:42 Tower2 logger: /etc/rc.d/rc.inet1:  Polling for DHCP server on interface eth0:

Sep 22 23:26:42 Tower2 logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -t 10 -h Tower2.dyndns-home.com -L eth0

Sep 22 23:26:42 Tower2 dhcpcd[1082]: version 5.2.7 starting

Sep 22 23:26:42 Tower2 kernel: forcedeth 0000:00:08.0: irq 46 for MSI/MSI-X

Sep 22 23:26:42 Tower2 kernel: forcedeth 0000:00:08.0 eth0: MSI enabled

Sep 22 23:26:42 Tower2 dhcpcd[1082]: forked to background, child pid 1083

Sep 22 23:26:42 Tower2 logger: /etc/rc.d/rc.inet1:  /sbin/route add default gw 192.168.20.1 metric 1

Sep 22 23:26:42 Tower2 logger: SIOCADDRT: Network is unreachable

Sep 22 23:26:42 Tower2 kernel: forcedeth 0000:00:08.0 eth0: no link during initialization

 

I have also a second problem, related...once I turned the port up, I wanted to see if I can also use the second port on the motherboard.

 

I ran a second connection to the switch and in the web interface I turned on bonding.

 

I repeated the reboot, and ifconfig for both cards this time (because the network was down otherwise).

 

Bond0 comes up, and both eth0 and eth1 are marked as slave.

But the system complains that eth1 is down (and marked in the log every few seconds the fact that the line was initially considered up, but then found down.

 

Checked the wires, checked BIOS, both ports are enabled, but had no success. Unfortunately I didn't capture the syslog for this particular test, but I'll repeat tonight and attach it to the message.

 

I'd appreciate any suggestions. Thank you!

 

hg

syslog.txt

your switch has to support bonding as well.

your switch has to support bonding as well.

Yes, thanks for pointing that out.

 

I have a D-Link EasySmart Switch DGS-1100-16 which supposedly does trunking.

 

I just turned that on (I'm afraid there are no other options to specify) - and didn't make a difference.

 

Unraid interface bonding has quite a few options to choose from. I think I picked up balance-xor in the idea of doing load balancing.

 

One additional detail: The ports on the motherboard have both the same MAC address. Not sure if this is supposed to be so - I've never before used two ports bonded together, and perhaps this is an option which is chosen from BIOS.

 

I've noticed quite a few folks have super micro m/bds and probably double ports on them. How do you connect your unraid server to your lan?

 

Thanks again

What does ethtool say?

What does ethtool say?

Thanks for mentioning that, but I'm not sure what to do with it. First of all didn't know it existed. I'll check it out.

I have two problems, are you thinking about using it for both?

 

1) The network doesn't come up with the system, unless I perform the ifconfig down/up sequence at the console, after the system has booted up.

2) Understand how to use bonding, with the switch I have.

 

Thank you for your help.

hg

Show the output of "ifconfig" and "ethtool eth0"? Try using one port at a time.

Hello;

I've been away for a while and not able to look further into the issue.

 

I've spent a bit of time last night and this morning and here is where I'm with my problems:

(note: my setup is based on Unraid 5.0 running on a SuperMicro H8SMi motherboard, equipped with two GB Ethernet ports, provided by Nvidia MCP55 chipset.)

 

I use as my main switch a D-Link DGS-1100-16 (16 ports managed) GB switch. I've upgraded the switch with the latest firmware, and it appears to work correctly.

I've checked the m/b bios (re-flushed the bios from SuperMicro web site). I tried several settings in the Bios on the motherboard.

 

I cannot make second port (eth1) work on the motherboard, with the said switch, as the link goes up and down (when I insert the network cable, the carrier is briefly  detected, then lost, and keeps doing that cycle for ever). So I've abandoned this battle...

 

The internet discussion boards acknowledge problems with the driver for NVidia MCP55  (forcedeth) and there are different suggestions to add options at boot time (forcedeth.conf file), but haven't been able to use them (or what i tried didn't seem to work - except for forcing the port to 10Mbps, with no negotiation, which appeared to keep the link up.)

 

When I use Eth0 instead, the link comes up, but not immediately (when the system is up, as soon as the boot process completes, I don't have yet an IP address on eth0).

 

I decided to disable (in MB BIOS) everything I didn't have a use for (floppy, comm, and parallel ports) and it appeared that I've got eth0 working - sort of, delayed. (I would log on as  root, as soon as the prompt showed on the console, and the netstat -rn command would show no route added, besides the one for localhost. But after 1/2 min or so, eth0 got an IP address and things just work from there on.)

 

I ended up added a 10s delay in go script just before /usr/local/sbin/emhttp command.

 

One thing quite intriguing was testing the connection to my router instead (an ASUS RT-N66U - which also has GB ports). The connection from eth1 to  RTN66 worked. The link came up, and stayed up (well... after running ifconfig and restarting the dhcp request). So something is not quite right with the port on the motherboard (perhaps a slightly less sensitive transceiver, combined with the driver software which doesn't do the best handshaking, in less optimal conditions)

 

Here is ethtool output when connected to the router:

Settings for eth1:

        Supported ports: [ MII ]

        Supported link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 1000Mb/s

        Duplex: Full

        Port: MII

        PHYAD: 3

        Transceiver: external

        Auto-negotiation: on

        Supports Wake-on: g

        Wake-on: d

        Link detected: yes

 

Anyway, I decided to leave the router alone (since there is no trunking available on it), and connected only eth0 to my main switch. I'm using only one network link, and abandoned the idea of port bonding.

 

A few things I want to point out, for what is worth. After having gone in all the startup scripts and checking what is and isn't there and might be of use. There is an awful lot of stuff from the generic Slackware distribution, which doesn't serve any purpose, but slows down any troubleshooting. Since unraid is so barbones, I'm not sure why all that stuff is still kept around.

 

For motherboards with two ports, unless one is disabled in the BIOS, chosing to use eth1 over eth0 doesn't work out of the box (if eth0 is enabled, but not in use). Would be nice to have the startup script check which link is up and attach an IP address to it, etc.

 

There are a few messages coming up at startup, or at shudown, which do not seem to be alarming, but it would be nice to have a completely clean startup and shutdown. I'm not sure if there is an easy solution, since everyone's hardware is different, and very little time to intercept and document everything.

This goes as well for the add-ons. Some of them also tend to complain (either when loading, or at shutdown), and while things are perhaps resolved in the forum, I'm not sure they make their way back into the package upgrades.

 

If you've made it this far (this was a long write-up!) thanks for reading, and any comments.

 

hg