The only other strategy I would think is if the ISR is never triggered for any reason by a certain deadline, it'd probably be a strong indicator that something's not right.  <br><br>UNDI is a minefield of dubious implementations...<br>
<br><div class="gmail_quote">On Sun, Feb 12, 2012 at 8:53 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="im">On Sunday 12 Feb 2012 13:24:59 Jarrod Johnson wrote:<br>
> Well, I have an Emulex firmware that is doing so, but I think they may have<br>
> some working levels of firmware and some not.  It might also have some sort<br>
> of interaction with system firmware, as I'm fairly sure they've gotten this<br>
> working in the past without the workaround and really insufficient time has<br>
> 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<br>
> a packet we set some really short timeout (tx completion should be very<br>
> very soon) and if no TX completion interrupt comes along during<br>
> undinet_poll, could declare that interrupts are not coming.<br>
<br>
</div>That was my thought as well.  I'm not sure that all PXE stacks will generate<br>
TX completion interrupts, though, so that strategy might create false<br>
positives.<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br>