[PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Magnus Leatti]

motorcomm_init() writes 0 to MGMT_INT_CTRL0, which unmasks the MISC
interrupt. MISC arrives on MSI-X vector 5, which stmmac requests as its
MAC interrupt, and nothing in stmmac clears it. The vendor driver masks
it.

Since commit 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts"),
heavy RX load sets MISC and it never clears again, even though every
status register I could find reads zero. Vector 5 then fires about 120k
times per second and the machine stops responding until the TX watchdog
resets the adapter, or does not recover at all. A 64-byte UDP flood
from another host is enough:

  iperf3 -c <host> -u -b 0 -l 64 -R -P 4 -t 10

Mask MISC, as the vendor driver does. I could not find anything else
that depends on it here: EEE is not supported, and Wake-on-LAN uses PME.

Tested on one YT6801 board with net at cb284914e749. Without this
patch the flood above hangs the board within a second. With it, no MAC
interrupt fires under that flood or heavier ones, including after link,
ring, MTU and speed changes and a module reload, and throughput is
unchanged. Suspend could not be tested. The register values were read
with a debug build of stmmac.

Fixes: 02ff155ea281 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller")
Signed-off-by: Magnus Leatti <magnusleatti@kernelriot.com>
---
Russell, d3265c19b35d ("net: stmmac: xgmac2: disable RBUE in default RX
interrupt mask") describes a similar storm on xgmac2. Should dwmac4 do
the same? I have only tested the glue change.

 drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
index 124fcd55a..610d533b9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
@@ -30,6 +30,7 @@
 #define OOB_WOL_CTRL				0x1010
 #define  OOB_WOL_CTRL_DIS			BIT(0)
 #define MGMT_INT_CTRL0				0x1100
+#define  MGMT_INT_CTRL0_MASK_MISC		BIT(21)
 #define INT_MODERATION				0x1108
 #define  INT_MODERATION_RX			GENMASK(11, 0)
 #define  INT_MODERATION_TX			GENMASK(27, 16)
@@ -172,7 +173,11 @@ static void motorcomm_reset(struct dwmac_motorcomm_priv *priv)
 
 static void motorcomm_init(struct dwmac_motorcomm_priv *priv)
 {
-	writel(0x0, priv->base + MGMT_INT_CTRL0);
+	/*
+	 * Nothing services the MISC source, and once raised it never
+	 * deasserts, so keep it masked.
+	 */
+	writel(MGMT_INT_CTRL0_MASK_MISC, priv->base + MGMT_INT_CTRL0);
 
 	writel(FIELD_PREP(INT_MODERATION_RX, 200) |
 	       FIELD_PREP(INT_MODERATION_TX, 200),

base-commit: cb284914e749388eef402938bdb3115fe1f6d337
-- 
2.54.0

Re: [PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Maxime Chevallier]

Hi Magnus,

On 11/2/26 09:09, Magnus Leatti wrote:
> motorcomm_init() writes 0 to MGMT_INT_CTRL0, which unmasks the MISC
> interrupt. MISC arrives on MSI-X vector 5, which stmmac requests as its
> MAC interrupt, and nothing in stmmac clears it. The vendor driver masks
> it.
> 
> Since commit 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts"),
> heavy RX load sets MISC and it never clears again, even though every
> status register I could find reads zero. Vector 5 then fires about 120k
> times per second and the machine stops responding until the TX watchdog
> resets the adapter, or does not recover at all. A 64-byte UDP flood
> from another host is enough:
> 
>   iperf3 -c <host> -u -b 0 -l 64 -R -P 4 -t 10
> 
> Mask MISC, as the vendor driver does. I could not find anything else
> that depends on it here: EEE is not supported, and Wake-on-LAN uses PME.
> 
> Tested on one YT6801 board with net at cb284914e749. Without this
> patch the flood above hangs the board within a second. With it, no MAC
> interrupt fires under that flood or heavier ones, including after link,
> ring, MTU and speed changes and a module reload, and throughput is
> unchanged. Suspend could not be tested. The register values were read
> with a debug build of stmmac.
> 
> Fixes: 02ff155ea281 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller")
> Signed-off-by: Magnus Leatti <magnusleatti@kernelriot.com>

Can you test this, sent a few days ago ? I also saw that storm, but it didn't
seem to be motorcomm specific :

https://lore.kernel.org/r/20261030102251.208929-1-maxime.chevallier@bootlin.com

It should address the issue, doesn't require masking MISC entirely,
and isn't motorcomm specific (this storm will happen on all dwmac4 multi-MSI
glues).


> ---
> Russell, d3265c19b35d ("net: stmmac: xgmac2: disable RBUE in default RX
> interrupt mask") describes a similar storm on xgmac2. Should dwmac4 do
> the same? I have only tested the glue change.

The above patch should handle these too on dwmac4 :)

Thanks,

Maxime

Re: [PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Magnus Leatti]

On 11/2/26 09:22, Maxime Chevallier wrote:
> Can you test this, sent a few days ago ? I also saw that storm, but it didn't
> seem to be motorcomm specific :

Thanks, I missed it. It fixes the hang here with MISC left unmasked,
so masking is not needed. I replied with a Tested-by on your thread.

Please drop this patch.

For context, I ran into the hang while benchmarking the glue for a few
patches I plan to send once net-next opens, among them Wake-on-LAN from
S5, which does not work on this board today.

Re: [PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Nicolai Buchwitz]

Hi Magnus

On 2.11.2026 09:09, Magnus Leatti wrote:

> [...]

> Russell, d3265c19b35d ("net: stmmac: xgmac2: disable RBUE in default RX
> interrupt mask") describes a similar storm on xgmac2. Should dwmac4 do
> the same? I have only tested the glue change.

AFAIU RBU is the cause. Dropping it in dwmac4, as Russel did in  
d3265c19b35d,
would cover all multi-MSI users.

> 
>  drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> index 124fcd55a..610d533b9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> @@ -30,6 +30,7 @@
>  #define OOB_WOL_CTRL				0x1010
>  #define  OOB_WOL_CTRL_DIS			BIT(0)
>  #define MGMT_INT_CTRL0				0x1100
> +#define  MGMT_INT_CTRL0_MASK_MISC		BIT(21)

Where is this bit documented? The vendor driver?

>  #define INT_MODERATION				0x1108
>  #define  INT_MODERATION_RX			GENMASK(11, 0)
>  #define  INT_MODERATION_TX			GENMASK(27, 16)
> @@ -172,7 +173,11 @@ static void motorcomm_reset(struct 
> dwmac_motorcomm_priv *priv)
> 
>  static void motorcomm_init(struct dwmac_motorcomm_priv *priv)
>  {
> -	writel(0x0, priv->base + MGMT_INT_CTRL0);
> +	/*
> +	 * Nothing services the MISC source, and once raised it never
> +	 * deasserts, so keep it masked.
> +	 */
> +	writel(MGMT_INT_CTRL0_MASK_MISC, priv->base + MGMT_INT_CTRL0);

Doesn't this turn off the stmmac MAC irq on vector 5 completely? If so,
please mention it in the comment.

Also, does the MSI fallback still get RX/TX interrupts with MISC masked?

> [...]

Thanks,
Nicolai

Re: [PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Maxime Chevallier]

Hi,

On 11/2/26 09:29, Nicolai Buchwitz wrote:
> Hi Magnus
> 
> On 2.11.2026 09:09, Magnus Leatti wrote:
> 
>> [...]
> 
>> Russell, d3265c19b35d ("net: stmmac: xgmac2: disable RBUE in default RX
>> interrupt mask") describes a similar storm on xgmac2. Should dwmac4 do
>> the same? I have only tested the glue change.
> 
> AFAIU RBU is the cause. Dropping it in dwmac4, as Russel did in  d3265c19b35d,
> would cover all multi-MSI users.

As I commented, the other solution is to properly ack it. I'm not convinced about
the RBU interrupt's usefulness TBH, even when ack'd it makes a bad situation even
worse, but it does have the nice effect of making this visible by incrementing the
associated counter.

Anyway, this issue should be covered by this :

https://lore.kernel.org/all/20261030102251.208929-1-maxime.chevallier@bootlin.com/

Maxime

Re: [PATCH net] net: stmmac: dwmac-motorcomm: mask the MISC interrupt

[Magnus Leatti]

Hi Nicolai,

On 11/2/26 09:29, Nicolai Buchwitz wrote:
>> +#define  MGMT_INT_CTRL0_MASK_MISC		BIT(21)
> 
> Where is this bit documented? The vendor driver?

Yes. The vendor driver writes 0x00200000 there unless it services MISC
itself, and the yt6801 driver Motorcomm posted in 2025 defines the mask
field as bits 16-31 of MGMT_INT_CTRL0, with MISC as status bit 5.

>> +	writel(MGMT_INT_CTRL0_MASK_MISC, priv->base + MGMT_INT_CTRL0);
> 
> Doesn't this turn off the stmmac MAC irq on vector 5 completely? If so,
> please mention it in the comment.

Yes. On this device vector 5 only carries MISC. I should have said so.

> Also, does the MSI fallback still get RX/TX interrupts with MISC masked?

RX and TX have their own mask bits, but I did not test the single-MSI
path.

Maxime's patch fixes the hang here without the mask, so I have asked
for this one to be dropped.

Thanks for jumping on this so quickly, Maxime and Nicolai! I really
appreciate it. Have a good Monday :)

Magnus