Dell - Internal Use - Confidential Christian,
The possibility of using a different NIC was suggested to us either being the Intel X520 8086:10fb or Broadcom 57412 14e4:16d6. Are either of those NICs compatible with the iPXE stack, I attempted to look online to see if they were compatible but may have missed the list. Lynn Heinemann Principal Engineer, Solutions Support Team Dell EMC| Remote Services and Solutions Office: +1 512 723 7471 lynn.heinem...@dell.com -----Original Message----- From: Christian Nilsson [mailto:nik...@gmail.com] Sent: Thursday, January 11, 2018 2:13 PM To: Heinemann, Lynn <lynn_heinem...@dell.com> Cc: iPXE Developer List <ipxe-de...@ipxe.org> Subject: Re: iPXE MemoryAllocationLib.c assert failures on Dell PowerEdge There is not yet any native drivers for 8086:1572 in iPXE which strengthens the possibility of it being the NIC firmware / SNP driver that is at fault. Does the NIC have separate firmware ROM or is it included in the mainboard firmware? and have you made sure that you are using the same firmware revisions as the customer? I would recommend these build commands: make -j16 bin-x86_64-efi/ipxe.efi DEBUG=snp,snponly,nii make -j16 bin-x86_64-efi/snponly.efi DEBUG=snp,snponly,nii This should show a bit more info and hopefully it will give us an idea of what it does when the assert happens. /Christian On Thu, Jan 11, 2018 at 9:01 PM, <lynn.heinem...@dell.com> wrote: > Dell - Internal Use - Confidential > > I really appreciate the quick reply, no we have not attempted to use the > snponly.efi only the compiled ipxe.efi provided by our end user. To date, > this error has only occurred within the end user environment, I have been > unable to recreate it in my lab. I'm looking for options to increase the > value of our debugging with the end user. The network card being used is a > Dell branded Intel X710 4 port SFP daughter card pci identifier > 8086:1572:1028:0000. > > Lynn Heinemann > Principal Engineer, Solutions Support Team Dell EMC| Remote Services > and Solutions > Office: +1 512 723 7471 > lynn.heinem...@dell.com > > -----Original Message----- > From: Christian Nilsson [mailto:nik...@gmail.com] > Sent: Thursday, January 11, 2018 1:51 PM > To: Heinemann, Lynn <lynn_heinem...@dell.com> > Cc: iPXE Developer List <ipxe-de...@ipxe.org> > Subject: RE: iPXE MemoryAllocationLib.c assert failures on Dell > PowerEdge > > From: <lynn.heinem...@dell.com> > Date: Thu, 11 Jan 2018 15:05:57 > Good morning, > > I'm reaching out to the iPXE dev team for some possible assistance with an > issue one of our customers is seeing. Due to confidentiality, I cannot share > details but I'm hoping to leverage some of the community development > expertise on how to further debug this issue. > > In short, we have a Dell PowerEdge server and Intel 10Gb network card that's > attempting to boot in UEFI mode to a PXE server, and fails during ipxe.efi > initialization with the following error: > > iPXE initialising devices...ASSERT > u:\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllocationLib.c(819): > !EFI_ERROR (Status) > > I have Dell engineering resources available to debug the hardware aspect of > this issue but the necessary knowledge of adding debug functions to the iPXE > efi image itself is lacking. The version of iPXE we're using is the > following commit: > > https://github.com/ipxe/ipxe/tree/1b67a0564657b6fcef18b1588ea6491ca1b1 > 996d > > I've compiled this on RedHat 7.4 and 6.2 with no flags other than a very > basic embed script that lists things like system asset information and mac > address on console but the assert is happening within the first 3 or 4 lines > of the NIC starting the PXE bootstrap. > > I apologize for the slim amount of information but can you provide any > thoughts or suggestions? > > Lynn Heinemann > Principal Engineer, Solutions Support Team Dell EMC| Remote Services > and Solutions > Office: +1 512 723 7471<tel:15127237471> > lynn.heinem...@dell.com<mailto:lynn.heinem...@dell.com> > > Confidentiality Notice: This email message, including any attachments, is f= > or the sole use of the intended recipient(s) and may contain confidential o= > r proprietary information. Any unauthorized review, use, disclosure or dist= > ribution is prohibited. If you are not the intended recipient, immediately = > contact the sender by reply e-mail and destroy all copies of the original m= > essage. > > Hi, > Not sure if your email reached the list properly, but will answer so > it does reach the list in at least some way ;) > > Which exact PCI device is this? might not be relevant but please provide it > for completeness. > > if you use snponly.efi does that show the same behavior? also please try > without and with the embedded script. > > The assert itself is not from iPXE code, but more probable from the EFI > firmware itself. (or some kind of efi firmware at least), it might be in the > NIC firmware that occurs when the SNP driver is loaded, could you try to > remove or disable the NIC and see if you get the same thing? > > iPXE have the syntax when building of DEBUG=any_c_file,other_c_file > here is some more info: http://ipxe.org/download#debug_builds > > > Official git repo is at: http://git.ipxe.org/ipxe.git current master is > always recommended to try, but there don't seem to be any changes that should > have any impact here. > > Regards > Christian _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
