Bug 218383
| Summary: | WWAN Intel XMM7560 LTE wakes system from s2idle | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Martin (mwolf) |
| Component: | network-wireless-intel | Assignee: | Default virtual assignee for network-wireless-intel (drivers_network-wireless-intel) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dennis.lissov, kai.heng.feng, kolAflash, mario.limonciello, mkchetan, shaneparslow808 |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg after the problem occured again
extracted "PM:" lines from dmesg for better visibility I guess I am not on the proper firmware(?) s2idle with recent version + wakeup after a short time |
||
|
Description
Martin
2024-01-16 18:55:19 UTC
To add extra credence to the above comment, Martin did confirm that disabling WWAN in BIOS fixes the issue. So something in XMM7560 driver or firmware configuration is causing the GPIO to be asserted while the system is in s0i3 which will wake it up. Is there really no one at intel, that cares about this problem? (In reply to Martin from comment #2) > Is there really no one at intel, that cares about this problem? I am trying to reproduce the issue on 865 G9 (can't find any 845 G9 w/ 7560). Does the issue require the lid remain closed? Yes, occurred when the lid was closed. (In reply to Martin from comment #4) > Yes, occurred when the lid was closed. I wonder how the issue was spotted when lid remained closed? Battery drain, fan spinning up, warm notebook and dmesg OK, I can reproduce the issue on 865 G9. And seems like the issue is fixed by latest mainline kernel (v6.8-rc6). Is it possible for you to also give that kernel a try? yes, it looks fixed. So probably fixed by https://github.com/torvalds/linux/commit/1db34aa58d80988f5ee99d2fd9d8f7489c3b0681 ? no, that is from an other bug of mine ;) https://bugzilla.kernel.org/show_bug.cgi?id=217200 no, sorry that one: https://bugzilla.kernel.org/show_bug.cgi?id=217996 Could you bisect what actually fixed it then? I would like to understand this. Actually, I am not sure, when the problem started. Also as you notice, there are quite a few bugs in the iosm device, that cause various issues. How would I take these fixes / bugs into account? Or should I basically say "bad" e.g. Kernel 6.7 and good Kernel 6.8v6? (In reply to Mario Limonciello (AMD) from comment #12) > Could you bisect what actually fixed it then? I would like to understand > this. I am doing the bisection. Since I use not waking up for 24 hours as "good" so it can take a while. I am not sure if it is really fixed. (I updated to -rc7 now) Mär 07 15:57:37 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 15:57:37 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 15:58:06 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 15:58:06 HP845G9 systemd-sleep[409553]: Entering sleep state 'suspend'... Mär 07 16:01:12 HP845G9 systemd-sleep[409553]: System returned from sleep state. Mär 07 16:01:12 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:01:12 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:01:41 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:01:41 HP845G9 systemd-sleep[410010]: Entering sleep state 'suspend'... Mär 07 16:02:12 HP845G9 systemd-sleep[410010]: System returned from sleep state. Mär 07 16:02:12 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:02:12 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:02:41 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:02:41 HP845G9 systemd-sleep[410437]: Entering sleep state 'suspend'... Mär 07 16:40:14 HP845G9 systemd-sleep[410437]: System returned from sleep state. Mär 07 16:40:14 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:40:14 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:40:43 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:40:43 HP845G9 systemd-sleep[410934]: Entering sleep state 'suspend'... Mär 07 16:41:13 HP845G9 systemd-sleep[410934]: System returned from sleep state. Mär 07 16:41:14 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:41:14 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:41:43 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:41:43 HP845G9 systemd-sleep[411382]: Entering sleep state 'suspend'... Mär 07 16:45:34 HP845G9 systemd-sleep[411382]: System returned from sleep state. Mär 07 16:45:34 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:45:34 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:46:03 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:46:03 HP845G9 systemd-sleep[411864]: Entering sleep state 'suspend'... Mär 07 16:46:33 HP845G9 systemd-sleep[411864]: System returned from sleep state. Mär 07 16:46:34 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:46:34 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:47:03 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:47:03 HP845G9 systemd-sleep[412307]: Entering sleep state 'suspend'... Mär 07 16:56:36 HP845G9 systemd-sleep[412307]: System returned from sleep state. Mär 07 16:56:37 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:56:37 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:57:06 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:57:06 HP845G9 systemd-sleep[412764]: Entering sleep state 'suspend'... Mär 07 16:57:38 HP845G9 systemd-sleep[412764]: System returned from sleep state. Mär 07 16:57:38 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:57:38 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Mär 07 16:58:07 HP845G9 systemd[1]: Starting systemd-suspend.service - System Suspend... Mär 07 16:58:07 HP845G9 systemd-sleep[413181]: Entering sleep state 'suspend'... Mär 07 16:58:44 HP845G9 systemd-sleep[413181]: System returned from sleep state. Mär 07 16:58:45 HP845G9 systemd[1]: systemd-suspend.service: Deactivated successfully. Mär 07 16:58:45 HP845G9 systemd[1]: Finished systemd-suspend.service - System Suspend. Turns out it's quite hard to bisect. The system can't boot or freezes on suspend on many of the commits in bisection. (In reply to Martin from comment #16) > I am not sure if it is really fixed. > (I updated to -rc7 now) Can you please run `echo 1 > /sys/power/pm_debug_messages`, reproduce the issue and attach the dmesg here? Thanks! Created attachment 306102 [details]
dmesg after the problem occured again
dmesg with echo 1 > /sys/power/pm_debug_messages
sorry, that it took so long, but the problem is not easy to reproduce. I am still not 100% sure when the problem returns. Is it possible that it has something to do with the removal / plugging in of the power cord? Created attachment 306104 [details]
extracted "PM:" lines from dmesg for better visibility
extracted "PM:" lines from dmesg for better visibility
Mario, can you please confirm it's still the same issue? "GPIO 17 is active: 0x30157a00" the GPIO value seems to be different to the older dmesg. And I still couldn't figure out how to find the connection between GPIO 17 and GP 13, is there anyway to determine that from dmesg? Using https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py is better because it captures more system state information about active GPIO, IRQ and mapping out what they are. GPIO 17 is active comes from pinctrl-amd driver. GPIO values are set up from _AEI. So looking at _AEI/_EVT can see what ACPI devices are notified when it's active. ACPI GP13 maps to PCI WWAN. As GP13 is notified it's pin for WWAN. Regarding GPIO values being different the difference is bit 29. This indicates whether the GPIO was the very first thing to start the wakeup sequence. GPIO bit 28 and 29 being active means that the interrupt is active and it's the first thing to wake the system. GPIO bit 28 only being active means that the system already woke from hardware sleep from a different reason (will capture it in that report) but this GPIO is ALSO active. Created attachment 306113 [details]
I guess I am not on the proper firmware(?)
I am on Fedora 40 (beta) with all Updates installed. Shouldnt the firmware be already in Stable?
I *think* that's output from an older version of the script that didn't know about some WLAN firmware versions for the WCN6855. yeah, you are right. I used the old one, when I tested for the error for the first time. I am sorry. I will run it again. Am I allowed to close the lid, after I started it? Sure. But be cognizant it might be an easy way to trip this issue to close the lid after in suspend. (In reply to Mario Limonciello (AMD) from comment #24) > GPIO 17 is active comes from pinctrl-amd driver. GPIO values are set up from > _AEI. So looking at _AEI/_EVT can see what ACPI devices are notified when > it's active. > > ACPI GP13 maps to PCI WWAN. As GP13 is notified it's pin for WWAN. I wonder how the dots are connected without ACPI tables? You'll need a schematic for that. I've used this technique on a number of bugs, it's been used to find floating pins, missing drivers, buggy drivers. Could this be related? first hibernate to disk fails on HP EliteBook 845 G8 when Intel 7360 WWAN enabled in BIOS https://bugzilla.kernel.org/show_bug.cgi?id=216647#c18 Hint: Start reading that bug from the linked recent comment number 18 (2024-04-10). The older comments are mostly obsolete. Created attachment 306148 [details]
s2idle with recent version + wakeup after a short time
I hope this is what you are looking for.
(In reply to Martin from comment #33) > Created attachment 306148 [details] > s2idle with recent version + wakeup after a short time > > I hope this is what you are looking for. Does this issue happen when `iosm` module is not loaded? I think you are right. I have blacklisted 'iosm' and my system still stays in standby as it should. Do you plan to fix this? I am not able to use the LTE Modem for almost half a year now. |