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

[Torgeir Wulfsberg]

Hi!

The patch did work as you said ;)
Thank you so much..

Regards,
Torgeir

On 01/12/2013 11:25 AM, Richard Moore wrote:
> Hi,
>
> I made a little override patch (attached) to fix the PXE booting on 
> the new HP laptop hardware (XX70x's) which seems to have solved the 
> problem in our environment.
>
> I thought I would post it as other people had had problems and no 
> better solution has been forthcoming.
>
> (Have cc'd to everyone who seemed to have had some dealings with it in 
> the past)
>
> Hope this helps someone.
>
>
> Regards
>
> Rich
>
>
>
> On 13/11/12 09:03, Richard Moore wrote:
>> 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
>