From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 48C0E210C642A for ; Thu, 2 Aug 2018 07:44:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E7EDCFB48; Thu, 2 Aug 2018 14:44:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-32.rdu2.redhat.com [10.10.123.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 95BEC2026D69; Thu, 2 Aug 2018 14:44:17 +0000 (UTC) To: Rafael Machado , Andrew Fish Cc: "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Yao, Jiewen" References: <74D8A39837DF1E4DA445A8C0B3885C503AC75235@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BD4FFA1@SHSMSX104.ccr.corp.intel.com> <17C6FC15-6D2E-41A6-8996-15E665C4D28F@apple.com> From: Laszlo Ersek Message-ID: <40832a91-0eca-3b9f-f533-f98666295a25@redhat.com> Date: Thu, 2 Aug 2018 16:44:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 02 Aug 2018 14:44:18 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 02 Aug 2018 14:44:18 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' 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 14:44:20 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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/87acb6e298e718250dd8b741b6888a3a54c7cb5a/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 the > 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 about > the MemoryTypeInformation efi var, that may be corrupted, and considering > it's used to guide the boot process it may impact the boot, but I am not > sure if this is the case and also I didn't find to much information about > 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