Shutdown -h results in reboot on Dell 7010

SUSE Linux Enterprise Desktop SLED Configure-Administer
1

PC: Dell Optiplex 7010 BIOS version A16
System: SLED11 SP3 x86_64 3.0.101-0.15-default

Problem: after a “shutdown -h now” the system restarts. This is annoying
as student’s PCs are supposed to be powered off at night and are shut
down with the help of a cron script. A very similar installation did
work well with an Optiplex 745 in 32 bit mode.
Is this a known problem with this hardware and kernel? Anything I can do
about it, kernel parameters or BIOS settings?

Günther

2

[QUOTE==?ISO-8859-15?Q?G=FCnther_Schwarz?=;20125]PC: Dell Optiplex 7010 BIOS version A16
System: SLED11 SP3 x86_64 3.0.101-0.15-default

Problem: after a “shutdown -h now” the system restarts. This is annoying
as student’s PCs are supposed to be powered off at night and are shut
down with the help of a cron script. A very similar installation did
work well with an Optiplex 745 in 32 bit mode.
Is this a known problem with this hardware and kernel? Anything I can do
about it, kernel parameters or BIOS settings?
[/QUOTE]

A quick search of the Knowledge Base https://www.suse.com/support/kb/ didn’t yield anything relevant, but if you want a definitive answer on whether it’s a know problem you’d have to ask SUSE.

Machines that reboot rather than turn off is something that crops up on various hardware with various distros* and there’s no magic bullet fix. Solutions can sometimes be found in BIOS settings but BIOSs are many and varied. I’d start by experimenting with whatever power related settings the BIOS provides or looking to see if there’s a newer BIOS available from Dell.

A Make and model of the computer isn’t all that useful when looking at problems like this. More useful is what the actual hardware is.

$ lspci -nnk
  • Search for
"shutdown -h" reboots

on Google. Note the double quotes.

3

mikewillis wrote:[color=blue]

=?ISO-8859-15?Q?G=FCnther_Schwarz?=;20125 Wrote:[color=green]

PC: Dell Optiplex 7010 BIOS version A16
System: SLED11 SP3 x86_64 3.0.101-0.15-default

Problem: after a “shutdown -h now” the system restarts. This is
annoying
as student’s PCs are supposed to be powered off at night and are shut
down with the help of a cron script. A very similar installation did
work well with an Optiplex 745 in 32 bit mode.
Is this a known problem with this hardware and kernel? Anything I can
do
about it, kernel parameters or BIOS settings?
[/color]

A quick search of the Knowledge Base https://www.suse.com/support/kb/
didn’t yield anything relevant, but if you want a definitive answer on
whether it’s a know problem you’d have to ask SUSE.

Machines that reboot rather than turn off is something that crops up on
various hardware with various distros* and there’s no magic bullet fix.
Solutions can sometimes be found in BIOS settings but BIOSs are many and
varied. I’d start by experimenting with whatever power related settings
the BIOS provides or looking to see if there’s a newer BIOS available
from Dell.

A Make and model of the computer isn’t all that useful when looking at
problems like this. More useful is what the actual hardware is.

Code:

 $ lspci -nnk

--------------------[/color]
[color=blue]

  • Search for

Code:

 "shutdown -h" reboots

on Google. Note the double quotes.[/color]

As one can see from the output below this is an almost pure Intel
system. It is also one of the most popular office PC and thus a typical
system for a SLED installation. Hardware variations are minimal within
one series of Dell office PC. The BIOS is the most recent one from DELL.
I will have to try various BIOS setting as well as kernel parameters.
Which is time consuming.

Tests done so far:
BIOS:
Variable “Deep Sleep” enable/disable → no effect

Kernel Parameters:
acpi=off → X will not start
irq=off → no effect

Output from lspci -nnk:

00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen
Core processor DRAM Controller [8086:0150] (rev 09)
Subsystem: Dell Device [1028:0577]
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: i915
Kernel modules: i915
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: xhci_hcd
Kernel modules: xhci-hcd
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: mei
Kernel modules: mei
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit
Network Connection [8086:1502] (rev 04)
Subsystem: Dell Device [1028:052c]
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev a4)
00:1f.0 ISA bridge [0601]: Intel Corporation Q77 Express Chipset LPC
Controller [8086:1e47] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel modules: iTCO_wdt
00:1f.2 IDE interface [0101]: Intel Corporation 7 Series/C210 Series
Chipset Family 4-port SATA Controller [IDE mode] [8086:1e00] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: ata_piix
Kernel modules: ide-pci-generic, ata_generic, pata_acpi, ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset
Family SMBus Controller [8086:1e22] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel modules: i2c-i801
00:1f.5 IDE interface [0101]: Intel Corporation 7 Series/C210 Series
Chipset Family 2-port SATA Controller [IDE mode] [8086:1e08] (rev 04)
Subsystem: Dell Device [1028:0577]
Kernel driver in use: ata_piix
Kernel modules: ide-pci-generic, ata_generic, pata_acpi, ata_piix

I am open and very grateful for any new suggestions.

Günther

4

Hi
Looking on the web, that system has a WoL setting for the ethernet, can
you ensure it’s disabled and see if that makes a difference. Can you
also have a look through the messages file for any acpi events that may
show an error. You could also try acpi_osi="\!Windows 2012" or
acpi_osi="Linux" in the grub options.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-7-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

5

malcolmlewis wrote:[color=blue]

Hi
Looking on the web, that system has a WoL setting for the ethernet, can
you ensure it’s disabled and see if that makes a difference. Can you
also have a look through the messages file for any acpi events that may
show an error. You could also try acpi_osi="\!Windows 2012" or
acpi_osi="Linux" in the grub options.[/color]

Thank you very much indeed for your further suggestions. Meanwhile, just
to make things even more confusing, I found out that some of the
installations behave just fine while others do a reboot consistently.
All with the very same hardware from one lot and the very same BIOS
settings - I did cross check this. Also the installation is identical
from one single Zenworks image. Strange enough.

On one of the “bad” ones I tried the above kernel parameter acpi_osi
with no success. Disabling WOL does indeed do the trick and might be a
valuable starting point for further investigation. Unfortunately I do
need WOL as a feature for maintenance purposes, and I will rather let
them run 24/7 than turning off this feature.

Günther

6

Hi
OK, so on the misbehaving systems do the have all the same network
cards and firmware?

lspci -nnk |grep Ethernet -A3
ethtool <interface> |grep Wake
lshw -class network

I built a copy of lshw here for you to use as a test;
https://build.opensuse.org/package/binaries/home:malcolmlewis:SLE_11_SPn_General/lshw?repository=SLE_11_SP3
Just click the ‘go to download repository’ and just grab the lshw rpm
and install temporarily.

If the cards are all the same on good and bad systems, it’s either some
hardware issue to follow up with DELL, else are the systems clustered
on the same switch, maybe some erroneous network traffic triggering the
WoL event (use wireshark or tcpdump to analyze traffic)?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-7-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

7

malcolmlewis wrote:
[color=blue]

[/QUOTE]
Hi
OK, so on the misbehaving systems do the have all the same network
cards and firmware?

lspci -nnk |grep Ethernet -A3
> ethtool <interface> |grep Wake
> lshw -class network

I built a copy of lshw here for you to use as a test;
https://build.opensuse.org/package/binaries/home:malcolmlewis:SLE_11_SPn_General/lshw?repository=SLE_11_SP3
Just click the ‘go to download repository’ and just grab the lshw rpm
and install temporarily.

If the cards are all the same on good and bad systems, it’s either some
hardware issue to follow up with DELL, else are the systems clustered
on the same switch, maybe some erroneous network traffic triggering the
WoL event (use wireshark or tcpdump to analyze traffic)?
[/color]

The “good” one:

lspci -nnk |grep Ethernet -A3

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit
Network Connection [8086:1502] (rev 04)
Subsystem: Dell Device [1028:052c]
Kernel driver in use: e1000e
Kernel modules: e1000e

lshw -class network

*-network
description: Ethernet interface
product: 82579LM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: em1
version: 04
serial: f8:b1:56:a4:e2:06
size: 100Mbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp
10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=2.1.4-k duplex=full firmware=0.13-4 ip=192.168.1.175
latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
resources: irq:43 memory:f7c00000-f7c1ffff
memory:f7c38000-f7c38fff ioport:f060(size=32)

ethtool em1

Settings for em1:
Supported ports: [ TP ]
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: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes

The “bad” one:

lspci -nnk |grep Ethernet -A3

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit
Network Connection [8086:1502] (rev 04)
Subsystem: Dell Device [1028:052c]
Kernel driver in use: e1000e
Kernel modules: e1000e

lshw -class network

*-network
description: Ethernet interface
product: 82579LM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: em1
version: 04
serial: f8:b1:56:a5:72:58
size: 100Mbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp
10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=2.1.4-k duplex=full firmware=0.13-4 ip=192.168.1.176
latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
resources: irq:42 memory:f7c00000-f7c1ffff
memory:f7c38000-f7c38fff ioport:f060(size=32)

ethtool em1

Settings for em1:
Supported ports: [ TP ]
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: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes

Looks very much the same to me. Dell is known for small but annoying
variations in their hardware within one series of Desktop systems, but
at least the NIC and it’s firmware should be the same.
I agree that it is most likely a BIOS bug. But then I might have a hard
time convincing DELL to fix this for me. Actually they do not seem to
care about SLED. At least a quick search in the YES certification data
base does not show any results. But I’m still willing to take another try.

Günther

8

Hi
If you disconnect the ethernet cable from a system not shutting down, then try a shutdown, does it still reboot? Are the systems connected to a managed switch?

9

Given you say that disabling WOL in the BIOS fixes the problem, I’m wondering it specifying WOL state before shutdown might help. E.g.

$ ethtool -s em1 wol g

though you have it set to g already, so maybe disable then change it back

$ ethtool -s em1 wol d $ ethtool -s em1 wol g
I can’t cite anything that says that might work, it’s just a hunch, but it’s quick and easy to try.

10

malcolmlewis wrote:
[color=blue]

If you disconnect the ethernet cable from a system not shutting down,
then try a shutdown, does it still reboot? Are the systems connected to
a managed switch?[/color]

The systems are attached to a not so recent model from Cisco. I do not
have the exact type at hand. But then the switch and the network
environment are probably not to blame as the system reboots with the
cable disconnected also :frowning:

This starts to remind on this legendary and extremely long thread on the
SUSE powermanagement support pages many years ago. The poor guy finally
managed to get his notebook in suspend mode and got a medal of honour
for not giving up :slight_smile:
Hopefully it will not take me that long to find a solution to my problem.

Günther

11

mikewillis wrote:[color=blue]

Given you say that disabling WOL in the BIOS fixes the problem, I’m
wondering it specifying WOL state before shutdown might help. E.g.

Code:

 $ ethtool -s em1 wol g

though you have it set to g already, so maybe disable then change it
back

Code:

 $ ethtool -s em1 wol d

$ ethtool -s em1 wol g

I can’t cite anything that says that might work, it’s just a hunch, but
it’s quick and easy to try.[/color]

Sorry, also this does not work. Is it OK that this setting is not
persistent through a reboot?

Günther

12

If you specify WOL state with ethtool it is expected behaviour that it won’t persist after a reboot. The output from ethtool you posted before indicated that the wol settings was already set to g though, the same as I advised to try setting it to, so I’m a little curious as to what it it is that’s caused you to ask about the setting not persisting across a reboot.

There’s various ways of automatically running ethtool to set the desired state, see the cron and udev methods at:
https://wiki.archlinux.org/index.php/Wake-on-LAN
You could also put the ethool command in boot.local or halt.local. There’s something in that page about the reboot instead of shutdown problem that you could try.

13

mikewillis wrote:[color=blue]

=?UTF-8?B?R8O8bnRoZXIgU2Nod2Fyeg==?=;20263 Wrote:[color=green]

Sorry, also this does not work. Is it OK that this setting is not
persistent through a reboot?
[/color]

If you specify WOL state with ethtool it is expected behaviour that it
won’t persist after a reboot. The output from ethtool you posted before
indicated that the wol settings was already set to g though, the same as
I advised to try setting it to, so I’m a little curious as to what it it
is that’s caused you to ask about the setting not persisting across a
reboot.[/color]

Just to test I did set it to “d” and then, after a reboot, it was back
to “g”. So it is as you explained and as expected.

Günther

14

Günther Schwarz wrote:
[color=blue]

I agree that it is most likely a BIOS bug.[/color]

Just as another test I did a factory reset of the BIOS. Just with
factory settings except ATA instead of AHCI (system was originally
installed with ATA and won’t find it’s LVM2 partitions in AHCI mode) the
machine stays off.
As soon as I enable WOL the system reboots. Further changes I did to the
BIOS do not change this. As I do depend on WOL for maintenance and
configuration management I’m stuck here.

Have a nice weekend.

Günther

15

A few other ideas:

Perhaps SUSE can help.the way to find out is log a Service Request, assuming you can, https://www.suse.com/support/

Install openSUSE 13.1. If the issue doesn’t occur live in hope it won’t occur with SLED 12. (Don’t know release date, but it’s currently going through Beta testing.)

Disable onboard network card. Fit a PCI network card.

16

mikewillis wrote:[color=blue]

A few other ideas:

Perhaps SUSE can help.the way to find out is log a Service Request,
assuming you can, https://www.suse.com/support/

Install openSUSE 13.1. If the issue doesn’t occur live in hope it won’t
occur with SLED 12. (Don’t know release date, but it’s currently going
through Beta testing.)

Disable onboard network card. Fit a PCI network card.[/color]

Thank you very much for these additional suggestions. Buying new NICs
might be just hardly justified by the savings on the electricity bill
considering how low the actual idle power consumption is with today’s
desktop hardware. For the time being the systems do a nightly reboot
instead of a shutdown.
The problem will go so SUSE as well as to Dell. I will come back with
the solution they will hopefully provide.
Thank you and Malcom very much again for their help and suggestions.

Günther

17

We have a lab full of Dells (of various vintages now) and the most recent ones (7010s onwards) are displaying the same behaviour. WOL is enabled, and on a linux poweroff, they do power off, then reboot.

Some extra data though. These systems are dual-boot windows/linux (ok we’re running centos 6.5, but the kernel will be the same) and the windows poweroff does not display the same behaviour - it works. So if it is a Dell bug, then it is one Windows 7 isn’t triggering with exactly the same BIOS settings where the linux kernel does.

I’ll watch this thread with interest. My tradeoff (autopoweron in the mornings when it matters, vs manual shutdown via button in the evening) is similar to Gunther’s

John

18

Hi
What are the ‘C States Control’ and ‘AC Recovery’ settings in the BIOS?

19

js138 wrote:
[color=blue]

Some extra data though. These systems are dual-boot windows/linux (ok
we’re running centos 6.5, but the kernel will be the same) and the
windows poweroff does not display the same behaviour - it works. So if
it is a Dell bug, then it is one Windows 7 isn’t triggering with exactly
the same BIOS settings where the linux kernel does.[/color]

Of course, as all tests are done with Windows and the BIOS is tweaked
and adjusted to this OS. This is a very old story, especially with
Notebooks.
In the meantime I did contact Dell. They told me that they are not aware
of the problem and they do not have a more recent version of the BIOS at
hand. One suggestion was to try an older version. I did not find time
yet to test this.

Günther

20

malcolmlewis wrote:
[color=blue]

What are the ‘C States Control’ and ‘AC Recovery’ settings in the BIOS?[/color]

This will get very specific for Dell, as names in BIOS are vender
specific. For me on the Optiplex 7010, “Deep Sleep” is disabled as it
powers off the NIC and thus breaks WOL while “Block Sleep” ist not allowed.
AC recovery is set to “off” as starting all PCs at once after a blackout
might trigger a fuse.
I did spent quit some time with these settings, and changing them will
not result in a proper shutdown IME.
This morning about half of the machines were powered off. So the mystery
remains why some installations work as others just reboot.

Günther