Created attachment 306651 [details] dmesg | grep iwlwifi Hello, I am experiencing a significant reduction in WiFi download speeds when using any Linux kernel version greater than 6.8.12. The issue does not occur with kernel versions 6.8.12 or lower. The only change is the firmware version loaded by the kernel (I have attached the full output of "dmesg | grep iwlwifi" for both kernel versions as text files). I have also tried downgrading the firmware, but it did not resolve the issue. The problem occurs across different Linux distributions, indicating that it is related to the default kernel. Hardware Details: Laptop Model: Acer Nitro 5 AN-515-58 Network Card: Intel® Wi-Fi 6 AX203, REV=0x370 CPU: Intel i7-12700H Bluetooth: Intel Corp. AX201 Bluetooth Additional Information: lspci -nnkv | sed -n ‘/Network/,/^$/p’: 0000:00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01) Subsystem: Rivet Networks Dual Band Wi-Fi 6(802.11ax) Killer AX1650i 160MHz 2x2 [Cyclone Peak] [1a56:1652] Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 10 Memory at 6105274000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: iwlwifi Kernel modules: iwlwifi lsusb | grep Bluetooth: Bus 003 Device 003: ID 8087:0026 Intel Corp. AX201 Bluetooth Thank you for your assistance.
Would be great if you could bisect: https://docs.kernel.org/admin-guide/bug-bisect.html
(In reply to siero.o.p.33 from comment #0) > I am experiencing a significant reduction in WiFi download speeds when using > any Linux kernel version greater than 6.8.12. Any? So did you try recent mainline as well (6.11-rc1 or newer)? If the issue happens there, then a bisection would really be for the best: https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
(In reply to Artem S. Tashkinov from comment #1) > Would be great if you could bisect: > https://docs.kernel.org/admin-guide/bug-bisect.html Hello, First of all, thank you for the suggestion. I spent the entire weekend performing a bisect between version 6.8 and 6.9. I had difficulties with Arch Linux-based distributions, but I resolved them with LMDE6. After 13 operations, the final result was as follows: <b345ff698ec7ed52d90bd5603ec8fc1802f40110 is the first bad commit commit b345ff698ec7ed52d90bd5603ec8fc1802f40110 Merge: 480e035fc4c7 5d9e12972259 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Mar 14 09:43:51 2024 -0700 Merge tag 'auxdisplay-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay updates from Andy Shevchenko: - New driver for GPIO based 7-segment LED display (Chris Packham) - New driver for Maxim MAX6958/6959 I²C 7-segment LED display controller - Refactor linedisp library to make the above happen - Update Holtek HT16k33 driver to follow the linedisp refactoring - Convert .remove to return void in platform drivers (Uwe Kleine-König) - Fix DT schemas (Krzysztof Kozlowski) - Refresh MAINTAINERS database * tag 'auxdisplay-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: (27 commits) auxdisplay: img-ascii-lcd: Convert to platform remove callback returning void auxdisplay: hd44780: Convert to platform remove callback returning void auxdisplay: cfag12864bfb: Convert to platform remove callback returning void auxdisplay: seg-led-gpio: Import linedisp namespace dt-bindings: auxdisplay: Add bindings for generic 7-segment LED auxdisplay: Add 7-segment LED display driver auxdisplay: Add driver for MAX695x 7-segment LED controllers dt-bindings: auxdisplay: Add Maxim MAX6958/6959 auxdisplay: ht16k33: Drop struct ht16k33_seg auxdisplay: ht16k33: Switch to use line display character mapping auxdisplay: ht16k33: Define a few helper macros auxdisplay: ht16k33: Move ht16k33_linedisp_ops down auxdisplay: ht16k33: Add default to switch-cases auxdisplay: linedisp: Allocate buffer for the string auxdisplay: linedisp: Add support for overriding character mapping auxdisplay: linedisp: Provide struct linedisp_ops for future extension auxdisplay: linedisp: Move exported symbols to a namespace auxdisplay: linedisp: Add missing header(s) auxdisplay: linedisp: Unshadow error codes in ->store() auxdisplay: linedisp: Use unique number for id ... .../bindings/auxdisplay/arm,versatile-lcd.yaml | 4 +- .../bindings/auxdisplay/gpio-7-segment.yaml | 55 ++++++ .../bindings/auxdisplay/hit,hd44780.yaml | 68 +++---- .../bindings/auxdisplay/holtek,ht16k33.yaml | 54 +++--- .../bindings/auxdisplay/img,ascii-lcd.yaml | 4 +- .../bindings/auxdisplay/maxim,max6959.yaml | 44 +++++ MAINTAINERS | 8 +- drivers/auxdisplay/Kconfig | 25 +++ drivers/auxdisplay/Makefile | 2 + drivers/auxdisplay/cfag12864bfb.c | 6 +- drivers/auxdisplay/hd44780.c | 5 +- drivers/auxdisplay/ht16k33.c | 174 +++++++----------- drivers/auxdisplay/img-ascii-lcd.c | 45 ++--- drivers/auxdisplay/line-display.c | 166 +++++++++++++++-- drivers/auxdisplay/line-display.h | 53 +++++- drivers/auxdisplay/max6959.c | 194 ++++++++++++++++++++ drivers/auxdisplay/panel.c | 202 +++++++++------------ drivers/auxdisplay/seg-led-gpio.c | 113 ++++++++++++ 18 files changed, 886 insertions(+), 336 deletions(-) create mode 100644 Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml create mode 100644 Documentation/devicetree/bindings/auxdisplay/maxim,max6959.yaml create mode 100644 drivers/auxdisplay/max6959.c create mode 100644 drivers/auxdisplay/seg-led-gpio.c> I hope I performed it correctly and that the result was useful.
Thx for your effort. But that looks a lot like something went sideways during the bisection somewhere. Could you please recheck if 480e035fc4c714fb5536e64ab9db04fedc89e910 really is good? And if it is if b345ff698ec7ed52d90bd5603ec8fc1802f40110 really is bad?
Hello, I kindly ask you to ignore the output I provided earlier. I had difficulty changing the bisect choice between good and bad for the following commits: 480e035fc4c714fb5536e64ab9db04fedc89e910 b345ff698ec7ed52d90bd5603ec8fc1802f40110 I repeated the bisect several times and the result was as follows: 099a47dbe71b758e6875d0297467f2b8d23014df is the first bad commit commit 099a47dbe71b758e6875d0297467f2b8d23014df Author: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Date: Tue Jan 23 20:08:10 2024 +0200 wifi: iwlwifi: Add support for new 802.11be device Add support for the new 802.11be device with limites capabilities: - 320 MHz isn't supported - MCSs 12 and 13 are not supported Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240123200528.8529bd2acedf.I25dccb7bbeb21b8df2123fad51dde7fcf137a508@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> drivers/net/wireless/intel/iwlwifi/cfg/bz.c | 1 + drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 13 +++++++++++++ drivers/net/wireless/intel/iwlwifi/iwl-config.h | 4 ++++ drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 16 ++++++++++++++-- drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 ++ drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 7 ++++++- 6 files changed, 40 insertions(+), 3 deletions(-)
thx, forwarded by mail https://lore.kernel.org/all/7a43d26e-95eb-49d4-bc02-434c239909ff@leemhuis.info/
From the report, it really isn't clear why that commit should make a difference. It is not even clear whether this might be a kernel or firmware regression (as the pasted dmesg suggests that different firmware versions are being used). As such, I would be interested in the following data points: 1. Full dmesg of a "good" run (including mac80211 messages!) 2. Full dmesg of a "bad" run 3. If the firmware between the runs differ, trying to force loading the older firmware and checking if that makes a difference (e.g. by simply moving the newer firmware away) Also, if you say "significant" reduction, what do you mean? Please include at least *some* numbers to back it up. And please also verify that you are connected to the same AP and channel using "iw dev" (and that the connection uses the same bandwidth).
Hello, I apologize again, but I had to repeat the bisect because the last two commits I marked as BAD were actually GOOD, and the result was as follows: f33edcee7c47118e59dde72826843 Author: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Date: Fri Jan 26 09:00:30 2024 +0200 wifi: iwlwifi: disable 160 MHz based on subsystem device ID The driver should not send 160 MHz BW support for 5 GHz band in HE if PCI subsystem device ID indicates no 160 MHz support. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240126085924.77c248ce6986.I558e8d0cf19dc862b1c4124df78a4cb690095bb2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 4 ++++ drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 3 ++- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 + 3 files changed, 7 insertions(+), 1 deletion(-) Unfortunately, since this involves testing download speed, it is influenced by various factors, and sometimes I get a "false positive." When I said "significant reduction..." I mean that the download speed differs between 500 and 400 Mbps: good commit 1200/1100 Mbps, bad commit 600/700 Mbps. I compared the outputs of iw dev between kernel 6.8.12 and later versions, and the difference I found is in the following line: v6.8.12 - channel 64 (5320 MHz), width: 160 MHz, center1: 5250 MHz subsequent versions - channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz Even though some BAD commits reported - channel 64 (5320 MHz), width: 160 MHz, center1: 5250 MHz, the download speed was around 650 Mbps... I installed kernel 6.10.3, which reported - channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz, and the download speed is around 650 Mbps... I also noticed that all the good commits are channel 64 (5320 MHz), width: 160 MHz, center1: 5250 MHz loaded firmware version 86.fb5c9aeb.0 so-a0-hr-b0-86.ucode op_mode iwlmvm while some bad commits are channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz loaded firmware version 89.202a2f7b.0 so-a0-hr-b0-89.ucode op_mode iwlmvm some else channel 64 (5320 MHz), width: 160 MHz, center1: 5250 MHz loaded firmware version 86.fb5c9aeb.0 so-a0-hr-b0-86.ucode op_mode iwlmvm I tried to downgrade the firmware in the bad commit from 89.202a2f7b.0 to 86.fb5c9aeb but the output of iw dev remains channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz. I apologize for the mistakes made; do you still need the entire dmesg output for a good and a bad commit?
Greetings, Is there any news regarding my report in which with kernels after version 6.8.12 the wi-fi bandwidth in the 5GHz network is incorrectly set to 80MHz? I tried kernel 6.12.1 and the problem persists. Thanks for your attention.