Bug 1519940 - Suspend/resume stopped working between 4.15.0-0.rc0.git7.2 and 4.15.0-0.rc1.git1.1 (on Lenovo T460p)
Summary: Suspend/resume stopped working between 4.15.0-0.rc0.git7.2 and 4.15.0-0.rc1.g...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-01 18:17 UTC by Jan Pokorný [poki]
Modified: 2017-12-13 13:29 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 19:00:37 UTC


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2017-12-01 18:17:27 UTC
The symptom is that system never comes back from suspend (indicated with
blinking LEDs per expectation), whatever I try (closing and reopening
the lid, etc., un-/plugging AC adapter, pressing the main switch and
whatever keys and functional key combos).

The difference I can observe in the journal around the event of
suspending:

- bad case (4.15.0-0.rc1.git1.1)
> Dec 01 18:46:32 betenoire systemd-logind[991]: Lid closed.
> Dec 01 18:46:32 betenoire systemd-logind[991]: Suspending...
> [...]
> Dec 01 18:46:32 betenoire systemd[1]: Reached target Sleep.
> Dec 01 18:46:32 betenoire systemd[1]: Starting Suspend...
> Dec 01 18:46:32 betenoire systemd-sleep[1308]: Suspending system...
> Dec 01 18:46:32 betenoire kernel: PM: suspend entry (deep)
[ nothing from here on, was unable to make the machine resume,
  had to power off by force with a long power switch button press ]

- happy case (4.15.0-0.rc0.git7.2)
> Dec 01 18:49:00 betenoire systemd-logind[1004]: Lid closed.
> Dec 01 18:49:00 betenoire systemd-logind[1004]: Suspending...
> [...]
> Dec 01 18:49:00 betenoire systemd[1]: Reached target Sleep.
> Dec 01 18:49:00 betenoire systemd[1]: Starting Suspend...
> Dec 01 18:49:00 betenoire systemd-sleep[1347]: Suspending system...
> Dec 01 18:49:00 betenoire kernel: PM: suspend entry (deep)
> Dec 01 18:49:00 betenoire kernel: PM: Syncing filesystems ... done.
[ gap until the system was successfully resumed again ]

For the record, I am using legacy BIOS to boot.

Comment 1 Jan Pokorný [poki] 2017-12-01 19:06:08 UTC
Looking briefly into the 0c86a6bd85ff...43570f0383d delta, there are
some vague hits, amongst others those related to drm/i915:

https://patchwork.freedesktop.org/series/33609/
https://patchwork.freedesktop.org/series/32274/

Hans, do you think these might be related?
This laptop indeed uses i915 driver/module to service
Intel Corporation HD Graphics 530 (rev 06).

Comment 2 Jan Pokorný [poki] 2017-12-03 08:24:09 UTC
Not going away with 4.15.0-0.rc1.git3.1.fc28.x86_64.

Comment 3 Laura Abbott 2017-12-04 22:55:14 UTC
https://marc.info/?l=linux-kernel&m=151242635416764 Looks like there are systemwide suspsend issues

Comment 4 Laura Abbott 2017-12-05 00:11:41 UTC
https://lkml.org/lkml/2017/11/30/546 this was reported to fix the issue and Linus picked it up. I'll double check this is in the next rawhide build.

Comment 5 Jan Pokorný [poki] 2017-12-05 01:49:01 UTC
Thanks, Laura, for the guidance, the patch indeed
works for me (from [comment 3], on top of 4.15.0-0.rc2.git0.1).

(83 minutes 9 second for an rpmbuild on that machine, also observing
things like bad parameter quoting of shell scripts amongst the produced
lines:
./arch/ia64/scripts/check-gas: line 11: [: !=: unary operator expected)

Comment 6 Jan Pokorný [poki] 2017-12-08 13:14:54 UTC
For the record, why having this issue fixed is important for me
is that there was a "genious" idea to hardwire Fn+4 combo to instant
suspend at least for some Lenovo machines.  With my common shortcuts,
it sometimes happens to be pressed, though that's easy to recover
from unless a show stopper, as was this one, comes to play.

Comment 7 Jan Pokorný [poki] 2017-12-12 13:25:25 UTC
Confirming kernel-4.15.0-0.rc2.git2.1.fc28.x86_64 works for me
(not sure if accidentally or not).

Comment 8 Laura Abbott 2017-12-12 19:00:37 UTC
Yes, I picked up the patch mentioned in the thread so it was expected. Going to mark this as resolved.

Comment 9 Jan Pokorný [poki] 2017-12-13 13:29:52 UTC
I was unsure because this bug wasn't marked in the changelog, although
I can see that might be a maintenance hell to have every bug tracked
with a fine granularity in the "component" of this size.

Cross-checking the records, mentioned version 4.15.0-0.rc2.git2.1 aka
v4.15-rc2-252-g968edbd93c0c should be, moreover, the very first release
fixing this bug.


Note You need to log in before you can comment on or make changes to this bug.