Bug 848889

gnome sends a PowerOff dbus signal to systemd (or Reboot if that was chosen)

        g_dbus_proxy_call (systemd->priv->sd_proxy,
                           restart ? "Reboot" : "PowerOff",
                           g_variant_new ("(b)", TRUE),
                           0,
                           G_MAXINT,
                           NULL,
                           reboot_or_poweroff_done,
                           systemd);

I'd say a good starting point would be journalctl, checking if anything did not cleanly shutdown.

NOT gnome. The fact that it says GNOME in the subject does not indicate it being a GNOME bug.

Please install the package laptop-mode-tools and report if this does help

A friend of mine was experiencing this problem on her ThinkPad T430 with 13.1, after installing laptop-mode-tools the problem was gone.

@ Wolfgang:  Does this also help in your case?

Apparently yes, I haven't seen the issue since I installed the package. I do not shut down that often but it's most likely fixed for me.

*** Bug 853116 has been marked as a duplicate of this bug. ***

Change Carbon Copy list to help to find the last duplicate

Yast installs "Laptop" pattern (which contains the laptop-mode-tools package) when a laptop is detected.

What does "hwinfo --sys" command print? Esp. the "Formfactor" is interesting.
Is the laptop pattern installed? ("zypper se -t pattern laptop")

I found out that laptop-mode-tools package is not recommended, only suggested in that pattern. That means installing "Laptop" pattern does not install laptop-mode-tools by default. I have no idea why it is not in default...


Anyway, please attach the "hwinfo --sys" and "zypper se -t pattern laptop" output and we will see how to proceed..

S | Name   | Zusammenfassung | Typ   
--+--------+-----------------+-------
i | laptop | Laptop          | Schema


ox:~ # hwinfo --sys
02: None 00.0: 10107 System                                     
  [Created at sys.63]
  Unique ID: rdCR.n_7QNeEnh23
  Hardware Class: system
  Model: "System"
  Formfactor: "laptop"
  Driver Info #0:
    Driver Status: thermal,fan are not active
    Driver Activation Cmd: "modprobe thermal; modprobe fan"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

The other problem is that I at least had the issue once again after laptop-mode-tools was installed.
Was is actually needed? Just the installation or does the service need to be enabled?
ox:~ # systemctl status laptop-mode
laptop-mode.service - Laptop Mode Tools
   Loaded: loaded (/usr/lib/systemd/system/laptop-mode.service; disabled)
   Active: inactive (dead)

(In reply to comment #12)

> Was is actually needed? Just the installation or does the service need to be
> enabled?

This is a good question. Fact is that with the package a udev rules gets installed.  This works without enabling the service its self if the appropiate event from the kernel triggers the rule. And this at least executes /usr/sbin/laptop_mode

(In reply to comment #12)
> S | Name   | Zusammenfassung | Typ   
> --+--------+-----------------+-------
> i | laptop | Laptop          | Schema

Ok, the pattern got installed...
 
> ox:~ # hwinfo --sys
>   Formfactor: "laptop"

... and a laptop was detected properly.

So from the Yast POV it is OK.


> The other problem is that I at least had the issue once again after
> laptop-mode-tools was installed.

So it seems it could be caused by something else.

> Was is actually needed? Just the installation or does the service need to be
> enabled?

No idea, I'm not a laptop expert nor laptop-mode-tools maintainer.

I'm resetting the assignee to the default, this is not a Yast bug and I do not know who could fix it.

(In reply to comment #11)
> [...]
> I found out that laptop-mode-tools package is not recommended, only suggested
> in that pattern. That means installing "Laptop" pattern does not install
> laptop-mode-tools by default. I have no idea why it is not in default...
> [...]

laptop-mode-tools do not seem to be useful for modern laptops, i.e., Ivy Bridge or later. The kernel already does a conservative but pretty good powersaving job there, thus, I would not recommend using laptop-mode-tools!
And many laptop-mode-tools modules simply do nothing because they use proc/sys files that do not exist anymore. And there is neither eth0 nor HAL anymore. And I do not have an ondemand scaling governor anymore.

Using a T430s, it seems to be sufficient to only set CONTROL_RUNTIME_PM=1 in /etc/laptop-mode/conf.d/runtime-pm.conf and to disable most things else in /etc/laptop-mode/laptop-mode.conf by setting ENABLE_AUTO_MODULES=0, CONTROL_READAHEAD=0, CONTROL_NOATIME=0, CONTROL_HD_POWERMGMT="0", and CONTROL_MOUNT_OPTIONS=0.

I am performing a binary search for the PCI devices that need power/control set to "auto". For now, I ignore the SPI devices since there are no such devices here and I ignore i2c devices because they are "auto" per default.

BTW, while trying to figure out how to work around without the full laptop-mode-tools suite, I noticed that the reboot only happens when I have done a suspend once before shutting down. Just booting and then shutting down works.

(In reply to comment #17)
> BTW, while trying to figure out how to work around without the full
> laptop-mode-tools suite, I noticed that the reboot only happens when I have
> done a suspend once before shutting down. Just booting and then shutting down
> works.

Just for the record, the above was not the case for me (X230) nor my friend (T430), in our cases the machine would practically always reboot instead of shut down. Interestingly it would sort of "appear" to shut down, but then just proceed to boot back up (Really frustrating when you had already closed the laptop and put it in your backpack, only to find it low on power hours later).

My binary search result:
echo "auto" > /sys/bus/pci/devices/0000:00:19.0/power/control
This device is my (unused) on-board ethernet controller: 
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
Them, the T430s did shutdown correctly the last four times. Without laptop-mode-tools.

Can anyone confirm this?

@Troels: Maybe it was just a coincidence. And it is even worse if your laptop shuts down automatically because your battery is low and then reboots instead. :)

(In reply to comment #19)
> My binary search result:
> echo "auto" > /sys/bus/pci/devices/0000:00:19.0/power/control
> This device is my (unused) on-board ethernet controller: 
> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
> Connection (rev 04)
> Them, the T430s did shutdown correctly the last four times. Without
> laptop-mode-tools.
> 
> Can anyone confirm this?
> 
> @Troels: Maybe it was just a coincidence. And it is even worse if your laptop
> shuts down automatically because your battery is low and then reboots instead.
> :)

As I said, it was the case for both my friend and I, she has a T430, I have an X230. You know what Goldfinger said: First time happenstance, second time coincidence, third time enemy action. :P

@Troels: I meant that my observation was a coincidence for me. ;) However, since laptop-mode-tools work for you, could you try to remove them, reboot, and only set power/control of your ethernet controller to "auto" before shutting down? I assume that all of us (X1, X230, T430, T430s) have the same controller: Intel 82579LM

@Wolfgang @Troels: Does shutting down the laptop work with 13.2?

(In reply to Jan Ritzerfeld from comment #23)
> @Wolfgang @Troels: Does shutting down the laptop work with 13.2?

Yes, I have not had this issue with 13.2 on my X230. :-)

However, one note, I have yet to try 13.2 on my friend's T430, so I can only speak about my X230. I should be able to find out for the T430 in about a month or so. I will report my result when I do.

(In reply to Jan Ritzerfeld from comment #23)
> @Wolfgang @Troels: Does shutting down the laptop work with 13.2?

I can now confirm that openSUSE 13.2 does not exhibit the shutdown issues on my friend's ThinkPad T430. :-) Nor does it do so on my X230 as I mentioend earlier.

So as far as I am concerned, this bug was resolved by 13.2.

I might also add, that 13.2 generally works a heck of a lot better than 13.1, I also had various weird shutdown issues with 13.1 on my desktop computer, but none of those happen with 13.2. So 13.2 is just all-round a lot more robust, it would appear, than 13.1. :-) Good job on 13.2, guys!

(In reply to Jan Ritzerfeld from comment #23)
> @Wolfgang @Troels: Does shutting down the laptop work with 13.2?

Error definitely persists with SUSE 13.2

Hi Kernel-maintainers, would you please kindly help to have a look at here? Thank you!

(In reply to Thorsten Staerk from comment #26)
> (In reply to Jan Ritzerfeld from comment #23)
> > @Wolfgang @Troels: Does shutting down the laptop work with 13.2?
> 
> Error definitely persists with SUSE 13.2

Which laptop model?  The issue is very much specific to the hardware, so just "me too" doesn't help, unfortunately.  If you have other than Lenovo machines, open another bug report.

Did you install laptop-mode-tools?  Or the situation changes if you uninstall it?

The spurious wakeup symptom comes often from the wrong XHCI wakeup or Ethernet WoL.  Try to disable such an item in BIOS if you can find.

As I do not have a Lenovo laptop it's okay from my side if you close this bug.

Hi Takashi, would you please help to have a look at this issue? Thank you.

The issue seems no longer reproducible with Lenovo machines with 13.2.  Let's close.