've now got 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 p
) going to make it into 3.10?
---
From 118428bf3b207d9b390a27f32dfef6dc2979078d Mon Sep 17 00:00:00 2001
From: Matthew Garrett matthew.garr...@nebula.com
Date: Sat, 1 Jun 2013 16:06:20 -0400
Subject: [PATCH] Modify UEFI anti-bricking code
This patch reworks the UEFI anti-bricking code
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
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
'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, includin
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 some
於 四，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
>
於 四，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
no risk
Garrett matthew.garr...@nebula.com
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
118428bf3b207d9b390a27f32dfef6dc2979078d Mon Sep 17 00:00:00 2001
From: Matthew Garrett matthew.garr...@nebula.com
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
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 line
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. It
0: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 31ff2f20. It turns o
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
t; 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] Modify UEFI anti
於 三，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, _DUMMY_GUID, 0, 0, NULL);
>
> Hm. Actually, is that going to work? From the spec:
>
The patch I tested on OVMF,
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
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, _DUMMY_GUID, 0, 0, NULL);
>
> Hm. Actually, is that going to work? From the spec:
>
> If a preexisting
On Wed, 2013-06-05 at 16:59 +0100, Matt Fleming wrote:
> + /* clean DUMMY object */
> + efi.set_variable(efi_dummy_name, _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 not
ed 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 31ff2f20. It t
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
On 4 June 2013 04:35, joeyli j...@suse.com 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 sure
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
380dcc12ba82f4e10feb6a72207b2e4771d16d8d Mon Sep 17 00:00:00 2001
From: Matthew Garrett matthew.garr...@nebula.com
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
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
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 variable is
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 case.
於 三，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 OVMF, it can
, this is what I've got queued up.
---
From 380dcc12ba82f4e10feb6a72207b2e4771d16d8d Mon Sep 17 00:00:00 2001
From: Matthew Garrett matthew.garr...@nebula.com
Date: Sat, 1 Jun 2013 16:06:20 -0400
Subject: [PATCH] Modify UEFI anti-bricking code
This patch reworks the UEFI anti-bricking code
?
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 matthew.garr...@nebula.com
Date: Sat, 1 Jun 2013 16:06:20 -0400
Subject: [PATCH] Modify UEFI anti
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
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
於 一，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
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
於 六，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 =
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
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
於 一，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 case we
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
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
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
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
於 六，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 =
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
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 and
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
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
48 matches
Mail list logo
