Jump to content
XPEnology Community

Possible Built-in NIC issues / Configuration problem


mexican

Recommended Posts

Hello!

 

I have an interesting situation. I bought a Dell C2100 (FS12-TY) so I can load Xpenology. I used the latest XPenoboot (5644.4.iso) and DSM (5644.pat). Booting from Xpenoboot and loading DSM (pat) was no problem, the issues started after the DSM rebooted to complete the installation. From the server side, it looks like everything is fine, however, when I try to load the address, it fails with "The connection has timed out. The server at is taking too long to respond.". One thing i noticed was that during setup, the NIC had 1Gbps speed, however, after the reboot and any other subsequent reboot that I do, the NIC speed is only 10Mbps.

 

I honestly don't know if that is the problem, but has anyone encountered an issue like that?

 

Your help is much appreciated!

Link to comment
Share on other sites

I was thinking that it could potentially be a NIC issue. So, i booted from a live CD and found that the NICs are Intel 82576 (rev01). Additionally, when the server is rebooting, as well as on this live CD, the connection is at 1Gbps (1000Mbps). I have a Ubiquiti switch and is set for autonegotiation. So, I don't think it is a compatibility issue especially because the connection works fine just before the manual setup (installing PAT file).

Link to comment
Share on other sites

I had the exact same problem, as a work around I installed a Broadcom dual port NIC and used those instead. the system booted properly but noticed that the Intel nics were still active on the hardware list, also the cpu was flat at 26 % all the time. I decided to disable the onboard Intel Nics on the bios and the CPU usage dropped to 0%.

So I Think we can safely say that the Onboard Intel Nics are the culprit of this problem.

Link to comment
Share on other sites

I was thinking that it could potentially be a NIC issue. So, i booted from a live CD and found that the NICs are Intel 82576 (rev01). Additionally, when the server is rebooting, as well as on this live CD, the connection is at 1Gbps (1000Mbps). I have a Ubiquiti switch and is set for autonegotiation. So, I don't think it is a compatibility issue especially because the connection works fine just before the manual setup (installing PAT file).

 

Intel 82576 adapters are supported by the igb driver.

DELL provide normal igb without anything "exotic".

XPEnoboot 5644 have igb v5.3.3.2 (2015-09-12)

 

Can you test with XPEnoboot 5592 which have igb v5.0.6 (2013-09-17).

 

The weird thing is that igb v5.2.17 should fix a transmit hangs on 82576 issue : http://sourceforge.net/projects/e1000/f ... le/5.2.17/

Link to comment
Share on other sites

Just an update. I retry installing Xpenoboot using the previous version (5592) and I had the same results. Everything worked flawless when booted (1000Mbps) and when uploading the PAT file. However, when the system was rebooted to complete the installation, it came back with only 10Mbps and unable to connect due to timeout.

 

Would it be beneficial to attempt upgrading the firmware on those NICs?

 

I was looking at maybe buying the TP Link card if there is no way of getting the onboard NICs working.

Link to comment
Share on other sites

Just an update. I retry installing Xpenoboot using the previous version (5592) and I had the same results. Everything worked flawless when booted (1000Mbps) and when uploading the PAT file. However, when the system was rebooted to complete the installation, it came back with only 10Mbps and unable to connect due to timeout.

 

Would it be beneficial to attempt upgrading the firmware on those NICs?

 

I was looking at maybe buying the TP Link card if there is no way of getting the onboard NICs working.

 

Did you try both ports ?

When booting, when GRUD shows up edit the boot command line and remove loglevel=0 in order to see more information on screen.

When DSM is installed log in via console, try to unload driver and reload it:

rmmod igb

insmod /lib/modules/igb.ko

 

Check the logs /var/log/message and/or dmesg to see what's happening.

Link to comment
Share on other sites

Did you try both ports ?

I sure did!

When booting, when GRUD shows up edit the boot command line and remove loglevel=0 in order to see more information on screen.

On this view, I see some events with "dhcp-client (eth0)main process (17198) killed by TERM signal" and same for eth1

When DSM is installed log in via console, try to unload driver and reload it:

rmmod igb

insmod /lib/modules/igb.ko

 

Check the logs /var/log/message and/or dmesg to see what's happening.

What is the default account? I thought it was admin with a blank password, but I get access denied. I have not setup any account yet since I just rebooted to finish the manual PAT installation.

 

Additionally, I tried to ping the assigned IP addresses for either NIC and I get "Destination Host Unreachable" I pinged from my workstation and from the router, both same result. So, it definitely it is something with the NICs not being either loaded or based on the output, killed after the reboot that follows the PAT file installation.

Link to comment
Share on other sites

I want to try

"When DSM is installed log in via console, try to unload driver and reload it:

rmmod igb

insmod /lib/modules/igb.ko

 

Check the logs /var/log/message and/or dmesg to see what's happening.

"

However, the default admin account and blank password does not work for me. Does anyone know what it is?

Link to comment
Share on other sites

I end up buying the TP-Link NIC and it works perfectly. The built-in NICs are detected after boot, but is like the driver does not work because they don't auto assign an address when ethernet is plugged in.

 

So, definitely, there is something wrong with the PAT file and the built-in NIC. Even though I would still like to use them, the TP-Link will do. Maybe there is something I can tweak now that I can access the system.

Link to comment
Share on other sites

I end up buying the TP-Link NIC and it works perfectly. The built-in NICs are detected after boot, but is like the driver does not work because they don't auto assign an address when ethernet is plugged in.

 

So, definitely, there is something wrong with the PAT file and the built-in NIC. Even though I would still like to use them, the TP-Link will do. Maybe there is something I can tweak now that I can access the system.

 

Since you have now access to the system check /var/log/message and dmesg to see if anything goes wrong with intel igb driver.

Remove loglevel parameter from boot command line in grub (syslinux.cfg) in order to have more information display on screen.

Try to unload / reload igb driver:

rmmod igb

insmod /lib/modules/igb.ko

Try to un-plug / plug the cable to see what's happening.

Link to comment
Share on other sites

Since you have now access to the system check /var/log/message and dmesg to see if anything goes wrong with intel igb driver.

Remove loglevel parameter from boot command line in grub (syslinux.cfg) in order to have more information display on screen.

Try to unload / reload igb driver:

rmmod igb

insmod /lib/modules/igb.ko

Try to un-plug / plug the cable to see what's happening.

 

I am not sure if I am doing something wrong. I tried to access the system directly from the server entering the username/password that I setup via command line. However, I get:

login: can't chdir to home directory '/var/services/homes/'

login: can't run /sbin/nologin: No such file or directory

 

After which brings me back to the login prompt. Additionally, I enabled SSH service to see if I can access my system that way, however, after I enter my credentials, the Putty window disappears.

 

I have no problems accessing the system using the Web GUI.

 

Something I noticed after removing loglevel=0 this time around was the following:

igb 0000:06:00.0 eth0: PCIe link lost, device now detached

igb 0000:06:00.1 eth1: PCIe link lost, device now detached

 

So, I think there is a very good chance that reloading the driver will work, but I just need to know how to access via command line.

 

Any ideas would be appreciated.

Link to comment
Share on other sites

Since you have now access to the system check /var/log/message ...

 

From the messages files, I found the following after boot:

 

Feb 19 11:13:03 NAS synonetseqadj: synonetseqadj.c:312 Error internal NIC devices 3 does not equal to internal NIC number 4

Feb 19 11:13:03 NAS interface-catcher: eth0 (dhcp) is added

Feb 19 11:13:03 NAS interface-catcher: eth1 (dhcp) is added

Feb 19 11:13:03 NAS interface-catcher: eth2 (dhcp) is added

Feb 19 11:13:03 NAS interface-catcher: lo (inet 127.0.0.1 netmask 255.0.0.0 ) is added

Feb 19 11:13:04 NAS synonetd: net_route_table_edit.c:72 eth0 ip route del failed, instead of route

Feb 19 11:13:05 NAS dhcp-client: started on eth0

Feb 19 11:13:05 NAS synonetd: net_route_table_edit.c:72 eth1 ip route del failed, instead of route

Feb 19 11:13:05 NAS [ 56.337056] init: dhcp-client (eth0) main process (16997) killed by TERM signal

Feb 19 11:13:05 NAS dhcp-client: stopped on eth0

Feb 19 11:13:05 NAS dhcp-client: started on eth0

Feb 19 11:13:06 NAS dhcp-client: started on eth1

Feb 19 11:13:06 NAS dhcp-client: stopped on eth1

Feb 19 11:13:06 NAS [ 57.128439] init: dhcp-client (eth1) main process (17170) killed by TERM signal

Feb 19 11:13:06 NAS dhcp-client: started on eth1

Feb 19 11:13:06 NAS synonetd: net_route_table_edit.c:72 eth2 ip route del failed, instead of route

Feb 19 11:13:07 NAS dhcp-client: started on eth2

Feb 19 11:13:07 NAS [ 58.223418] init: dhcp-client (eth2) main process (17291) killed by TERM signal

Feb 19 11:13:07 NAS dhcp-client: stopped on eth2

Feb 19 11:13:07 NAS dhcp-client: started on eth2

Feb 19 11:13:10 NAS [ 60.879375] init: dhcp-client (eth2) main process (17360) killed by TERM signal

Feb 19 11:13:10 NAS dhcp-client: stopped on eth2

Feb 19 11:13:10 NAS dhcp-client: started on eth2

 

... and dmesg to see if anything goes wrong with intel igb driver.

 

From dmesg I found the following using grep for igb/eth:

 

[ 8.589783] ioatdma: Intel® QuickData Technology Driver 4.00

[ 8.632437] Intel® Gigabit Ethernet Network Driver - version 5.3.3.2

[ 8.658253] Copyright © 2007-2015 Intel Corporation.

[ 8.671958] igb 0000:06:00.0: irq 65 for MSI/MSI-X

[ 8.671966] igb 0000:06:00.0: irq 66 for MSI/MSI-X

[ 8.840713] igb 0000:06:00.0: added PHC on eth0

[ 8.854314] igb 0000:06:00.0: Intel® Gigabit Ethernet Network Connection

[ 8.868369] igb 0000:06:00.0: eth0: (PCIe:2.5GT/s:Width x4)

[ 8.882581] igb 0000:06:00.0 eth0: MAC:

Link to comment
Share on other sites

Even when I tried to unplug/plug the cable, it did not work. I am sure by rebooting they will be back to their normal "unusable" state, but will be visible. Have not done so yet.

 

Well, I went ahead and rebooted and now I am not able to access the system. All the NICs are back (ifconfig) and the usable NIC gets an IP (dhcp), but I cannot get a response. From the system I try to ping the switch but even that fails. Pinging from my workstation to the router and to the switch is successful, just not to the system.

 

Looks like by unloading/reloading igb did something that affected the other usable NIC. The switch and router do show the connection fine to the "working" NIC.

 

Do I have to nuke my system and start over?

Link to comment
Share on other sites

×
×
  • Create New...