[ipxe-devel] snponly.efi broken
Jarrod Johnson
jarrod.b.johnson at gmail.com
Wed Aug 6 18:40:31 UTC 2014
PXE initialising devices...EFIDRV connecting our drivers
EFIPCI 0x6952b718 PciRoot(0x0)/Pci(0x5,0x4) cannot read PCI configuration:
No such device (http://ipxe.org/2c044087)
EFIPCI 0x69527618 PciRoot(0x0)/Pci(0x1F,0x6) cannot read PCI configuration:
No such device (http://ipxe.org/2c044087)
EFIPCI 0x69524318 PciRoot(0x1)/Pci(0x5,0x4) cannot read PCI configuration:
No such device (http://ipxe.org/2c044087)
SNP 0x691e5f18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)
is an SNP device
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) has driver
"SNP"
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) disconnecting
existing drivers
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) connecting new
drivers
SNP 0x691e5f18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)
is an SNP device
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) has driver
"SNP"
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) DRIVER_START
SNP 0x691e5f18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)
is an SNP device
SNP 0x691e5f18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)
registered as net0
EFIDRV 0x691e5f18
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) using driver
"SNP"
SNP 0x69c24b98 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0)
is an SNP device
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) has driver
"SNP"
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) disconnecting
existing drivers
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) connecting new
drivers
SNP 0x69c24b98 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0)
is an SNP device
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) has driver
"SNP"
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) DRIVER_START
SNP 0x69c24b98 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0)
is an SNP device
SNP 0x69c24b98 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0)
registered as net1
EFIDRV 0x69c24b98
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x1)/MAC(5CF3FC6E473C,0x0) using driver
"SNP"
ok
iPXE 1.0.0+ (b17d9) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: HTTP DNS TFTP EFI Menu
iPXE> ifstat
net0: 5c:f3:fc:6e:47:38 using SNP on SNP-PCI0c:00.0 (closed)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]
net1: 5c:f3:fc:6e:47:3c using SNP on SNP-PCI0c:00.1 (closed)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Unknown (http://ipxe.org/1a086194)]
And it did work at that point... snponly.efi looks no better (as you'd
expect). It seems netX has no meaning so I don't see a nice way to tell
which nic did work to continue trying to boot from. Maybe it would be
possible to do the same search that snp.efi and correlate with the loaded
image indicated device?
> I'm contemplating a similar course of action, for the sake of booting
Windows.
Yes that was first and foremost on my mind, making bootmgfw.efi work.
Incidentally, though esxi's bootloader will do download protocol, I would
also lean toward that style boot for them so that the download is in
imgfetch rather than through the bootloader which doesn't do serial output
so well and I like seeing network interaction on serial console. Also for
elilo since I have to patch elilo today and such a boot mode would not
require that...
On Wed, Aug 6, 2014 at 11:00 AM, Michael Brown <mcb30 at ipxe.org> wrote:
> On 06/08/14 15:40, Jarrod Johnson wrote:
>
>> EFIDRV 0x691db218
>> PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) could not
>> open device path: Error 0x7f37e08f (http://ipxe.org/7f37e08f)
>>
>
> This error can no longer happen, as of commit
>
> http://git.ipxe.org/ipxe.git/commitdiff/7b3cc18
>
> Could you retry with the latest iPXE code?
>
>
> I guess my question on having to disconnect the protocols is how
>> important that is in the snp or snponly cases.
>>
>
> From observation, MNP installs a periodic timer which will continually
> attempt to retrieve packets from the SNP device. If iPXE attempts to use
> the SNP device without having first disconnected MNP, then we are likely to
> experience heavy packet loss.
>
>
> I will confess to having thought about creating a simple filesystem device
>> that in no way looks like a network device to avoid triggering network
>> behaviors in EFI bootloaders, but that would probably be making a new
>> device handle instead of trying to use the network device.
>>
>
> I'm contemplating a similar course of action, for the sake of booting
> Windows.
>
>
> That said, forgive me if this sounds stupid but I don't know better...
>> Would it make sense to chase the parentage of the device path of
>> interested looking for a managed network protocol device in this case?
>>
>
> It's plausible that MNP has not yet been connected to (or has already been
> disconnected from) the SNP device, in which case we wouldn't find it.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20140806/1bea1843/attachment.htm>
More information about the ipxe-devel
mailing list