netdev - Re: [PATCH] net: dp83822: disable false carrier interrupt

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1303327043.278846.1655974274654.JavaMail.zimbra@savoirfairelinux.com>
Date:   Thu, 23 Jun 2022 04:51:14 -0400 (EDT)
From:   Enguerrand de Ribaucourt 
        <enguerrand.de-ribaucourt@...oirfairelinux.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     davem@...emloft.net, netdev <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org, linux <linux@...linux.org.uk>,
        hkallweit1 <hkallweit1@...il.com>
Subject: Re: [PATCH] net: dp83822: disable false carrier interrupt

----- Original Message -----
> From: "Andrew Lunn" <andrew@...n.ch>
> To: "Enguerrand de Ribaucourt" <enguerrand.de-ribaucourt@...oirfairelinux.com>
> Cc: davem@...emloft.net, "netdev" <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org, "linux"
> <linux@...linux.org.uk>, "hkallweit1" <hkallweit1@...il.com>
> Sent: Friday, June 17, 2022 7:55:54 PM
> Subject: Re: [PATCH] net: dp83822: disable false carrier interrupt

> On Fri, Jun 17, 2022 at 03:46:11PM +0200, Enguerrand de Ribaucourt wrote:
> > When unplugging an Ethernet cable, false carrier events were produced by
> > the PHY at a very high rate. Once the false carrier counter full, an
> > interrupt was triggered every few clock cycles until the cable was
> > replugged. This resulted in approximately 10k/s interrupts.

> > Since the false carrier counter (FCSCR) is never used, we can safely
> > disable this interrupt.

> > In addition to improving performance, this also solved MDIO read
> > timeouts I was randomly encountering with an i.MX8 fec MAC because of
> > the interrupt flood. The interrupt count and MDIO timeout fix were
> > tested on a v5.4.110 kernel.

>> Signed-off-by: Enguerrand de Ribaucourt
> > <enguerrand.de-ribaucourt@...oirfairelinux.com>
> > ---
> > drivers/net/phy/dp83822.c | 1 -
> > 1 file changed, 1 deletion(-)

> > diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
> > index e6ad3a494d32..95ef507053a6 100644
> > --- a/drivers/net/phy/dp83822.c
> > +++ b/drivers/net/phy/dp83822.c
> > @@ -230,7 +230,6 @@ static int dp83822_config_intr(struct phy_device *phydev)
> > return misr_status;

> > misr_status |= (DP83822_RX_ERR_HF_INT_EN |
> > - DP83822_FALSE_CARRIER_HF_INT_EN |

> Does the same problem exist for RX_ERR_HF_INT ? That appears to be
> that the RX error counter has reached half full. I don't see anything
> using register 0x15.

> Andrew

I can produce RX errors using improper ethtool speed settings, which can be seen
in the statistics, but they do not increment register 0x15. However, RX errors due 
to cable disconnection do increase it. After the counter is half full (0x7fff, 
the datasheet is wrong), interrupts that we don't need were indeed generated.

I measured a ~3k/s interrupt flood which also kept going even if I stopped the 
RX errors transfer so we should definitively disable RX_ERR_HF_INT as well.

I'll send a separate patch for RX_ERR_HF_INT_EN to have clear commmit messages.

Thanks,
Enguerrand