linux-kernel - Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error interrupts unmasking

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: <ZkIakC6ixYpRMiUV@minibuilder>
Date: Mon, 13 May 2024 15:50:08 +0200
From: Ramón Nordin Rodriguez <ramon.nordin.rodriguez@...roamp.se>
To: Andrew Lunn <andrew@...n.ch>
Cc: Piergiorgio Beruto <Pier.Beruto@...emi.com>,
	"Parthiban.Veerasooran@...rochip.com" <Parthiban.Veerasooran@...rochip.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"horms@...nel.org" <horms@...nel.org>,
	"saeedm@...dia.com" <saeedm@...dia.com>,
	"anthony.l.nguyen@...el.com" <anthony.l.nguyen@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"corbet@....net" <corbet@....net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"Horatiu.Vultur@...rochip.com" <Horatiu.Vultur@...rochip.com>,
	"ruanjinjie@...wei.com" <ruanjinjie@...wei.com>,
	"Steen.Hegelund@...rochip.com" <Steen.Hegelund@...rochip.com>,
	"vladimir.oltean@....com" <vladimir.oltean@....com>,
	"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
	"Thorsten.Kummermehr@...rochip.com" <Thorsten.Kummermehr@...rochip.com>,
	Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>,
	"Nicolas.Ferre@...rochip.com" <Nicolas.Ferre@...rochip.com>,
	"benjamin.bigler@...nformulastudent.ch" <benjamin.bigler@...nformulastudent.ch>
Subject: Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error
 interrupts unmasking

On Mon, May 13, 2024 at 03:00:48PM +0200, Andrew Lunn wrote:
> > I've enabled some debugging options but so far nothing seems to hit.
> > What I've been able to conclude is that there still is SPI
> > communication, the macphy interrupt is still pulled low, and the cpu
> > does the ack so that it's reset to inactive.
> 
> Is it doing this in an endless cycle?

Exactly, so what I'm seeing is when the driver livelocks the macphy is
periodically pulling the irq pin low, the driver clears the interrupt
and repeat.

> 
> Probably the debug tools are not showing anything because it is not
> looping in just one location. It is a complex loop, interrupts
> triggering a thread which runs to completion etc. So it looks like
> normal behaviour.

Gotcha. The 'do work' func called in the worker threads loop does run
and return, so I guess there is not much to trigger on.

> 
> If it is an endless cycle, it sounds like an interrupt storm. Some
> interrupt bit is not getting cleared, so it immediately fires again as
> soon as interrupts are enabled.

Good input. I'll add some instrumentation/stats for how many jiffies
have elapsed between releases of the worker thread and for the irq
handler. I can probably find a gpio to toggle as well if it's really
tight timings.

The irq pin is inactive/high for 100s of us to ms in the measurments
I've done. But I've been using multiple channels and not the fanciest
equipment so samplerates might be playing tricks, I'll rerun some tests
while only measuring the irq pin.

> 
> Is this your dual device board? Do you have both devices on the same
> SPI bus? Do they share interrupt lines?
> 

It's on the dual device board, the macphys are using separate spi buses,
one chip shares the bus with another spi device, but the other is the
only tenant on the bus.

No device shares an irq line.

Pretty sure I can replicate the result for both devices, but need to 
double check, been to much testing of random things for me to keep track.

I'll do some more digging, I think we're getting pretty close to
understading the behaviour now.

R