ot queued up.
Is this (or similar) going to make it into 3.10?
>
> ---
>
> >From 118428bf3b207d9b390a27f32dfef6dc2979078d Mon Sep 17 00:00:00 2001
> From: Matthew Garrett
> Date: Sat, 1 Jun 2013 16:06:20 -0400
> Subject: [PATCH] Modify UEFI anti-bricking code
>
> This
On Thu, Jun 06, 2013 at 04:00:39PM +0100, Matt Fleming wrote:
> On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> > This looks like it will try to allocate more than the remaining size.
> > Is that intended?
>
> Yes, the intention is to trigger garbage collection.
OK, if that's what it takes.
On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> This looks like it will try to allocate more than the remaining size.
> Is that intended?
Yes, the intention is to trigger garbage collection.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the lin
've now got queued up.
>
> ---
>
> >From 118428bf3b207d9b390a27f32dfef6dc2979078d Mon Sep 17 00:00:00 2001
> From: Matthew Garrett
> Date: Sat, 1 Jun 2013 16:06:20 -0400
> Subject: [PATCH] Modify UEFI anti-bricking code
>
> This patch reworks the UEFI anti-bricking code, includi
0:00 2001
From: Matthew Garrett
Date: Sat, 1 Jun 2013 16:06:20 -0400
Subject: [PATCH] Modify UEFI anti-bricking code
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in
於 四，2013-06-06 於 05:42 +，Matthew Garrett 提到：
> On Thu, 2013-06-06 at 13:05 +0800, joeyli wrote:
>
> > + if (!(attributes & EFI_VARIABLE_NON_VOLATILE))
> > + return EFI_OUT_OF_RESOURCES;
>
> I'd move this up to the top of the function, and just return 0 - there's
>
On Thu, 2013-06-06 at 13:05 +0800, joeyli wrote:
> + if (!(attributes & EFI_VARIABLE_NON_VOLATILE))
> + return EFI_OUT_OF_RESOURCES;
I'd move this up to the top of the function, and just return 0 - there's
no risk of the firmware causing problems if it's a volatile
8d Mon Sep 17 00:00:00 2001
> > From: Matthew Garrett
> > Date: Sat, 1 Jun 2013 16:06:20 -0400
> > Subject: [PATCH] Modify UEFI anti-bricking code
> >
> > This patch reworks the UEFI anti-bricking code, including an effective
> > reversion of cc5a080c and 31ff2
> Do that and add Joey's signed-off-by?
>
> Right, this is what I've got queued up.
>
> ---
>
> >From 380dcc12ba82f4e10feb6a72207b2e4771d16d8d Mon Sep 17 00:00:00 2001
> From: Matthew Garrett
> Date: Sat, 1 Jun 2013 16:06:20 -0400
> Subject: [PATCH] M
於 三，2013-06-05 於 16:08 +，Matthew Garrett 提到：
> On Wed, 2013-06-05 at 16:59 +0100, Matt Fleming wrote:
>
> > + /* clean DUMMY object */
> > + efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID, 0, 0, NULL);
>
> Hm. Actually, is that going to work? From the spec:
>
The patch I tested on OVM
On 06/05/2013 08:59 AM, Matt Fleming wrote:
> + * There still isn't enough room, so return an error
> + */
> + if (remaining_size - size < 5120)
> + return EFI_OUT_OF_RESOURCES;
> + }
Please don't open-code the constant 5120 in this cas
On Wed, 05 Jun, at 04:08:39PM, Matthew Garrett wrote:
> On Wed, 2013-06-05 at 16:59 +0100, Matt Fleming wrote:
>
> > + /* clean DUMMY object */
> > + efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID, 0, 0, NULL);
>
> Hm. Actually, is that going to work? From the spec:
>
> If a preexisting va
On Wed, 2013-06-05 at 16:59 +0100, Matt Fleming wrote:
> + /* clean DUMMY object */
> + efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID, 0, 0, NULL);
Hm. Actually, is that going to work? From the spec:
If a preexisting variable is rewritten with different attributes,
SetVariable()shall
x27;ve got queued up.
---
>From 380dcc12ba82f4e10feb6a72207b2e4771d16d8d Mon Sep 17 00:00:00 2001
From: Matthew Garrett
Date: Sat, 1 Jun 2013 16:06:20 -0400
Subject: [PATCH] Modify UEFI anti-bricking code
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and
On Wed, 2013-06-05 at 15:49 +0100, Fleming, Matt wrote:
> Folks, what do you want me to do with this? Merge it with Matthew's patch?
Do that and add Joey's signed-off-by?
--
Matthew Garrett | mj...@srcf.ucam.org
On 4 June 2013 04:35, joeyli wrote:
> 於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
>> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
>>
>> > Oliver raised a question for if power fails between that succesful
>> > attempt and the deletion?
>>
>> It's a pretty tiny window, but sure. Making sur
On 06/02/2013 04:06 AM, Matthew Garrett wrote:
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in some firmware
implementations jumping to physical addresses even af
於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
>
> > Oliver raised a question for if power fails between that succesful
> > attempt and the deletion?
>
> It's a pretty tiny window, but sure. Making sure we delete it seems
> sensible. In that ca
On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
> Oliver raised a question for if power fails between that succesful
> attempt and the deletion?
It's a pretty tiny window, but sure. Making sure we delete it seems
sensible. In that case we should make the GUID a #define rather than
write it out t
於 六，2013-06-01 於 16:06 -0400，Matthew Garrett 提到：
> + unsigned long dummy_size = remaining_size + 1024;
> + void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
> + efi_char16_t efi_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
> + efi_guid_t guid = EFI_
On Mon, 2013-06-03 at 13:17 +0100, Matt Fleming wrote:
> Do we really want to drop this hunk? The point of this code was to
> inform firmware vendors that their implementation is returning funky
> results, and that they should look into why it's doing that.
We're not doing anything with that info
On 01/06/13 21:06, Matthew Garrett wrote:
> This patch reworks the UEFI anti-bricking code, including an effective
> reversion of cc5a080c and 31ff2f20. It turns out that calling
> QueryVariableInfo() from boot services results in some firmware
> implementations jumping to physical addresses even a
After quick testing it looks like this fixes the boot problem.
Boots with grub2 (EFI stubs), grub (no EFI stubs) and elilo.
Thanks!
On Sat, Jun 01, 2013 at 04:06:20PM -0400, Matthew Garrett wrote:
> This patch reworks the UEFI anti-bricking code, including an effective
> reversion of cc5a080c an
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in some firmware
implementations jumping to physical addresses even after entering virtual
mode, so until we have 1:1 m
24 matches
Mail list logo
