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

[Jarrod Johnson]

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.

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.

On Sun, Feb 12, 2012 at 8:11 AM, Michael Brown <mbrown at fensystems.co.uk>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20120212/108f3eb6/attachment.htm>