On Mon, 22 Sep, at 02:44:23PM, Josh Boyer wrote:
>
> This wound up in rc6 as commit
> 9cb0e394234d244fe5a97e743ec9dd7ddff7e64b. That caused all the EFI
> machines I have to no longer boot. They hang after the 'setup_efi_pci
> failed' message and I get nothing from the kernel at all, even with
>
On Mon, 22 Sep, at 02:44:23PM, Josh Boyer wrote:
This wound up in rc6 as commit
9cb0e394234d244fe5a97e743ec9dd7ddff7e64b. That caused all the EFI
machines I have to no longer boot. They hang after the 'setup_efi_pci
failed' message and I get nothing from the kernel at all, even with
On Mon, 08 Sep, at 03:01:31PM, Maarten Lankhorst wrote:
> Sorry, forgot about it.
>
> My system boots fine with this patch, thanks!
Excellent, thanks for testing. I'll queue this up in the 'urgent'
branch.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list:
Hey,
Op 08-09-14 om 14:55 schreef Ard Biesheuvel:
> On 5 September 2014 22:27, Matt Fleming wrote:
>> On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
>>> Thanks Ard, I'll take a look in the morning.
>> Maarten, could you try out this patch?
>>
> Any developments regarding this patch?
> I
On 5 September 2014 22:27, Matt Fleming wrote:
> On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
>>
>> Thanks Ard, I'll take a look in the morning.
>
> Maarten, could you try out this patch?
>
Any developments regarding this patch?
I tried to test it myself, but my Macbook happily boots
On 5 September 2014 22:27, Matt Fleming m...@console-pimps.org wrote:
On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
Thanks Ard, I'll take a look in the morning.
Maarten, could you try out this patch?
Any developments regarding this patch?
I tried to test it myself, but my Macbook
Hey,
Op 08-09-14 om 14:55 schreef Ard Biesheuvel:
On 5 September 2014 22:27, Matt Fleming m...@console-pimps.org wrote:
On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
Thanks Ard, I'll take a look in the morning.
Maarten, could you try out this patch?
Any developments regarding this
On Mon, 08 Sep, at 03:01:31PM, Maarten Lankhorst wrote:
Sorry, forgot about it.
My system boots fine with this patch, thanks!
Excellent, thanks for testing. I'll queue this up in the 'urgent'
branch.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send
On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
>
> Thanks Ard, I'll take a look in the morning.
Maarten, could you try out this patch?
---
>From a058d81d9687671813560af72f34d63da3cc16bc Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 5 Sep 2014 14:52:26 +0100
Subject: [PATCH]
On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
Thanks Ard, I'll take a look in the morning.
Maarten, could you try out this patch?
---
From a058d81d9687671813560af72f34d63da3cc16bc Mon Sep 17 00:00:00 2001
From: Matt Fleming matt.flem...@intel.com
Date: Fri, 5 Sep 2014 14:52:26 +0100
On Thu, 04 Sep, at 11:25:48PM, Ard Biesheuvel wrote:
>
> As it turns out, this breaks 32-bit, and the linker script is shared.
>
> So I suggest that we go with Matt's suggestion, i.e., move/clone the
> GOT fixup code so that it runs exactly once in each code path, but
> early enough so that the
On 4 September 2014 21:12, Ard Biesheuvel wrote:
> On 4 September 2014 14:54, Michael Brown wrote:
>> On 04/09/14 11:48, Maarten Lankhorst wrote:
>
> If not, Ard please go ahead with option #2 above. Overkill yes, but I've
> done the single __attribute__() hacks in other projects and
On 4 September 2014 14:54, Michael Brown wrote:
> On 04/09/14 11:48, Maarten Lankhorst wrote:
If not, Ard please go ahead with option #2 above. Overkill yes, but I've
done the single __attribute__() hacks in other projects and someone
(usually me) always eventually forgets to
On 04/09/14 11:48, Maarten Lankhorst wrote:
If not, Ard please go ahead with option #2 above. Overkill yes, but I've
done the single __attribute__() hacks in other projects and someone
(usually me) always eventually forgets to tag some instance.
It appears we just got lucky on arm64, since we
Op 04-09-14 om 13:19 schreef Ard Biesheuvel:
>
>> On 4 sep. 2014, at 12:48, Maarten Lankhorst
>> wrote:
>>
>> Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
>>> On 3 September 2014 19:59, Matt Fleming wrote:
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
> Will do, thanks.
>
> On 4 sep. 2014, at 12:48, Maarten Lankhorst
> wrote:
>
> Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
>> On 3 September 2014 19:59, Matt Fleming wrote:
>>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
Will do, thanks.
@Matt: so there is two ways to fix this, the
Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
> On 3 September 2014 19:59, Matt Fleming wrote:
>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>>> Will do, thanks.
>>>
>>> @Matt: so there is two ways to fix this, the patch above addressing
>>> this single instance, and alternatively,
Op 04-09-14 om 09:40 schreef Matt Fleming:
> On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
>> So how about we:
>> - add ASSERT(_got == _egot, "GOT entries not supported in
>> boot/compressed") to the linker script
>> - #define __nogotentry __attribute__((visibility(hidden))) somewhere
>> in
On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
>
> So how about we:
> - add ASSERT(_got == _egot, "GOT entries not supported in
> boot/compressed") to the linker script
> - #define __nogotentry __attribute__((visibility(hidden))) somewhere
> in compiler.h or wherever else it belongs
> - add
On Wed, 03 Sep, at 02:47:32PM, H. Peter Anvin wrote:
>
> I think we really have two options: either fix up the GOT (which may be
> a null operation, if the GOT is empty) or we add a compile-time check
> that the GOT is empty, lest we will keep having these problems.
>
> Since the GOT fixup loop
On 3 September 2014 23:47, H. Peter Anvin wrote:
>>
>> Any reason we can't reuse the existing GOT fixup code in the early x86
>> boot code? We're not executing it before the EFI boot stub atm, which is
>> the reason Maarten is hitting these difficulties.
>>
>> Maarten, does the following help?
>>
On 4 September 2014 14:54, Michael Brown mbr...@fensystems.co.uk wrote:
On 04/09/14 11:48, Maarten Lankhorst wrote:
If not, Ard please go ahead with option #2 above. Overkill yes, but I've
done the single __attribute__() hacks in other projects and someone
(usually me) always eventually
On 4 September 2014 21:12, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 4 September 2014 14:54, Michael Brown mbr...@fensystems.co.uk wrote:
On 04/09/14 11:48, Maarten Lankhorst wrote:
If not, Ard please go ahead with option #2 above. Overkill yes, but I've
done the single
On Thu, 04 Sep, at 11:25:48PM, Ard Biesheuvel wrote:
As it turns out, this breaks 32-bit, and the linker script is shared.
So I suggest that we go with Matt's suggestion, i.e., move/clone the
GOT fixup code so that it runs exactly once in each code path, but
early enough so that the
On 3 September 2014 23:47, H. Peter Anvin h...@zytor.com wrote:
Any reason we can't reuse the existing GOT fixup code in the early x86
boot code? We're not executing it before the EFI boot stub atm, which is
the reason Maarten is hitting these difficulties.
Maarten, does the following help?
On Wed, 03 Sep, at 02:47:32PM, H. Peter Anvin wrote:
I think we really have two options: either fix up the GOT (which may be
a null operation, if the GOT is empty) or we add a compile-time check
that the GOT is empty, lest we will keep having these problems.
Since the GOT fixup loop is
On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
So how about we:
- add ASSERT(_got == _egot, GOT entries not supported in
boot/compressed) to the linker script
- #define __nogotentry __attribute__((visibility(hidden))) somewhere
in compiler.h or wherever else it belongs
- add the
Op 04-09-14 om 09:40 schreef Matt Fleming:
On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
So how about we:
- add ASSERT(_got == _egot, GOT entries not supported in
boot/compressed) to the linker script
- #define __nogotentry __attribute__((visibility(hidden))) somewhere
in compiler.h
Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote:
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
Will do, thanks.
@Matt: so there is two ways to fix this, the patch above addressing
this single instance, and
On 4 sep. 2014, at 12:48, Maarten Lankhorst maarten.lankho...@canonical.com
wrote:
Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote:
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
Will do, thanks.
@Matt: so there
Op 04-09-14 om 13:19 schreef Ard Biesheuvel:
On 4 sep. 2014, at 12:48, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote:
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel
On 04/09/14 11:48, Maarten Lankhorst wrote:
If not, Ard please go ahead with option #2 above. Overkill yes, but I've
done the single __attribute__() hacks in other projects and someone
(usually me) always eventually forgets to tag some instance.
It appears we just got lucky on arm64, since we
>
> Any reason we can't reuse the existing GOT fixup code in the early x86
> boot code? We're not executing it before the EFI boot stub atm, which is
> the reason Maarten is hitting these difficulties.
>
> Maarten, does the following help?
>
> If not, Ard please go ahead with option #2 above.
On 09/03/2014 12:57 PM, Ard Biesheuvel wrote:
>
> I guess that is likely to work, I just wasn't aware it existed :-)
> I think adding another visibility(hidden) attribute or 2 would
> complete eliminate the need for GOT fixups, but I guess that is more
> sensitive to compiler versions being
On 3 September 2014 19:59, Matt Fleming wrote:
> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>>
>> Will do, thanks.
>>
>> @Matt: so there is two ways to fix this, the patch above addressing
>> this single instance, and alternatively, adding a #pragma GCC
>> visiblilty push(hidden) to all
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>
> Will do, thanks.
>
> @Matt: so there is two ways to fix this, the patch above addressing
> this single instance, and alternatively, adding a #pragma GCC
> visiblilty push(hidden) to all .c files under libstub/, *before* the
> #includes.
On 3 September 2014 17:30, Maarten Lankhorst
wrote:
> Hey,
>
> Op 03-09-14 om 14:18 schreef Ard Biesheuvel:
>> Could you please try adding the visibility attribute lik this instead?
>>
>> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
>> index 044a2fd3c5fe..8725d85f1903
Hey,
Op 03-09-14 om 14:18 schreef Ard Biesheuvel:
> Could you please try adding the visibility attribute lik this instead?
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 044a2fd3c5fe..8725d85f1903 100644
> --- a/arch/x86/include/asm/efi.h
> +++
On 3 September 2014 10:27, Maarten Lankhorst
wrote:
> Op 03-09-14 om 08:06 schreef Ard Biesheuvel:
>> On 2 September 2014 21:29, Matt Fleming wrote:
>>> On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Op 03-09-14 om 08:06 schreef Ard Biesheuvel:
> On 2 September 2014 21:29, Matt Fleming wrote:
>> On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> My macbook pro 8.2 fails to do a efi stub boot with these patches.
>>>
>>> Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared
On 2 September 2014 21:29, Matt Fleming wrote:
> On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> My macbook pro 8.2 fails to do a efi stub boot with these patches.
>>
>> Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to
>> "
>> causes the first break, but
On 2 September 2014 21:29, Matt Fleming m...@console-pimps.org wrote:
On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 efi/x86: efistub: Move shared dependencies to
asm/efi.h
causes the
Op 03-09-14 om 08:06 schreef Ard Biesheuvel:
On 2 September 2014 21:29, Matt Fleming m...@console-pimps.org wrote:
On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 efi/x86: efistub: Move
On 3 September 2014 10:27, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 03-09-14 om 08:06 schreef Ard Biesheuvel:
On 2 September 2014 21:29, Matt Fleming m...@console-pimps.org wrote:
On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
Hey,
My macbook pro 8.2 fails to do a
Hey,
Op 03-09-14 om 14:18 schreef Ard Biesheuvel:
Could you please try adding the visibility attribute lik this instead?
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 044a2fd3c5fe..8725d85f1903 100644
--- a/arch/x86/include/asm/efi.h
+++
On 3 September 2014 17:30, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
Op 03-09-14 om 14:18 schreef Ard Biesheuvel:
Could you please try adding the visibility attribute lik this instead?
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
Will do, thanks.
@Matt: so there is two ways to fix this, the patch above addressing
this single instance, and alternatively, adding a #pragma GCC
visiblilty push(hidden) to all .c files under libstub/, *before* the
#includes. The
On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote:
On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
Will do, thanks.
@Matt: so there is two ways to fix this, the patch above addressing
this single instance, and alternatively, adding a #pragma GCC
visiblilty
On 09/03/2014 12:57 PM, Ard Biesheuvel wrote:
I guess that is likely to work, I just wasn't aware it existed :-)
I think adding another visibility(hidden) attribute or 2 would
complete eliminate the need for GOT fixups, but I guess that is more
sensitive to compiler versions being recent
Any reason we can't reuse the existing GOT fixup code in the early x86
boot code? We're not executing it before the EFI boot stub atm, which is
the reason Maarten is hitting these difficulties.
Maarten, does the following help?
If not, Ard please go ahead with option #2 above. Overkill
On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
> Hey,
>
> My macbook pro 8.2 fails to do a efi stub boot with these patches.
>
> Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to
> "
> causes the first break, but this can be averted by changing
>
> struct efi_config
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to
"
causes the first break, but this can be averted by changing
struct efi_config *efi_early;
to
struct efi_config *efi_early
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 efi/x86: efistub: Move shared dependencies to
asm/efi.h
causes the first break, but this can be averted by changing
struct efi_config *efi_early;
to
struct efi_config *efi_early
On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote:
Hey,
My macbook pro 8.2 fails to do a efi stub boot with these patches.
Commit f23cf8bd5c1f49 efi/x86: efistub: Move shared dependencies to
asm/efi.h
causes the first break, but this can be averted by changing
struct efi_config
54 matches
Mail list logo
