Thread (140 messages) 140 messages, 10 authors, 2024-07-23

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

From: Ramón Nordin Rodriguez <hidden>
Date: 2024-05-15 21:45:21
Also in: linux-devicetree, linux-doc, lkml

quoted
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.
What might be more interesting is the interrupt status registers. Is
there a bit always set which the driver is not clearly correctly?
Ah great point, I'll dump the irq status registers when things go awry.
You can try printing the values. But that might upset the timing so
you cannot reproduce the issue.

If the printk() does upset the timing, what i have done before is
allocate an array of u32 values. Write the interrupt status into it,
looping around when you get to the end of the array. And then use
debugfs_create_u32_array() to export the array in /sys/kernel/debugfs.
Trigger the problem and then look at the values.
Good tip, sounds like the exact strategy I need. Appreciate the hands on
suggestions!
quoted
quoted
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.
I was just wondering how your setup differs so you can trigger the
issue, but others have not been able to reproduce it. It might be
another clue as to what is going on. I don't think you need to do
anything with respect to this, its just information to keep in mind.
My typical setup is weird for sure, I skip the initramfs and load a
kernel and dtb into ram (which means I don't have DMA, due to missing fw),
but I'm in the habit of occasionally flashing and running a 'normal system'
every once in a while for verifcation.

I can't think of anything on top of my head that would set my system in
a unique position. But since I don't get the failure when I have a UDP
multicast running I'm guessing different networking daemons might affect
things, in this case we're running systemd-networkd and I manually set
an ipv4 address on the interfaces.

R
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help