From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4003:c06::22d; helo=mail-oi0-x22d.google.com; envelope-from=rafaelrodrigues.machado@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9FB0A210C642A for ; Thu, 2 Aug 2018 09:42:41 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 8-v6so4896105oip.0 for ; Thu, 02 Aug 2018 09:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V65Z0tBO7m+qdThVRkjdlvRqbCpzm2cZUTZAnL/msqU=; b=sKK2awAiMb3MQtShQTM5kRd1XmtgSAM9x0fdKTAnTkPKhkzEyrjFuolvlGmS2WmW5O ZBENDM22ALRMPxh0Z4b+mHo+nwpOI9mKuC6w+fkCy66XrB4qoO7zFMhcstXZ7bmqhEJy cA/3aJ115qVt1Xuq/rHxdpNHvqcDBKuh3sjWd+XPyphmigt9IGQOWF6QzYmKpckX7ynw jNTJ3lP4Dt9BcCh6uQ48Oh4Y2V5kdsXAlp+cCQJyQYbTgDdSLi953uxo1Jvpssqf3B7k d7fvmq1vdaIS71Kf+aDCeuPZdw6NMQeWGGrbUP4D+8DuLGKmLsYAi2rXSZzHBGer/cuh KHhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V65Z0tBO7m+qdThVRkjdlvRqbCpzm2cZUTZAnL/msqU=; b=iKQtPT34xe/h73E84jtYAiX8WRDHfU9p+pPFQB4zTBtw+n9Erg2QIoWMK+vOOPrOk7 mYyIPGY5wR0C+Rv5uiqhT0kNLpJQIHyNo1pA7lRFb88AeMOo5a9EYErCEOC8KpaViEAw BynxXjQJb7U18qrt5LcPCu+gyo32bWHE7NcrIPOEgBoOjCXEUtRlNF2pNYJdfgQ4UNfp Jp6sIYJBb8VOma6uiT/VJbcrxc2FJHlfwir6LY7EQ6IwN7xd/5xU/Hu5CcFOzx4ny/kY utL5PdVxHfoj0fzMHfP5mg+WcpJczs4d4Mh4vCroyRCLLarXJXGCjKMhdbc58fiL1wJm RWkQ== X-Gm-Message-State: AOUpUlH0F1EWaozZu7AwiYNNQfNTuATH6FU2gOCnN1a1Lw4sHSC8YiUl D94GOcEH3JnDc5d04ypmiD8YNXheNXkPEBFtOLU= X-Google-Smtp-Source: AAOMgpftel9uCWOnkASxrRdZOpeUJxTEcTN/hOo75XjgosJTFXsso/vb98QAWW4qLOpYy+J6RKeE30ujOii/9/9N4wI= X-Received: by 2002:aca:5003:: with SMTP id e3-v6mr96902oib.89.1533228160291; Thu, 02 Aug 2018 09:42:40 -0700 (PDT) MIME-Version: 1.0 References: <74D8A39837DF1E4DA445A8C0B3885C503AC75235@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BD4FFA1@SHSMSX104.ccr.corp.intel.com> <17C6FC15-6D2E-41A6-8996-15E665C4D28F@apple.com> <40832a91-0eca-3b9f-f533-f98666295a25@redhat.com> In-Reply-To: <40832a91-0eca-3b9f-f533-f98666295a25@redhat.com> From: Rafael Machado Date: Thu, 2 Aug 2018 13:42:28 -0300 Message-ID: To: Laszlo Ersek Cc: Andrew Fish , "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Yao, Jiewen" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 Subject: Re: Question about memory map entries X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 16:42:41 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Andrew and Laszlo for the clarification and guidance. About Laszlo questions >Is the reboot automatic (from the platform firmware), or application / >user initiated? Yes. We just do some clean up, finish the events and "return EFI_SUCCESS;" >Do you exit the application before the system is powered off? No. At this test we just let the application finishes it's work and power off the system. No "return EFI_SUCCESS;" Thanks and Regards Rafael Em qui, 2 de ago de 2018 =C3=A0s 11:44, Laszlo Ersek escreveu: > On 08/02/18 14:39, Rafael Machado wrote: > > Hi everyone > > > > After some other tasks I am back to this case :) > > > > After some debug, we detected the moment where things start to go wrong= , > > but I am not sure what may cause this. > > > > What we noticed is that the following assert is reached: > > > https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54= c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199 > > > > Just to remember, this assert is reached with the following steps: > > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > > 2 - Execute the application tasks > > 3 - exit the application (free everything, all events closed and no > memory > > leaks detected as suggested to check by Andrew on the previous e-mail, > then > > return efi_success) > > 4 - the system will reboot and reach the assert > > Is the reboot automatic (from the platform firmware), or application / > user initiated? > > > But it does not happen with the following scenario: > > 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick > > 2 - Execute the application tasks > > 3 - Power off the system > > Do you exit the application before the system is powered off? > > > > > As far as I could understand (please correct my understanding that may = be > > wrong since is the first time I look at this part of the code), at this > > point the HOBs passed from sec phase are processed by PEI so the memory > > could be "detected/mapped/initialized" correctly. But for some reason t= he > > required HOB is no present at the list. > > > > Could someone with more experience at this part of the code please > confirm > > my understanding, and if possible give some guesses about what could > cause > > this scenario? > > PEI may act differently (produce different HOBs) dependent on boot mode. > The PI spec defines several boot modes; it's platform-dependent what > hardware states / transitions are mapped to what PI boot modes by the > firmware. > > > My guess is that some memory cleanup that should be done by the bios > after > > the application exits is not being done correctly. So I believe the > problem > > is not at the application, but at the BIOS. A friend here mentioned abo= ut > > the MemoryTypeInformation efi var, that may be corrupted, and consideri= ng > > it's used to guide the boot process it may impact the boot, but I am no= t > > sure if this is the case and also I didn't find to much information abo= ut > > this var and it's usage, so any help about this would be well received > also. > > MemoryTypeInformation measures peak usage (of various UEFI memory types) > during boot, so that at next boot, the internal allocation "bins" can be > primed with large enough sizes. The goal is to reduce fragmentation due > to "unforeseen" allocations. > > If you exit the application gracefully in both scenarios (and the only > difference is whether you reboot the system, or power it down, > afterwards, e.g. by passing different options to the RESET command of > the UEFI shell), then I don't see how MemoryTypeInformation could be > relevant. > > Thanks > Laszlo >