iwlwifi: network not back after resuming from suspend since v6.15-rc2

iwlwifi: network not back after resuming from suspend since v6.15-rc2

[Coiby Xu]

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

Re: iwlwifi: network not back after resuming from suspend since v6.15-rc2

[Grumbach, Emmanuel]

Hi,


On Mon, 2026-05-11 at 14:49 +0800, Coiby Xu wrote:
> 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. 
> 

This is ... strange.
Can you try to use our backport tree?
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/

I am pretty sure it won't solve anything, but at least, it'll make it
easier for us to work together on this issue.

Also, may I suggest you open a bugzilla ticket on the drivers /
wireless-intel component?
As a starting point, I'll absolutely need the kernel log.


> 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

This is even more strange.

> 
>      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!

My problem here is that we seem to be talking about "the issue" but we
don't know exactly which one... Let's start with a bugzilla ticket with
logs.


<snip>

> 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
> 

Those tickets are all over the place and unfortunately, nothing very
conclusive comes up from those links.

Re: iwlwifi: network not back after resuming from suspend since v6.15-rc2

[Coiby Xu]

On Mon, May 11, 2026 at 07:17:31AM +0000, Grumbach, Emmanuel wrote:
>Hi,

Your quick reply is much appreciated:)

>
>
>On Mon, 2026-05-11 at 14:49 +0800, Coiby Xu wrote:
>> 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.
>>
>
>This is ... strange.
>Can you try to use our backport tree?
>https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/
>
>I am pretty sure it won't solve anything, but at least, it'll make it
>easier for us to work together on this issue.
>
>Also, may I suggest you open a bugzilla ticket on the drivers /
>wireless-intel component?
>As a starting point, I'll absolutely need the kernel log.

Thanks for the suggestion! I've filed 
https://bugzilla.kernel.org/show_bug.cgi?id=221501
with kernel logs after reproducing the issue using the backport tree
version.

>
>
>> 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
>
>This is even more strange.
>
>>
>>      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!
>
>My problem here is that we seem to be talking about "the issue" but we
>don't know exactly which one... Let's start with a bugzilla ticket with
>logs.

Sorry I can only describe the issue as "network unavailable after
resuming from suspend". I've opened the ticket. Please let me know if
you need further info to narrow down the issue and find the root cause.
Meanwhile I'll also do some experiments like reverting the 1st bad
commit in the backport tree.

>
><snip>
>
>> 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
>>
>
>Those tickets are all over the place and unfortunately, nothing very
>conclusive comes up from those links.

-- 
Best regards,
Coiby