Jump to content

On board LAN disabled after soft reboot

ygohome
 Share
Go to solution Solved by ygohome,

*edit:

okay, updating drivers didn't fix it.

applying the latest kernal security patch seems to be the cause of my problems. 2.6.39-400.109.5.el6uek.x86_64


everything up to that patch and the on board LAN worked great on "shutdown -r" and "shutdown -h"


After applying the kernal patch, the on board LAN is getting it's MAC wiped out to 00:00:00:00:00:00


I have a workaround. I can either NOT apply that security patch... or I can do the following:

I disable the NetworkManager daemon, shutting down its service. I enabled the simple "network" service instead so that I can manually set it up.

chkconfig NetworkManager off
service NetworkManager stop
chkconfig network on

then I manually apply the missing hw# (MAC address) to eth0 (eth0 being the on board LAN).

ifconfig eth0 hw ether bc:f5:f4:9e:47:93

then I activate it

ifup eth0


And that fixes it until the next shutdown and restart the system again. Then I have to reassign the MAC and activate it again.

To avoid all of that I have a simple script that I run at startup: /etc/init.d/eth0mac

all it does is this:
ifconfig eth0 hw ether bc:f5:f4:9e:47:93

ifup eth0

It is a workaround but it does the trick. Now, if I remotely issue a shutdown/restart.... "shutdown -r now" it will come back online on startup and I can log in again.

 

Posted

Has anyone seen anything resembling the following and is there a simple resolution besides RMA the mobo or buying a new NIC?

 

 

I've setup a new system and I'm seeing some strange behavior with on board LAN on the new motherboard.  

 

Motherboard:  Asrock b75m-dgs r2.0

 

ON BOARD LAN:   Realtek 8111E

 

OS:  RHEL 6.3   2.6.39-400.109.5.el6uek.x86_64 

 

 

Computer is powered off.  I press the power button and wait for OS to boot up.  Everything works fine.  LAN port is completely functional.  ifconfig shows all the info on eth0

 

eth0      Link encap:Ethernet  HWaddr BC:5F:F4:9E:47:93  
          inet addr:192.168.1.118  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2002:4c1f:7d54:0:be5f:f4ff:fe9e:4793/64 Scope:Global
          inet6 addr: fe80::be5f:f4ff:fe9e:4793/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:419943 errors:0 dropped:0 overruns:0 frame:0
          TX packets:139775 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:477026382 (454.9 MiB)  TX bytes:52898008 (50.4 MiB)
          Interrupt:44 Base address:0x8000 

 

 

 

Then I shutdown and restart the system:   "shutdown -r"  , the LAN port is not seen by the OS after the restart.  The light is not on the LAN port of the motherboard (and the corresponding LED light is not lit on the router's LAN port) and ifconfig doesn't show eth0 at all.

 

Doing another shutdown -r and then going into UEFI settings as it starts up again shows the LAN is disabled.

 

Exiting from UEFI and letting it boot back into the OS... again the LAN port is not seen.

 

Doing a shutdown -h (no restart) and then physically powering it back on by pressing the front power button (not the PSU rocker switch) allows the LAN to be seen.  Everything works fine.

*edit:  correction to the above... "shutdown -h" would shutoff the LAN port (no LEDs, nothing).  And then powering system back on, the LAN would still not be recognized.  LEDs on LAN port are not lit, not even orange.  Only way to get it working again is switching PSU off/on.

 

Pretty strange stuff.  A hard reboot without graceful shutdown works.  But soft shutdown or restart does not.  Doesn't seem to be an OS issue since the LAN is disabled even after restart, going immediately into the UEFI and seeing it is disabled.  

 

I'm going to try setting the UEFI back to default incase it was some setting that I messed up there.

Then I may try installing a simple Ubuntu on an extra HDD I have laying around to see if it behaves any differently using the different OS.

 

I'm also going to contact Newegg and Asrock to see if they have any answers.  I'm tempted though to just buy a NIC and be done with it.

 

 

Any suggestions or ideas are appreciated.  Thanks.

Link to comment
Share on other sites
Link to post
Share on other sites
Posted

Um seems to be a NIC power issue, when the PC is off and the PSU is ON does the NIC work (standby power) ?

Is there any setting in the UEFI that has to do with the NIC power such as "Wake on lan" etc... ? You might want to tinker then.

 

If you are going for a dedicated NIC then grab an Intel pro series one.

Something wrong with your connection ?

Run the damn cable :)

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

Um seems to be a NIC power issue, when the PC is off and the PSU is ON does the NIC work (standby power) ?

Is there any setting in the UEFI that has to do with the NIC power such as "Wake on lan" etc... ? You might want to tinker then.

 

If you are going for a dedicated NIC then grab an Intel pro series one.

Thanks rufee.  I'll look at the UEFI again.  There are a few UEFI settings, if I recall, relating to power up.  I don't recall seeing settings for Wake on LAN, although documentation shows that it is supported.  The only LAN setting I remember seeing is the DISABLE/ENABLE setting.  But I'm not very familiar with this UEFI GUI... so I need to look through every menu to find stuff.

 

Oh, I've updated my original post to show on board LAN is a "Realtek 8111E".  

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

Ahh, realtek 8111E may not be supported for WoL in RHEL.  And maybe that has something to do with it.  I should probably just get that Intel Pro like you suggest and be more aware which on board LAN I'm getting next time.

 

[brtate@egg etc]$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                    100baseT/Half 100baseT/Full 
                                    1000baseT/Full 
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000033 (51)
      drv probe ifdown ifup
Cannot get link status: Operation not permitted
 
There may be something I can try (see link below about getting WoL to work in Fedora).  But I think I might be better off just getting an Intel Pro NIC
 
Link to comment
Share on other sites
Link to post
Share on other sites
Posted

Well Realtek has its "strengths". WoL should not be a direct problem because you don't use it, it might influence something in the device when OS restarts (sets a bit or something).

Try other OS'es something Debian based like Ubuntu or even Windows and see if it might be an OS issue.

Something wrong with your connection ?

Run the damn cable :)

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

Yeah, I agree with your statement.  WoL isn't really my issue, but it might be a clue that something isn't setup right.  

 

I'll try this mobo with a different OS to see what happens.

 

 

 

I checked another server that I have here.  Both servers have same Realtek on board LAN and RHEL6, but different mobo, chipset.  The one server's LAN works just fine, all of the time.   Must be something in the UEFI or still maybe something different in my OS config.

 

 

output from lspci command on server that is not having problems:

 

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

 

 

output from lspci command on new server that is having LAN problems:

 

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

 

 

 

Also for comparison, here is the output from ethtool eth0 command on server that is not having issues (showing Wake-on being supported):

 

Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                    100baseT/Half 100baseT/Full 
                                    1000baseT/Full 
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
Link to comment
Share on other sites
Link to post
Share on other sites
Posted

Looks like the two NIC's are not identical one board has rev 6 the other rev 2 of the chip, that's why only one board is affected.

Something wrong with your connection ?

Run the damn cable :)

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

Yes.  But what I just now realized, I should have been running ethtool command as root on the new server as I was when I ran the command on the good server. My brtate login didn't have proper privs to view the eth0 status.

 

Now, as root, I ran that eth0 command again on the new server and it shows that wol is supported.  sorry for that wild goose chase.  Still though I need to figure out what is happening on soft reset.  I'll try another OS and also look again at the UEFI settings, resetting those to default.

 

[root@egg ~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                       100baseT/Half 100baseT/Full 
                       1000baseT/Half 1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                    100baseT/Half 100baseT/Full 
                                    1000baseT/Full 
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000033 (51)
      drv probe ifdown ifup
Link detected: yes
Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

Um seems to be a NIC power issue, when the PC is off and the PSU is ON does the NIC work (standby power) ?

Is there any setting in the UEFI that has to do with the NIC power such as "Wake on lan" etc... ? You might want to tinker then.

 

If you are going for a dedicated NIC then grab an Intel pro series one.

you mentioned something earlier for me to check.  How can I see if the NIC has standby power?  I ping the NICs local IP address while the system is off (and with PSU on) but I get the following.  Can I run a traceroute or something similar?

 

PING 192.168.1.118 (192.168.1.118): 56 data bytes

Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
^C
--- 192.168.1.118 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

FYI, the light on LAN of the mobo is off while the system is shutdown, even with PSU on.

 

I probably have the wrong UEFI setting for PCI power on or somthing along those lines.  I'm not in the room with the computer else I would check that right now.  I'll post back after I look closer at the UEFI.

 

Thanks again.

Link to comment
Share on other sites
Link to post
Share on other sites
Posted

Usually NIC's stay up when the PC is powered off this is needed for features like WoL, however it might not be pingable by IP.

Not sure about integrated NIC's, but my servers dedicated ones flash bright green when PC is off.

Something wrong with your connection ?

Run the damn cable :)

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

I hope to have time today to test using a different os, but I want to try a few different settings in RHEL network first.

Interestingly if I do an abrupt reset (hitting reset button on case) without graceful shutdown then the nic link works fine on startup (nic led even stays on while system is off and in S5 state) .

If I shutdown or restart via "shutdown" command then the nic light immediatly turns off even before system completely shuts down fully, and led stays off. The NIC led remains off and undiscovered by os on next startup (unless I flip psu off/on first).

This behavior makes me think it may be something in the linux shutdown or the networkManager in linux.

Ill have to do more tests, trying different network configs in and also try different os.

Meanwhile I have an Intel pro nic on the way. On board lans are usually sub par performance anyway.

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

I booted from a clonzilla linux usb thumb drive.  The NIC light stayed on (orange).  I did a "shutdown -h now" from the clonezilla command prompt and it the NIC light stayed on the whole time even after shutting down.  I restarted and the NIC light was still on.  Again, this has me thinking it is a network issue within my RHEL os environment rather than the mobo or on board LAN.  More test results to follow as I install and try Ubuntu with network enabled.

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

I reinstalled RHEL6 on a seperate HDD.

 

Immediately after installing, kernal is...  

 

2.6.39-200.24.1.el6uek_x86_64

 

This is before applying any patches, bug fixes or kernal updates.  The on board LAN is recognized and operational at this point.

 

I do a soft restart with "shutdown -r now"  (or even a "shutdown -h now" followed by pressing the power button on front of case) and the NIC LED shuts off as system powers down, but then soon it lights up orange while it is in S5 state (previously the LED would shut off and stay off - which was bad in that it would NEVER turn on again unless PSU off/on).  As the system boots up again, the orange LED turns off briefly as the linux networkManager does it's thing, then it turns green.  This is very good.  

 

So, the issue is related to the OS after all.    I just need to slowly apply the patches and test NIC behavior in between updates until I get to where I need to be or until I discover when the original issue arises.  That will take awhile as there are a TON of patches to be applied.

 

ALthough I did just pay for a new $30 NIC that is on it's way here.  Oh well, the Intel Pro card should perform better than onBoardLAN and maybe I can even utilize them both.

 

Thanks

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author
  • Solution

*edit:

okay, updating drivers didn't fix it.

applying the latest kernal security patch seems to be the cause of my problems. 2.6.39-400.109.5.el6uek.x86_64


everything up to that patch and the on board LAN worked great on "shutdown -r" and "shutdown -h"


After applying the kernal patch, the on board LAN is getting it's MAC wiped out to 00:00:00:00:00:00


I have a workaround. I can either NOT apply that security patch... or I can do the following:

I disable the NetworkManager daemon, shutting down its service. I enabled the simple "network" service instead so that I can manually set it up.

chkconfig NetworkManager off
service NetworkManager stop
chkconfig network on

then I manually apply the missing hw# (MAC address) to eth0 (eth0 being the on board LAN).

ifconfig eth0 hw ether bc:f5:f4:9e:47:93

then I activate it

ifup eth0


And that fixes it until the next shutdown and restart the system again. Then I have to reassign the MAC and activate it again.

To avoid all of that I have a simple script that I run at startup: /etc/init.d/eth0mac

all it does is this:
ifconfig eth0 hw ether bc:f5:f4:9e:47:93

ifup eth0

It is a workaround but it does the trick. Now, if I remotely issue a shutdown/restart.... "shutdown -r now" it will come back online on startup and I can log in again.

 

Link to comment
Share on other sites
Link to post
Share on other sites
Posted
  • Author

The new Intel Pro NIC arrived today and it works great of course.  None of the weird behavior that the on board LAN was having.  

 

Now I have two working LAN ports. cool

Link to comment
Share on other sites
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing Networking

×