Arch Linux

Same here with my Thinkpad X240. The problem is present since Kernel 4.17. It's not reproducable on the LTS-Kernel 4.14.

Please try linux 4.17.4-1 currently in testing. Does that make any difference?

I may confirm that:
4.14-LTS works fine with no problem,
4.17.4-1 is still affected.

I have the same issue with my ThinkPad W530,
4.17.5-1 is still affected

https://bbs.archlinux.org/viewtopic.php?pid=1797473

Same here on hardware: Asus Rog G750JH with Nvidia 780M
4.17.2-1-ARCH

Same on my Toshiba Tecra laptop, which does NOT have an NVIDIA card.

Kernel: 4.17.5-1-ARCH
Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)

First suspend after a reboot works, after that, any type of suspend, reboot or shutdown triggers a kernel panic. It happens so late in the process that I can't find any logs, I think the journal has already been shut down before the panic happens.

I think @twelveeighty is right.

I tried to turn off (instead of suspend this time) and in fact there is a kernel panic.
I took two photos of the screen.

Try 4.18-rc6 or try bisecting between 4.16 and 4.17 or report the bug to the kernel mailing list.

Similar issue (but not sure if the first suspend always worked for me). If I suspend my laptop in text console there is a stack trace pointing to Intel Management Engine Interface mei_* functions. mei_cl_all_disconnect, mei_reset, mei_stop, pci_device_shutdown to be precise.

Dell Latitude E7440, some old BIOS. No Nvidia hardware.
Not reproducible on LTS 4.14 kernel.

I'm also affected on my Lenovo ThinkPad X230 running 4.17.13.arch1-1.

I also feel the severity is too low: This bug makes my laptop unusable for its intended use case.
Having proper suspend should not be considered an "optional-feature".

@JayFoxRox even if the severity was set to critical no action will occur because of this bug report.
It is not a packaging or integration issue so you are expected to work with upstream to resolve it.
Once you have a patch from upstream the kernel package maintainers could apply it.

I'm on a Dell XPS 15 here, system is hanging on second shutdown, fan is powering up, thats it.
However, due to path changes in the 4.17 kernels I tried, I started up without bbswitch running and it worked fine.

So I investigated and apparently, when I enable my discrete GPU first with bbswitch, the suspend is working.
Also it seems to be safe to turn it off again until the next suspend.

This still appears to be the only place where this is mentioned, couldn't find anything upstream.
Could someone else affected try suspending with enabled discrete GPU and report?

Edit: Appears to be a litte more specific. I tried to automate that workaround, but enabling the GPU via systemd-unit right before sleep.target does not prevent the system from hanging on the second suspend!
Will investigate further, trying delays between enabling and suspending. Also I have to finally figure out the last working kernel.

Anything anywhere upstream yet?

Edit#2:
Okay, now, for me at least, that the discrete graphics can be turned on exactly once. Maybe I broke my notebook, looping through ON/OFF in bbswitch worked yesterday.
The card is turned on by bbswitch on suspend, as apparently, there are devices that don't like being suspended/powered off with the card disabled or can't use them after such an event.

Anyway, without bbswitch module loaded on suspend, it works. I don't know if the discrete card is usable though and this isn't a solution.

It's also clearly not a direct bbswitch fault: When I suspended first and removed bbswitch module after resuming, I "used up" my one enabling. When shutting down after that, the kernel also tries to enable the card very late in the halt routine, but it still fails. Luckily, kernel doesn't care for suspend here.

The consistend log line is:
> pci 0000:01:00.0: Refused to change power state, currently in D3

Possibly related: https://bbs.archlinux.org/viewtopic.php?id=238389

Kernel 4.18.3 still has the same problem (after a suspend, any type of poweroff, reboot or suspend crashes) for me on my Toshiba Tecra. Is this fixed for you Thinkpad guys on the latest kernel, by chance?

We'll need to work with upstream on getting this resolved, I'm sure, but if the problem goes away for some of us, that would be important to know.

Edit: kernel 4, not 14
Edit2: damnit, Thinkpad, not Dell.

I still have the issue on my X230, running 4.18.3.arch1-1.
I'm updating to linux-4.18.4.arch1-1 now (latest at time of writing), but I don't expect any changes.

I tested (4.18.5-arch1-1-ARCH) for 2 days, it works perfect for me.

Asus Rog G750JH with Nvidia 780M

I can *not* confirm what rodstu said.

I'm on "Linux x230 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 UTC 2018 x86_64 GNU/Linux" now.
The *problem persists*: First suspend after boot works fine. Suspending again will cause immediate wakeup.

Had the same problem with 4.18.5 but with 4.19.0-rc1 (self compiled as well as the binary from miffe repo) the problem is solved for me (Fujitsu AH532).

I'm on "Linux x230 4.18.7-arch1-1-ARCH #1 SMP PREEMPT Sun Sep 9 11:27:58 UTC 2018 x86_64 GNU/Linux" now.

The regression appears to be fixed.
Suspend seems to work fine again.

I believe I still had a couple of hangs when returning from suspend a couple of days ago, but that would probably be another issue.
I'm not sure which update fixed it for me, but it must have been 4.18.6 or 4.18.7.