Hi all
If we sent ethernet frames to the GMAC Port with a rate of 2.4 kHz (one frame every 416 us), we would expect for each frame an Rx Interrupt, if coalising is disabled (ethtool -C eth0 rx-usecs 0).
What we are observing is two Rx Interrupts for each frame, in which the second one comes very closely (15 - 20 us) to the first one.
We traced a case where one frame is send periodically to the GMAC (eth0) with 2.4 kHz.
This is what we observed:
- First interrupt arrives (irq_handler_entry/exit)
- The irq_thread (86) is scheduled
- The softirq NET_RX (irq_soft_raise) is raised
- Before the softirq can be handled by the driver and NAPI, it gets interrupted by another irq (irq_handler_entry)
- This causes the ksoftirqd/0 to be woken up for some reason
- Second interrupt also raises a softirq
- Now the first softirq is handled (napi_poll) where it founds 1 packet (work=1)
- It exits this softirq followed by the entering the second one
- This does yet another napi_poll but interestingly does NOT find a package (work=0)
- The woken up ksoftirqd gets to run but most likely has nothing to do and the idle state kicks in
We crosschecked the ethernet traffic and ensured that we have only the expected frames with the 2.4 kHz frame rate.
We checked the proc/interrupts file and found here as well the double amont of interrupts.
We checked the configuration of the interrupts and it is set on the default (Level, High)
We check as well the same on the PRU's where the amount of Interrupts reflects the ammount of frames (as expected, if oalising is disabled)
We observed this behavior with the TI SDK 5.3.
We have done the same measurements with the TI SDK 6.0 with the same unexpected result (double amount of interrupts)
We are using the RT-Patch
Thanks for your support
Stephan Gerspach
