On Fri, Mar 02, 2012 at 06:18:15PM +0000, Michael Brown wrote: > Thanks for tracking this down. Applied a reworked version of your patch: > > http://git.ipxe.org/ipxe.git/commitdiff/6324bd9
That's totally unrecognizable as my patch--Much less revolting Thanks for dealing with this, in a much more refined fashion > > Please let me know if this works for you! Indeed, for the MCP55 that was working OK before your commit. Unfortunate- ly, my QLogic 8242 still doesn't respond to DHCP Offers, unless i force irq_supported = 0 and let ipxe poll, and then it binds and boots ipxelinux from TFTP (and lets that boot an HTTP kernel) just fine If you have any tips on tracking down what's going on with the QLogic card or the box it's plugged into (same hardware as the one with the onboard MCP55 that's working fine [but i didn't notice if that's running IRQ-driv- en or not], though i've got the MCP55 PXE BIOS disabled on the one with the QLogic card), i'd feel duty-bound to help figure it out. I added a bunch of DBGC's to undinet_poll(), but it never seems to process a PXENV_UNDI_ISR_OUT_RECEIVE (unless i unset irq_supported) Anyways, i've got something that works, so thanks again for that, although i feel a bit guilty that perhaps perfectly well-working PXE stacks are now gonna stop working b/c of your new code unconditionally stripping the link- layer header. I also worry that if somebody compiles in VLAN tagging, then the code is going to pull off the VLAN tag instead of the protocol number, but, no, i haven't looked at the code to see if that's a real possibility or no _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
