lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Mar 2022 08:43:24 -0700
From:   Jakub Kicinski <>
To:     Tomas Melin <>,
        Robert Hancock <>
Subject: Re: [PATCH v3] net: macb: restart tx after tx used bit read

On Wed, 23 Mar 2022 10:08:20 +0200 Tomas Melin wrote:
> > From: <>
> > To: <>, <>
> > Cc: <>, <>,
> > 	<>
> > Subject: [PATCH v3] net: macb: restart tx after tx used bit read
> > Date: Mon, 17 Dec 2018 10:02:42 +0000	[thread overview]
> > Message-ID: <> (raw)
> > 
> > From: Claudiu Beznea <>
> > 
> > On some platforms (currently detected only on SAMA5D4) TX might stuck
> > even the pachets are still present in DMA memories and TX start was
> > issued for them. This happens due to race condition between MACB driver
> > updating next TX buffer descriptor to be used and IP reading the same
> > descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
> > GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
> > is asserted TX must be restarted. Restart TX if used bit is read and
> > packets are present in software TX queue. Packets are removed from software
> > TX queue if TX was successful for them (see macb_tx_interrupt()).
> > 
> > Signed-off-by: Claudiu Beznea <>  
> On Xilinx Zynq the above change can cause infinite interrupt loop leading 
> to CPU stall. Seems timing/load needs to be appropriate for this to happen, and currently
> with 1G ethernet this can be triggered normally within minutes when running stress tests
> on the network interface.
> The events leading up to the interrupt looping are similar as the issue described in the
> commit message. However in our case, restarting TX does not help at all. Instead
> the controller is stuck on the queue end descriptor generating endless TX_USED           
> interrupts, never breaking out of interrupt routine.
> Any chance you remember more details about in which situation restarting TX helped for
> your use case? was tx_qbar at the end of frame or stopped in middle of frame?

Which kernel version are you using? Robert has been working on macb +
Zynq recently, adding him to CC.

Powered by blists - more mailing lists