On 2025 Apr 24 (Thu) at 20:53:07 +0200 (+0200), Rafael Sadowski wrote:
:On Thu Apr 24, 2025 at 08:26:13PM +0200, Stefan Sperling wrote:
:> On Thu, Apr 24, 2025 at 11:38:37AM +0200, Stefan Sperling wrote:
:> > There is a known issue where qwx(4) triggers a pool corruption check:
:> > 
:> >   panic: pool_cache_item_magic_check: mcl2k cpu free list modified
:> > 
:> > As an attempt to fix this, the patch below makes the driver discard
:> > pending packets on all Rx rings.
:> > 
:> > My theory is that the hardware is doing a DMA write to an mbuf which is
:> > on one of these rings. While the interface goes down we are freeing mbufs
:> > but we are not updating the ring state from the device's point of view
:> > before doing so.
:> > The panic happens later when qwx or another network driver attempts to
:> > allocate a new mbuf from the 2K cluster pool.
:> > 
:> > The issue has been observed during suspend/resume, though if my theory
:> > is correct it might just as well happen during ifconfig down/up.
:> > 
:> > Also, port over qwx_dp_mon_link_free() from ath11k. I noticed that this
:> > was missing while searching the Linux driver code for clues.
:> 
:> Theo pointed out that disabling interrupts won't necessarily stop DMA.
:> 
:> So here's a new version which flushes the rings after the STOP command
:> has been sent to (and acknowledged by) firmware. This will hopefully
:> have the desired effect of stopping DMA.
:> 
:> I've also renamed the "reap" function to "flush", to avoid an implication
:> that rings were being completely destroyed/freed.
:
:Thanks Stefan. I tested your previous and the diff below with
:
:qwx0 at pci2 dev 0 function 0 "Qualcomm QCNFA765" rev 0x01: msi
:
:No issues so far.
:

Tested on my X13s with
qwx0 at pci1 dev 0 function 0 "Qualcomm QCNFA765" rev 0x01: msi

So far so good.


-- 
What is the robbing of a bank compared to the FOUNDING of a bank?
		-- Bertolt Brecht