On 11/25/06, Matthew Dillon <[EMAIL PROTECTED]> wrote:
:Only 34 intr came during your testing :-(
:
:Please testing following patch:
:http://leaf.dragonflybsd.org/~sephe/em_intr.diff
:
:See whether it helps.
:
:Best Regards,
:sephe
Ouch. I don't quite understand the jist of the patch. Clearly
it is dealing with a situation where an RX ring overrun occurs,
and I assume that has something to do with the stoppage,
but I'm not sure what the intention of the fix is.
After staring at the extremely low interrupt rate, I think something
should be wrong with interrupt processing in our code. The loop
mainly handles thingy that happens when we processing TX/RX desc
rings. I think it is necessary when RX overrun happens, the extra ICR
reading/processing may restore the RX engine, I don't think the extra
ICR reading will hurt if ICR has nothing left
What I don't understand is why the polling code would also fail.
The polling code unconditionally processes the RX ring no
matter what the ICR status. I'm wondering if we have to kick the
interface somehow after it gets a RX overflow to get the receive
ring going again.
mmm, I forgot to take polling failure into account, polling does not
even touch ICR ...
The above patch is updated a little bit:
http://leaf.dragonflybsd.org/~sephe/em_intr1.diff
Best Regards,
sephe
--
Live Free or Die
