<html><head></head><body><div>On Mon, 2016-04-18 at 19:14 +0200, Christian Nilsson wrote:</div><blockquote type="cite"><pre>On Mon, Apr 18, 2016 at 4:57 PM, Moore, Richard F. <<a href="mailto:rfm6@leicester.ac.uk">rfm6@leicester.ac.uk</a>> wrote:
<blockquote type="cite">
Hi,

Have added below patch, works fine chainloading other things (like SCCM) but
trying to chainload PXELINUX (lpxelinux.0) causes a hang after it is
downloaded.
With DEBUG=intel on it doesn't hang, but produces lots of errors (see
attached 2x screenshots), loading the my menu up screen after several
screen-fulls of  'unexpected ICR' errors -
but then the syslinux  screen is partly corrupted and it slowly redraws
itself becoming unresponsive if trying to use the menu, after a few seconds
getting stuck a sort of unresponsive redraw loop.
(Not adding the patch and thus falling back to the undinet driver, it works
normally. The whole system also works fine on other hardware using intel.c
code.)

This also relates partially to
<a href="http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004516.html">http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004516.html</a>
where Michael asked for anyone with this 8086:15b7 to reply - (from the SCCM
chainloading it appears to not need the phy_rst.)

I am sorry if this is a PXELINUX problem but I need to start somewhere
trying to get to the bottom of it! Thanks.


Cheers

Rich



--- ./drivers/net/intel.c.orig 2016-04-15 15:35:49.579291961 +0100
+++ ./drivers/net/intel.c 2016-04-15 15:23:11.509454802 +0100
@@ -1067,6 +1067,7 @@
  PCI_ROM ( 0x8086, 0x15a1, "i218v-2", "I218-V", 0 ),
  PCI_ROM ( 0x8086, 0x15a2, "i218lm-3", "I218-LM", INTEL_NO_PHY_RST ),
  PCI_ROM ( 0x8086, 0x15a3, "i218v-3", "I218-V", INTEL_NO_PHY_RST ),
+ PCI_ROM ( 0x8086, 0x15b7, "i219lm", "I219-LM", 0 ),
  PCI_ROM ( 0x8086, 0x15b8, "i219v-2", "I219-V (2)", 0 ),
  PCI_ROM ( 0x8086, 0x294c, "82566dc-2", "82566DC-2", 0 ),
  PCI_ROM ( 0x8086, 0x2e6e, "cemedia", "CE Media Processor", 0 ),

_______________________________________________
ipxe-devel mailing list
<a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a>
<a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel">https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel</a>

</blockquote>

Hi,

If you are using undionly.kpxe which implements undi then The intel
driver is not used at all.
If you are using ipxe.pxe or 808615b7.pxe or similar to get The intel
driver, then there is no undi fallback.

So far the INTEL_NO_PHY_RST part have been used to fix an issue with
the link only negotiating at 10mbit, this does not always happen, but
is mostly seen in legacy -> pxe chain, but once again this is only
relevant if using a pxe binary that activates the driver.


Your mention of undi fallback leads me to believe you might be using
something other then the two variants above, such as ipxe.kkpxe (note
more then one k) which might give you undefined behavior.

One other thing to check is for HP firmware upgrades. (have seen quite
a loot of issue reports about HP machines, and bad firmware is not
uncommon)


/Christian - just a iPXE user, and IRC lurker
</pre></blockquote><div><br></div><div><br></div><div><div>Hi Christian,</div><div><div><br></div><div>Sorry for the lack of clarity , I am using ipxe.usb with all drivers built in and the driver 'fallback' as far as I understand is undipci [not undinet], according to what DEBUG=pci  shows, which works fine.</div><div><br></div><div>Cheers</div><div><br></div><div>Rich</div><div><br></div></div></div></body></html>