From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SkiWq-0006lS-QQ for mharc-grub-devel@gnu.org; Fri, 29 Jun 2012 17:15:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkiWn-0006k1-As for grub-devel@gnu.org; Fri, 29 Jun 2012 17:14:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SkiWl-0005SA-DC for grub-devel@gnu.org; Fri, 29 Jun 2012 17:14:56 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:49875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkiWl-0005Rt-0q for grub-devel@gnu.org; Fri, 29 Jun 2012 17:14:55 -0400 Received: by wibhq4 with SMTP id hq4so1036342wib.12 for ; Fri, 29 Jun 2012 14:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=u7XUSW+D+2nw0dBwgiSNM6qMCx/QDuQImwSxWm5vpX4=; b=C5+AX5MzWcSQMltAfODBu96xnxmgTdoY3+GYlMNbJ/JKvDtkAcvrUvuPk/+zZomk8r vV/PgWprF35nMXGLNZ4/ceFq+GonSal+GkcqX8aPq3MPz4xBqPuxSp3RwYsbyo1cnjbt Do1SYL7Zy+toDUkyV2b580eCnW/m5RrZJ7aMGL8JnNET7JW9iO1C0XhMoxSigKhCGwZk 4JjF9r9Oi1W1/mM+OF6LVAV9t4Fj8hdQl+h/0MiJIxLBLmZd9sV4o/2ii/+Ntaz9cO0Q fZWDJCaKrmFatXv63rqCbV3xrRMp5qbcX+ST6thqneJO5how1aJ/qrfXA+RP+ifPipsu U1JQ== Received: by 10.180.94.4 with SMTP id cy4mr981024wib.2.1341004493050; Fri, 29 Jun 2012 14:14:53 -0700 (PDT) Received: from debian.x201.phnet (105-233.197-178.cust.bluewin.ch. [178.197.233.105]) by mx.google.com with ESMTPS id f10sm13807959wiw.1.2012.06.29.14.14.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 14:14:52 -0700 (PDT) Message-ID: <4FEE1AB8.3050102@gmail.com> Date: Fri, 29 Jun 2012 23:14:32 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [bug #36532] boot in EFI mode (x86_64) fails on some systems References: <20120523-193311.sv88235.49420@savannah.gnu.org> <20120531-112908.sv72589.64321@savannah.gnu.org> <959D45574D89AF41A9DADF6F446A2E9A2AE507A772@AUSX7MCPS310.AMER.DELL.COM> <959D45574D89AF41A9DADF6F446A2E9A2AE55A707B@AUSX7MCPS310.AMER.DELL.COM> <4FD1180B.8090709@gmail.com> <959D45574D89AF41A9DADF6F446A2E9A2AE5668374@AUSX7MCPS310.AMER.DELL.COM> <4FD646FE.4050301@gmail.com> <959D45574D89AF41A9DADF6F446A2E9A2AE56AEA8E@AUSX7MCPS310.AMER.DELL.COM> <4FD79D9E.6010702@gmail.com> <959D45574D89AF41A9DADF6F446A2E9A2AEC020701@AUSX7MCPS310.AMER.DELL.COM> <4FEB721E.3080908@gmail.com> <959D45574D89AF41A9DADF6F446A2E9A2AEC0F46AF@AUSX7MCPS310.AMER.DELL.COM> In-Reply-To: <959D45574D89AF41A9DADF6F446A2E9A2AEC0F46AF@AUSX7MCPS310.AMER.DELL.COM> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB313998C9603EFF978490191" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.171 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:14:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB313998C9603EFF978490191 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29.06.2012 22:49, Stuart_Hayes@Dell.com wrote: >>>>> Vladimir, >>>>> >>>>> The 2.00rc1 version of grub2 still doesn't fix the efi memory map >>>> buffer size I've been working on (though I can see you are now >>>> allocating the efi memory map buffer very shortly before you are >>>> calling grub_efi_finish_boot_services()). >>>>> >>>>> Increasing the mmap_size in find_efi_mmap_size()--as in the patch >>>> immediately above this text--does fix the problem. Even adding (2 >> << >>>> 12) (instead of (1 << 12)) to the mmap_size will work on the system >>> I'm >>>> testing with. >>>>> >>>> >>>> I've changed it to 3. Thanks. It's annoying that even such simple >>>> operations as we have between find_efi_mmap and finish drastically >>>> increase memory map size. >>>> >>>> -- >>>> Regards >>>> Vladimir '=CF=86-coder/phcoder' Serbinenko >>> >>> Thanks! I completely agree that it is annoying. >>> >> >> FYI, while grub-2.00 works on my system now, someone else here at Dell= >> has tested it and found that it still doesn't work. (I verified that >> they were indeed using version 2.00, and saw the error myself). >> >> I have no idea how or why the memory map size is growing that much. A= s >> I get time, I'll try to figure that out... >=20 > FYI again: >=20 > I've found the problem. The memory map is not growing wildly... it is = more of a firmware "quirk." The firmware is thinking it needs a larger b= uffer than it actually needs. So calls to GetMemoryMap with a buffer tha= t is smaller than (say) 52368 bytes will return EFI_BUFFER_TOO_SMALL and = say that the buffer needs to be 52368 bytes, but then when you call it wi= th a buffer that's 52368 bytes, it will put the memory map into the buffe= r and tell you that the memory map is in fact only (say) 24576 bytes. >=20 > Unfortunately, right now, find_efi_mmap_size() will then return 24576 b= ytes (plus 3 pages, aligned to a page size), which isn't enough, but not = because the memory map size is growing... >=20 > I'll send in a patch for grub that will make it immune to this quirk...= it should be pretty low risk (I'm thinking modify find_efi_mmap_size() t= o use the value of mmap_size that was passed to grub_efi_get_memory_map()= , rather than the value of mmap_size that was returned from that function= =2E) With that, I don't believe it would even need to add 3 pages to the= memory map size (I watched the memory map size, and it is not growing si= gnificantly). >=20 What about this: =3D=3D=3D modified file 'grub-core/loader/i386/linux.c' --- grub-core/loader/i386/linux.c 2012-06-27 20:55:09 +0000 +++ grub-core/loader/i386/linux.c 2012-06-29 21:12:53 +0000 @@ -118,12 +118,13 @@ find_efi_mmap_size (void) int ret; grub_efi_memory_descriptor_t *mmap; grub_efi_uintn_t desc_size; + grub_efi_uintn_t cur_mmap_size =3D mmap_size; =20 - mmap =3D grub_malloc (mmap_size); + mmap =3D grub_malloc (cur_mmap_size); if (! mmap) return 0; =20 - ret =3D grub_efi_get_memory_map (&mmap_size, mmap, 0, &desc_size, = 0); + ret =3D grub_efi_get_memory_map (&cur_mmap_size, mmap, 0, &desc_si= ze, 0); grub_free (mmap); =20 if (ret < 0) @@ -134,6 +135,8 @@ find_efi_mmap_size (void) else if (ret > 0) break; =20 + if (mmap_size < cur_mmap_size) + mmap_size =3D cur_mmap_size; mmap_size +=3D (1 << 12); } =20 It will take the largest size returned which should be safe. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigB313998C9603EFF978490191 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk/uGrgACgkQNak7dOguQgmUpQD9Fy1iGwbHiogUMLD5+oH7+dnW ubshtLAeYpRSmgyinSQA/293MtD7K30KdEuPimMI73cb+SO9wefmxre+9tAFAIWi =DfhR -----END PGP SIGNATURE----- --------------enigB313998C9603EFF978490191--