On Thu, 15 Jan, at 11:59:42AM, H. Peter Anvin wrote:
> On 01/15/2015 11:41 AM, Matt Fleming wrote:
> >>
> >>Tianocore makes assumptions about the kernel's GDT layout? Yuck.
> >
> >No, but 32-bit Tianocore does rely on the second GDT entry being a
> >32-bit CS.
> >
> >It has no knowledge of Linux's
On Mon, 12 Jan, at 08:28:20PM, Ard Biesheuvel wrote:
> This ensures all stub component are freed when the kernel proper is
> done booting, by prefixing the names of all ELF sections that have
> the SHF_ALLOC attribute with ".init". This approach ensures that even
> implicitly emitted allocated data
On Mon, 12 Jan, at 08:42:54AM, Peter Jones wrote:
> Add sysfs files for the EFI System Resource Table (ESRT) under
> /sys/firmware/efi/esrt and for each EFI System Resource Entry under
> entries/ as a subdir.
>
> The EFI System Resource Table (ESRT) provides a read-only catalog of
> system compone
On 01/15/2015 11:41 AM, Matt Fleming wrote:
Tianocore makes assumptions about the kernel's GDT layout? Yuck.
No, but 32-bit Tianocore does rely on the second GDT entry being a
32-bit CS.
It has no knowledge of Linux's GDT layout.
If it assumes that descriptor 16 is a 32-bit CS (and what a
On Wed, 14 Jan, at 10:27:47AM, Andy Lutomirski wrote:
>
> How are you manually triggering an MCE? I've been playing with some
> MCE stuff recently, but the only reasonably reliable way I know of to
> trigger an MCE is using WHEA, and I don't have a box with WHEA, and I
> assume your ASUS T100 doe
On Thu, 2015-01-15 at 12:01 +, Ard Biesheuvel wrote:
> When remapping the UEFI memory map using ioremap_cache(), we
> have to deal with potential failure. Note that, even if the
> common case is for ioremap_cache() to return the existing linear
> mapping of the memory map, we cannot rely on tha
On Thu, Jan 15, 2015 at 12:01:06PM +, Ard Biesheuvel wrote:
> When remapping the UEFI memory map using ioremap_cache(), we
> have to deal with potential failure. Note that, even if the
> common case is for ioremap_cache() to return the existing linear
> mapping of the memory map, we cannot rely
On 01/15/15 at 12:21pm, Dan Carpenter wrote:
> The "> 0" here should ">= 0" so we free map_entries[0].
>
> Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/firmware/efi/runtime-map.c
> b/drivers/firmware/efi/runtime-
On 01/15/15 at 01:28pm, Dan Carpenter wrote:
> On Thu, Jan 15, 2015 at 05:54:55PM +0800, Dave Young wrote:
> > > out_add_entry:
> > > - for (j = i - 1; j > 0; j--) {
> > > + for (j = i - 1; j >= 0; j--) {
> > > entry = *(map_entries + j);
> > > kobject_put(&entry->kobj);
> > >
When remapping the UEFI memory map using ioremap_cache(), we
have to deal with potential failure. Note that, even if the
common case is for ioremap_cache() to return the existing linear
mapping of the memory map, we cannot rely on that to be always the
case, e.g., in the presence of a mem= kernel p
On Thu, Jan 15, 2015 at 05:54:55PM +0800, Dave Young wrote:
> > out_add_entry:
> > - for (j = i - 1; j > 0; j--) {
> > + for (j = i - 1; j >= 0; j--) {
> > entry = *(map_entries + j);
> > kobject_put(&entry->kobj);
> > }
>
> see below code, as for an invalid entry
Hi, Dan
On 01/15/15 at 12:21pm, Dan Carpenter wrote:
> The "> 0" here should ">= 0" so we free map_entries[0].
>
> Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/firmware/efi/runtime-map.c
> b/drivers/firmware/efi
The "> 0" here should ">= 0" so we free map_entries[0].
Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs')
Signed-off-by: Dan Carpenter
diff --git a/drivers/firmware/efi/runtime-map.c
b/drivers/firmware/efi/runtime-map.c
index 018c29a..87b8e3b 100644
--- a/drivers/firmware/
13 matches
Mail list logo
