Andrey Borzenkov wrote:

В Сб, 04/01/2014 в 12:15 +0100, Per Jessen пишет:

...

I have a Toshiba Satellite with openSUSE 12.3 - the automatic suspend/resume when I close and open the lid have been working fine until fairly recently after an update. I can't say which update it was though. Where should I begin to look?

And what does not work - it ignores lid close event or it tries to suspend but fails?

As far as I can tell, it ignores the lid event. -- Per Jessen, Zürich (5.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 4. Januar 2014, 13:34:18 schrieb Per Jessen:

[...] I need the newer kernel as it fixed bug#814510 (icmp redirect being ignored).

I remember. However, if the old kernel works, you know which update caused the problem and could take a deeper look at the patchinfo. Gruß Jan -- Think twice before speaking, but don't say "think think click click". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Сб, 04/01/2014 в 13:34 +0100, Per Jessen пишет:

...

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 12:15:30 schrieb Per Jessen:

...

I have a Toshiba Satellite with openSUSE 12.3 - the automatic suspend/resume when I close and open the lid have been working fine until fairly recently after an update. I can't say which update it was though. Where should I begin to look?

There was a kernel update:

https://build.opensuse.org/patchinfo/show/openSUSE:Maintenance:2034/patchinf...

...

...

Maybe the old kernel is still installed (multiversion) so that you could simply access it from the grub menu.

I need the newer kernel as it fixed bug#814510 (icmp redirect being ignored).

Yes, but this will allow testing whether problem is kernel related.

Thanks Jan and Andrey - I'll look into that, I've got at least 2 kernel versions. -- Per Jessen, Zürich (5.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 4. Januar 2014, 14:36:51 schrieb Per Jessen:

[...] In fact only 2 versions. I tried using 3.7.10-1.16, but this had no effect, it still doesn't auto-suspend/resume. 3.7.10-1.16 is dated October 2013, I'm pretty certain this problem appeared later.

Okay. You could try "rpm -qa --last | o" to narrow down the search for the problematic update by installation time. I do not see any interesting 12.3 updates in the last weeks from openSUSE. Do you use the proprietary Nvidia driver? Here are some bugs but most of them are quite old: https://bugzilla.novell.com/show_bug.cgi?id=809511 https://bugzilla.novell.com/show_bug.cgi?id=838979 https://bugzilla.novell.com/show_bug.cgi?id=808542 Besides, since 12.3 systemd-logind handles the lid switch. Please check whether acpid is installed because it will conflict with logind. And check /etc/systemd/logind.conf for any non-commented, active lines. What does "journalctl -u systemd-logind" say after you closed the lid (and opened it again)? Gruß Jan -- Tolerances will accumulate uni-directionally toward maximum difficultly to assemble. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Сб, 04/01/2014 в 17:22 +0100, Per Jessen пишет:

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 14:36:51 schrieb Per Jessen:

...

[...] In fact only 2 versions. I tried using 3.7.10-1.16, but this had no effect, it still doesn't auto-suspend/resume. 3.7.10-1.16 is dated October 2013, I'm pretty certain this problem appeared later.

Okay. You could try "rpm -qa --last | o" to narrow down the search for the problematic update by installation time. I do not see any interesting 12.3 updates in the last weeks from openSUSE. Do you use the proprietary Nvidia driver?

Nope, it's Intel graphics.

...

Besides, since 12.3 systemd-logind handles the lid switch. Please check whether acpid is installed because it will conflict with logind.

Yes, acpid _is_ installed and running.

...

And check /etc/systemd/logind.conf for any non-commented, active lines.

There is only the section header "[Login]".

...

What does "journalctl -u systemd-logind" say after you closed the lid (and opened it again)?

This is almost certainly me logging in, then closing the lid, then opening:

Jan 04 15:11:06 toshiba1 systemd-logind[669]: New session 12 of user per. Jan 04 15:11:06 toshiba1 systemd-logind[669]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.

What is missing is my closing the lid again ... (and the machine wasn't suspended either). It looks like logind ceases to detect the lid change?

Do you see lid close event in acpid logs? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 4. Januar 2014, 17:22:11 schrieb Per Jessen:

Jan Ritzerfeld wrote: [...]. Nope, it's Intel graphics.

Okay.

[...]. Yes, acpid _is_ installed and running.

It should not and it will not installed as default on 12.3: https://github.com/openSUSE/patterns/pull/12

...

And check /etc/systemd/logind.conf for any non-commented, active lines.

There is only the section header "[Login]".

Okay.

[...]. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.

What is missing is my closing the lid again ... (and the machine wasn't suspended either).

But the lid close is detected and logind tries to suspend. That is good! So: 1. Is the suspend attempt above recorded in /var/log/pm-suspend.log? Date and time of the attempt are printed in the second line. Are there any errors in this log? 2. Does "systemctl suspend" work? 3. Does "pm-suspend" work? 4. Does a suspend from KDE (or any other Desktop) work?

It looks like logind ceases to detect the lid change?

Well, since the suspend before does not work at all, I would ignore anything suspicious until the suspend works.

I tried stopping acpid too, no noticable effect on the functionality.

I would remove it and check again after a reboot because "[...]installing both will lead to funny behaviour.": https://bugzilla.novell.com/show_bug.cgi?id=805304#c2 Gruß Jan -- The government that governs least governs best. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Сб, 04/01/2014 в 19:21 +0100, Per Jessen пишет:

...

...

[...]. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.

What is missing is my closing the lid again ... (and the machine wasn't suspended either).

But the lid close is detected and logind tries to suspend. That is good!

Except it only happens once.

systemd-logind gets events directly from input device corresponding to LID switch. Here it is P: /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input4 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input4 E: EV=21 E: ID_FOR_SEAT=input-acpi-PNP0C0D_00 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0, E: NAME="Lid Switch" E: PHYS="PNP0C0D/button/input0" E: PRODUCT=19/0/5/0 E: PROP=0 E: SUBSYSTEM=input E: SW=1 E: TAGS=:seat: E: USEC_INITIALIZED=139610 And systemd-l 30202 root 13u CHR 13,71 0t0 5897 /dev/input/event7 systemd-l 30202 root 20u CHR 13,69 0t0 5886 /dev/input/event5 systemd-l 30202 root 21u CHR 13,68 0t0 5885 /dev/input/event4 systemd-l 30202 root 22u CHR 13,70 0t0 5887 /dev/input/event6 If systemd-logind does not log Lid close/open event anymore this would mean that either kernel stops delivering it or for whatever reasons device changed in between, so logind continues to listen on "dead" device. Both imply some kernel issue. I had once funny case of "On Battery" information being wrong after resume because kernel incorrectly restored memory used to store this bit ... Try running "upower --monitor-detail" across suspend. It takes events from the same source so it would be interesting whether it stops seeing Lid close at the same time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Вс, 05/01/2014 в 10:46 +0100, Per Jessen пишет:

Andrey Borzenkov wrote:

...

If systemd-logind does not log Lid close/open event anymore this would mean that either kernel stops delivering it or for whatever reasons device changed in between, so logind continues to listen on "dead" device. Both imply some kernel issue. I had once funny case of "On Battery" information being wrong after resume because kernel incorrectly restored memory used to store this bit ...

Try running "upower --monitor-detail" across suspend. It takes events from the same source so it would be interesting whether it stops seeing Lid close at the same time.

I tried this a couple of times - upower appears to log a "device changed" message for /org/freedesktop/UPower/devices/battery_BAT1 about every 30 seconds. No messages about the lid being closed or opened.

Well, this makes it kernel issue. Kernel does not deliver event. Here is what I get Monitoring activity from the power daemon. Press Ctrl+C to cancel. [14:43:16.709] daemon changed: daemon-version: 0.9.23 can-suspend: yes can-hibernate: no on-battery: no on-low-battery: no lid-is-closed: yes lid-is-present: yes is-docked: no [14:43:44.733] daemon changed: daemon-version: 0.9.23 can-suspend: yes can-hibernate: no on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no This is on 13.1, but I do not expect much changes in this respect. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 4. Januar 2014, 19:21:22 schrieb Per Jessen:

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 17:22:11 schrieb Per Jessen:

...

Jan Ritzerfeld wrote: [...]. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.

What is missing is my closing the lid again ... (and the machine wasn't suspended either).

But the lid close is detected and logind tries to suspend. That is good!

Except it only happens once.

So, do I understand correctly that the suspend does never work when closing the lid? Even the very first time when the lid close is detected?

...

So: 1. Is the suspend attempt above recorded in /var/log/pm-suspend.log? Date and time of the attempt are printed in the second line. Are there any errors in this log?

Yes, that attempt is recorded, and I don't see any errors.

...

2. Does "systemctl suspend" work?

Yes, works fine. [...].

Are there any differences in /var/log/pm-suspend.log between the working suspends and the failing one?

[...].

...

I would remove it and check again after a reboot because "[...]installing both will lead to funny behaviour.": https://bugzilla.novell.com/show_bug.cgi?id=805304#c2

Okay, I'll do that.

Although it did not help: If you eventually have to file a bug report, they will ask you to remove it anyway. ;) Gruß Jan -- You can't antagonize and influence at the same time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Вс, 05/01/2014 в 17:06 +0100, Per Jessen пишет:

There isn't really a failing suspend, the suspend simply doesn't happen. The automatic resume doesn't happen either.

Did you consider broken lid switch? I had it at least once. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Andrey Borzenkov wrote:

...

В Вс, 05/01/2014 в 17:06 +0100, Per Jessen пишет:

...

There isn't really a failing suspend, the suspend simply doesn't happen. The automatic resume doesn't happen either.

Did you consider broken lid switch? I had it at least once.

Good question, I guess I can't exclude the possiblity.

Unless it's built into the screen hinges, AFAICT, it's not a mechanical switch. I expect some sort of optical sensor perhaps. I am wondering how I could verify the lid switch - how about if I boot Knoppix (the openSUSE Live image doesn't fit on a CD) or some such and check the relevant logs when opening/closing the lid? -- Per Jessen, Zürich (4.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Jan 15, 2014 at 11:03 AM, Per Jessen wrote:

Per Jessen wrote:

...

Per Jessen wrote:

...

Andrey Borzenkov wrote:

...

В Вс, 05/01/2014 в 17:06 +0100, Per Jessen пишет:

...

There isn't really a failing suspend, the suspend simply doesn't happen. The automatic resume doesn't happen either.

Did you consider broken lid switch? I had it at least once.

Good question, I guess I can't exclude the possiblity.

Unless it's built into the screen hinges, AFAICT, it's not a mechanical switch. I expect some sort of optical sensor perhaps. I am wondering how I could verify the lid switch - how about if I boot Knoppix (the openSUSE Live image doesn't fit on a CD) or some such and check the relevant logs when opening/closing the lid?

Okay, I booted from openSUSE-KDE-Live-13.1 - the first time I closed the lid, it worked, when I opened it, it also resumed, but the second time it stopped working.

Did you try to completely power off notebook (I'd even remove battery) and boot normal installed system to check whether it works first time after power cycle? It could be that kernel screws up something in ACPI settings first time it does suspend/resume cycle. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/01/14 03:06, Per Jessen wrote:

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 19:21:22 schrieb Per Jessen:

...

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 17:22:11 schrieb Per Jessen:

...

Jan Ritzerfeld wrote: [...]. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.

What is missing is my closing the lid again ... (and the machine wasn't suspended either). But the lid close is detected and logind tries to suspend. That is good! Except it only happens once. So, do I understand correctly that the suspend does never work when closing the lid? Even the very first time when the lid close is detected? That is certainly how it looked yesterday. Now however, it it doesn't seem to work at all.

...

...

...

So: 1. Is the suspend attempt above recorded in /var/log/pm-suspend.log? Date and time of the attempt are printed in the second line. Are there any errors in this log? Yes, that attempt is recorded, and I don't see any errors.

...

2. Does "systemctl suspend" work? Yes, works fine. [...]. Are there any differences in /var/log/pm-suspend.log between the working suspends and the failing one? There isn't really a failing suspend, the suspend simply doesn't happen. The automatic resume doesn't happen either.

I am coming in in the middle of this thread and do not know what has been said earlier, but the words "laptop" and "closing lid" and "won't suspend" got my attention. I have a ThinkPad and I had installed 13.1 several days ago (after getting rid of Windows and reformatting the HDD). The laptop will NOT *shut* down: the screen goes black but the cursor is still on the screen and the only way to switch off the laptop is to press/hold the on/off switch. The interesting part is that when I bought the laptop it had Windows 8 installed and I installed 13.1 - and 13.1 behaved perfectly. But then I wiped W8 and did a clean install of 13.1 and now the laptop will not shutdown. If it is of any help, I do have the latest stable kernel installed on the laptop (kernel 3.12.6.1) whereas previously I had the standard kernel (3.11.x which comes with 13.1) installed. BC -- Using openSUSE 13.1, KDE 4.12.0 & kernel 3.12.6-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 OC 2GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/01/14 01:43, Marco Calistri wrote:

Il 06/01/2014 05:30, Basil Chupin ha scritto:

...

On 06/01/14 03:06, Per Jessen wrote:

...

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 19:21:22 schrieb Per Jessen:

...

Jan Ritzerfeld wrote:

...

Am Samstag, 4. Januar 2014, 17:22:11 schrieb Per Jessen: > Jan Ritzerfeld wrote: [...]. > Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. > Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... > Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened. > > What is missing is my closing the lid again ... (and the machine > wasn't suspended either). But the lid close is detected and logind tries to suspend. That is good! Except it only happens once. So, do I understand correctly that the suspend does never work when closing the lid? Even the very first time when the lid close is detected? That is certainly how it looked yesterday. Now however, it it doesn't seem to work at all.

...

...

...

So: 1. Is the suspend attempt above recorded in /var/log/pm-suspend.log? Date and time of the attempt are printed in the second line. Are there any errors in this log? Yes, that attempt is recorded, and I don't see any errors.

...

2. Does "systemctl suspend" work? Yes, works fine. [...]. Are there any differences in /var/log/pm-suspend.log between the working suspends and the failing one? There isn't really a failing suspend, the suspend simply doesn't happen. The automatic resume doesn't happen either. I am coming in in the middle of this thread and do not know what has been said earlier, but the words "laptop" and "closing lid" and "won't suspend" got my attention.

I have a ThinkPad and I had installed 13.1 several days ago (after getting rid of Windows and reformatting the HDD).

The laptop will NOT *shut* down: the screen goes black but the cursor is still on the screen and the only way to switch off the laptop is to press/hold the on/off switch.

The interesting part is that when I bought the laptop it had Windows 8 installed and I installed 13.1 - and 13.1 behaved perfectly. But then I wiped W8 and did a clean install of 13.1 and now the laptop will not shutdown.

If it is of any help, I do have the latest stable kernel installed on the laptop (kernel 3.12.6.1) whereas previously I had the standard kernel (3.11.x which comes with 13.1) installed.

BC Hello,

I have a Lenovo Z470 laptop wherein I installed 13.1 64bits (I believe it is similar to ThinkPad line) and with this hardware the suspend on RAM/hibernate never worked automatically when battery reaches critical threshold since openSUSE-12.3. Simply the laptop shut-down in the middle of my works whenever battery goes below the minimal level and this is a very annoying behaviour.

Manual suspend/hibernate works but I would like the automatic feature!

Cheers,

I run my ThinkPad on AC power 99.9% of the time so the state of the battery doesn't come into it. BC -- Using openSUSE 13.1, KDE 4.12.0 & kernel 3.12.7-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 OC 2GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org