Syslinux - Mar 2016 - lpxelinux.0 with device that doesn't support Interrupts

I am experiencing an issue where I ran ipxe (as an option rom) and downloaded
the lpxelinux.0 as the bootloader.
Next it should download the ldlinux.c32 file using UNDI API.
but before that it will close and open  the underlying device (which is ipxe),
and hooking the device interrupt so it can start getting some packets.

What I'm experiencing is that if the underlying device doesn't support
interrupts, i.e. the IntNumber that is returned in PXENV_UNDI_GET_INFORMATION is
0, then lpxelinux.0 will hook IRQ0 which is very bad behavior.

one good example of the faulty code is in undinet.c where we open a device, we
hook the IRQ regardless if its 0 or not, while in the latest iPXE code this
behavior was corrected and a check expression was added to avoid such bad
behavior

-----Original Message-----
From: Syslinux [mailto:syslinux-bounces at zytor.com] On Behalf Of Geert
Stappers via Syslinux
Sent: Friday, February 26, 2016 15:35
To: syslinux at zytor.com
Subject: Re: [syslinux] lpxelinux.0 with device that doesn't support
Interrupts

On Fri, Feb 26, 2016 at 01:00:21PM +0000, Wissam Shoukair via Syslinux
wrote:
> hi
> does anyone know if there are some known issues with running 
> lpxelinux.0 with device that doesn't support Interrupts?
> i.e. irq function is null...
Take some time to elaborate the question.


Cheers
Geert Stappers
Who thinks that Original Poster  doesn't want to hear/read issues.
_______________________________________________
Syslinux mailing list
Submissions to Syslinux at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux

On Fri, Feb 26, 2016 at 6:10 PM, Wissam Shoukair via Syslinux
<syslinux at zytor.com> wrote:
> I am experiencing an issue where I ran ipxe (as an option rom) and
downloaded the lpxelinux.0 as the bootloader.
> Next it should download the ldlinux.c32 file using UNDI API.
> but before that it will close and open  the underlying device (which is
ipxe), and hooking the device interrupt so it can start getting some packets.
Why load lpxelinux.0?  iPXE is normally configured to support HTTP and
PXELINUX supports calling iPXE for HTTP access.  PXELINUX's callback
was broken at one point but is functioning in the latest git code and
will be in 6.04.
> What I'm experiencing is that if the underlying device doesn't
support interrupts, i.e. the IntNumber that is returned in
PXENV_UNDI_GET_INFORMATION is 0, then lpxelinux.0 will hook IRQ0 which is very
bad behavior.
>
> one good example of the faulty code is in undinet.c where we open a device,
we hook the IRQ regardless if its 0 or not, while in the latest iPXE code this
behavior was corrected and a check expression was added to avoid such bad
behavior
It helps to give context.  I'd have to assume this is iPXE's
src/arch/i386/drivers/net/undinet.c but project, path, line, and
function are helpful.

See core/fs/pxe/isr.c:243 pxe_start_isr(), lpxelinux.0 does NOT hook
IRQ 0 and falls back to polling mode.  This code hasn't changed since
the 4.10-pre* series.

-- 
-Gene
> -----Original Message-----
> From: Syslinux [mailto:syslinux-bounces at zytor.com] On Behalf Of Geert
Stappers via Syslinux
> Sent: Friday, February 26, 2016 15:35
> To: syslinux at zytor.com
> Subject: Re: [syslinux] lpxelinux.0 with device that doesn't support
Interrupts
>
> On Fri, Feb 26, 2016 at 01:00:21PM +0000, Wissam Shoukair via Syslinux
wrote:
>> hi
>> does anyone know if there are some known issues with running
>> lpxelinux.0 with device that doesn't support Interrupts?
>> i.e. irq function is null...
>
> Take some time to elaborate the question.

On 02/26/16 15:10, Wissam Shoukair via Syslinux wrote:
>
> I am experiencing an issue where I ran ipxe (as an option rom) and
> downloaded the lpxelinux.0 as the bootloader.
> Next it should download the ldlinux.c32 file using UNDI API.
>
> but before that it will close and open  the underlying device (which
> is ipxe), and hooking the device interrupt so it can start getting
> some packets.
> 
> What I'm experiencing is that if the underlying device doesn't
> support interrupts, i.e. the IntNumber that is returned in
> PXENV_UNDI_GET_INFORMATION is 0, then lpxelinux.0 will hook IRQ0
> which is very bad behavior.
> 
> one good example of the faulty code is in undinet.c where we open a
> device, we hook the IRQ regardless if its 0 or not, while in the
> latest iPXE code this behavior was corrected and a check expression
> was added to avoid such bad behavior
>
This will happen if the device reports that it supports interrupts via
the device flags, but checking that IRQ != 0 seems like a good sanity check.

In other words, we're reacting badly to a firmware bug which is probably
fairly common and is also easy to work around.

	-hpa

On 03/01/16 11:38, H. Peter Anvin via Syslinux wrote:
> On 02/26/16 15:10, Wissam Shoukair via Syslinux wrote:
>>
>> I am experiencing an issue where I ran ipxe (as an option rom) and
>> downloaded the lpxelinux.0 as the bootloader.
>> Next it should download the ldlinux.c32 file using UNDI API.
>>
>> but before that it will close and open  the underlying device (which
>> is ipxe), and hooking the device interrupt so it can start getting
>> some packets.
>>
>> What I'm experiencing is that if the underlying device doesn't
>> support interrupts, i.e. the IntNumber that is returned in
>> PXENV_UNDI_GET_INFORMATION is 0, then lpxelinux.0 will hook IRQ0
>> which is very bad behavior.
>>
>> one good example of the faulty code is in undinet.c where we open a
>> device, we hook the IRQ regardless if its 0 or not, while in the
>> latest iPXE code this behavior was corrected and a check expression
>> was added to avoid such bad behavior
>>
> 
> This will happen if the device reports that it supports interrupts via
> the device flags, but checking that IRQ != 0 seems like a good sanity
check.
> 
> In other words, we're reacting badly to a firmware bug which is
probably
> fairly common and is also easy to work around.
> 
I just looked at this:

There is no file called undinet.c in the Syslinux sources.  None.  The
main UNDI handing is in core/lwip/src/netif/undiif.c, but the IRQ
handing is in core/fs/pxe/isr.c:

    if (irq) {
        if (!install_irq_vector(irq, pxe_isr, &pxe_irq_chain))
            irq = 0;            /* Install failed or stuck interrupt */
    }

This call obviously doesn't happen if irq is zero.

	-hpa