From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Pa6UB-00052N-1c for mharc-grub-devel@gnu.org; Tue, 04 Jan 2011 07:59:35 -0500 Received: from [140.186.70.92] (port=37023 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pa6U8-0004zo-49 for grub-devel@gnu.org; Tue, 04 Jan 2011 07:59:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pa6U6-0003qb-IX for grub-devel@gnu.org; Tue, 04 Jan 2011 07:59:31 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:47963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pa6U6-0003qL-9e for grub-devel@gnu.org; Tue, 04 Jan 2011 07:59:30 -0500 Received: by wyj26 with SMTP id 26so14885000wyj.0 for ; Tue, 04 Jan 2011 04:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=NxwZn5TP36q3cCLP+w5u9AV9mdcIVidQJM/pAWImhGc=; b=KGiH8SP4EF/iiN5N0ZTMu1+ywT0VjHzcV7mu9yu7uj0Ta2rug2ts5ZvRuNnEV4Yl8A BwpkblJLBCk65TMfrX2C9VOpeeU1ArWlTjmSPdxs05iPoiia9dqOicH16KAPuMJwaU9l ykQupO+2+PUjAw0ejlGy9DfqwBr7zmBSvcCKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=W72hpRV9eHWh7pH6AnoMDXaanklglv5PdXswvCZXeVlsr1scoK9ZXS7+PH93w6fTmH h4MaOhumAFR6Mhwri4TibxTaU13j8iT1w0Qjuf3IWbb90v+icx4EIdxUaQ6/9HGGWcvs 36Q6hBf2Ej4CBnW2D8NJFj8wOopR/t/HKgMKo= Received: by 10.217.3.13 with SMTP id q13mr8349099wes.70.1294145968220; Tue, 04 Jan 2011 04:59:28 -0800 (PST) Received: from debian.bg45.phnet (102-33.62-81.cust.bluewin.ch [81.62.33.102]) by mx.google.com with ESMTPS id o19sm10504787wee.26.2011.01.04.04.59.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 04:59:25 -0800 (PST) Message-ID: <4D23199F.6050506@gmail.com> Date: Tue, 04 Jan 2011 13:59:11 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 MIME-Version: 1.0 To: The development of GNU GRUB References: <22824150.11271836407741.JavaMail.root@wombat> In-Reply-To: <22824150.11271836407741.JavaMail.root@wombat> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig82024C9CBD56B9970A634BE5" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: gburanov@gmail.com Subject: Re: GRUB2 for UEFI crashes at startup when we got 8 gigabyte of memory X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Tue, 04 Jan 2011 12:59:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig82024C9CBD56B9970A634BE5 Content-Type: multipart/mixed; boundary="------------090006030900090006010804" This is a multi-part message in MIME format. --------------090006030900090006010804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/21/2010 09:53 AM, gburanov@gmail.com wrote: > In Febryary I was testing GRUB for UEFI and noticed that it was simply = crashing. > > See topic > http://lists.gnu.org/archive/html/grub-devel/2010-02/msg00000.html > > At that time I blamed incorrect UEFI implementation on that computer (c= ause it worked fine on another one), but now I noticed that when I took o= ff one memory stick, everything is working fine on that special computer!= !!! > > So, it seems that GRUB2 is crashing on computers with 8 gb of memory (= or more?) > > =20 It has been discovered that some EFI implementations contrary to the following sentence from the spec " any memory space defined by the UEFI memory map is identity mapped (virtual address equals physical address). " do not map the post-4G memory. Attached is a possible workaround. Can you test it? > Is it known bug? Are there workarounds? > > > -- > This message was sent on behalf of gburanov@gmail.com at openSubscriber= =2Ecom > http://www.opensubscriber.com/messages/grub-devel@gnu.org/topic.html > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------090006030900090006010804 Content-Type: text/x-diff; name="efi_l4.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="efi_l4.diff" =3D=3D=3D modified file 'grub-core/kern/efi/mm.c' --- grub-core/kern/efi/mm.c 2010-10-16 15:50:48 +0000 +++ grub-core/kern/efi/mm.c 2011-01-04 12:56:14 +0000 @@ -52,13 +52,13 @@ grub_efi_status_t status; grub_efi_boot_services_t *b; =20 -#if GRUB_TARGET_SIZEOF_VOID_P < 8 +#if 1 /* Limit the memory access to less than 4GB for 32-bit platforms. */ if (address > 0xffffffff) return 0; #endif =20 -#if GRUB_TARGET_SIZEOF_VOID_P < 8 || defined (MCMODEL_SMALL) +#if 1 if (address =3D=3D 0) { type =3D GRUB_EFI_ALLOCATE_MAX_ADDRESS; @@ -251,7 +251,7 @@ desc =3D NEXT_MEMORY_DESCRIPTOR (desc, desc_size)) { if (desc->type =3D=3D GRUB_EFI_CONVENTIONAL_MEMORY -#if GRUB_TARGET_SIZEOF_VOID_P < 8 || defined (MCMODEL_SMALL) +#if 1 && desc->physical_start <=3D 0xffffffff #endif && desc->physical_start + PAGES_TO_BYTES (desc->num_pages) > 0x100000= @@ -267,7 +267,7 @@ desc->physical_start =3D 0x100000; } =20 -#if GRUB_TARGET_SIZEOF_VOID_P < 8 || defined (MCMODEL_SMALL) +#if 1 if (BYTES_TO_PAGES (filtered_desc->physical_start) + filtered_desc->num_pages > BYTES_TO_PAGES (0x100000000LL)) --------------090006030900090006010804 Content-Type: text/x-diff; name="efi4G.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="efi4G.diff" =3D=3D=3D modified file 'grub-core/lib/efi/relocator.c' --- grub-core/lib/efi/relocator.c 2010-04-20 16:08:26 +0000 +++ grub-core/lib/efi/relocator.c 2011-01-04 11:02:37 +0000 @@ -62,13 +62,25 @@ (char *) desc < ((char *) descs + mmapsize); desc =3D NEXT_MEMORY_DESCRIPTOR (desc, desc_size)) { + grub_uint64_t start =3D desc->physical_start; + grub_uint64_t end =3D desc->physical_start + (desc->num_pages << 1= 2); + + /* post-4G addresses are never supported on 32-bit EFI.=20 + Moreover it has been reported that some 64-bit EFI contrary to the + spec don't map post-4G pages. So if you enable post-4G allocations, + map pages manually or check that they are mapped. + */ + if (end >=3D 0x100000000ULL) + end =3D 0x100000000ULL; + if (end <=3D start) + continue; if (desc->type !=3D GRUB_EFI_CONVENTIONAL_MEMORY) continue; events[counter].type =3D REG_FIRMWARE_START; - events[counter].pos =3D desc->physical_start; + events[counter].pos =3D start; counter++; events[counter].type =3D REG_FIRMWARE_END; - events[counter].pos =3D desc->physical_start + (desc->num_pages <<= 12); + events[counter].pos =3D end; counter++; =20 } =20 @@ -85,6 +97,9 @@ if (grub_efi_is_finished) return 1; =20 + grub_dprintf ("relocator", "EFI alloc: %llx, %llx\n", + (unsigned long long) start, (unsigned long long) size); + b =3D grub_efi_system_table->boot_services; status =3D efi_call_4 (b->allocate_pages, GRUB_EFI_ALLOCATE_ADDRESS, GRUB_EFI_LOADER_DATA, size >> 12, &address); --------------090006030900090006010804-- --------------enig82024C9CBD56B9970A634BE5 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk0jGZ8ACgkQNak7dOguQgkYfgD9FTfXD48GyxYcrd8XefKtxnPJ 5ok5lTuWQykBZJPYjiwBAKhVgJe+089dtNwGYGOwH1C8K3hDn+f8REslk8BXscEX =DqGi -----END PGP SIGNATURE----- --------------enig82024C9CBD56B9970A634BE5--