[ipxe-devel] Negative implications of doing undinet_poll loop even if ISR not triggered?

[Michael Brown]

On Saturday 04 Feb 2012 15:24:13 Jarrod Johnson wrote:
> So I'm faced with a few situations where a device makes it appear that it
> supports interrupts, but undinet_isr_trigered behavior suggests that it
> really doesn't.  As noted in one of the commit log messages, this does not
> work at all.
> 
> If I leave everything alone, but remove the return if isr not triggered,
> everything *seems* fine on these systems and existing systems don't seem
> broken by it.
> 
> What bad behavior is feared if undinet_poll proceeds through on a proper
> stack with interrupts working but no interrupt triggered at the time?  Is
> it just an efficiency thing or are there scenarios that somehow get broken
> by this sort of strategy?

From the comments for undinet_poll():

 * Addendum (21/10/03).  Some cards don't play nicely with this trick,
 * so instead of doing it the easy way we have to go to all the hassle
 * of installing a genuine interrupt service routine and dealing with
 * the wonderful 8259 Programmable Interrupt Controller.  Joy.

Unfortunately, this predates the git repository history (which goes back only 
as far as 2005).  From memory, there was at least one PXE stack (I think on a 
Tulip card) which would immediately lock up if we called 
PXENV_UNDI_ISR_IN_START without there first being an interrupt generated by the 
NIC.  This behaviour by the PXE stack is provably broken anyway, since it 
wouldn't allow for a shared interrupt.

I don't remember whether or not we ever tested the strategy of bypassing 
PXENV_UNDI_ISR_IN_START completely and simply calling 
PXENV_UNDI_ISR_IN_PROCESS regardless.  In the years since, I have observed at 
least one PXE NBP (emBoot's winBoot/i) which used this strategy, so it's 
plausible that it would work.

Which cards are reporting that interrupts are supported but not actually 
generating interrupts?  Is there any way you can think of that we could detect 
this scenario and so clear undinic->irq_supported, which would produce the 
polling behaviour.

Michael