On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: >> On Mon, 2017-11-27 at 18:18 -0500, Gene Cumm wrote: > >>> On Mon, Nov 27, 2017 at 6:07 PM, Joakim Tjernlund >>> <Joakim.Tjernlund at infinera.com> wrote: >>> > On Mon, 2017-11-27 at 18:03 -0500, Gene Cumm wrote: >>> > > On Mon, Nov 27, 2017 at 2:14 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> > > > On Mon, Nov 27, 2017 at 12:07 PM, Joakim Tjernlund >>> > > > <Joakim.Tjernlund at infinera.com> wrote: >>> > > > > On Mon, 2017-11-27 at 08:42 -0500, Gene Cumm wrote: >>> > > > > > Bringing the discussion to the list. >>> > > > > > >>> > > > > > You stated you see the following on your Lenovo ThinkPad T470s with >>> > > > > > UEFI firmware N1WET41W (1.20 date: 10/17/2017): >>> > > > > > >>> > > > > > >>> > > > > > core_udp_sendto: stalling on configure with no mapping >>> > > > > > >>> > > > > > >>> > > > > > OUI 54-E1-AD >>> > > > > > >>> > > > > > lspci -s 0:1f.6 -v >>> > > > > > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (4) >>> > > > > > I219-V (rev 21) >>> > > > > > Subsystem: Lenovo Ethernet Connection (4) I219-V >>> > > > > > Flags: bus master, fast devsel, latency 0, IRQ 125 >>> > > > > > Memory at dc200000 (32-bit, non-prefetchable) [size=128K] >>> > > > > > Capabilities: [c8] Power Management version 3 >>> > > > > > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ >>> > > > > > Capabilities: [e0] PCI Advanced Features >>> > > > > > Kernel driver in use: e1000e >>> > > > > > Kernel modules: e1000e >>> > > > > > >>> > > > > > This might be the only wired NIC but there's possibly multiple device >>> > > > > > handles to it and possibly a device handle to the wrong NIC >>> > > > > > (wireless). >>> > > > > > >>> > > > > > In your EFI shell (hopefully you have such an option): >>> > > > > > >>> > > > > > version > fs0:\efi-ver.txt >>> > > > > > dh -p Net > fs0:\efi-dh-net.txt >>> > > > > > >>> > > > > > Feel free to run it without the redirect (">") to see the results >>> > > > > > yourself. The redirects would help if you can access the files so you >>> > > > > > don't need to manually transcribe the output. >>> > > > > > >>> > > > > > Here's some other UEFI Shell commands that may be of use: >>> > > > > > >>> > > > > > guid > fs0:\efi-guid.txt >>> > > > > > or alias > fs0:\efi-alias.txt >>> > > > > > dh > fs0:\efi-dh.txt >>> > > > > >>> > > > > Managed to install an EFI shell from here: >>> > > > > https://github.com/tianocore/edk2/blob/master/ShellBinPkg/UefiShell/X64/Shell.efi >>> > > > > >>> > > > > and got a dh > dh.txt >>> > > > > I don't know what to do with this info so attaching it here. >>> > > > >>> > > > Ok. Different GUID aliases. Line 1381 says what I see as "Net" you >>> > > > likely see as "SimpleNetwork". This handle has the necessary >>> > > > "UDPv4ServiceBinding" (I see as "UDPv4Sb"). >>> > > > >>> > > > Thanks for the excellent data. It's been a while since I looked at >>> > > > the handle search code to debug this. >>> > > >>> > > Did you ever see a "disable UseDefaultAddress" message? The code >>> > > should have printed those original messages dump the new message then >>> > > try again at doing the network transaction. >>> > >>> > Yes, that was the last message I think. Then, after a while, it rebooted. >>> > I figured the names(Net vs. SimpleNetwork) to search for was standardized? >>> >>> That's a partially good thing. This says it tried to bind UDP where >>> we got PXE, failed, hunted for something that provides UDP on the same >>> MAC, found it, attempted to use the UseDefaultAddress flag, failed to >>> configure, and fell back to attempting to manually configure the >>> entire UDP datagram. At this point, it should have just worked. >>> >>> The aliases/names aren't entirely standardized and it's just a >>> friendly name for the GUID (which is standardized). The aliases could >>> easily be localized though I believe there's only 2 common groups, the >>> two we see here. >>> >>> Did you happen to peek at the version command? I'm guessing it's >>> saying 2.0 since the UDPv4Sb is not on the same handle as the PxeBc. >> >> Gene, I am curious, do you have an idea how to fix this? > > Yes, I have an idea but I need to add some debug code so I can > understand more how your particular machine is behaving. > > -- > -GeneOn Tue, Nov 28, 2017 at 6:45 AM, Joakim Tjernlund via Syslinux <syslinux at zytor.com> wrote:> But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux > but I think Gene has an idea how to solve it.Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses longer names). Yours has PxeBc atop a Net with MNPSb on another handle. This is not the first and doubtfully the last we'll encounter. UEFI-2.0 allows this but starting in UEFI-2.1, it MUST live atop an MNPSb. I'm still trying to build something that'll print the paths but strangely having issues. On Mon, Nov 27, 2017 at 6:39 PM, Joakim Tjernlund <Joakim.Tjernlund at infinera.com> wrote:> Fond an old boot logg: > [ 0.000000] efi: EFI v2.50 by Lenovo > [ 0.000000] efi: SMBIOS=0x6f098000 SMBIOS 3.0=0x6f095000 ACPI=0x6fffe000 ACPI 2.0=0x6fffe014 MPS=0x6f468000 ESRT=0x6eb33000 MEMATTR=0x6976d018 > [ 0.000000] ACPI: UEFI 0x000000006FF53000 000042 (v01 LENOVO TP-N1W 00001200 PTEC 00000002) > [ 0.000000] ACPI: UEFI 0x000000006FF39000 00013E (v01 LENOVO TP-N1W 00001200 PTEC 00000002)It sure doesn't look 2.5 compliant to me. Merely adding the new stuff from a new UEFI spec version doesn't mean it's compliant with the current nor previous versions. If I'm wrong, I'd love to hear especially from the author or someone with first-hand knowledge. -- -Gene
On Wed, Dec 6, 2017 at 6:49 AM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund>>> Gene, I am curious, do you have an idea how to fix this? >> >> Yes, I have an idea but I need to add some debug code so I can >> understand more how your particular machine is behaving. >> >> -- >> -Gene> On Tue, Nov 28, 2017 at 6:45 AM, Joakim Tjernlund via Syslinux > <syslinux at zytor.com> wrote: > >> But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux >> but I think Gene has an idea how to solve it. > > Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop > a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses > longer names). Yours has PxeBc atop a Net with MNPSb on another > handle. This is not the first and doubtfully the last we'll > encounter. UEFI-2.0 allows this but starting in UEFI-2.1, it MUST > live atop an MNPSb. > > I'm still trying to build something that'll print the paths but > strangely having issues. > > On Mon, Nov 27, 2017 at 6:39 PM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > >> Fond an old boot logg: >> [ 0.000000] efi: EFI v2.50 by Lenovo >> [ 0.000000] efi: SMBIOS=0x6f098000 SMBIOS 3.0=0x6f095000 ACPI=0x6fffe000 ACPI 2.0=0x6fffe014 MPS=0x6f468000 ESRT=0x6eb33000 MEMATTR=0x6976d018 >> [ 0.000000] ACPI: UEFI 0x000000006FF53000 000042 (v01 LENOVO TP-N1W 00001200 PTEC 00000002) >> [ 0.000000] ACPI: UEFI 0x000000006FF39000 00013E (v01 LENOVO TP-N1W 00001200 PTEC 00000002) > > It sure doesn't look 2.5 compliant to me. Merely adding the new stuff > from a new UEFI spec version doesn't mean it's compliant with the > current nor previous versions. If I'm wrong, I'd love to hear > especially from the author or someone with first-hand knowledge. > > -- > -GeneJoakim, attached is a TGZ with some test binaries. I'm assuming the "imd" will print one device while "mnp" another. This is mostly to firm up which devices it's actually trying to use. Based on your other results, this should help a little more to understand how the code is reacting to your machine. It won't give me an answer but just lead me towards the next step. -- -Gene -------------- next part -------------- A non-text attachment was scrubbed... Name: sl604p1g9-x64.tgz Type: application/x-gzip Size: 162432 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20171210/8fa047b4/attachment-0001.bin>
On Wed, Dec 13, 2017 at 7:03 AM, Joakim Tjernlund <Joakim.Tjernlund at infinera.com> wrote:> On Mon, 2017-12-11 at 08:59 +0100, Joakim Tjernlund wrote: >> On Sun, 2017-12-10 at 14:41 -0500, Gene Cumm wrote: >> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> > >> > >> > On Wed, Dec 6, 2017 at 6:49 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> > > On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> > > > On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund >> > > > > Gene, I am curious, do you have an idea how to fix this? >> > > > >> > > > Yes, I have an idea but I need to add some debug code so I can >> > > > understand more how your particular machine is behaving. >> > > > >> > > > -- >> > > > -Gene >> > > >> > > On Tue, Nov 28, 2017 at 6:45 AM, Joakim Tjernlund via Syslinux >> > > <syslinux at zytor.com> wrote: >> > > >> > > > But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux >> > > > but I think Gene has an idea how to solve it. >> > > >> > > Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop >> > > a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses >> > > longer names). Yours has PxeBc atop a Net with MNPSb on another >> > > handle. This is not the first and doubtfully the last we'll >> > > encounter. UEFI-2.0 allows this but starting in UEFI-2.1, it MUST >> > > live atop an MNPSb. >> > > >> > > I'm still trying to build something that'll print the paths but >> > > strangely having issues. >> > > >> > > On Mon, Nov 27, 2017 at 6:39 PM, Joakim Tjernlund >> > > <Joakim.Tjernlund at infinera.com> wrote: >> > > >> > > > Fond an old boot logg: >> > > > [ 0.000000] efi: EFI v2.50 by Lenovo >> > > > [ 0.000000] efi: SMBIOS=0x6f098000 SMBIOS 3.0=0x6f095000 ACPI=0x6fffe000 ACPI 2.0=0x6fffe014 MPS=0x6f468000 ESRT=0x6eb33000 MEMATTR=0x6976d018 >> > > > [ 0.000000] ACPI: UEFI 0x000000006FF53000 000042 (v01 LENOVO TP-N1W 00001200 PTEC 00000002) >> > > > [ 0.000000] ACPI: UEFI 0x000000006FF39000 00013E (v01 LENOVO TP-N1W 00001200 PTEC 00000002) >> > > >> > > It sure doesn't look 2.5 compliant to me. Merely adding the new stuff >> > > from a new UEFI spec version doesn't mean it's compliant with the >> > > current nor previous versions. If I'm wrong, I'd love to hear >> > > especially from the author or someone with first-hand knowledge. >> > > >> > > -- >> > > -Gene >> > >> > Joakim, attached is a TGZ with some test binaries. I'm assuming the >> > "imd" will print one device while "mnp" another. This is mostly to >> > firm up which devices it's actually trying to use. Based on your >> > other results, this should help a little more to understand how the >> > code is reacting to your machine. It won't give me an answer but just >> > lead me towards the next step. >> >> Hi Gene, thanks for staying with me :) >> >> There was only one syslinux.efi/ldlinux.e64 in the tar file and it printed:Sounds like you got the attachment intact.> Hi again > > We got a new server so figured we should try UEFI PXE on that so used your latest debug > build and got similar results(efi.jpg). Using a EFI linux kernel directly does not > work either(efistub.jpg) > > JockeYour previous message was held due to a attachment limit on the list. These were a lot smaller. efi.jpg: imd-Finding path; to str; imd at Acpi(PNP0A03,0)/Pci(1C|0)/Pci(0|0)/Mac(40F2E92FCA02)/IPv4(not-done) Getting cached packet My IP is 192.168.201.185 netmask 255.255.255.0 gateway 192.168.201.1 mnp-Finding path; to str; mnp at Acpi(PNP0A03,0)/Pci(1C|0)/Pci(0|0)/Mac(40F2E92FCA02) efistub.jpg:>>Start PXE over IPv4.Station IP address is 192.168.201.185 Server IP address is 10.210.32.100 NBP filename is pxelinux.0 NBP filesize is 6644000 Bytes Downloading NBP file... Succeed to download NBP file. Downloading NBP file... Succeed to download NBP file. I was a bit concerned about the "IPv4(not-done)" bit until I saw that gnu-efi has that in the code and doesn't decode the IP address. -- -Gene
> > efistub.jpg: > > >>Start PXE over IPv4. > Station IP address is 192.168.201.185 > > Server IP address is 10.210.32.100 > NBP filename is pxelinux.0 > NBP filesize is 6644000 Bytes > Downloading NBP file... > > Succeed to download NBP file. > > Downloading NBP file... > > Succeed to download NBP file. >I will not pretend that I understand all these technical details, but I do know one thing: pxelinux.0 is not for UEFI (unless in CSM mode). So, here's a (somewhat rhetorical) question: why are "efistub" and "pxelinux.0" together in this conversation? Regards, Ady.
On Wed, 2017-12-13 at 10:34 -0500, Gene Cumm wrote:> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On Wed, Dec 13, 2017 at 7:03 AM, Joakim Tjernlund > <Joakim.Tjernlund at infinera.com> wrote: > > On Mon, 2017-12-11 at 08:59 +0100, Joakim Tjernlund wrote: > > > On Sun, 2017-12-10 at 14:41 -0500, Gene Cumm wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > > > > > > > On Wed, Dec 6, 2017 at 6:49 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > > > > On Wed, Nov 29, 2017 at 6:30 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > > > > > On Tue, Nov 28, 2017 at 2:38 PM, Joakim Tjernlund > > > > > > > Gene, I am curious, do you have an idea how to fix this? > > > > > > > > > > > > Yes, I have an idea but I need to add some debug code so I can > > > > > > understand more how your particular machine is behaving. > > > > > > > > > > > > -- > > > > > > -Gene > > > > > > > > > > On Tue, Nov 28, 2017 at 6:45 AM, Joakim Tjernlund via Syslinux > > > > > <syslinux at zytor.com> wrote: > > > > > > > > > > > But I have tried older versions too. Seems my Lenovo EFI is too "modern" for syslinux > > > > > > but I think Gene has an idea how to solve it. > > > > > > > > > > Too modern? Nope, again, broken. A PxeBc should be atop a MNPSb atop > > > > > a Net. (EDK shell uses the short names for the GUIDs; EDK2 shell uses > > > > > longer names). Yours has PxeBc atop a Net with MNPSb on another > > > > > handle. This is not the first and doubtfully the last we'll > > > > > encounter. UEFI-2.0 allows this but starting in UEFI-2.1, it MUST > > > > > live atop an MNPSb. > > > > > > > > > > I'm still trying to build something that'll print the paths but > > > > > strangely having issues. > > > > > > > > > > On Mon, Nov 27, 2017 at 6:39 PM, Joakim Tjernlund > > > > > <Joakim.Tjernlund at infinera.com> wrote: > > > > > > > > > > > Fond an old boot logg: > > > > > > [ 0.000000] efi: EFI v2.50 by Lenovo > > > > > > [ 0.000000] efi: SMBIOS=0x6f098000 SMBIOS 3.0=0x6f095000 ACPI=0x6fffe000 ACPI 2.0=0x6fffe014 MPS=0x6f468000 ESRT=0x6eb33000 MEMATTR=0x6976d018 > > > > > > [ 0.000000] ACPI: UEFI 0x000000006FF53000 000042 (v01 LENOVO TP-N1W 00001200 PTEC 00000002) > > > > > > [ 0.000000] ACPI: UEFI 0x000000006FF39000 00013E (v01 LENOVO TP-N1W 00001200 PTEC 00000002) > > > > > > > > > > It sure doesn't look 2.5 compliant to me. Merely adding the new stuff > > > > > from a new UEFI spec version doesn't mean it's compliant with the > > > > > current nor previous versions. If I'm wrong, I'd love to hear > > > > > especially from the author or someone with first-hand knowledge. > > > > > > > > > > -- > > > > > -Gene > > > > > > > > Joakim, attached is a TGZ with some test binaries. I'm assuming the > > > > "imd" will print one device while "mnp" another. This is mostly to > > > > firm up which devices it's actually trying to use. Based on your > > > > other results, this should help a little more to understand how the > > > > code is reacting to your machine. It won't give me an answer but just > > > > lead me towards the next step. > > > > > > Hi Gene, thanks for staying with me :) > > > > > > There was only one syslinux.efi/ldlinux.e64 in the tar file and it printed: > > Sounds like you got the attachment intact. > > > Hi again > > > > We got a new server so figured we should try UEFI PXE on that so used your latest debug > > build and got similar results(efi.jpg). Using a EFI linux kernel directly does not > > work either(efistub.jpg) > > > > Jocke > > Your previous message was held due to a attachment limit on the list. > These were a lot smaller. > > efi.jpg: > > imd-Finding path; to str; > imd at Acpi(PNP0A03,0)/Pci(1C|0)/Pci(0|0)/Mac(40F2E92FCA02)/IPv4(not-done) > Getting cached packet > My IP is 192.168.201.185 > netmask 255.255.255.0 gateway 192.168.201.1 > mnp-Finding path; to str; > mnp at Acpi(PNP0A03,0)/Pci(1C|0)/Pci(0|0)/Mac(40F2E92FCA02) > > > efistub.jpg: > > > > Start PXE over IPv4. > > Station IP address is 192.168.201.185 > > Server IP address is 10.210.32.100 > NBP filename is pxelinux.0 > NBP filesize is 6644000 Bytes > Downloading NBP file... > > Succeed to download NBP file. > > Downloading NBP file... > > Succeed to download NBP file. > > > I was a bit concerned about the "IPv4(not-done)" bit until I saw that > gnu-efi has that in the code and doesn't decode the IP address. >Any progress on figuring out what is causing the problem on my Lenovo laptop? Jocke