[syslinux] [PATCH][git-pull] lwIP PXE fixes

[Gene Cumm]

On Tue, Sep 17, 2013 at 9:36 AM, Matt Fleming <matt at console-pimps.org> wrote:
> On Tue, 03 Sep, at 07:31:52PM, Gene Cumm wrote:
>> The following changes since commit 6438fbcb6cb7e0cd40e4bb3681ada047fe77ffdd:
>>   Gene Cumm (1):
>>         Allow for UNDIIF_ID_DEBUG in 1 mk line
>>
>> are available in the git repository at:
>>
>>   git://github.com/geneC/syslinux.git elflink-pxe-fixes-for-mfleming
>>   https://github.com/geneC/syslinux/tree/elflink-pxe-fixes-for-mfleming
>>
>> Gene Cumm (12):
>>       core/lwip/undi: Improve UNDIIF_ID_DEBUG messages
>>       core: mbox/semaphore NULL checks
>>       core: make mbox_post()/__sem_down_slow() check if valid
>>       PXELINUX: Use sendto() instead of connect()/send()/disconnect()
>>       PXELINUX: allow forcing poll by macro
>>       core: dprintf() the banner.
>>       undiif: show thread of execution on UNDIIF_ID_DEBUG
>>       PXELINUX: specify PXE/lwIP
>>       com32: Define ddprintf() macro
>>       PXE: use ddprintf macro
>>       core/lwip: Fix NULL pointer check
>>       PXE ISR: Force polling on select hardware WORKAROUND
>>
>
> Thanks Gene. I've pulled this into the elflink branch.
>
> Could you summarise what scenario these changes improve and on which
> hardware?

The primary things are "Use sendto() instead of
connect()/send()/disconnect()" prevents a race-condition on systems
that have functional interrupts (iPXE and the below Dell systems).
Without this, the reply packet could be received by the core prior to
the disconnect() call, see that it doesn't have a matching PCB
(protocol control block, iirc) since the reply has a different far-end
UDP port than the original request, and lwIP will discard the packet
before PXELINUX can see it.

On select platforms (Dell OptiPlex 760, Dell OptiPlex 960; perhaps
more), the interrupt appears to go "deaf" after a few seconds.  By
matching MAC OUI and flags value, force polling on these select
platforms.  I'm not sure if there's any better data available that
shallow in the core.  I believe PCI IDs can be fetched with functions
from other libraries and the UUID and DMI data (the most likely to be
useful is SYSPRODUCT) is available in ldlinux.c32.

> As a side note: I don't think the ddprintf() function is the way to go
> (the proliferation of print functions in Syslinux is getting out of
> hand). Unfortunately, I don't have time right now to come up with
> something different, and your solution clearly fixes something that
> wasn't working before, so we can revisit it later.

Agreed.  Something to the effect of using only 1 C printf()-like
function within the core that's contained within the primary binary
(no components in ldlinux.c32) that can address printing to the
current console and a debug console with dynamic run-time adjustment
would be better.

See also the recent thread on printk().

-- 
-Gene