Bug 219967
| Summary: | Wifi not been detected in kernel version 6.14. | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Asunnya (develop-asunnya) |
| Component: | network-wireless-intel | Assignee: | Default virtual assignee for network-wireless-intel (drivers_network-wireless-intel) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | high | ||
| Priority: | P3 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 6.14 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Zip with LOGs from 6.14 and 6.13 - iwlwifi loop
patch to avoid reset after failed handshake patch to avoid reset after failed handshake |
||
|
Description
Asunnya
2025-03-29 21:56:57 UTC
Since this looks like a regression, could you bisect? https://docs.kernel.org/admin-guide/bug-bisect.html Maybe try kernel 6.13 first. 1. I have confirmed that the bug does not occur in version 6.13.8. I used the `linux-6.13.8.arch1-1-x86_64.pkg.tar.zst` package from the Arch Linux archives, and the Wi-Fi worked normally.
2. I have started the `git bisect` process. The initial log is:
```
git bisect start
# status: waiting for both good and bad commits
# bad: [38fec10eb60d687e30c8c6b5420d86e8149f7557] Linux 6.14
git bisect bad 38fec10eb60d687e30c8c6b5420d86e8149f7557
# status: waiting for good commit(s), bad commit known
# good: [ffd294d346d185b70e28b1a28abe367bbfe53c04] Linux 6.13
git bisect good ffd294d346d185b70e28b1a28abe367bbfe53c04
```
3. My question now is how to proceed with testing the intermediate commits that `git bisect` will select. Do I need to set up the environment and manually compile the kernel for each `bisect` step in order to test the Wi-Fi? I would appreciate any guidance on this.
4. Forget to mention that my distro is not archlinux, it's cachyOS but Im using the kernel provide from arch linux archives.
https://github.com/CachyOS/linux-cachyos/issues/425
Created attachment 307909 [details]
Zip with LOGs from 6.14 and 6.13 - iwlwifi loop
I am attaching a `.7z` archive containing 3 log files
- One with NetworkManager logs from kernel 6.14 (where the bug occurs).
- One with 'iwlwifi' related kernel messages from 6.14.
- One with kernel logs from the working 6.13.8 version.
There's a patch we should've included that should make it not spin, at least: https://p.sipsolutions.net/0c2dac2f5c4818d8.txt However, can't figure out why it's actually happening in the first place. Note also that there's a dup filed _just_ after this one: https://bugzilla.kernel.org/show_bug.cgi?id=219968 Still digging. Can you specify the laptop/machine model(s) this happens on? Created attachment 307917 [details] patch to avoid reset after failed handshake This should fix the issue that we get a SW (or deeper) reset after the handshake fails. It looks like the handshake failure was also there in 6.13 already, but I don't know why. I couldn't reproduce it here on any device that I could get my hands on (though not the same MAC/RF combination so far). Assuming this patch works and you only get a single "FW reset handshake timeout" and no follow-up errors, you could try the FW debug from https://wireless.docs.kernel.org/en/latest/en/users/drivers/iwlwifi/debugging.html#firmware-debugging and capture the dump and send it to us. Created attachment 307918 [details]
patch to avoid reset after failed handshake
ok that patch was stupid, this one's hopefully better :)
Pretty sure this is a dup of https://bugzilla.kernel.org/show_bug.cgi?id=219968 which was confirmed fixed with the patch. *** This bug has been marked as a duplicate of bug 219968 *** My case is a samsung book 2 Samsung Galaxy Book2 550XED |