iwlwifi: Regression after migrating to 6.6.32

iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi,

After upgrading from kernel 5.10.y to 6.6.32 on an i.MX8MM IoT Gateway board,
I started seeing the following storm of iwlwifi warnings (these warnings
keep coming in a loop):

[    6.995391] ------------[ cut here ]------------
[    7.373564] WARNING: CPU: 3 PID: 136 at
/drivers/net/wireless/intel/iwlwifi/pcie/rx.c:269
iwl_pcie_rxmq_restock+0x158/0x178 [iwlwifi]
[    7.385677] Modules linked in: iwlmvm(+) mac80211 libarc4
openvswitch nsh nf_conncount nf_nat iwlwifi edt_ft5x06 cfg80211 rfkill
fuse nfnetlink ipv6
[    7.399053] CPU: 3 PID: 136 Comm: irq/209-iwlwifi Tainted: G
W          6.6.32-stable-standard-00001-ga9f741529938 #1
[    7.410285] Hardware name: CompuLab i.MX8MM IoT Gateway (DT)
[    7.415951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    7.422921] pc : iwl_pcie_rxmq_restock+0x158/0x178 [iwlwifi]
[    7.428648] lr : iwl_pcie_rxmq_restock+0x40/0x178 [iwlwifi]
[    7.434285] sp : ffff800081f6bd30
[    7.437605] x29: ffff800081f6bd30 x28: 0000000000000000 x27: 0000000000000000
[    7.444761] x26: 0000000000000000 x25: ffff0000c0c0ae70 x24: ffffffffffffe844
[    7.451913] x23: ffff0000c0c0b62c x22: 0000000000000001 x21: ffff0000c0c08080
[    7.459066] x20: ffff0000c0c0c078 x19: ffff0000c0c0c000 x18: 0000000000000000
[    7.466220] x17: 000000040044ffff x16: 00500072b5503510 x15: ffff0000ff7a22c0
[    7.473374] x14: 0000000000000000 x13: 000001308d5fa082 x12: 00000000000001da
[    7.480525] x11: 0000000000000000 x10: 0000000000000a30 x9 : ffff800081f6bd10
[    7.487677] x8 : ffff0000c02b4590 x7 : dead000000000122 x6 : dead000000000100
[    7.494829] x5 : ffff0000c0c09e70 x4 : ffff0000c4ed4290 x3 : ffff0000c4ed42a8
[    7.501981] x2 : 00000000fb645800 x1 : ffff0000c4ed42b8 x0 : 0000000000000fff
[    7.509134] Call trace:
[    7.511585]  iwl_pcie_rxmq_restock+0x158/0x178 [iwlwifi]
[    7.516965]  iwl_pcie_irq_msix_handler+0x38c/0x444 [iwlwifi]
[    7.522690]  irq_thread_fn+0x2c/0xa8
[    7.526281]  irq_thread+0x160/0x248
[    7.529782]  kthread+0x110/0x114
[    7.533021]  ret_from_fork+0x10/0x20
[    7.536607] ---[ end trace 0000000000000000 ]---
[    7.541357] ------------[ cut here ]------------

Does anyone have any suggestions on how to fix this for 6.6.y?

Thanks,

Fabio Estevam

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Tue, 2024-06-11 at 08:46 -0300, Fabio Estevam wrote:
> 
> [    6.995391] ------------[ cut here ]------------
> [    7.373564] WARNING: CPU: 3 PID: 136 at
> /drivers/net/wireless/intel/iwlwifi/pcie/rx.c:269
> iwl_pcie_rxmq_restock+0x158/0x178 [iwlwifi]
> 

This warning happens if DMA mapping/allocation returns a page that's not
page-aligned??

                rxb->page_dma =
                        dma_map_page(trans->dev, page, rxb->offset,
                                     trans_pcie->rx_buf_bytes,
                                     DMA_FROM_DEVICE);

(or similar places), where rxb->offset will always be 0 unless
rx_buf_bytes is set to 2048, but that can only happen if the amsdu_size
module parameter is set to 4 (=2k) but that's not even supported any
more?

Maybe make this WARN_ONCE(...) with a string that has more info on the
addresses.

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi Johannes,

On Tue, Jun 11, 2024 at 9:52 AM Johannes Berg <johannes@sipsolutions.net> wrote:

> This warning happens if DMA mapping/allocation returns a page that's not
> page-aligned??
>
>                 rxb->page_dma =
>                         dma_map_page(trans->dev, page, rxb->offset,
>                                      trans_pcie->rx_buf_bytes,
>                                      DMA_FROM_DEVICE);
>
> (or similar places), where rxb->offset will always be 0 unless
> rx_buf_bytes is set to 2048, but that can only happen if the amsdu_size
> module parameter is set to 4 (=2k) but that's not even supported any
> more?
>
> Maybe make this WARN_ONCE(...) with a string that has more info on the
> addresses.

I did as suggested:

--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -266,7 +266,8 @@ static void iwl_pcie_rxmq_restock(struct iwl_trans *trans,
                list_del(&rxb->list);
                rxb->invalid = false;
                /* some low bits are expected to be unset (depending on hw) */
-               WARN_ON(rxb->page_dma & trans_pcie->supported_dma_mask);
+               WARN_ONCE(rxb->page_dma & trans_pcie->supported_dma_mask,
+                         "rxb->offset is %d trans_pcie->rx_buf_bytes
is %d\n", rxb->offset, trans_pcie->rx_buf_bytes);
                /* Point to Rx buffer via next RBD in circular buffer */
                iwl_pcie_restock_bd(trans, rxq, rxb);
                rxq->write = (rxq->write + 1) & (rxq->queue_size - 1);
-- 

and this is the result:

[    5.033520] ------------[ cut here ]------------
[    5.033723] iwlwifi 0000:01:00.0: Detected RF HR B3, rfid=0x10a100
[    5.038174] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096
[    5.038279] WARNING: CPU: 1 PID: 135 at
/drivers/net/wireless/intel/iwlwifi/pcie/rx.c:269
iwl_pcie_rxmq_restock.part.0+0x160/0x16c [iwlwifi]
[    5.062764] Modules linked in: iwlmvm(+) mac80211 libarc4
openvswitch nsh nf_conncount nf_nat iwlwifi edt_ft5x06 cfg80211 rfkill
fuse nfnetlink ipv6
[    5.076130] CPU: 1 PID: 135 Comm: irq/203-iwlwifi Not tainted
6.6.32-stable-standard-00002-ga107bd5acba0 #1
[    5.085889] Hardware name: CompuLab i.MX8MM IoT Gateway (DT)
[    5.091562] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    5.098537] pc : iwl_pcie_rxmq_restock.part.0+0x160/0x16c [iwlwifi]
[    5.104900] lr : iwl_pcie_rxmq_restock.part.0+0x160/0x16c [iwlwifi]
[    5.111254] sp : ffff80008000bd20
[    5.114575] x29: ffff80008000bd20 x28: ffff0000c1ab0080 x27: ffff0000c1ab8000
[    5.121729] x26: dead000000000122 x25: dead000000000100 x24: ffff0000c1ab1e70
[    5.128884] x23: ffff0000c1ab0080 x22: ffff0000c4e34460 x21: ffff0000c1ab8078
[    5.136041] x20: ffff0000c4e34470 x19: ffff0000c1ab8000 x18: ffffffffffffffff
[    5.143194] x17: 0000000000000001 x16: 0000000000000000 x15: ffff80008000b8e0
[    5.150350] x14: 0000000000000000 x13: ffff80008185a15d x12: 625f6675625f7872
[    5.157506] x11: fffffffffffe0000 x10: 000000000000000a x9 : 0000000000001000
[    5.164659] x8 : 000000000000000a x7 : 0000000000000004 x6 : 0000000000000000
[    5.171812] x5 : ffff0000ff76dd48 x4 : 0000000000000000 x3 : 0000000000000027
[    5.178968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c1898000
[    5.186121] Call trace:
[    5.188573]  iwl_pcie_rxmq_restock.part.0+0x160/0x16c [iwlwifi]
[    5.194607]  iwl_pcie_rxq_restock+0x40/0x4c [iwlwifi]
[    5.199744]  iwl_pcie_rx_handle+0x414/0x884 [iwlwifi]
[    5.204877]  iwl_pcie_napi_poll_msix+0x38/0xb0 [iwlwifi]
[    5.210280]  __napi_poll+0x38/0x178
[    5.213790]  net_rx_action+0x128/0x270
[    5.217554]  __do_softirq+0x100/0x26c
[    5.221227]  ____do_softirq+0x10/0x1c
[    5.224900]  call_on_irq_stack+0x24/0x4c
[    5.228834]  do_softirq_own_stack+0x1c/0x2c
[    5.233027]  do_softirq+0x54/0x6c
[    5.236357]  __local_bh_enable_ip+0x8c/0x98
[    5.240554]  iwl_pcie_irq_rx_msix_handler+0x90/0xe8 [iwlwifi]
[    5.246403]  irq_thread_fn+0x2c/0xa8
[    5.249991]  irq_thread+0x160/0x248
[    5.253490]  kthread+0x110/0x114
[    5.256728]  ret_from_fork+0x10/0x20
[    5.260317] ---[ end trace 0000000000000000 ]--

Many other warnings follow:

[   10.724476] ------------[ cut here ]------------
[   10.724481] Invalid rxb from HW 4085
[   10.724531] iwlwifi 0000:01:00.0: Microcode SW error detected.
Restarting 0x0.
[   10.724601] WARNING: CPU: 1 PID: 135 at
/drivers/net/wireless/intel/iwlwifi/pcie/rx.c:1490
iwl_pcie_rx_handle+0x694/0x884 [iwlwifi]
[   10.724681] Modules linked in: caam_jr caamhash_desc caamalg_desc
authenc libdes btusb option btrtl usb_wwan btintel usbserial smsc
btmtk btbcm bluetooth ecdh_generic ecc smsc95xx usbnet hantro_vpu
v4l2_vp9 v4l2_h264 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem
videobuf2_v4l2 videobuf2_common imx8m_ddrc videodev etnaviv
crct10dif_ce gpu_sched mc at24 fsl_imx8_ddr_perf clk_bd718x7
snvs_pwrkey rtc_snvs caam error pwm_imx27 spi_imx imx_sdma
imx8mm_thermal snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma pwm_bl
backlight imx_cpufreq_dt iwlmvm mac80211 libarc4 openvswitch nsh
nf_conncount nf_nat iwlwifi edt_ft5x06 cfg80211 rfkill fuse nfnetlink
ipv6
[   10.724837] CPU: 1 PID: 135 Comm: irq/203-iwlwifi Tainted: G
W          6.6.32-stable-standard-00002-ga107bd5acba0 #1
[   10.724845] Hardware name: CompuLab i.MX8MM IoT Gateway (DT)
[   10.724849] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   10.724857] pc : iwl_pcie_rx_handle+0x694/0x884 [iwlwifi]
[   10.724923] lr : iwl_pcie_rx_handle+0x694/0x884 [iwlwifi]
[   10.724991] sp : ffff80008000bd80
[   10.724994] x29: ffff80008000bdf0 x28: ffff0000c1ab0080 x27: ffff0000c1ab8000
[   10.725004] x26: 000000000000000c x25: ffff0000c1ab1c80 x24: 00000000fffee582
[   10.725014] x23: 0000000000000001 x22: 0000000000000001 x21: 0000000000000040
[   10.725024] x20: ffff0000c1ab0080 x19: ffff0000c1ab8078 x18: ffffffffffffffff
[   10.725035] x17: ffff80007e2ab000 x16: ffff800080008000 x15: ffff80008000b940
[   10.725045] x14: 0000000000000000 x13: ffff80008185f804 x12: 206278722064696c
[   10.725055] x11: fffffffffffe0000 x10: 000000000000000a x9 : 0000000000000ff5
[   10.725064] x8 : 000000000000000a x7 : 0000000000000004 x6 : 0000000000000000
[   10.725073] x5 : ffff0000ff76dd48 x4 : 0000000000000000 x3 : 0000000000000027
[   10.725083] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c1898000
[   10.725093] Call trace:
[   10.725096]  iwl_pcie_rx_handle+0x694/0x884 [iwlwifi]
[   10.725164]  iwl_pcie_napi_poll_msix+0x38/0xb0 [iwlwifi]
[   10.725232]  __napi_poll+0x38/0x178
[   10.725245]  net_rx_action+0x128/0x270
[   10.725254]  __do_softirq+0x100/0x26c
[   10.725260]  ____do_softirq+0x10/0x1c
[   10.725269]  call_on_irq_stack+0x24/0x4c
[   10.725276]  do_softirq_own_stack+0x1c/0x2c
[   10.725282]  do_softirq+0x54/0x6c
[   10.725293]  __local_bh_enable_ip+0x8c/0x98
[   10.725303]  iwl_pcie_irq_rx_msix_handler+0x90/0xe8 [iwlwifi]
[   10.725370]  irq_thread_fn+0x2c/0xa8
[   10.725377]  irq_thread+0x160/0x248
[   10.725384]  kthread+0x110/0x114
[   10.725391]  ret_from_fork+0x10/0x20
[   10.725399] ---[ end trace 0000000000000000 ]---
[   11.040466] iwlwifi 0000:01:00.0: Start IWL Error Log Dump:
[   11.046122] iwlwifi 0000:01:00.0: Transport status: 0x0000004B, valid: 6
[   11.046133] iwlwifi 0000:01:00.0: Loaded firmware version:
77.ad46c98b.0 cc-a0-77.ucode
[   11.046140] iwlwifi 0000:01:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
[   11.046146] iwlwifi 0000:01:00.0: 0x00A0A2B0 | trm_hw_status0
[   11.046152] iwlwifi 0000:01:00.0: 0x00000001 | trm_hw_status1
[   11.046157] iwlwifi 0000:01:00.0: 0x004F8B7A | branchlink2
[   11.046162] iwlwifi 0000:01:00.0: 0x004EEC2A | interruptlink1
[   11.046167] iwlwifi 0000:01:00.0: 0x004EEC2A | interruptlink2
[   11.046173] iwlwifi 0000:01:00.0: 0x000152DA | data1
[   11.046178] iwlwifi 0000:01:00.0: 0x01000000 | data2
[   11.046183] iwlwifi 0000:01:00.0: 0x00000000 | data3
[   11.046188] iwlwifi 0000:01:00.0: 0x00000000 | beacon time
[   11.046193] iwlwifi 0000:01:00.0: 0x00155CAF | tsf low
[   11.046199] iwlwifi 0000:01:00.0: 0x00000000 | tsf hi
[   11.046204] iwlwifi 0000:01:00.0: 0x00000000 | time gp1
[   11.046209] iwlwifi 0000:01:00.0: 0x0015B919 | time gp2
[   11.046214] iwlwifi 0000:01:00.0: 0x00000001 | uCode revision type
[   11.046219] iwlwifi 0000:01:00.0: 0x0000004D | uCode version major
[   11.046224] iwlwifi 0000:01:00.0: 0xAD46C98B | uCode version minor
[   11.046230] iwlwifi 0000:01:00.0: 0x00000340 | hw version
[   11.046235] iwlwifi 0000:01:00.0: 0x00C89000 | board version
[   11.046240] iwlwifi 0000:01:00.0: 0x8035F500 | hcmd
[   11.046246] iwlwifi 0000:01:00.0: 0x20020000 | isr0
[   11.046251] iwlwifi 0000:01:00.0: 0x00000000 | isr1
[   11.046256] iwlwifi 0000:01:00.0: 0x08F00002 | isr2
[   11.046261] iwlwifi 0000:01:00.0: 0x00C0001C | isr3
[   11.046266] iwlwifi 0000:01:00.0: 0x00000000 | isr4
[   11.046271] iwlwifi 0000:01:00.0: 0x00000000 | last cmd Id
[   11.046276] iwlwifi 0000:01:00.0: 0x000152DA | wait_event
[   11.046282] iwlwifi 0000:01:00.0: 0x00000000 | l2p_control
[   11.046287] iwlwifi 0000:01:00.0: 0x00010000 | l2p_duration
[   11.046292] iwlwifi 0000:01:00.0: 0x00000000 | l2p_mhvalid
[   11.046297] iwlwifi 0000:01:00.0: 0x00000000 | l2p_addr_match
[   11.046302] iwlwifi 0000:01:00.0: 0x00000009 | lmpm_pmg_sel
[   11.046308] iwlwifi 0000:01:00.0: 0x00000000 | timestamp
[   11.046313] iwlwifi 0000:01:00.0: 0x00000848 | flow_handler
[   11.046367] iwlwifi 0000:01:00.0: Start IWL Error Log Dump:
[   11.046372] iwlwifi 0000:01:00.0: Transport status: 0x0000004B, valid: 7
[   11.046378] iwlwifi 0000:01:00.0: 0x20000066 | NMI_INTERRUPT_HOST
[   11.046384] iwlwifi 0000:01:00.0: 0x00000000 | umac branchlink1
[   11.046390] iwlwifi 0000:01:00.0: 0x80455D2E | umac branchlink2
[   11.276561] iwlwifi 0000:01:00.0: 0x80472CBA | umac interruptlink1
[   11.276572] iwlwifi 0000:01:00.0: 0x80472CBA | umac interruptlink2
[   11.276577] iwlwifi 0000:01:00.0: 0x01000000 | umac data1
[   11.276583] iwlwifi 0000:01:00.0: 0x80472CBA | umac data2
[   11.276588] iwlwifi 0000:01:00.0: 0x00000000 | umac data3
[   11.276593] iwlwifi 0000:01:00.0: 0x0000004D | umac major
[   11.276599] iwlwifi 0000:01:00.0: 0xAD46C98B | umac minor
[   11.276604] iwlwifi 0000:01:00.0: 0x0015B916 | frame pointer
[   11.276609] iwlwifi 0000:01:00.0: 0xC0886260 | stack pointer
[   11.276614] iwlwifi 0000:01:00.0: 0x000801B3 | last host cmd
[   11.276619] iwlwifi 0000:01:00.0: 0x00000000 | isr status reg
[   11.276644] iwlwifi 0000:01:00.0: IML/ROM dump:
[   11.276650] iwlwifi 0000:01:00.0: 0x00000003 | IML/ROM error/state
[   11.276668] iwlwifi 0000:01:00.0: 0x00005B4F | IML/ROM data1
[   11.276686] iwlwifi 0000:01:00.0: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[   11.276698] iwlwifi 0000:01:00.0: Fseq Registers:
[   11.276706] iwlwifi 0000:01:00.0: 0x60000041 | FSEQ_ERROR_CODE
[   11.276715] iwlwifi 0000:01:00.0: 0x00290021 | FSEQ_TOP_INIT_VERSION
[   11.276724] iwlwifi 0000:01:00.0: 0x00050008 | FSEQ_CNVIO_INIT_VERSION
[   11.276733] iwlwifi 0000:01:00.0: 0x0000A503 | FSEQ_OTP_VERSION
[   11.276742] iwlwifi 0000:01:00.0: 0x80000003 | FSEQ_TOP_CONTENT_VERSION
[   11.276751] iwlwifi 0000:01:00.0: 0x4552414E | FSEQ_ALIVE_TOKEN
[   11.276760] iwlwifi 0000:01:00.0: 0x00100530 | FSEQ_CNVI_ID
[   11.276771] iwlwifi 0000:01:00.0: 0x00000532 | FSEQ_CNVR_ID
[   11.276782] iwlwifi 0000:01:00.0: 0x00100530 | CNVI_AUX_MISC_CHIP
[   11.276793] iwlwifi 0000:01:00.0: 0x00000532 | CNVR_AUX_MISC_CHIP
[   11.276804] iwlwifi 0000:01:00.0: 0x05B0905B |
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[   11.276815] iwlwifi 0000:01:00.0: 0x0000025B |
CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[   11.276824] iwlwifi 0000:01:00.0: 0x00050008 | FSEQ_PREV_CNVIO_INIT_VERSION
[   11.276833] iwlwifi 0000:01:00.0: 0x00290021 | FSEQ_WIFI_FSEQ_VERSION
[   11.276842] iwlwifi 0000:01:00.0: 0x00290021 | FSEQ_BT_FSEQ_VERSION
[   11.276851] iwlwifi 0000:01:00.0: 0x00000000 | FSEQ_CLASS_TP_VERSION
[   11.276870] iwlwifi 0000:01:00.0: UMAC CURRENT PC: 0x804727d0
[   11.475114] iwlwifi 0000:01:00.0: LMAC1 CURRENT PC: 0xd0
[   11.475165] iwlwifi 0000:01:00.0: Starting mac, retry will be
triggered anyway
[   11.475202] iwlwifi 0000:01:00.0: FW error in SYNC CMD RSS_CONFIG_CMD
[   11.475213] CPU: 3 PID: 369 Comm: systemd-network Tainted: G
W          6.6.32-stable-standard-00002-ga107bd5acba0 #1
[   11.475223] Hardware name: CompuLab i.MX8MM IoT Gateway (DT)
[  OK  ] Reached targe[   11.475227] Call trace:
[   11.475230]  dump_backtrace+0x90/0xe8
t Login Prompts.
[   11.475247]  show_stack+0x18/0x24
[   11.475257]  dump_stack_lvl+0x48/0x60
[   11.475267]  dump_stack+0x18/0x24
[   11.475276]  iwl_trans_txq_send_hcmd+0x374/0x434 [iwlwifi]
[   11.475371]  iwl_trans_send_cmd+0xa4/0x118 [iwlwifi]
[   11.543800]  iwl_mvm_send_cmd_pdu+0x48/0x94 [iwlmvm]
[   11.548854]  iwl_send_rss_cfg_cmd+0xac/0xdc [iwlmvm]
[   11.553886]  iwl_mvm_up+0x664/0x8a0 [iwlmvm]
[   11.558222]  __iwl_mvm_mac_start+0x128/0x204 [iwlmvm]
[   11.563340]  iwl_mvm_mac_start+0x80/0x194 [iwlmvm]
[   11.568196]  drv_start+0x34/0x58 [mac80211]
[   11.572516]  ieee80211_do_open+0x2a8/0x6b0 [mac80211]
[   11.577688]  ieee80211_open+0x80/0xa8 [mac80211]
[   11.577821]  __dev_open+0x100/0x1d8
[   11.577834]  __dev_change_flags+0x194/0x20c
[   11.577844]  dev_change_flags+0x24/0x6c
[  OK  ] Reached targe[   11.577854]  do_setlink+0x27c/0xeb0
t Multi-User System.[   11.577863]  rtnl_setlink+0x120/0x1d8

[   11.577872]  rtnetlink_rcv_msg+0x128/0x378
[   11.577880]  netlink_rcv_skb+0x60/0x130
[   11.577891]  rtnetlink_rcv+0x18/0x24
[   11.577900]  netlink_unicast+0x300/0x36c
[   11.577907]  netlink_sendmsg+0x1a8/0x420
[   11.577914]  __sys_sendto+0x118/0x180
[   11.577922]  __arm64_sys_sendto+0x28/0x38
[   11.577929]  invoke_syscall+0x48/0x114
[   11.577939]  el0_svc_common.constprop.0+0xc0/0xe0
[   11.577948]  do_el0_svc+0x1c/0x28
[   11.577957]  el0_svc+0x40/0xe4
[   11.577966]  el0t_64_sync_handler+0x120/0x12c
[   11.577975]  el0t_64_sync+0x190/0x194
[   11.578728] iwlwifi 0000:01:00.0: Failed to configure RSS queues: -5
[   11.676672] iwlwifi 0000:01:00.0: mac start retry 0

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

Hi Fabio,

> 
> I did as suggested:
> 
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -266,7 +266,8 @@ static void iwl_pcie_rxmq_restock(struct iwl_trans *trans,
>                 list_del(&rxb->list);
>                 rxb->invalid = false;
>                 /* some low bits are expected to be unset (depending on hw) */
> -               WARN_ON(rxb->page_dma & trans_pcie->supported_dma_mask);
> +               WARN_ONCE(rxb->page_dma & trans_pcie->supported_dma_mask,
> +                         "rxb->offset is %d trans_pcie->rx_buf_bytes
> is %d\n", rxb->offset, trans_pcie->rx_buf_bytes);
> 

> [    5.038174] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096

so that looks pretty normal?

Might be useful to see rx->page_dma too, supported_dma_mask should be
4095 or 2047 depending on the device, but I'm not sure how you could end
up with a DMA mapping for a page that's not at least 11 bit aligned?

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi Johannes,

I forgot to mention, but the Wifi device I am using is:

Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340

On Tue, Jun 11, 2024 at 10:54 AM Johannes Berg
<johannes@sipsolutions.net> wrote:

> > [    5.038174] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096
>
> so that looks pretty normal?
>
> Might be useful to see rx->page_dma too, supported_dma_mask should be
> 4095 or 2047 depending on the device, but I'm not sure how you could end
> up with a DMA mapping for a page that's not at least 11 bit aligned?

Here it goes:

[    4.344218] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096
rxb->page_dma is 4215433216 trans_pcie->supported_dma_mask is 4095
[    4.355936] WARNING: CPU: 2 PID: 135 at
/drivers/net/wireless/intel/iwlwifi/pcie/rx.c:269
iwl_pcie_rxmq_restock.part.0+0x15c/0x168 [iwlwifi]

I don't know what a typical rxb->page_dma should be.

Thanks

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Tue, 2024-06-11 at 11:32 -0300, Fabio Estevam wrote:
> Hi Johannes,
> 
> I forgot to mention, but the Wifi device I am using is:
> 
> Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
> 
> On Tue, Jun 11, 2024 at 10:54 AM Johannes Berg
> <johannes@sipsolutions.net> wrote:
> 
> > > [    5.038174] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096
> > 
> > so that looks pretty normal?
> > 
> > Might be useful to see rx->page_dma too, supported_dma_mask should be
> > 4095 or 2047 depending on the device, but I'm not sure how you could end
> > up with a DMA mapping for a page that's not at least 11 bit aligned?
> 
> Here it goes:
> 
> [    4.344218] rxb->offset is 0 trans_pcie->rx_buf_bytes is 4096
> rxb->page_dma is 4215433216 trans_pcie->supported_dma_mask is 4095

> I don't know what a typical rxb->page_dma should be.
> 

It should be an address (so that's fine), but I don't see how it ends up
not being page-aligned if we request to map a page and 4096 bytes??

Is that platform "weird" with strange page size, or something?

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

On Tue, Jun 11, 2024 at 11:50 AM Johannes Berg
<johannes@sipsolutions.net> wrote:

> It should be an address (so that's fine), but I don't see how it ends up
> not being page-aligned if we request to map a page and 4096 bytes??
>
> Is that platform "weird" with strange page size, or something?

It is an NXP i.MX8MM, which is ARM64 with a 4KB page size.

Thanks

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Tue, 2024-06-11 at 11:59 -0300, Fabio Estevam wrote:
> On Tue, Jun 11, 2024 at 11:50 AM Johannes Berg
> <johannes@sipsolutions.net> wrote:
> 
> > It should be an address (so that's fine), but I don't see how it ends up
> > not being page-aligned if we request to map a page and 4096 bytes??
> > 
> > Is that platform "weird" with strange page size, or something?
> 
> It is an NXP i.MX8MM, which is ARM64 with a 4KB page size.
> 

Strange. Is there an IOMMU involved on this platform?

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi Johannes,

On Wed, Jun 12, 2024 at 4:10 PM Johannes Berg <johannes@sipsolutions.net> wrote:

> Strange. Is there an IOMMU involved on this platform?

IOMMU isn't available on i.MX8M as far as I know.

Interestingly, such a warning does not happen with the 5.10 kernel.

I only noticed it yesterday, after migrating to 6.6.32.

Thanks

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Wed, 2024-06-12 at 16:15 -0300, Fabio Estevam wrote:
> Hi Johannes,
> 
> On Wed, Jun 12, 2024 at 4:10 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > Strange. Is there an IOMMU involved on this platform?
> 
> IOMMU isn't available on i.MX8M as far as I know.

Alright, so I don't know.

> Interestingly, such a warning does not happen with the 5.10 kernel.

Sure, but that's also _ancient_. There are >12k commits since then that
change arch/arm64/ alone ... And since we didn't change the driver, I
guess the issue is somewhere there?

But ... I see you're one of the NXP ARM64 kernel maintainers so you will
likely know better than me what's going on there :P

I guess you could also check the *virtual* address of the allocated
paged isn't also weirdly unaligned, but either way it's strange that the
arch/iommu/... gives an unaligned physical/IO-virtual address.

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Baochen Qiang]

On 6/13/2024 3:15 AM, Fabio Estevam wrote:
> Hi Johannes,
> 
> On Wed, Jun 12, 2024 at 4:10 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> 
>> Strange. Is there an IOMMU involved on this platform?
> 
> IOMMU isn't available on i.MX8M as far as I know.
If IOMMU not present, likely the buffer is mapped by SWIOTLB. The iova 4215433216, aka 0xFB426800, is 2K aligned, which also supports such guessing. See definition of IO_TLB_SIZE.

> 
> Interestingly, such a warning does not happen with the 5.10 kernel.
> 
> I only noticed it yesterday, after migrating to 6.6.32.
> 
> Thanks
> 

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Thu, 2024-06-13 at 15:10 +0800, Baochen Qiang wrote:
> 
> On 6/13/2024 3:15 AM, Fabio Estevam wrote:
> > Hi Johannes,
> > 
> > On Wed, Jun 12, 2024 at 4:10 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> > 
> > > Strange. Is there an IOMMU involved on this platform?
> > 
> > IOMMU isn't available on i.MX8M as far as I know.
> If IOMMU not present, likely the buffer is mapped by SWIOTLB.

Why? The device can do 64-bit DMA, so should be able to just access any
page in the system. Even older devices can do 36-bit DMA, but this is a
newer one. And if IOMMU isn't present, you have no protection anyway.

>  The iova 4215433216, aka 0xFB426800, is 2K aligned, which also supports such guessing. See definition of IO_TLB_SIZE.

Not sure that means anything though, I really would have expected a 4k
buffer to be 4k aligned - why would you even want to map it across two
pages?

If it is SWIOTLB, shouldn't we get into this condition?

        /*
         * Historically, swiotlb allocations >= PAGE_SIZE were guaranteed to be
         * page-aligned in the absence of any other alignment requirements.
         * 'alloc_align_mask' was later introduced to specify the alignment
         * explicitly, however this is passed as zero for streaming mappings
         * and so we preserve the old behaviour there in case any drivers are
         * relying on it.
         */
        if (!alloc_align_mask && !iotlb_align_mask && alloc_size >= PAGE_SIZE)
                alloc_align_mask = PAGE_SIZE - 1;


Otherwise, not sure though how we could possibly fix this in the driver,
we really shouldn't do dma_set_min_align_mask() since on the TX side we
really have no alignment requirements, and swiotlb_map() uses 0 as
alignment.

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Baochen Qiang]

On 6/13/2024 3:40 PM, Johannes Berg wrote:
> On Thu, 2024-06-13 at 15:10 +0800, Baochen Qiang wrote:
>>
>> On 6/13/2024 3:15 AM, Fabio Estevam wrote:
>>> Hi Johannes,
>>>
>>> On Wed, Jun 12, 2024 at 4:10 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>>>
>>>> Strange. Is there an IOMMU involved on this platform?
>>>
>>> IOMMU isn't available on i.MX8M as far as I know.
>> If IOMMU not present, likely the buffer is mapped by SWIOTLB.
> 
> Why? The device can do 64-bit DMA, so should be able to just access any
> page in the system. Even older devices can do 36-bit DMA, but this is a
> newer one. And if IOMMU isn't present, you have no protection anyway.
Then no idea :(

> 
>>  The iova 4215433216, aka 0xFB426800, is 2K aligned, which also supports such guessing. See definition of IO_TLB_SIZE.
> 
> Not sure that means anything though, I really would have expected a 4k
> buffer to be 4k aligned - why would you even want to map it across two
> pages?
IMO SWIOTLB manages buffers in a unit of IO_TLB_SIZE, it does not care about whether or not we are crossing page boundaries, no?

> 
> If it is SWIOTLB, shouldn't we get into this condition?
> 
>         /*
>          * Historically, swiotlb allocations >= PAGE_SIZE were guaranteed to be
>          * page-aligned in the absence of any other alignment requirements.
>          * 'alloc_align_mask' was later introduced to specify the alignment
>          * explicitly, however this is passed as zero for streaming mappings
>          * and so we preserve the old behaviour there in case any drivers are
>          * relying on it.
>          */
>         if (!alloc_align_mask && !iotlb_align_mask && alloc_size >= PAGE_SIZE)
>                 alloc_align_mask = PAGE_SIZE - 1;
> 
This is not present in 6.6.32 stable kernel.

> 
> Otherwise, not sure though how we could possibly fix this in the driver,
> we really shouldn't do dma_set_min_align_mask() since on the TX side we
> really have no alignment requirements, and swiotlb_map() uses 0 as
> alignment.
> 
> johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Johannes Berg]

On Thu, 2024-06-13 at 17:51 +0800, Baochen Qiang wrote:
> > 
> > Not sure that means anything though, I really would have expected a 4k
> > buffer to be 4k aligned - why would you even want to map it across two
> > pages?
> IMO SWIOTLB manages buffers in a unit of IO_TLB_SIZE, it does not care about whether or not we are crossing page boundaries, no?

Well arguably it should have some 'natural' alignment guarantees?

> > 
> > If it is SWIOTLB, shouldn't we get into this condition?
> > 
> >         /*
> >          * Historically, swiotlb allocations >= PAGE_SIZE were guaranteed to be
> >          * page-aligned in the absence of any other alignment requirements.
> >          * 'alloc_align_mask' was later introduced to specify the alignment
> >          * explicitly, however this is passed as zero for streaming mappings
> >          * and so we preserve the old behaviour there in case any drivers are
> >          * relying on it.
> >          */
> >         if (!alloc_align_mask && !iotlb_align_mask && alloc_size >= PAGE_SIZE)
> >                 alloc_align_mask = PAGE_SIZE - 1;
> > 
> This is not present in 6.6.32 stable kernel.
> 

Oh. So I guess try to pick up commit 14cebf689a78 ("swiotlb: Reinstate
page-alignment for mappings >= PAGE_SIZE").

johannes

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi Johannes and Baochen,

Thanks for the great suggestions.

On Thu, Jun 13, 2024 at 7:37 AM Johannes Berg <johannes@sipsolutions.net> wrote:

> Oh. So I guess try to pick up commit 14cebf689a78 ("swiotlb: Reinstate
> page-alignment for mappings >= PAGE_SIZE").

Good catch, thanks!

After applying 14cebf689a78 ("swiotlb: Reinstate> page-alignment for
mappings >= PAGE_SIZE")
on top of 6.6.33 I no longer have the flood of alignment warnings and
iwlwifi can be used again:

# dmesg | grep iwlwifi
[    4.295064] iwlwifi 0000:01:00.0: enabling device (0000 -> 0002)
[    4.305459] iwlwifi 0000:01:00.0: Detected crf-id 0x3617, cnv-id
0x100530 wfpm id 0x80000000
[    4.315440] iwlwifi 0000:01:00.0: PCI dev 2723/0084, rev=0x340, rfid=0x10a100
[    4.346029] iwlwifi 0000:01:00.0: api flags index 2 larger than
supported by driver
[    4.353816] iwlwifi 0000:01:00.0: TLV_FW_FSEQ_VERSION: FSEQ
Version: 89.3.35.37
[    4.363135] iwlwifi 0000:01:00.0: loaded firmware version
77.ad46c98b.0 cc-a0-77.ucode op_mode iwlmvm
[    4.444427] iwlwifi 0000:01:00.0: Detected Intel(R) Wi-Fi 6 AX200
160MHz, REV=0x340
[    4.604918] iwlwifi 0000:01:00.0: Detected RF HR B3, rfid=0x10a100
[    4.676138] iwlwifi 0000:01:00.0: base HW address: 3c:21:9c:4e:16:6x
[    5.339929] iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0
[    9.840136] iwlwifi 0000:01:00.0: Registered PHC clock:
iwlwifi-PTP, with index: 1

Will, is it OK for me to ask the stable folks to backport 14cebf689a78
("swiotlb: Reinstate> page-alignment for mappings >= PAGE_SIZE")
to 6.6 stable?

Thanks!

Fabio Estevam

Re: iwlwifi: Regression after migrating to 6.6.32

[Will Deacon]

Hi Fabio,

On Thu, Jun 13, 2024 at 05:15:03PM -0300, Fabio Estevam wrote:
> On Thu, Jun 13, 2024 at 7:37 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > Oh. So I guess try to pick up commit 14cebf689a78 ("swiotlb: Reinstate
> > page-alignment for mappings >= PAGE_SIZE").
> 
> Good catch, thanks!
> 
> After applying 14cebf689a78 ("swiotlb: Reinstate> page-alignment for
> mappings >= PAGE_SIZE")
> on top of 6.6.33 I no longer have the flood of alignment warnings and
> iwlwifi can be used again:
> 
> # dmesg | grep iwlwifi
> [    4.295064] iwlwifi 0000:01:00.0: enabling device (0000 -> 0002)
> [    4.305459] iwlwifi 0000:01:00.0: Detected crf-id 0x3617, cnv-id
> 0x100530 wfpm id 0x80000000
> [    4.315440] iwlwifi 0000:01:00.0: PCI dev 2723/0084, rev=0x340, rfid=0x10a100
> [    4.346029] iwlwifi 0000:01:00.0: api flags index 2 larger than
> supported by driver
> [    4.353816] iwlwifi 0000:01:00.0: TLV_FW_FSEQ_VERSION: FSEQ
> Version: 89.3.35.37
> [    4.363135] iwlwifi 0000:01:00.0: loaded firmware version
> 77.ad46c98b.0 cc-a0-77.ucode op_mode iwlmvm
> [    4.444427] iwlwifi 0000:01:00.0: Detected Intel(R) Wi-Fi 6 AX200
> 160MHz, REV=0x340
> [    4.604918] iwlwifi 0000:01:00.0: Detected RF HR B3, rfid=0x10a100
> [    4.676138] iwlwifi 0000:01:00.0: base HW address: 3c:21:9c:4e:16:6x
> [    5.339929] iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0
> [    9.840136] iwlwifi 0000:01:00.0: Registered PHC clock:
> iwlwifi-PTP, with index: 1
> 
> Will, is it OK for me to ask the stable folks to backport 14cebf689a78
> ("swiotlb: Reinstate> page-alignment for mappings >= PAGE_SIZE")
> to 6.6 stable?

If you want to backport that change, then I think you should probably
take the whole series:

https://lore.kernel.org/all/20240308152829.25754-1-will@kernel.org/

(and there were some follow-ups from Michael iirc; you're best off
checking the git history for kernel/dma/swiotlb.c).

FWIW: we have this series backported to 6.6 in the android15-6.6 tree.

Will

Re: iwlwifi: Regression after migrating to 6.6.32

[Fabio Estevam]

Hi Will,

On Mon, Jun 17, 2024 at 9:08 AM Will Deacon <will@kernel.org> wrote:

> If you want to backport that change, then I think you should probably
> take the whole series:
>
> https://lore.kernel.org/all/20240308152829.25754-1-will@kernel.org/
>
> (and there were some follow-ups from Michael iirc; you're best off
> checking the git history for kernel/dma/swiotlb.c).
>
> FWIW: we have this series backported to 6.6 in the android15-6.6 tree.

Thanks for the suggestion.

From this series, only the two patches below are not present in the
6.6 stable tree:

swiotlb: Enforce page alignment in swiotlb_alloc()
swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE

I will submit these two to stable and also an additional one:

swiotlb: extend buffer pre-padding to alloc_align_mask if necessary

Thanks,

Fabio Estevam