[ipxe-devel] 8086:15b7, intel.c, HP EliteDesk 800 G2, PXELINUX chainloading problem

[Christian Nilsson]

On Mon, Apr 18, 2016 at 4:57 PM, Moore, Richard F. <rfm6 at leicester.ac.uk> wrote:
> 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
> http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004516.html
> 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
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>

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