public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Tomas Pilar <tpilar@solarflare.com>, Devel EDK2 <devel@edk2.groups.io>
Subject: Re: [edk2-devel] iSCSI and iBFT
Date: Wed, 22 May 2019 12:19:07 +0200	[thread overview]
Message-ID: <da8f9967-f333-3fa6-d514-9d7f9bcbcca2@redhat.com> (raw)
In-Reply-To: <1c6545291d0f460fac20abf2187a551c@ukex01.SolarFlarecom.com>

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 <tpilar@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
>>
>>
>>
>>
> 
> 
> 
> 


  reply	other threads:[~2019-05-22 10:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 15:56 iSCSI and iBFT Tomas Pilar (tpilar)
2019-05-21 14:54 ` Tomas Pilar (tpilar)
2019-05-21 19:47   ` [edk2-devel] " Laszlo Ersek
2019-05-22  9:55     ` Tomas Pilar (tpilar)
2019-05-22 10:19       ` Laszlo Ersek [this message]
2019-05-22 10:40         ` Tomas Pilar (tpilar)
2019-05-22 22:26           ` Michael Brown
2019-05-23  9:46             ` Tomas Pilar (tpilar)
2019-05-23 10:35               ` Michael Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da8f9967-f333-3fa6-d514-9d7f9bcbcca2@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox