[ipxe-devel] DHCP failing on Intel 82579V Gigabit [8086:1503] after PXE boot]

Richard Moore rich at richud.com
Tue Nov 13 09:03:37 UTC 2012


Oh dear..

Simplistically - an overriding rule list first to just match the ven/dev
and/or subsys/rev and jump to appropriate action before using any other

ven:8086 dev:1503 (rev:04) sven:103c sdev:17ab

Otherwise is it possible to infer anything from probing other
e.g if x and y report something then it is likely z isn't true?

Are there any commonalities to other devices broken in this way that
be looked for?

Can some other packet be sent to the dhcp server to generate a response
that can be checked in some way - e.g. it should always return at least
something and if RX=0 then something is wrong, try the next approach?

Am sure all of these have been thought of but just thinking out loud,

Thanks for all your efforts,


on Mon, 2012-11-12 at 15:11 +0000, Michael Brown wrote:
> On 12/11/12 15:05, Richard Moore wrote:
> > On Mon, 2012-11-12 at 14:45 +0000, Michael Brown wrote:
> >> Try the attached hack.  This forces undinet into polling mode
> >> (rather than interrupt mode); if this works then at least it
> >> identifies the problem.
> >
> > yep that worked :)
> OK; so we now know the problem is that this particular underlying PXE
> stack is advertising that it supports interrupts, but never actually
> generates any.
> This is a known problem for some PXE stacks, with no good solution known
> at present.  Commit b6ca3aa includes some explanation:
>    http://git.ipxe.org/ipxe.git/commitdiff/b6ca3aa
> Suggested solutions welcome.
> Michael

More information about the ipxe-devel mailing list