[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
Hi,
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
logic?
ven:8086 dev:1503 (rev:04) sven:103c sdev:17ab
Otherwise is it possible to infer anything from probing other
'features'?
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
could
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,
Rich
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