* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase [not found] ` <20220624072740.GA12171@thinkpad> @ 2022-07-18 11:15 ` Kalle Valo 2022-07-20 9:39 ` Manivannan Sadhasivam 0 siblings, 1 reply; 8+ messages in thread From: Kalle Valo @ 2022-07-18 11:15 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k + ath11k list Manivannan Sadhasivam <mani@kernel.org> writes: > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: >> During runtime, the MHI endpoint may be powered up/down several times. >> So instead of allocating and destroying the IRQs all the time, let's just >> enable/disable IRQs during power up/down. >> >> The IRQs will be allocated during mhi_register_controller() and freed >> during mhi_unregister_controller(). This works well for things like PCI >> hotplug also as once the PCI device gets removed, the controller will >> get unregistered. And once it comes back, it will get registered back >> and even if the IRQ configuration changes (MSI), that will get accounted. >> >> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > Applied to mhi-next! I did a bisect and this patch breaks ath11k during rmmod. I'm on vacation right now so I can't investigate in detail but more info below. [ 66.939878] rmmod ath11k_pci [ 67.606269] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI [ 67.606328] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 67.606387] CPU: 3 PID: 1463 Comm: rmmod Not tainted 5.19.0-rc1+ #669 [ 67.606456] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 67.606492] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] [ 67.606565] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 [ 67.606639] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 [ 67.606706] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: 0000000000000001 [ 67.606742] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: ffff888110e8d120 [ 67.606776] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffff86ac17af [ 67.606810] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: ffff88812c3afb80 [ 67.606845] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: ffff88812e1e2800 [ 67.606880] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) knlGS:0000000000000000 [ 67.606915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 67.606950] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: 00000000003706e0 [ 67.606987] Call Trace: [ 67.607021] <TASK> [ 67.607056] __free_irq+0x590/0x9d0 [ 67.607099] ? slab_free_freelist_hook+0xf0/0x1a0 [ 67.607136] free_irq+0x7b/0x110 [ 67.607171] mhi_deinit_free_irq+0x14e/0x260 [mhi] [ 67.607210] mhi_unregister_controller+0x69/0x290 [mhi] [ 67.607249] ath11k_mhi_unregister+0x2b/0x70 [ath11k_pci] [ 67.607284] ath11k_pci_remove+0x107/0x2a0 [ath11k_pci] [ 67.607321] pci_device_remove+0x89/0x1b0 [ 67.607359] device_release_driver_internal+0x3bc/0x600 [ 67.607400] driver_detach+0xbc/0x180 [ 67.607439] bus_remove_driver+0xe2/0x2d0 [ 67.607476] pci_unregister_driver+0x21/0x250 [ 67.607512] __do_sys_delete_module+0x307/0x4b0 [ 67.607548] ? free_module+0x4e0/0x4e0 [ 67.607584] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 67.607618] ? syscall_enter_from_user_mode+0x1d/0x50 [ 67.607653] ? lockdep_hardirqs_on+0x79/0x100 [ 67.607688] do_syscall_64+0x35/0x80 [ 67.607723] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 67.607758] RIP: 0033:0x7fef008e1a6b [ 67.607794] Code: 73 01 c3 48 8b 0d 25 c4 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 c3 0c 00 f7 d8 64 89 01 48 [ 67.607836] RSP: 002b:00007ffdd5803a38 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 67.607873] RAX: ffffffffffffffda RBX: 000055c0d3f107a0 RCX: 00007fef008e1a6b [ 67.607961] RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055c0d3f10808 [ 67.607995] RBP: 00007ffdd5803a98 R08: 0000000000000000 R09: 0000000000000000 [ 67.608029] R10: 00007fef0095dac0 R11: 0000000000000206 R12: 00007ffdd5803c70 [ 67.608063] R13: 00007ffdd5804eb7 R14: 000055c0d3f0f2a0 R15: 000055c0d3f107a0 [ 67.608100] </TASK> [ 67.608134] Modules linked in: ath11k_pci(-) ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core [ 67.608185] ---[ end trace 0000000000000000 ]--- [ 67.608186] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] [ 67.608192] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 [ 67.608194] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 [ 67.608196] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: 0000000000000001 [ 67.608197] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: ffff888110e8d120 [ 67.608198] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffff86ac17af [ 67.608199] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: ffff88812c3afb80 [ 67.608200] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: ffff88812e1e2800 [ 67.608201] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) knlGS:0000000000000000 [ 67.608203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 67.608204] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: 00000000003706e0 [ 67.608206] Kernel panic - not syncing: Fatal exception [ 67.608665] Kernel Offset: 0xa00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 67.608704] Rebooting in 10 seconds.. git bisect start # bad: [9df125af0822d3e2bde7508e9536d67ab541a166] bus: mhi: ep: Check dev_set_name() return value git bisect bad 9df125af0822d3e2bde7508e9536d67ab541a166 # good: [178329d4d635fb1848cc7ca1803dee5a634cde0d] bus: mhi: host: pci_generic: Add support for Quectel EM120 FCCL modem git bisect good 178329d4d635fb1848cc7ca1803dee5a634cde0d # bad: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase git bisect bad 1227d2a20cd7319fb45c62fab4b252600e0308bf # good: [b7ce716254315dffcfce60e149ddd022c8a60345] bus: mhi: host: pci_generic: Add Cinterion MV31-W with new baseline git bisect good b7ce716254315dffcfce60e149ddd022c8a60345 # first bad commit: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-18 11:15 ` [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase Kalle Valo @ 2022-07-20 9:39 ` Manivannan Sadhasivam 2022-07-20 9:47 ` Qiang Yu 2022-07-25 17:57 ` Kalle Valo 0 siblings, 2 replies; 8+ messages in thread From: Manivannan Sadhasivam @ 2022-07-20 9:39 UTC (permalink / raw) To: Kalle Valo Cc: Manivannan Sadhasivam, Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: > + ath11k list > > Manivannan Sadhasivam <mani@kernel.org> writes: > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: > >> During runtime, the MHI endpoint may be powered up/down several times. > >> So instead of allocating and destroying the IRQs all the time, let's just > >> enable/disable IRQs during power up/down. > >> > >> The IRQs will be allocated during mhi_register_controller() and freed > >> during mhi_unregister_controller(). This works well for things like PCI > >> hotplug also as once the PCI device gets removed, the controller will > >> get unregistered. And once it comes back, it will get registered back > >> and even if the IRQ configuration changes (MSI), that will get accounted. > >> > >> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > Applied to mhi-next! > > I did a bisect and this patch breaks ath11k during rmmod. I'm on > vacation right now so I can't investigate in detail but more info below. > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. log: https://paste.debian.net/1247788/ Thanks, Mani > [ 66.939878] rmmod ath11k_pci > [ 67.606269] general protection fault, probably for non-canonical > address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN > PTI > [ 67.606328] KASAN: null-ptr-deref in range > [0x0000000000000000-0x0000000000000007] > [ 67.606387] CPU: 3 PID: 1463 Comm: rmmod Not tainted 5.19.0-rc1+ #669 > [ 67.606456] Hardware name: Intel(R) Client Systems > NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 > [ 67.606492] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] > [ 67.606565] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 > 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea > 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 > [ 67.606639] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 > [ 67.606706] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: > 0000000000000001 > [ 67.606742] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: > ffff888110e8d120 > [ 67.606776] RBP: 0000000000000000 R08: 0000000000000001 R09: > ffffffff86ac17af > [ 67.606810] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: > ffff88812c3afb80 > [ 67.606845] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: > ffff88812e1e2800 > [ 67.606880] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) > knlGS:0000000000000000 > [ 67.606915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 67.606950] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: > 00000000003706e0 > [ 67.606987] Call Trace: > [ 67.607021] <TASK> > [ 67.607056] __free_irq+0x590/0x9d0 > [ 67.607099] ? slab_free_freelist_hook+0xf0/0x1a0 > [ 67.607136] free_irq+0x7b/0x110 > [ 67.607171] mhi_deinit_free_irq+0x14e/0x260 [mhi] > [ 67.607210] mhi_unregister_controller+0x69/0x290 [mhi] > [ 67.607249] ath11k_mhi_unregister+0x2b/0x70 [ath11k_pci] > [ 67.607284] ath11k_pci_remove+0x107/0x2a0 [ath11k_pci] > [ 67.607321] pci_device_remove+0x89/0x1b0 > [ 67.607359] device_release_driver_internal+0x3bc/0x600 > [ 67.607400] driver_detach+0xbc/0x180 > [ 67.607439] bus_remove_driver+0xe2/0x2d0 > [ 67.607476] pci_unregister_driver+0x21/0x250 > [ 67.607512] __do_sys_delete_module+0x307/0x4b0 > [ 67.607548] ? free_module+0x4e0/0x4e0 > [ 67.607584] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 > [ 67.607618] ? syscall_enter_from_user_mode+0x1d/0x50 > [ 67.607653] ? lockdep_hardirqs_on+0x79/0x100 > [ 67.607688] do_syscall_64+0x35/0x80 > [ 67.607723] entry_SYSCALL_64_after_hwframe+0x46/0xb0 > [ 67.607758] RIP: 0033:0x7fef008e1a6b > [ 67.607794] Code: 73 01 c3 48 8b 0d 25 c4 0c 00 f7 d8 64 89 01 48 83 > c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 c3 0c 00 f7 d8 64 89 01 48 > [ 67.607836] RSP: 002b:00007ffdd5803a38 EFLAGS: 00000206 ORIG_RAX: > 00000000000000b0 > [ 67.607873] RAX: ffffffffffffffda RBX: 000055c0d3f107a0 RCX: > 00007fef008e1a6b > [ 67.607961] RDX: 000000000000000a RSI: 0000000000000800 RDI: > 000055c0d3f10808 > [ 67.607995] RBP: 00007ffdd5803a98 R08: 0000000000000000 R09: > 0000000000000000 > [ 67.608029] R10: 00007fef0095dac0 R11: 0000000000000206 R12: > 00007ffdd5803c70 > [ 67.608063] R13: 00007ffdd5804eb7 R14: 000055c0d3f0f2a0 R15: > 000055c0d3f107a0 > [ 67.608100] </TASK> > [ 67.608134] Modules linked in: ath11k_pci(-) ath11k mac80211 libarc4 > cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core > [ 67.608185] ---[ end trace 0000000000000000 ]--- > [ 67.608186] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] > [ 67.608192] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 > 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea > 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 > [ 67.608194] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 > [ 67.608196] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: > 0000000000000001 > [ 67.608197] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: > ffff888110e8d120 > [ 67.608198] RBP: 0000000000000000 R08: 0000000000000001 R09: > ffffffff86ac17af > [ 67.608199] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: > ffff88812c3afb80 > [ 67.608200] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: > ffff88812e1e2800 > [ 67.608201] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) > knlGS:0000000000000000 > [ 67.608203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 67.608204] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: > 00000000003706e0 > [ 67.608206] Kernel panic - not syncing: Fatal exception > [ 67.608665] Kernel Offset: 0xa00000 from 0xffffffff81000000 > (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 67.608704] Rebooting in 10 seconds.. > > git bisect start > # bad: [9df125af0822d3e2bde7508e9536d67ab541a166] bus: mhi: ep: Check dev_set_name() return value > git bisect bad 9df125af0822d3e2bde7508e9536d67ab541a166 > # good: [178329d4d635fb1848cc7ca1803dee5a634cde0d] bus: mhi: host: pci_generic: Add support for Quectel EM120 FCCL modem > git bisect good 178329d4d635fb1848cc7ca1803dee5a634cde0d > # bad: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase > git bisect bad 1227d2a20cd7319fb45c62fab4b252600e0308bf > # good: [b7ce716254315dffcfce60e149ddd022c8a60345] bus: mhi: host: pci_generic: Add Cinterion MV31-W with new baseline > git bisect good b7ce716254315dffcfce60e149ddd022c8a60345 > # first bad commit: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > -- மணிவண்ணன் சதாசிவம் -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-20 9:39 ` Manivannan Sadhasivam @ 2022-07-20 9:47 ` Qiang Yu 2022-07-21 10:19 ` Manivannan Sadhasivam 2022-07-25 17:57 ` Kalle Valo 1 sibling, 1 reply; 8+ messages in thread From: Qiang Yu @ 2022-07-20 9:47 UTC (permalink / raw) To: Manivannan Sadhasivam, Kalle Valo Cc: quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote: > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: >> + ath11k list >> >> Manivannan Sadhasivam <mani@kernel.org> writes: >> >>> On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: >>>> During runtime, the MHI endpoint may be powered up/down several times. >>>> So instead of allocating and destroying the IRQs all the time, let's just >>>> enable/disable IRQs during power up/down. >>>> >>>> The IRQs will be allocated during mhi_register_controller() and freed >>>> during mhi_unregister_controller(). This works well for things like PCI >>>> hotplug also as once the PCI device gets removed, the controller will >>>> get unregistered. And once it comes back, it will get registered back >>>> and even if the IRQ configuration changes (MSI), that will get accounted. >>>> >>>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >>> Applied to mhi-next! >> I did a bisect and this patch breaks ath11k during rmmod. I'm on >> vacation right now so I can't investigate in detail but more info below. >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq handler for a shared IRQ will be invoked and null pointer access happen. #ifdef CONFIG_DEBUG_SHIRQ /* * It's a shared IRQ -- the driver ought to be prepared for an IRQ * event to happen even now it's being freed, so let's make sure that * is so by doing an extra call to the handler .... * * ( We do this after actually deregistering it, to make sure that a * 'real' IRQ doesn't run in parallel with our fake. ) */ if (action->flags & IRQF_SHARED) { local_irq_save(flags); action->handler(irq, dev_id); local_irq_restore(flags); } #endif > > log: https://paste.debian.net/1247788/ > > Thanks, > Mani > >> [ 66.939878] rmmod ath11k_pci >> [ 67.606269] general protection fault, probably for non-canonical >> address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN >> PTI >> [ 67.606328] KASAN: null-ptr-deref in range >> [0x0000000000000000-0x0000000000000007] >> [ 67.606387] CPU: 3 PID: 1463 Comm: rmmod Not tainted 5.19.0-rc1+ #669 >> [ 67.606456] Hardware name: Intel(R) Client Systems >> NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 >> [ 67.606492] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] >> [ 67.606565] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 >> 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea >> 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 >> [ 67.606639] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 >> [ 67.606706] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: >> 0000000000000001 >> [ 67.606742] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: >> ffff888110e8d120 >> [ 67.606776] RBP: 0000000000000000 R08: 0000000000000001 R09: >> ffffffff86ac17af >> [ 67.606810] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: >> ffff88812c3afb80 >> [ 67.606845] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: >> ffff88812e1e2800 >> [ 67.606880] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) >> knlGS:0000000000000000 >> [ 67.606915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 67.606950] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: >> 00000000003706e0 >> [ 67.606987] Call Trace: >> [ 67.607021] <TASK> >> [ 67.607056] __free_irq+0x590/0x9d0 >> [ 67.607099] ? slab_free_freelist_hook+0xf0/0x1a0 >> [ 67.607136] free_irq+0x7b/0x110 >> [ 67.607171] mhi_deinit_free_irq+0x14e/0x260 [mhi] >> [ 67.607210] mhi_unregister_controller+0x69/0x290 [mhi] >> [ 67.607249] ath11k_mhi_unregister+0x2b/0x70 [ath11k_pci] >> [ 67.607284] ath11k_pci_remove+0x107/0x2a0 [ath11k_pci] >> [ 67.607321] pci_device_remove+0x89/0x1b0 >> [ 67.607359] device_release_driver_internal+0x3bc/0x600 >> [ 67.607400] driver_detach+0xbc/0x180 >> [ 67.607439] bus_remove_driver+0xe2/0x2d0 >> [ 67.607476] pci_unregister_driver+0x21/0x250 >> [ 67.607512] __do_sys_delete_module+0x307/0x4b0 >> [ 67.607548] ? free_module+0x4e0/0x4e0 >> [ 67.607584] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 >> [ 67.607618] ? syscall_enter_from_user_mode+0x1d/0x50 >> [ 67.607653] ? lockdep_hardirqs_on+0x79/0x100 >> [ 67.607688] do_syscall_64+0x35/0x80 >> [ 67.607723] entry_SYSCALL_64_after_hwframe+0x46/0xb0 >> [ 67.607758] RIP: 0033:0x7fef008e1a6b >> [ 67.607794] Code: 73 01 c3 48 8b 0d 25 c4 0c 00 f7 d8 64 89 01 48 83 >> c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f >> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 c3 0c 00 f7 d8 64 89 01 48 >> [ 67.607836] RSP: 002b:00007ffdd5803a38 EFLAGS: 00000206 ORIG_RAX: >> 00000000000000b0 >> [ 67.607873] RAX: ffffffffffffffda RBX: 000055c0d3f107a0 RCX: >> 00007fef008e1a6b >> [ 67.607961] RDX: 000000000000000a RSI: 0000000000000800 RDI: >> 000055c0d3f10808 >> [ 67.607995] RBP: 00007ffdd5803a98 R08: 0000000000000000 R09: >> 0000000000000000 >> [ 67.608029] R10: 00007fef0095dac0 R11: 0000000000000206 R12: >> 00007ffdd5803c70 >> [ 67.608063] R13: 00007ffdd5804eb7 R14: 000055c0d3f0f2a0 R15: >> 000055c0d3f107a0 >> [ 67.608100] </TASK> >> [ 67.608134] Modules linked in: ath11k_pci(-) ath11k mac80211 libarc4 >> cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core >> [ 67.608185] ---[ end trace 0000000000000000 ]--- >> [ 67.608186] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] >> [ 67.608192] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 >> 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea >> 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 >> [ 67.608194] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 >> [ 67.608196] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: >> 0000000000000001 >> [ 67.608197] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: >> ffff888110e8d120 >> [ 67.608198] RBP: 0000000000000000 R08: 0000000000000001 R09: >> ffffffff86ac17af >> [ 67.608199] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: >> ffff88812c3afb80 >> [ 67.608200] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: >> ffff88812e1e2800 >> [ 67.608201] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) >> knlGS:0000000000000000 >> [ 67.608203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 67.608204] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: >> 00000000003706e0 >> [ 67.608206] Kernel panic - not syncing: Fatal exception >> [ 67.608665] Kernel Offset: 0xa00000 from 0xffffffff81000000 >> (relocation range: 0xffffffff80000000-0xffffffffbfffffff) >> [ 67.608704] Rebooting in 10 seconds.. >> >> git bisect start >> # bad: [9df125af0822d3e2bde7508e9536d67ab541a166] bus: mhi: ep: Check dev_set_name() return value >> git bisect bad 9df125af0822d3e2bde7508e9536d67ab541a166 >> # good: [178329d4d635fb1848cc7ca1803dee5a634cde0d] bus: mhi: host: pci_generic: Add support for Quectel EM120 FCCL modem >> git bisect good 178329d4d635fb1848cc7ca1803dee5a634cde0d >> # bad: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase >> git bisect bad 1227d2a20cd7319fb45c62fab4b252600e0308bf >> # good: [b7ce716254315dffcfce60e149ddd022c8a60345] bus: mhi: host: pci_generic: Add Cinterion MV31-W with new baseline >> git bisect good b7ce716254315dffcfce60e149ddd022c8a60345 >> # first bad commit: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase >> >> -- >> https://patchwork.kernel.org/project/linux-wireless/list/ >> >> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches >> -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-20 9:47 ` Qiang Yu @ 2022-07-21 10:19 ` Manivannan Sadhasivam 2022-07-25 18:00 ` Kalle Valo 0 siblings, 1 reply; 8+ messages in thread From: Manivannan Sadhasivam @ 2022-07-21 10:19 UTC (permalink / raw) To: Qiang Yu Cc: Manivannan Sadhasivam, Kalle Valo, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote: > > On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote: > > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: > > > + ath11k list > > > > > > Manivannan Sadhasivam <mani@kernel.org> writes: > > > > > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: > > > > > During runtime, the MHI endpoint may be powered up/down several times. > > > > > So instead of allocating and destroying the IRQs all the time, let's just > > > > > enable/disable IRQs during power up/down. > > > > > > > > > > The IRQs will be allocated during mhi_register_controller() and freed > > > > > during mhi_unregister_controller(). This works well for things like PCI > > > > > hotplug also as once the PCI device gets removed, the controller will > > > > > get unregistered. And once it comes back, it will get registered back > > > > > and even if the IRQ configuration changes (MSI), that will get accounted. > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > Applied to mhi-next! > > > I did a bisect and this patch breaks ath11k during rmmod. I'm on > > > vacation right now so I can't investigate in detail but more info below. > > > > > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm > > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. > > I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq > handler for a shared IRQ will be invoked and null pointer access happen. > > #ifdef CONFIG_DEBUG_SHIRQ > /* > * It's a shared IRQ -- the driver ought to be prepared for an IRQ > * event to happen even now it's being freed, so let's make sure that > * is so by doing an extra call to the handler .... > * > * ( We do this after actually deregistering it, to make sure that a > * 'real' IRQ doesn't run in parallel with our fake. ) > */ > if (action->flags & IRQF_SHARED) { > local_irq_save(flags); > action->handler(irq, dev_id); > local_irq_restore(flags); > } > #endif > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue. Thanks, Mani > > > > log: https://paste.debian.net/1247788/ > > > > Thanks, > > Mani > > > > > [ 66.939878] rmmod ath11k_pci > > > [ 67.606269] general protection fault, probably for non-canonical > > > address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN > > > PTI > > > [ 67.606328] KASAN: null-ptr-deref in range > > > [0x0000000000000000-0x0000000000000007] > > > [ 67.606387] CPU: 3 PID: 1463 Comm: rmmod Not tainted 5.19.0-rc1+ #669 > > > [ 67.606456] Hardware name: Intel(R) Client Systems > > > NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 > > > [ 67.606492] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] > > > [ 67.606565] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 > > > 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea > > > 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 > > > [ 67.606639] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 > > > [ 67.606706] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: > > > 0000000000000001 > > > [ 67.606742] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: > > > ffff888110e8d120 > > > [ 67.606776] RBP: 0000000000000000 R08: 0000000000000001 R09: > > > ffffffff86ac17af > > > [ 67.606810] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: > > > ffff88812c3afb80 > > > [ 67.606845] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: > > > ffff88812e1e2800 > > > [ 67.606880] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) > > > knlGS:0000000000000000 > > > [ 67.606915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > [ 67.606950] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: > > > 00000000003706e0 > > > [ 67.606987] Call Trace: > > > [ 67.607021] <TASK> > > > [ 67.607056] __free_irq+0x590/0x9d0 > > > [ 67.607099] ? slab_free_freelist_hook+0xf0/0x1a0 > > > [ 67.607136] free_irq+0x7b/0x110 > > > [ 67.607171] mhi_deinit_free_irq+0x14e/0x260 [mhi] > > > [ 67.607210] mhi_unregister_controller+0x69/0x290 [mhi] > > > [ 67.607249] ath11k_mhi_unregister+0x2b/0x70 [ath11k_pci] > > > [ 67.607284] ath11k_pci_remove+0x107/0x2a0 [ath11k_pci] > > > [ 67.607321] pci_device_remove+0x89/0x1b0 > > > [ 67.607359] device_release_driver_internal+0x3bc/0x600 > > > [ 67.607400] driver_detach+0xbc/0x180 > > > [ 67.607439] bus_remove_driver+0xe2/0x2d0 > > > [ 67.607476] pci_unregister_driver+0x21/0x250 > > > [ 67.607512] __do_sys_delete_module+0x307/0x4b0 > > > [ 67.607548] ? free_module+0x4e0/0x4e0 > > > [ 67.607584] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 > > > [ 67.607618] ? syscall_enter_from_user_mode+0x1d/0x50 > > > [ 67.607653] ? lockdep_hardirqs_on+0x79/0x100 > > > [ 67.607688] do_syscall_64+0x35/0x80 > > > [ 67.607723] entry_SYSCALL_64_after_hwframe+0x46/0xb0 > > > [ 67.607758] RIP: 0033:0x7fef008e1a6b > > > [ 67.607794] Code: 73 01 c3 48 8b 0d 25 c4 0c 00 f7 d8 64 89 01 48 83 > > > c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f > > > 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 c3 0c 00 f7 d8 64 89 01 48 > > > [ 67.607836] RSP: 002b:00007ffdd5803a38 EFLAGS: 00000206 ORIG_RAX: > > > 00000000000000b0 > > > [ 67.607873] RAX: ffffffffffffffda RBX: 000055c0d3f107a0 RCX: > > > 00007fef008e1a6b > > > [ 67.607961] RDX: 000000000000000a RSI: 0000000000000800 RDI: > > > 000055c0d3f10808 > > > [ 67.607995] RBP: 00007ffdd5803a98 R08: 0000000000000000 R09: > > > 0000000000000000 > > > [ 67.608029] R10: 00007fef0095dac0 R11: 0000000000000206 R12: > > > 00007ffdd5803c70 > > > [ 67.608063] R13: 00007ffdd5804eb7 R14: 000055c0d3f0f2a0 R15: > > > 000055c0d3f107a0 > > > [ 67.608100] </TASK> > > > [ 67.608134] Modules linked in: ath11k_pci(-) ath11k mac80211 libarc4 > > > cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core > > > [ 67.608185] ---[ end trace 0000000000000000 ]--- > > > [ 67.608186] RIP: 0010:mhi_irq_handler+0x61/0x370 [mhi] > > > [ 67.608192] Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 9b 02 00 > > > 00 49 8b ad 20 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea > > > 03 <80> 3c 02 00 0f 85 bd 02 00 00 48 8d 7b 10 48 8b 6d 00 48 b8 00 00 > > > [ 67.608194] RSP: 0018:ffffc900042ffba8 EFLAGS: 00010046 > > > [ 67.608196] RAX: dffffc0000000000 RBX: ffff88812e1e2800 RCX: > > > 0000000000000001 > > > [ 67.608197] RDX: 0000000000000000 RSI: ffff88812e1e2800 RDI: > > > ffff888110e8d120 > > > [ 67.608198] RBP: 0000000000000000 R08: 0000000000000001 R09: > > > ffffffff86ac17af > > > [ 67.608199] R10: fffffbfff0d582f5 R11: 0000000000000001 R12: > > > ffff88812c3afb80 > > > [ 67.608200] R13: ffff888110e8d000 R14: ffff88811ddba800 R15: > > > ffff88812e1e2800 > > > [ 67.608201] FS: 00007fef00794740(0000) GS:ffff888234200000(0000) > > > knlGS:0000000000000000 > > > [ 67.608203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > [ 67.608204] CR2: 000055df2323b788 CR3: 0000000109844001 CR4: > > > 00000000003706e0 > > > [ 67.608206] Kernel panic - not syncing: Fatal exception > > > [ 67.608665] Kernel Offset: 0xa00000 from 0xffffffff81000000 > > > (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > > > [ 67.608704] Rebooting in 10 seconds.. > > > > > > git bisect start > > > # bad: [9df125af0822d3e2bde7508e9536d67ab541a166] bus: mhi: ep: Check dev_set_name() return value > > > git bisect bad 9df125af0822d3e2bde7508e9536d67ab541a166 > > > # good: [178329d4d635fb1848cc7ca1803dee5a634cde0d] bus: mhi: host: pci_generic: Add support for Quectel EM120 FCCL modem > > > git bisect good 178329d4d635fb1848cc7ca1803dee5a634cde0d > > > # bad: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase > > > git bisect bad 1227d2a20cd7319fb45c62fab4b252600e0308bf > > > # good: [b7ce716254315dffcfce60e149ddd022c8a60345] bus: mhi: host: pci_generic: Add Cinterion MV31-W with new baseline > > > git bisect good b7ce716254315dffcfce60e149ddd022c8a60345 > > > # first bad commit: [1227d2a20cd7319fb45c62fab4b252600e0308bf] bus: mhi: host: Move IRQ allocation to controller registration phase > > > > > > -- > > > https://patchwork.kernel.org/project/linux-wireless/list/ > > > > > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > > > > -- மணிவண்ணன் சதாசிவம் -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-21 10:19 ` Manivannan Sadhasivam @ 2022-07-25 18:00 ` Kalle Valo 2022-07-26 8:09 ` Manivannan Sadhasivam 0 siblings, 1 reply; 8+ messages in thread From: Kalle Valo @ 2022-07-25 18:00 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k Manivannan Sadhasivam <mani@kernel.org> writes: > On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote: > >> >> On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote: >> > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: >> > > + ath11k list >> > > >> > > Manivannan Sadhasivam <mani@kernel.org> writes: >> > > >> > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: >> > > > > During runtime, the MHI endpoint may be powered up/down several times. >> > > > > So instead of allocating and destroying the IRQs all the time, let's just >> > > > > enable/disable IRQs during power up/down. >> > > > > >> > > > > The IRQs will be allocated during mhi_register_controller() and freed >> > > > > during mhi_unregister_controller(). This works well for things like PCI >> > > > > hotplug also as once the PCI device gets removed, the controller will >> > > > > get unregistered. And once it comes back, it will get registered back >> > > > > and even if the IRQ configuration changes (MSI), that will get accounted. >> > > > > >> > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >> > > > Applied to mhi-next! >> > > I did a bisect and this patch breaks ath11k during rmmod. I'm on >> > > vacation right now so I can't investigate in detail but more info below. >> > > >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm >> > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. >> >> I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq >> handler for a shared IRQ will be invoked and null pointer access happen. >> >> #ifdef CONFIG_DEBUG_SHIRQ >> /* >> * It's a shared IRQ -- the driver ought to be prepared for an IRQ >> * event to happen even now it's being freed, so let's make sure that >> * is so by doing an extra call to the handler .... >> * >> * ( We do this after actually deregistering it, to make sure that a >> * 'real' IRQ doesn't run in parallel with our fake. ) >> */ >> if (action->flags & IRQF_SHARED) { >> local_irq_save(flags); >> action->handler(irq, dev_id); >> local_irq_restore(flags); >> } >> #endif >> > > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue. So how to fix this regression? (If there's already a fix I might have missed it as I came back only today) -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-25 18:00 ` Kalle Valo @ 2022-07-26 8:09 ` Manivannan Sadhasivam 2022-07-26 17:48 ` Kalle Valo 0 siblings, 1 reply; 8+ messages in thread From: Manivannan Sadhasivam @ 2022-07-26 8:09 UTC (permalink / raw) To: Kalle Valo Cc: Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k On Mon, Jul 25, 2022 at 09:00:08PM +0300, Kalle Valo wrote: > Manivannan Sadhasivam <mani@kernel.org> writes: > > > On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote: > > > >> > >> On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote: > >> > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: > >> > > + ath11k list > >> > > > >> > > Manivannan Sadhasivam <mani@kernel.org> writes: > >> > > > >> > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: > >> > > > > During runtime, the MHI endpoint may be powered up/down several times. > >> > > > > So instead of allocating and destroying the IRQs all the time, let's just > >> > > > > enable/disable IRQs during power up/down. > >> > > > > > >> > > > > The IRQs will be allocated during mhi_register_controller() and freed > >> > > > > during mhi_unregister_controller(). This works well for things like PCI > >> > > > > hotplug also as once the PCI device gets removed, the controller will > >> > > > > get unregistered. And once it comes back, it will get registered back > >> > > > > and even if the IRQ configuration changes (MSI), that will get accounted. > >> > > > > > >> > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > >> > > > Applied to mhi-next! > >> > > I did a bisect and this patch breaks ath11k during rmmod. I'm on > >> > > vacation right now so I can't investigate in detail but more info below. > >> > > > >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm > >> > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. > >> > >> I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq > >> handler for a shared IRQ will be invoked and null pointer access happen. > >> > >> #ifdef CONFIG_DEBUG_SHIRQ > >> /* > >> * It's a shared IRQ -- the driver ought to be prepared for an IRQ > >> * event to happen even now it's being freed, so let's make sure that > >> * is so by doing an extra call to the handler .... > >> * > >> * ( We do this after actually deregistering it, to make sure that a > >> * 'real' IRQ doesn't run in parallel with our fake. ) > >> */ > >> if (action->flags & IRQF_SHARED) { > >> local_irq_save(flags); > >> action->handler(irq, dev_id); > >> local_irq_restore(flags); > >> } > >> #endif > >> > > > > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue. > > So how to fix this regression? (If there's already a fix I might have > missed it as I came back only today) > Copied you on the fix patch. Please test and let us know! Thanks, Mani > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-26 8:09 ` Manivannan Sadhasivam @ 2022-07-26 17:48 ` Kalle Valo 0 siblings, 0 replies; 8+ messages in thread From: Kalle Valo @ 2022-07-26 17:48 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k Manivannan Sadhasivam <mani@kernel.org> writes: > On Mon, Jul 25, 2022 at 09:00:08PM +0300, Kalle Valo wrote: > >> Manivannan Sadhasivam <mani@kernel.org> writes: >> >> > On Wed, Jul 20, 2022 at 05:47:37PM +0800, Qiang Yu wrote: >> > >> >> >> >> On 7/20/2022 5:39 PM, Manivannan Sadhasivam wrote: >> >> > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: >> >> > > + ath11k list >> >> > > >> >> > > Manivannan Sadhasivam <mani@kernel.org> writes: >> >> > > >> >> > > > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: >> >> > > > > During runtime, the MHI endpoint may be powered up/down several times. >> >> > > > > So instead of allocating and destroying the IRQs all the time, let's just >> >> > > > > enable/disable IRQs during power up/down. >> >> > > > > >> >> > > > > The IRQs will be allocated during mhi_register_controller() and freed >> >> > > > > during mhi_unregister_controller(). This works well for things like PCI >> >> > > > > hotplug also as once the PCI device gets removed, the controller will >> >> > > > > get unregistered. And once it comes back, it will get registered back >> >> > > > > and even if the IRQ configuration changes (MSI), that will get accounted. >> >> > > > > >> >> > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >> >> > > > Applied to mhi-next! >> >> > > I did a bisect and this patch breaks ath11k during rmmod. I'm on >> >> > > vacation right now so I can't investigate in detail but more info below. >> >> > > >> >> > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm >> >> > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. >> >> >> >> I suspect that in __free_irq(), if CONFIG_DEBUG_SHIRQ is enabled, irq >> >> handler for a shared IRQ will be invoked and null pointer access happen. >> >> >> >> #ifdef CONFIG_DEBUG_SHIRQ >> >> /* >> >> * It's a shared IRQ -- the driver ought to be prepared for an IRQ >> >> * event to happen even now it's being freed, so let's make sure that >> >> * is so by doing an extra call to the handler .... >> >> * >> >> * ( We do this after actually deregistering it, to make sure that a >> >> * 'real' IRQ doesn't run in parallel with our fake. ) >> >> */ >> >> if (action->flags & IRQF_SHARED) { >> >> local_irq_save(flags); >> >> action->handler(irq, dev_id); >> >> local_irq_restore(flags); >> >> } >> >> #endif >> >> >> > >> > Ah yes, after enabling CONFIG_DEBUG_SHIRQ I could reproduce the issue. >> >> So how to fix this regression? (If there's already a fix I might have >> missed it as I came back only today) >> > > Copied you on the fix patch. Please test and let us know! Thanks, testing it right now. Will let you know the result as a reply to the patch. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase 2022-07-20 9:39 ` Manivannan Sadhasivam 2022-07-20 9:47 ` Qiang Yu @ 2022-07-25 17:57 ` Kalle Valo 1 sibling, 0 replies; 8+ messages in thread From: Kalle Valo @ 2022-07-25 17:57 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Qiang Yu, quic_hemantk, loic.poulain, quic_jhugo, mhi, linux-arm-msm, linux-kernel, quic_cang, ath11k Manivannan Sadhasivam <mani@kernel.org> writes: > On Mon, Jul 18, 2022 at 02:15:23PM +0300, Kalle Valo wrote: > >> + ath11k list >> >> Manivannan Sadhasivam <mani@kernel.org> writes: >> >> > On Thu, Jun 23, 2022 at 10:43:03AM +0800, Qiang Yu wrote: >> >> During runtime, the MHI endpoint may be powered up/down several times. >> >> So instead of allocating and destroying the IRQs all the time, let's just >> >> enable/disable IRQs during power up/down. >> >> >> >> The IRQs will be allocated during mhi_register_controller() and freed >> >> during mhi_unregister_controller(). This works well for things like PCI >> >> hotplug also as once the PCI device gets removed, the controller will >> >> get unregistered. And once it comes back, it will get registered back >> >> and even if the IRQ configuration changes (MSI), that will get accounted. >> >> >> >> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >> > >> > Applied to mhi-next! >> >> I did a bisect and this patch breaks ath11k during rmmod. I'm on >> vacation right now so I can't investigate in detail but more info below. >> > > I just tested linux-next/master next-20220718 on my NUC with QCA6390, but I'm > not able to reproduce the issue during rmmod! Instead I couldn't connect to AP. > > log: https://paste.debian.net/1247788/ I get "Entry not found" for that link. But yeah, there were several regressions in ath11k while I was away. I except that the could not connect to AP bug should be fixed now in wireless-next and linux-next. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches -- ath11k mailing list ath11k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath11k ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-07-26 17:48 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1655952183-66792-1-git-send-email-quic_qianyu@quicinc.com>
[not found] ` <20220624072740.GA12171@thinkpad>
2022-07-18 11:15 ` [PATCH v4 1/1] bus: mhi: host: Move IRQ allocation to controller registration phase Kalle Valo
2022-07-20 9:39 ` Manivannan Sadhasivam
2022-07-20 9:47 ` Qiang Yu
2022-07-21 10:19 ` Manivannan Sadhasivam
2022-07-25 18:00 ` Kalle Valo
2022-07-26 8:09 ` Manivannan Sadhasivam
2022-07-26 17:48 ` Kalle Valo
2022-07-25 17:57 ` Kalle Valo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox