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

[Ramón Nordin Rodriguez]

> > 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!

> 
> > > 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