From: Coiby Xu <coiby.xu@gmail.com>
To: linux-wireless@vger.kernel.org,
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Subject: iwlwifi: network not back after resuming from suspend since v6.15-rc2
Date: Mon, 11 May 2026 14:49:46 +0800 [thread overview]
Message-ID: <agFzc-Ngf_ZFXJ3o@Rk> (raw)
Hi Emmanuel,
I notice since v6.15-rc2, most of the times the network won't be back
again after resuming from suspend. And sometimes I need to run
"systemctl suspend" for 8 or 9 consecutive times to make WIFI available
again. bisect and manual reverting show 15220a257319 ("wifi: iwlwifi:
don't warn if the NIC is gone in resume") is the 1st bad commit.
Here are some other clues that may help resolve this issue,
1. An iwlwifi setting [1] can make this issue disappear,
options iwlwifi swcrypto=0
options iwlwifi bt_coex_active=0
options iwlwifi power_save=0
options iwlwifi uapsd_disable=1
options iwlmvm power_scheme=1
2. Before v6.15-rc2, the issue rarely happens. And if it happens,
simply suspending once can bring the network online again. Other
users seem to have experienced the same issue e.g. [2][3][4].
3. Suspending by "rtcwake -m mem -s 5" instead of by "systemcl suspend"
can make it much easier to reproduce this issue for kernels older
than v6.15-rc2.
If you need more details from me, feel free to let me know! And I'll
very happy to test any possible solutions. Thanks!
## Notes on bisect
The bisect is done with an experimental branch [5] of
kernel-auto-bisect tool [6].
1. bisect conf file
TEST_STRATEGY="simple"
RUNS_PER_COMMIT=6
RUNS_PER_GOOD_COMMIT=3
GOOD_COMMIT=6.14.4-300.fc42.x86_64
BAD_COMMIT=6.19.14-200.fc43.x86_64
REPRODUCER_SCRIPT=reproducer_wifi.sh
2. Reproducer
on_test() {
# If sleep only 5 or 10 s, somehow the system will get suspended forever i.e.
# "rtcwake -m on won't wake up the system .
sleep 15
ip --brief addr show wlp4s0
# "rtcwake -m mem -s 5" will quite often makes wifi unavailable. So use
# systemctl suspend instead
#rtcwake -m mem -s 5
# Wake up the system after 4s
rtcwake -m on -s 4 &
systemctl suspend
sleep 12
ip --brief addr show wlp4s0 | grep -q " UP "
}
kernel-auto-bisect went through a two-phase bisection,
1. find 6.14.6-300.fc42.x86_64 as the 1st bad build
2. find Fedora kernel commit 6453e892cf86c [7] as 1st bad commit
I can't bisect against upstream kernel directly because v6.15-rc2 won't
be able to mount my root partition. So I manually reverted upstream
15220a257319 ("wifi: iwlwifi: don't warn if the NIC is gone in resume")
in v6.15 to confirm it's indeed the bad commit.
[1] https://bbs.archlinux.org/viewtopic.php?pid=2227202#p2227202
[2] https://bbs.archlinux.org/viewtopic.php?id=301971
[3] https://discussion.fedoraproject.org/t/random-wi-fi-adapter-loss-on-fedora-42-intel-alder-lake-p-cnvi/152878
[4] https://forums.opensuse.org/t/wifi-suddenly-no-more-available/184399
[5] https://github.com/coiby/kernel-auto-bisect/tree/random_issue_bisect
[6] https://github.com/rhkdump/kernel-auto-bisect
[7] https://gitlab.com/cki-project/kernel-ark/-/commit/6453e892cf86c900d51f5884e9013e0dbeeea4ad
--
Best regards,
Coiby
next reply other threads:[~2026-05-11 6:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 6:49 Coiby Xu [this message]
2026-05-11 7:17 ` iwlwifi: network not back after resuming from suspend since v6.15-rc2 Grumbach, Emmanuel
2026-05-11 10:13 ` Coiby Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agFzc-Ngf_ZFXJ3o@Rk \
--to=coiby.xu@gmail.com \
--cc=emmanuel.grumbach@intel.com \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.