Well, I have an Emulex firmware that is doing so, but I think they may have some working levels of firmware and some not.  It might also have some sort of interaction with system firmware, as I'm fairly sure they've gotten this working in the past without the workaround and really insufficient time has been spent determining why the interrupts aren't coming.<br>
<br>As far as detecting, I haven't tried but I was wondering if on transmit of a packet we set some really short timeout (tx completion should be very very soon) and if no TX completion interrupt comes along during undinet_poll, could declare that interrupts are not coming.<br>
<br><div class="gmail_quote">On Sun, Feb 12, 2012 at 8:11 AM, Michael Brown <span dir="ltr"><<a href="mailto:mbrown@fensystems.co.uk">mbrown@fensystems.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Saturday 04 Feb 2012 15:24:13 Jarrod Johnson wrote:<br>
> So I'm faced with a few situations where a device makes it appear that it<br>
> supports interrupts, but undinet_isr_trigered behavior suggests that it<br>
> really doesn't.  As noted in one of the commit log messages, this does not<br>
> work at all.<br>
><br>
> If I leave everything alone, but remove the return if isr not triggered,<br>
> everything *seems* fine on these systems and existing systems don't seem<br>
> broken by it.<br>
><br>
> What bad behavior is feared if undinet_poll proceeds through on a proper<br>
> stack with interrupts working but no interrupt triggered at the time?  Is<br>
> it just an efficiency thing or are there scenarios that somehow get broken<br>
> by this sort of strategy?<br>
<br>
</div></div>From the comments for undinet_poll():<br>
<br>
 * Addendum (21/10/03).  Some cards don't play nicely with this trick,<br>
 * so instead of doing it the easy way we have to go to all the hassle<br>
 * of installing a genuine interrupt service routine and dealing with<br>
 * the wonderful 8259 Programmable Interrupt Controller.  Joy.<br>
<br>
Unfortunately, this predates the git repository history (which goes back only<br>
as far as 2005).  From memory, there was at least one PXE stack (I think on a<br>
Tulip card) which would immediately lock up if we called<br>
PXENV_UNDI_ISR_IN_START without there first being an interrupt generated by the<br>
NIC.  This behaviour by the PXE stack is provably broken anyway, since it<br>
wouldn't allow for a shared interrupt.<br>
<br>
I don't remember whether or not we ever tested the strategy of bypassing<br>
PXENV_UNDI_ISR_IN_START completely and simply calling<br>
PXENV_UNDI_ISR_IN_PROCESS regardless.  In the years since, I have observed at<br>
least one PXE NBP (emBoot's winBoot/i) which used this strategy, so it's<br>
plausible that it would work.<br>
<br>
Which cards are reporting that interrupts are supported but not actually<br>
generating interrupts?  Is there any way you can think of that we could detect<br>
this scenario and so clear undinic->irq_supported, which would produce the<br>
polling behaviour.<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br>