Yeah, I just AllocateCopyPool the static struct on heap for each device. I can honestly see how one would assume that a protocol instance would never be installed on more than one handle, same as I assumed that using a statically allocated struct containing nothing but boilerplate info would also be fine.
The whole NII and UNDI drivers vs. SNP drivers compatibility across OEMs/IBVs and IHVs is a painful trash fire and this is just the last problem in a very long line of annoyances. </rant> On 22/05/2019 11:19, Laszlo Ersek wrote: > On 05/22/19 11:55, Tomas Pilar wrote: >> iPXE identifies the device it was pxe booted from by searching parents of >> the LoadedImage which support SNP and NII and uses the address of the >> installed NII and SNP as a discriminant to see if a device is in fact the >> one it was pxe booted from. This convoluted process is done to shoehorn >> chainload drivers into the ipxe driver api. >> >> Then it will chainload NII or SNP drivers on all devices if they pass the >> above check. My driver used a global static NII struct and installed that as >> NII on all ports so ipxe then tried to bind its NIIONLY driver on all ports >> on the adapter, not just the one it was pxebooted with. Thus it kicked off >> the network stack including the iSCSI connection on the second port even >> though it was pxe booted into using the first port. >> >> Ugh. > Thanks for the description! > > What is the solution to the problem? Per-port NII structs? (I don't have > any experience with EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL.) > > Thanks > Laszlo > > > >> -----Original Message----- >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek >> Sent: 21 May 2019 20:48 >> To: Devel EDK2 <devel@edk2.groups.io>; Tomas Pilar <tpi...@solarflare.com> >> Subject: Re: [edk2-devel] iSCSI and iBFT >> >> On 05/21/19 16:54, Tomas Pilar (tpilar) wrote: >>> I am going to commit the cardinal sin of online dev support. >> heh :) >> >>> 'Never mind, found the problem' >> What was it? >> >> I didn't ignore your original email -- I looked at iPXE briefly, but >> couldn't blame anything at once, and then I quickly ran out of steam. >> There wasn't anything I could have added to the thread. >> >> Thanks, >> Laszlo >> >>> From: Tomas Pilar >>> Sent: 20 May 2019 16:57 >>> To: 'devel@edk2.groups.io' <devel@edk2.groups.io> >>> Subject: iSCSI and iBFT >>> >>> Hi, >>> >>> I have a bit of an esoteric problem. When I configure the software iscsi >>> intiator that is part of EDK2 platform network stack, the platform network >>> stack with install iBFT table into the ACPI tables so that the >>> configuration can be picked up by further boot loaders and the OS. So far >>> so good. >>> >>> Problem: When I PXE boot into iPXE using my adapter, exit back into boot >>> manager, the iBFT has disappeared. Alternatively, if I use iPXE to then >>> boot WDS, the software initiator in WinPE won't find the iBFT table and >>> therefore won't hook the network drive. >>> >>> Observations: >>> * When I boot into UEFI shell on disk and exit back into boot manager, the >>> iBFT is preserved. >>> >>> * When I PXE boot into UEFI shell and exit, the iBFT is preserved. >>> >>> * When I boot into iPXE on disk and exit, the iBFT is preserved. >>> >>> * When I use a different adapter (Intel) to pxe boot into iBFT and exit >>> back to boot manager, the iBFT has moved from the penultimate position to >>> the last position in the ACPI tables. Almost as if something uninstalled >>> the iBFT and reinstalled it. >>> >>> Any ideas? >>> >>> Cheers >>> Tom >>> >>> >>> >>> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41225): https://edk2.groups.io/g/devel/message/41225 Mute This Topic: https://groups.io/mt/31686860/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
