* iwlwifi: Regression after migrating to 6.6.32 @ 2024-06-11 11:46 Fabio Estevam 2024-06-11 12:52 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Fabio Estevam @ 2024-06-11 11:46 UTC (permalink / raw) To: miriam.rachel.korenblit, kvalo, johannes.berg Cc: Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 11:46 iwlwifi: Regression after migrating to 6.6.32 Fabio Estevam @ 2024-06-11 12:52 ` Johannes Berg 2024-06-11 13:43 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-11 12:52 UTC (permalink / raw) To: Fabio Estevam, miriam.rachel.korenblit, kvalo Cc: Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 12:52 ` Johannes Berg @ 2024-06-11 13:43 ` Fabio Estevam 2024-06-11 13:54 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Fabio Estevam @ 2024-06-11 13:43 UTC (permalink / raw) To: Johannes Berg Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 13:43 ` Fabio Estevam @ 2024-06-11 13:54 ` Johannes Berg 2024-06-11 14:32 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-11 13:54 UTC (permalink / raw) To: Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 13:54 ` Johannes Berg @ 2024-06-11 14:32 ` Fabio Estevam 2024-06-11 14:50 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Fabio Estevam @ 2024-06-11 14:32 UTC (permalink / raw) To: Johannes Berg Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 14:32 ` Fabio Estevam @ 2024-06-11 14:50 ` Johannes Berg 2024-06-11 14:59 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-11 14:50 UTC (permalink / raw) To: Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 14:50 ` Johannes Berg @ 2024-06-11 14:59 ` Fabio Estevam 2024-06-12 19:10 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Fabio Estevam @ 2024-06-11 14:59 UTC (permalink / raw) To: Johannes Berg Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-11 14:59 ` Fabio Estevam @ 2024-06-12 19:10 ` Johannes Berg 2024-06-12 19:15 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-12 19:10 UTC (permalink / raw) To: Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-12 19:10 ` Johannes Berg @ 2024-06-12 19:15 ` Fabio Estevam 2024-06-13 6:58 ` Johannes Berg 2024-06-13 7:10 ` Baochen Qiang 0 siblings, 2 replies; 17+ messages in thread From: Fabio Estevam @ 2024-06-12 19:15 UTC (permalink / raw) To: Johannes Berg Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-12 19:15 ` Fabio Estevam @ 2024-06-13 6:58 ` Johannes Berg 2024-06-13 7:10 ` Baochen Qiang 1 sibling, 0 replies; 17+ messages in thread From: Johannes Berg @ 2024-06-13 6:58 UTC (permalink / raw) To: Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-12 19:15 ` Fabio Estevam 2024-06-13 6:58 ` Johannes Berg @ 2024-06-13 7:10 ` Baochen Qiang 2024-06-13 7:40 ` Johannes Berg 1 sibling, 1 reply; 17+ messages in thread From: Baochen Qiang @ 2024-06-13 7:10 UTC (permalink / raw) To: Fabio Estevam, Johannes Berg Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-13 7:10 ` Baochen Qiang @ 2024-06-13 7:40 ` Johannes Berg 2024-06-13 9:51 ` Baochen Qiang 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-13 7:40 UTC (permalink / raw) To: Baochen Qiang, Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-13 7:40 ` Johannes Berg @ 2024-06-13 9:51 ` Baochen Qiang 2024-06-13 10:36 ` Johannes Berg 0 siblings, 1 reply; 17+ messages in thread From: Baochen Qiang @ 2024-06-13 9:51 UTC (permalink / raw) To: Johannes Berg, Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-13 9:51 ` Baochen Qiang @ 2024-06-13 10:36 ` Johannes Berg 2024-06-13 20:15 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Johannes Berg @ 2024-06-13 10:36 UTC (permalink / raw) To: Baochen Qiang, Fabio Estevam Cc: miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-13 10:36 ` Johannes Berg @ 2024-06-13 20:15 ` Fabio Estevam 2024-06-17 12:08 ` Will Deacon 0 siblings, 1 reply; 17+ messages in thread From: Fabio Estevam @ 2024-06-13 20:15 UTC (permalink / raw) To: Johannes Berg, Will Deacon Cc: Baochen Qiang, miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-13 20:15 ` Fabio Estevam @ 2024-06-17 12:08 ` Will Deacon 2024-06-17 14:08 ` Fabio Estevam 0 siblings, 1 reply; 17+ messages in thread From: Will Deacon @ 2024-06-17 12:08 UTC (permalink / raw) To: Fabio Estevam Cc: Johannes Berg, Baochen Qiang, miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: iwlwifi: Regression after migrating to 6.6.32 2024-06-17 12:08 ` Will Deacon @ 2024-06-17 14:08 ` Fabio Estevam 0 siblings, 0 replies; 17+ messages in thread From: Fabio Estevam @ 2024-06-17 14:08 UTC (permalink / raw) To: Will Deacon Cc: Johannes Berg, Baochen Qiang, miriam.rachel.korenblit, kvalo, Jakub Kicinski, linux-wireless, linux-kernel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2024-06-17 14:08 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-11 11:46 iwlwifi: Regression after migrating to 6.6.32 Fabio Estevam 2024-06-11 12:52 ` Johannes Berg 2024-06-11 13:43 ` Fabio Estevam 2024-06-11 13:54 ` Johannes Berg 2024-06-11 14:32 ` Fabio Estevam 2024-06-11 14:50 ` Johannes Berg 2024-06-11 14:59 ` Fabio Estevam 2024-06-12 19:10 ` Johannes Berg 2024-06-12 19:15 ` Fabio Estevam 2024-06-13 6:58 ` Johannes Berg 2024-06-13 7:10 ` Baochen Qiang 2024-06-13 7:40 ` Johannes Berg 2024-06-13 9:51 ` Baochen Qiang 2024-06-13 10:36 ` Johannes Berg 2024-06-13 20:15 ` Fabio Estevam 2024-06-17 12:08 ` Will Deacon 2024-06-17 14:08 ` Fabio Estevam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®