All of lore.kernel.org
 help / color / mirror / Atom feed
* BGRT doesn't work for me on efi-next
       [not found]                 ` <5667E7B5.3080705-A/3C56C7qwM@public.gmane.org>
@ 2015-12-17 16:30                   ` Môshe van der Sterre
       [not found]                     ` <5672E335.8000004-A/3C56C7qwM@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Môshe van der Sterre @ 2015-12-17 16:30 UTC (permalink / raw)
  To: Sai Praneeth
  Cc: Matt Fleming, Josh Triplett, Matthew Garrett,
	linux-efi-u79uwXL29TY76Z2rM5mHXA

Hello Sai and others,

The change to use early_mem*() instead of early_io*() in 50a0cb56 does 
not work on my machine. Last week I discussed some BGRT changes and I 
created a patch for that, but can't test it on efi-next because of this.

I get this (when booting 50a0cb56, without any of my changes):
[    0.026936] ------------[ cut here ]------------
[    0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137 
__early_ioremap+0x102/0x1bb()
[    0.026941] Modules linked in:
[    0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
[    0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05 
07/14/2015
[    0.026946]  0000000000000000 900f03d5a116524d ffffffff81c03e60 
ffffffff813a3fff
[    0.026948]  0000000000000000 ffffffff81c03e98 ffffffff810a0852 
00000000d7b76000
[    0.026949]  0000000000000000 0000000000000001 0000000000000001 
000000000000017c
[    0.026951] Call Trace:
[    0.026955]  [<ffffffff813a3fff>] dump_stack+0x44/0x55
[    0.026958]  [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0
[    0.026959]  [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20
[    0.026961]  [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb
[    0.026962]  [<ffffffff81d8c602>] early_memremap+0x13/0x15
[    0.026964]  [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad
[    0.026966]  [<ffffffff81d778ec>] efi_late_init+0x9/0xb
[    0.026968]  [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f
[    0.026970]  [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120
[    0.026972]  [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c
[    0.026974]  [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d
[    0.026977] ---[ end trace f9b3812eb8e24c58 ]---
[    0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory

This is the second early_memremap call in efi_bgrt_init triggering 
WARN_ON(nrpages > NR_FIX_BTMAPS). Can you comment on this?

Greetings,
Môshe van der Sterre

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BGRT doesn't work for me on efi-next
       [not found]                     ` <5672E335.8000004-A/3C56C7qwM@public.gmane.org>
@ 2015-12-18 12:56                       ` Matt Fleming
       [not found]                         ` <20151218125628.GA2638-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Matt Fleming @ 2015-12-18 12:56 UTC (permalink / raw)
  To: Môshe van der Sterre
  Cc: Sai Praneeth, Josh Triplett, Matthew Garrett,
	linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Juergen Gross

(Pulling in Ingo and Juergen because of commit 954e12f7a800)

On Thu, 17 Dec, at 05:30:45PM, Môshe van der Sterre wrote:
> Hello Sai and others,
> 
> The change to use early_mem*() instead of early_io*() in 50a0cb56 does not
> work on my machine. Last week I discussed some BGRT changes and I created a
> patch for that, but can't test it on efi-next because of this.
> 
> I get this (when booting 50a0cb56, without any of my changes):
> [    0.026936] ------------[ cut here ]------------
> [    0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137
> __early_ioremap+0x102/0x1bb()
> [    0.026941] Modules linked in:
> [    0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
> [    0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05
> 07/14/2015
> [    0.026946]  0000000000000000 900f03d5a116524d ffffffff81c03e60
> ffffffff813a3fff
> [    0.026948]  0000000000000000 ffffffff81c03e98 ffffffff810a0852
> 00000000d7b76000
> [    0.026949]  0000000000000000 0000000000000001 0000000000000001
> 000000000000017c
> [    0.026951] Call Trace:
> [    0.026955]  [<ffffffff813a3fff>] dump_stack+0x44/0x55
> [    0.026958]  [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0
> [    0.026959]  [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20
> [    0.026961]  [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb
> [    0.026962]  [<ffffffff81d8c602>] early_memremap+0x13/0x15
> [    0.026964]  [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad
> [    0.026966]  [<ffffffff81d778ec>] efi_late_init+0x9/0xb
> [    0.026968]  [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f
> [    0.026970]  [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120
> [    0.026972]  [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c
> [    0.026974]  [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d
> [    0.026977] ---[ end trace f9b3812eb8e24c58 ]---
> [    0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory
> 
> This is the second early_memremap call in efi_bgrt_init triggering
> WARN_ON(nrpages > NR_FIX_BTMAPS). Can you comment on this?

Hmm... yeah NR_FIX_BTMAPS == 64, so early_memremap() is limited to
mapping ~200KB at once. That's not very big, your BGRT data is likely
much larger than that.

Obviously we can't use efi_lookup_mapped_addr() any more, so it makes
sense to come up with a much robust way to memremap the BGRT image.

The immediate solution that comes to mind is using memremap() instead
of the early_* version, since the late version won't use the FIXMAP
area and will allow us to map a much larger region into the kernel
virtual address space.

Digging through the history it appears I was the one who made the
switch from ioremap() to early_memremap() in commit 081cd62a010f
("x86/efi: Allow mapping BGRT on x86-32"), which I suspect was because
a generic memremap() implementation didn't exist at the time. Dan
Williams introduced one in Aug 2015 with commit 92281dee825f ("arch:
introduce memremap()").

Somewhat surprisingly, Juergen switched the BGRT driver from
early_memremap() to early_ioremap() in commit 954e12f7a800 ("x86/mm,
efi: Use early_ioremap() in arch/x86/platform/efi/efi-bgrt.c")
although I can't figure out why because this isn't I/O memory. And now
we're attempting to switch it back.

Juergen, could you provide a rationale for commit 954e12f7a800? All
the commit message says is that it's "an I/O-area", but that isn't
true.

In the meantime Môshe, could you try this patch ontop of the EFI
'next' branch? (Note it may not work/compile, but you get the gist)

---

diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index bf51f4c02562..b0970661870a 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -72,14 +72,14 @@ void __init efi_bgrt_init(void)
 		return;
 	}
 
-	image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header));
+	image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB);
 	if (!image) {
 		pr_err("Ignoring BGRT: failed to map image header memory\n");
 		return;
 	}
 
 	memcpy(&bmp_header, image, sizeof(bmp_header));
-	early_memunmap(image, sizeof(bmp_header));
+	memunmap(image);
 	bgrt_image_size = bmp_header.size;
 
 	bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
@@ -89,7 +89,7 @@ void __init efi_bgrt_init(void)
 		return;
 	}
 
-	image = early_memremap(bgrt_tab->image_address, bmp_header.size);
+	image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
 	if (!image) {
 		pr_err("Ignoring BGRT: failed to map image memory\n");
 		kfree(bgrt_image);
@@ -98,5 +98,5 @@ void __init efi_bgrt_init(void)
 	}
 
 	memcpy(bgrt_image, image, bgrt_image_size);
-	early_memunmap(image, bmp_header.size);
+	memunmap(image);
 }

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BGRT doesn't work for me on efi-next
       [not found]                         ` <20151218125628.GA2638-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
@ 2015-12-18 13:22                           ` Juergen Gross
  2015-12-20 19:24                           ` Môshe van der Sterre
  1 sibling, 0 replies; 4+ messages in thread
From: Juergen Gross @ 2015-12-18 13:22 UTC (permalink / raw)
  To: Matt Fleming, Môshe van der Sterre
  Cc: Sai Praneeth, Josh Triplett, Matthew Garrett,
	linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar

On 18/12/15 13:56, Matt Fleming wrote:
> (Pulling in Ingo and Juergen because of commit 954e12f7a800)
> 
> On Thu, 17 Dec, at 05:30:45PM, Môshe van der Sterre wrote:
>> Hello Sai and others,
>>
>> The change to use early_mem*() instead of early_io*() in 50a0cb56 does not
>> work on my machine. Last week I discussed some BGRT changes and I created a
>> patch for that, but can't test it on efi-next because of this.
>>
>> I get this (when booting 50a0cb56, without any of my changes):
>> [    0.026936] ------------[ cut here ]------------
>> [    0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137
>> __early_ioremap+0x102/0x1bb()
>> [    0.026941] Modules linked in:
>> [    0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
>> [    0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05
>> 07/14/2015
>> [    0.026946]  0000000000000000 900f03d5a116524d ffffffff81c03e60
>> ffffffff813a3fff
>> [    0.026948]  0000000000000000 ffffffff81c03e98 ffffffff810a0852
>> 00000000d7b76000
>> [    0.026949]  0000000000000000 0000000000000001 0000000000000001
>> 000000000000017c
>> [    0.026951] Call Trace:
>> [    0.026955]  [<ffffffff813a3fff>] dump_stack+0x44/0x55
>> [    0.026958]  [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0
>> [    0.026959]  [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20
>> [    0.026961]  [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb
>> [    0.026962]  [<ffffffff81d8c602>] early_memremap+0x13/0x15
>> [    0.026964]  [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad
>> [    0.026966]  [<ffffffff81d778ec>] efi_late_init+0x9/0xb
>> [    0.026968]  [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f
>> [    0.026970]  [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120
>> [    0.026972]  [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c
>> [    0.026974]  [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d
>> [    0.026977] ---[ end trace f9b3812eb8e24c58 ]---
>> [    0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory
>>
>> This is the second early_memremap call in efi_bgrt_init triggering
>> WARN_ON(nrpages > NR_FIX_BTMAPS). Can you comment on this?
> 
> Hmm... yeah NR_FIX_BTMAPS == 64, so early_memremap() is limited to
> mapping ~200KB at once. That's not very big, your BGRT data is likely
> much larger than that.
> 
> Obviously we can't use efi_lookup_mapped_addr() any more, so it makes
> sense to come up with a much robust way to memremap the BGRT image.
> 
> The immediate solution that comes to mind is using memremap() instead
> of the early_* version, since the late version won't use the FIXMAP
> area and will allow us to map a much larger region into the kernel
> virtual address space.
> 
> Digging through the history it appears I was the one who made the
> switch from ioremap() to early_memremap() in commit 081cd62a010f
> ("x86/efi: Allow mapping BGRT on x86-32"), which I suspect was because
> a generic memremap() implementation didn't exist at the time. Dan
> Williams introduced one in Aug 2015 with commit 92281dee825f ("arch:
> introduce memremap()").
> 
> Somewhat surprisingly, Juergen switched the BGRT driver from
> early_memremap() to early_ioremap() in commit 954e12f7a800 ("x86/mm,
> efi: Use early_ioremap() in arch/x86/platform/efi/efi-bgrt.c")
> although I can't figure out why because this isn't I/O memory. And now
> we're attempting to switch it back.
> 
> Juergen, could you provide a rationale for commit 954e12f7a800? All
> the commit message says is that it's "an I/O-area", but that isn't
> true.

I was hunting down some inconsistencies regarding early_[mem|io]remap.
I patched places where the remap and unmap calls where of different
type (e.g. a pair of early_memremap() / early_iounmap()).

Maybe I was fooled here by all other names hinting towards io
instead of mem (ioremapped, memcpy_fromio()).

Juergen

> 
> In the meantime Môshe, could you try this patch ontop of the EFI
> 'next' branch? (Note it may not work/compile, but you get the gist)
> 
> ---
> 
> diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> index bf51f4c02562..b0970661870a 100644
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -72,14 +72,14 @@ void __init efi_bgrt_init(void)
>  		return;
>  	}
>  
> -	image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header));
> +	image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB);
>  	if (!image) {
>  		pr_err("Ignoring BGRT: failed to map image header memory\n");
>  		return;
>  	}
>  
>  	memcpy(&bmp_header, image, sizeof(bmp_header));
> -	early_memunmap(image, sizeof(bmp_header));
> +	memunmap(image);
>  	bgrt_image_size = bmp_header.size;
>  
>  	bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
> @@ -89,7 +89,7 @@ void __init efi_bgrt_init(void)
>  		return;
>  	}
>  
> -	image = early_memremap(bgrt_tab->image_address, bmp_header.size);
> +	image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
>  	if (!image) {
>  		pr_err("Ignoring BGRT: failed to map image memory\n");
>  		kfree(bgrt_image);
> @@ -98,5 +98,5 @@ void __init efi_bgrt_init(void)
>  	}
>  
>  	memcpy(bgrt_image, image, bgrt_image_size);
> -	early_memunmap(image, bmp_header.size);
> +	memunmap(image);
>  }
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BGRT doesn't work for me on efi-next
       [not found]                         ` <20151218125628.GA2638-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
  2015-12-18 13:22                           ` Juergen Gross
@ 2015-12-20 19:24                           ` Môshe van der Sterre
  1 sibling, 0 replies; 4+ messages in thread
From: Môshe van der Sterre @ 2015-12-20 19:24 UTC (permalink / raw)
  To: Matt Fleming
  Cc: Sai Praneeth, Josh Triplett, Matthew Garrett,
	linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Juergen Gross

On 12/18/2015 01:56 PM, Matt Fleming wrote:
> (Pulling in Ingo and Juergen because of commit 954e12f7a800)
>
> On Thu, 17 Dec, at 05:30:45PM, Môshe van der Sterre wrote:
>> Hello Sai and others,
>>
>> The change to use early_mem*() instead of early_io*() in 50a0cb56 does not
>> work on my machine. Last week I discussed some BGRT changes and I created a
>> patch for that, but can't test it on efi-next because of this.
>>
>> I get this (when booting 50a0cb56, without any of my changes):
>> [    0.026936] ------------[ cut here ]------------
>> [    0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137
>> __early_ioremap+0x102/0x1bb()
>> [    0.026941] Modules linked in:
>> [    0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
>> [    0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05
>> 07/14/2015
>> [    0.026946]  0000000000000000 900f03d5a116524d ffffffff81c03e60
>> ffffffff813a3fff
>> [    0.026948]  0000000000000000 ffffffff81c03e98 ffffffff810a0852
>> 00000000d7b76000
>> [    0.026949]  0000000000000000 0000000000000001 0000000000000001
>> 000000000000017c
>> [    0.026951] Call Trace:
>> [    0.026955]  [<ffffffff813a3fff>] dump_stack+0x44/0x55
>> [    0.026958]  [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0
>> [    0.026959]  [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20
>> [    0.026961]  [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb
>> [    0.026962]  [<ffffffff81d8c602>] early_memremap+0x13/0x15
>> [    0.026964]  [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad
>> [    0.026966]  [<ffffffff81d778ec>] efi_late_init+0x9/0xb
>> [    0.026968]  [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f
>> [    0.026970]  [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120
>> [    0.026972]  [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c
>> [    0.026974]  [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d
>> [    0.026977] ---[ end trace f9b3812eb8e24c58 ]---
>> [    0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory
>>
>> This is the second early_memremap call in efi_bgrt_init triggering
>> WARN_ON(nrpages > NR_FIX_BTMAPS). Can you comment on this?
> Hmm... yeah NR_FIX_BTMAPS == 64, so early_memremap() is limited to
> mapping ~200KB at once. That's not very big, your BGRT data is likely
> much larger than that.
>
> Obviously we can't use efi_lookup_mapped_addr() any more, so it makes
> sense to come up with a much robust way to memremap the BGRT image.
>
> The immediate solution that comes to mind is using memremap() instead
> of the early_* version, since the late version won't use the FIXMAP
> area and will allow us to map a much larger region into the kernel
> virtual address space.
>
> Digging through the history it appears I was the one who made the
> switch from ioremap() to early_memremap() in commit 081cd62a010f
> ("x86/efi: Allow mapping BGRT on x86-32"), which I suspect was because
> a generic memremap() implementation didn't exist at the time. Dan
> Williams introduced one in Aug 2015 with commit 92281dee825f ("arch:
> introduce memremap()").
>
> Somewhat surprisingly, Juergen switched the BGRT driver from
> early_memremap() to early_ioremap() in commit 954e12f7a800 ("x86/mm,
> efi: Use early_ioremap() in arch/x86/platform/efi/efi-bgrt.c")
> although I can't figure out why because this isn't I/O memory. And now
> we're attempting to switch it back.
>
> Juergen, could you provide a rationale for commit 954e12f7a800? All
> the commit message says is that it's "an I/O-area", but that isn't
> true.
>
> In the meantime Môshe, could you try this patch ontop of the EFI
> 'next' branch? (Note it may not work/compile, but you get the gist)

The patch works on my laptop

> ---
>
> diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> index bf51f4c02562..b0970661870a 100644
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -72,14 +72,14 @@ void __init efi_bgrt_init(void)
>   		return;
>   	}
>   
> -	image = early_memremap(bgrt_tab->image_address, sizeof(bmp_header));
> +	image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB);
>   	if (!image) {
>   		pr_err("Ignoring BGRT: failed to map image header memory\n");
>   		return;
>   	}
>   
>   	memcpy(&bmp_header, image, sizeof(bmp_header));
> -	early_memunmap(image, sizeof(bmp_header));
> +	memunmap(image);
>   	bgrt_image_size = bmp_header.size;
>   
>   	bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
> @@ -89,7 +89,7 @@ void __init efi_bgrt_init(void)
>   		return;
>   	}
>   
> -	image = early_memremap(bgrt_tab->image_address, bmp_header.size);
> +	image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
>   	if (!image) {
>   		pr_err("Ignoring BGRT: failed to map image memory\n");
>   		kfree(bgrt_image);
> @@ -98,5 +98,5 @@ void __init efi_bgrt_init(void)
>   	}
>   
>   	memcpy(bgrt_image, image, bgrt_image_size);
> -	early_memunmap(image, bmp_header.size);
> +	memunmap(image);
>   }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-12-20 19:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5665E8E0.4050203@moshe.nl>
     [not found] ` <20151207204451.GC16222@cloud>
     [not found]   ` <56660979.5080204@moshe.nl>
     [not found]     ` <20151207235520.GA17617@cloud>
     [not found]       ` <566623B3.8010104@moshe.nl>
     [not found]         ` <20151208023443.GA10087@x>
     [not found]           ` <56664F79.6060100@moshe.nl>
     [not found]             ` <20151208140529.GH2518@codeblueprint.co.uk>
     [not found]               ` <5667E7B5.3080705@moshe.nl>
     [not found]                 ` <5667E7B5.3080705-A/3C56C7qwM@public.gmane.org>
2015-12-17 16:30                   ` BGRT doesn't work for me on efi-next Môshe van der Sterre
     [not found]                     ` <5672E335.8000004-A/3C56C7qwM@public.gmane.org>
2015-12-18 12:56                       ` Matt Fleming
     [not found]                         ` <20151218125628.GA2638-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-12-18 13:22                           ` Juergen Gross
2015-12-20 19:24                           ` Môshe van der Sterre

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.