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. 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. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
