On Thu, Jun 23, 2016 at 02:57:49PM +0200, Laszlo Ersek wrote: > On 06/23/16 06:43, Gary Lin wrote: > > On Wed, Jun 22, 2016 at 07:24:32PM +0200, Laszlo Ersek wrote: > >> Gary, > >> > >> On 06/22/16 17:33, Laszlo Ersek wrote: > >>> On 06/22/16 17:24, Gerd Hoffmann wrote: > >>>> On Mi, 2016-06-22 at 17:14 +0200, Laszlo Ersek wrote: > >>>>> On 06/22/16 10:34, Michael Brown wrote: > >>>>>> On 22/06/16 05:48, Laszlo Ersek wrote: > >>>>>>> In other words, the memcpy() quoted at the top copies 32 bytes into a > >>>>>>> 32-byte buffer, from a 20-byte buffer. It is the *source* buffer that > >>>>>>> is > >>>>>>> overflowed. > >>>>>>> > >>>>>>> As a result, bytes 20..31 of MacAddress (inclusive) are filled with > >>>>>>> garbage. > >>>>>> > >>>>>> Awesome debugging; thank you! I've pushed a fix at > >>>>>> > >>>>>> http://git.ipxe.org/ipxe.git/commitdiff/632e57f > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Gerd, do you think you can rebuild the iPXE binaries bundled with QEMU > >>>>> during the 2.7 soft/hard freeze <http://wiki.qemu.org/Planning/2.7>? > >>>> > >>>> I intend to update ipxe before softfreeze (and if it doesn't work out > >>>> for some reason surely before hardfreeze), to pick up this fix and > >>>> virtio 1.0 support. > >>>> > >>>> What is the state of this? IIRC there was some other issue beside this > >>>> ipxe bugfix. > >>> > >>> Right, when you open the iPXE form, that triggers an ASSERT(). > >>> > >>>> Is this root-caused meanwhile? edk2 issue? ipxe issue? > >>> > >>> I'll try to look into that next. > >>> > >>>> Should I wait for more ipxe fixes or can I go ahead with the update? > >>> > >>> Assuming you can sneak an iPXE rebuild into the QEMU soft freeze, I > >>> think it makes sense to wait a bit longer -- let's hope I can come up > >>> with something sensible for that error too... > >> > >> can you please retest with a fresh build of the current iPXE master (at > >> 04186319181298083ef28695a8309028b26fe83c presently)? I can no longer > >> reproduce the ASSERT -- the iPXE form can be entered just fine. > >> > >> I don't know what changed. o_O > >> > > I still got the crash all the time with 0418631918. However, Switching > > to cc8824ad (plus the size fix) lowers the chance of crash largerly > > (around 1 from 10). cc8824ad is the commit that is right before this: > > > > 5238c85b623200fa0f44a46db93965080053f745 > > [efi] Work around broken EFI HII specification > > > > The iPXE option started to crash all the time after I switched to > > 5238c85b6. However, reverting 5238c85b6 on git master didn't moderate > > the crash. The root cause is still hiding somewhere... > > If it reproduces non-deterministically, that's quite bad. If we don't > have a reliable reproducer, I'm not sure how it can be analyzed. > In my case:
ipxe git 04186319 -> always crash ipxe git cc8824ad -> 10% crash I had some findings by comparing the crash and non-crash log with cc8824ad. 1. For the non-crash case, all the Statement->ParentStatement of the iPXE options were NULL in InitializeDisplayStatement(). 2. For the crash case, one of the Scope of the iPXE Statement became non-zero, so MdeModulePkg/Universal/SetupBrowserDxe/IfrParse.c:ParseOpCodes() assigned CurrentStatement to ParentStatement. When this happened, it's always the statement for "TFTP server". > Can you perhaps correlate the crash with network traffic (tcpdump)? I'm > just grasping at straws here. Also, what exactly is your OVMF build > command line? Maybe it correlates somehow with the set of modules built > into OVMF. > I built OVMF with this command: ./build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE Hope this helps. Thanks, Gary Lin _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
