Re: [Re] kernel panic during shutdown in next-20260722

[Bert Karwatzki <spasswolf@web.de>]

Am Freitag, dem 24.07.2026 um 00:51 +0200 schrieb Bert Karwatzki:
> Am Donnerstag, dem 23.07.2026 um 18:17 +0200 schrieb Bert Karwatzki:
> > Am Donnerstag, dem 23.07.2026 um 15:23 +0200 schrieb Bert Karwatzki:
> > > Am Donnerstag, dem 23.07.2026 um 15:10 +0200 schrieb Bert Karwatzki:
> > > > I was able to gather the panic error message from a failed shutdown via netconsole,
> > > > this time the kernel used was v7.2-rc3:
> > > > #
> > > > Bert Karwatzki
> > > 
> > > Unfortunatetly I can now reproduce these kernel panics in v7.1:
> > > 
> > > 
> > > So now I'm going to use memtest86+ on my machine and then look at the changes I had in
> > > my userspace as the first error occured on 22.7.2026. Let's hope this does not escalate ...
> > > 
> > > Bert Karwatzki
> > 
> > 
> > But I found out an exciting thing:
> > I can only reproduce the crashes in v7.2-rc4 when watching the reboot via netconsole,
> > without netconsole no crash occurs!(This also explains why I had not seen this crashes before ...) 
> > 
> Actually this is not cause by netconsole, but by rebooting right after a crash. Some
> broken state seems to be preserved across reboots. Switching off the power supply after
> a crash or even a ~30s wait after switching off the crashed machine seems to be enough
> to get around this.
>  Also the hang when rebooting next-20260722 also occurs when compiling without PREEMPT_RT.
> 
> Bert Karwatzki

There are actually several errors here:
1) The shutdown hang wich occurs in next-20260722+ (PREMPT_RT or not)
This error is caused by (I'll open a separate thread for this):

commit 13b7e6a96a005c656d38f3da51581deaf9866375
Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date:   Wed Jul 8 16:43:47 2026 +0200

    wifi: mt76: Disable napi when removing device
    
    Unloading the mt7915e module with a MT7916 triggers multiples WARN in
    __netif_napi_del_locked() and in page_pool_disable_direct_recycling()
    because the driver does not disable the napi before destroying it.
    
    This is troublesome since on MT7916 it is required to unload the module
    and reinsert it with a different enable_6ghz parameter to change the
    frequency.  The system generally becomes unstable after reinserting the
    module.
    
    Fix it by disabling napi before deleting it.  Also, do not delete napi
    on WED queues since napi is neither used nor initialized on them.
    
    Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
    Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
    Link: https://patch.msgid.link/20260708144615.24092-1-nicolas.cavallari@green-communications.fr
    Signed-off-by: Felix Fietkau <nbd@nbd.name>

diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index f8c2fe5f2f58..322041859217 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -1189,7 +1189,10 @@ void mt76_dma_cleanup(struct mt76_dev *dev)
        mt76_for_each_q_rx(dev, i) {
                struct mt76_queue *q = &dev->q_rx[i];
 
-               netif_napi_del(&dev->napi[i]);
+               if (!mt76_queue_is_wed_rro(q)) {
+                       napi_disable(&dev->napi[i]);
+                       netif_napi_del(&dev->napi[i]);
+               }
                mt76_dma_rx_cleanup(dev, q);
 
                page_pool_destroy(q->page_pool);


2) The "scheduling while atomic" errors which occur in v7.2-rc4 and earlier, once I figure out
these I'll contiue here (v6.19 is free from these errors)

Bert Karwatzki