[syslinux] core_udp_sendto: no mapping

[Gene Cumm]

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.
>
> --
> -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