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