Regression in kernel 4.19.6 prevents my laptop to suspend

You could try blacklisting the modules but that's probably not enough.

Although I don't know what else you can do, I must applaud your perseverance :+1:

1 Like

Then lets hope that @philm has some more ideas, because I certainly don't know what else to try.

Maybe you could try with acpi_call (this link is just an example). I'm not sure if it will work though...

Unlikely, I would not even know how to get the correct parameters (the examples show only how to turn off discrete graphics cards). Switching off the device was just an idea to see if suspend works without it, but without easy method to test it and since I don't want to physically remove the module and don't want to omit the LTE module anyway, it would be more work than gain.

just an idea but maybe try stopping/disabling related systemd services and see if it changes the behavior and if it does then use create a systemd service to automatically disable on suspend and enable on wake similar to what you did with network manager?

1 Like

I brought this method up with the OP on the updates thread where this issue was first discussed. I don't know why this method has not been investigated by the OP, as there are many examples on the forum that this method works in many cases.

I have many other posts on this topic if you search the forum.

https://archived.forum.manjaro.org/t/kernel-4-19-0-3-not-network-after-suspending-gnome-edition/63544/2

https://archived.forum.manjaro.org/t/wifi-adapter-tp-link-tl-wn823n-must-be-reconnected-for-it-to-work/52968/19

https://archived.forum.manjaro.org/t/surface-pro-1796-wifi-not-resuming-after-suspend/48133/47

https://archived.forum.manjaro.org/t/thinkpad-x230t-wont-suspend-under-kernel-419rc4-4-18-4-17-4-14-4-9/59798/21

Here are some external links with excellent systemd reference material:

The ArchWiki - systemd

Red Hat - systemd-targets

Red Hat - systemd unit files

Systemd manpage

2 Likes

Because this issue is kernel related and does not have anything to do with anything else (like systemd or udev). I don't want to find a half-arsed workaround but a solution for the issue that is future proof and keeps the machine going also with future kernel upgrades.

There is just no doubt, it works with 4.19.5 but not with 4.19.6 with nothing else on the system changed, so it's a kernel issue, and not any of the many other suspend/resume problems others are experiencing. So why would I waste my time going through numerous totally unrelated suspend/resume issues?

I know you mean well, but this just isn't solvable following your recommendation.

Systemd runs your entire system these days. If you feel using a systemd service to solve a problem is a "half-arsed workaround" then basically that's what your saying every modern distribution that uses systemd is. I don't see why anyone would waste there time and effort helping you, when you simply dismiss out of hand a viable working solution because it's not good enough for you.

Have fun finding a solution that isn't a "half-arsed workaround". Let us know when you do.

1 Like

i see your point, while you may be able to work around it with systemd, you want to find the root cause which in the long run would be beneficial to you and others by not needing the workaround in the first place. good luck, hope it works out for ya

I'm sorry, but I really just see no logic in trying to fiddle around with systemd for trying to fix a kernel issue.

I have already proven that it is a kernel issue, I have done a fresh installation, applied the updates, swapped between kernel 4.19.5 und 4.19.6 with everything else staying the same including systemd, so this is 100% a kernel matter, not systemd or anything else related.

You are trying to dismiss my problem as some other totally unrelated suspend/resume issue, which just isn't the case here.

If it works with kernel 4.19.5 and doesn't with 4.19.6 while nothing else has changed, the only way is to track down the responsible regression in the kernel and/or its modules. Unfortunately I am not a developer and my knowledge is too limited to come up with the solution myself.

Last ideas from my side:

  1. disable XHCI in BIOS (if possible) and try again;
  2. compile a kernel without the commit (git --revert) you mentioned in your 1st post;
  3. report the problem directly upstream to the kernel devs.

If you had actually taken the time to read any of the links I posted you'd realize some of those cases were kernel regressions that were remedied (worked around) by a systemd service.

You seem to enjoy wandering through life with blinders on, so carry on bravely. I can't guarantee it will work in your case, but it certainly has worked for others to end their suspend issues.

1 Like

Well, as a temporary workaround the following is working:

  1. Use of kernel argument usbcore.quirks=12d1:15c3:m (which reverses the quirk applied by the quirks list and allows the laptop to actually reach suspend state)
  2. Use of echo XHC > /proc/acpi/wakeup to prevent immediate wakeup after suspend

However this does not really address the change in behavior from kernel 4.19.5 to 4.19.6, because the quirk is enabled by the quirks list in 4.19.5 as well and 4.19.5 did not have the immediate wakeup after suspend problem (which I have last experienced with 4.13 and 4.14 kernels).

The XHC disabling can be done by a systemd unit (I have used rc-local.service previously, but that one is obviously deprecated).

What's the most elegant way to reverse the application of the quirk?

I mean, adding the argument to the grub entry or is there another way?

@philm, you wanted to know more about my laptop, and I just discovered that it is the same as The Spitfire 2018 – 2nd Gen :slight_smile:

As said, the Clevo N13xWU is extremely common and can be found with many different names.

As you may know, it comes with its own Mini PCIe port for a modem module, because it already has a SIM card reader built-in. The Huawei ME906s-158 / HP lt4132 LTE module was the logical choice as an inexpensive fast solution (the HP lt4132 is the same module with branded firmware, thus is has a different vendorID and productID).

That module should be well supported I assumed, but obviously there are inconsistencies for both in usb_modeswitch and usbcore.quirks. Something the module does prevents kernels 4.13 / 4.14 / 4.19.6 from staying suspended (that's what disabling XHC in /proc/acpi/wakeup works around), which wasn't an issue with kernels 4.18 and up to 4.19.5.

With the usbcore.quirks having not changed between kernel 4.19.5 and 4.19.6 it makes no sense that I have to disable USB_QUIRK_DISCONNECT_SUSPEND in kernel 4.19.6 when it was working with enabled quirk (coming from the built-in quirks list) up to kernel 4.19.5 to make the laptop go into suspend at all.

If only someone with the same laptop and modem module would be able to give more insight.

I don't have the modem module installed in my #spitfire ...

Understandably, it does not come with one by default. Some companies working with the Clevo have listed it as an option, but the ME906s-158 or lt4132 are easy and cheap to find on eBay or AliExpress (which is where I got mine from). Of course it doesn't make sense if you have no use for it, but it is much more convenient when on the move often.

I filed this:
https://bugzilla.kernel.org/show_bug.cgi?id=201997

The commit you mentioned is the culprit. I reverted that and it works!

Here is the proper fix.

Very well, I'm glad the problem has been identified. For now I'm sticking with my workaround (disabling XHC in /proc/acpi/wakeup), but hopefully the fix will make it into a release soon.

It does not look like the fix has made it in 4.19.x releases yet.

Forum kindly sponsored by