Topic: Waking up of SME 9.1 using WoL (SME server used for Affa)

[turandot]

I am currently still running SME 8.2 on my SME backup server. This backup machine is regularly waked up using WoL by a magic packet from my productive SME server. A while after the wakeup, Affa is started, hence my productive machine is backuped. Using a cron job, the machine will halt once the Affa backup job is done. This works perfectly since a long time.

I am aware that SME 8.2 will become obsolete soon due to the obsolescence of CentOS 5. Therefore I was preparing to update my backup machine to SME 9.1. Unfortunately WoL does not work for the SME 9.1 test installation.

The ethtool on the SME 9.1 backup server (test installation) produces the following output:

Code: [Select]

[root@smebackup ~]# 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
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes
[root@smebackup ~]#
Doing the same on my productive SME 8.2 backup server, the output is the following:

Code: [Select]

[root@smebackup ~]# ethtool eth0
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 auto-negotiation: Yes
        Speed: 100Mb/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
[root@smebackup ~]#
The output is more or less identical except

Code: [Select]

                              drv probe ifdown ifupAny ideas what I can do? I have seen this bug report https://bugs.contribs.org/show_bug.cgi?id=7928 , but it relates to SME 8 (which works for me) and it seems to be fixed anyway...

Regards, turandot

[Stefano]

are 2 nics the same?

[turandot]

I should have stated that it is the identical hardware, except the HDD... To test all this, I just used a spare HDD which I swapped into my backup server for testing purposes.

So yes: same machine, identical NIC, same MAC address...

BTW: the SME 9.1 installation is completely updated.

Thanks, turandot

[Jean-Philippe Pialasse]

You can not have two identical mac address on same network from what i know, this will cause conflict. Even with same model, two nics should have two unique mac address.

Your issue is not sme related but hardware related. Check that wake on lan is enabled on bios setting and double check your mac address

[turandot]

Stefano,

sorry, this is a misunderstanding. I don't have two identical machines with identical MAC address in my network. I am using the same machine, alternatively with a 8.2 installation (productive server) or (exclusive or!) with the 9.1 test installation. (Just the HDD is different carrying the SME installations.)

Thanks, turandot

[Jean-Philippe Pialasse]

Ok my bad, same hardware except for hdd.

So bios should be set to the same.
The bug linked seemed stranged to me as the wake is related to the hardware not the os.

However i have seen some linux module not handling correctly some nics leaving them disabled.

One way to test this hypothesis.
1 Switch on your sme9 version, then halt it.
2 Try to wake it... works? Fails?
3 swap disk to sme8, do not power on, just try to wake up.
4. If previous failed, switch on and halt, then try to wake. And halt if success
5. Swap back to sme9, do not switch on, just try to wake

If both 2 and 3 failed and 4 and 5 succeed then this is a driver issue and need to be reported to redhat, and maybe buy a new nics (different brand) waiting for a fix

Or keep your server running, or use the bios hour programmed wake up. Carrefull for summer time not handled by bios.

[turandot]

OK, my fault as well: Jean-Philippe (and not Stefano)!

The BIOS settings are indeed unchanged.

I now need a bit of testing time, I will probably come back tomorrow. New year eve is coming!

Have a good time,

turandot

[turandot]

Here are my test results.

Test conditions:

• SME 8.2 32 Bit fully patched (noted as "SME 8.2" below)
• SME 9.1 64 Bit fully patched (noted as "SME 9.1" below)
• always use Putty for console commands, even though local console and monitor are available as well
• always use WoL to wake up server, just use power button in case of WoL Fail
• always 3x WoL (if Fail) in order to avoid "single events"
• always 1x WoL (if OK), first time works perfectly
• "Detach power" means: a) pull off main power cord, b) wait 30 seconds, c) plug in power cord. (BIOS Power up on AC power loss is disabled.)
• "Start, Stop" means: a) let the SME server boot completely, b) logon to remote console, c) apply console command signal-event halt

Test sequence and test results:

• Start test sequence with SME 8.2 HDD
• Detach power, reattach power, WoL --> OK
• Start, stop, WoL --> OK
• Start, stop, swap SME 8.2 HDD to SME 9.1 HDD without detaching main power, WoL --> OK
• Start, stop, WoL --> Fail
• Start, stop, detach power, reattach power, WoL --> OK
• Start, stop, WoL --> Fail
• Start, stop, swap SME 9.1 HDD to SME 8.2 HDD without detaching main power, WoL --> Fail
• Detach power, reattach power, WoL --> OK

My main conclusion is: once SME 9.1 was running and server was halted, WoL fails. This faulty situation is "healed" by cycling the main power.

The used system is a MSI Wind 2713 NetTop, the used hardware can be seen here:

Code: [Select]

[root@smebackup ~]# lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 3 (rev 01)
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 01)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 01)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
[root@smebackup ~]#

Any ideas?

Thanks, turandot

[Jean-Philippe Pialasse]

Wow, excellent testing!

Happy new year  !

So you have your confirmation, this is indeed driver related, something went bad on rhel6 version, hence you should report this to red hat bugzilla for rhel6 as sme9 is based on this.

This might take a while to fix, if you are urged by time, i advise to buy a different network card from different manifacturer capable of wol. Considering the cost of your time this might be a savvy solution, however i still strongly suggest you to report it to red hat. As you have the hardware in hand you are more suited than us to report it.

[Jean-Philippe Pialasse]

Two other thoughts:
- check for mother board firmware update
- is this a uefi or bios board? This could be related to some os security check to deactivate if this is an uefi

[turandot]

Happy new year as well!

Wow, excellent testing!

Thanks

...this is indeed driver related, something went bad on rhel6 version, hence you should report this to red hat bugzilla for rhel6 as sme9 is based on this.

Here I need a little help. You are suggesting, that I should raise a bug report here: https://bugzilla.redhat.com/index.cgi? Do I need to report what component is affected? How to differentiate between SME and Red Hat components?

...i advise to buy a different network card from different manifacturer capable of wol.

You are probably right.

check for mother board firmware update

Hmm, could do this, but the latest available Bios is from 2008-12-11...

is this a uefi or bios board? This could be related to some os security check to deactivate if this is an uefi

The machine has a classical Bios, nothing else.

I need to think now, because the affected machine is quite old, probably nine or ten years. May be I should sent the machine to the happy hunting grounds?

Whatever: some advice how to submit a bug at Red Hat would be very much appreciated anyhow.

Thanks, turandot

[ReetP]

https://bugzilla.redhat.com/

You could then open one in bugs.contribs.org and reference the redhat one.

B. Rgds
John

[TerryF]

Not a soluti8on but some reading and path for further investigation:

https://www.centos.org/forums/viewtopic.php?t=46364
https://www.centos.org/forums/viewtopic.php?t=3259

[Jean-Philippe Pialasse]

TerryF links could be promising.
at least the part where you see :

Code: [Select]

cat /proc/acpi/wakeup

You could indeed check at the message log about the time the machine is powering off to catch some errors on closing network.
also you could try to catch them on the screen connected to the server.

For the bugs, should be against rhel6. As we base sme9 on centos6 which is based on rhel6,

In term of hardware this is your call. As long as the disks have been replaced regularly ( 5 years) your machine could still go on. Maybe a check to the power supply and inspect the mother board for visually bad capacitors

[TerryF]

Although an old 8.2 bug it does highlight issues that can arise with driver/module updates upstream
https://bugs.contribs.org/show_bug.cgi?id=7928

Seems to be a bit of discussion around CentOS and that RealTek chip
eg https://www.unixteacher.org/blog/linux/ethernet-rtl-8168-driver-on-centos/

added: interesting although Ubuntu https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/981461