On 06/02/17 at 10:51am, Dave Young wrote:
> On 06/01/17 at 09:13pm, Maniaxx wrote:
> > On 01.06.2017 at 03:57 wrote Dave Young:
> > > This means the efi_bgrt_init failed out originally before the early init BGRT
> > > patch. Checking the code the only difference is current code we have no
> > > below code:
> > >
> > > status = acpi_get_table("BGRT", 0,
> > > (struct acpi_table_header **)&bgrt_tab);
> > > if (ACPI_FAILURE(status))
> > > return;
> > >
> > > So probably acpi_get_table has some more sanity checking and it failed
> > > early. Can you add a printk before above return to confirm it? Just test
> > > the old kernel without early init BGRT patch.
> >
> > Doesn't fail early. I can see the printk.
>
> Since you do not see /sys/firmware/acpi/bgrt, that means there must be
> somewhere failed early so bgrt image sysfs files are not created.
> for old kernel arch/x86/platform/efi/efi-bgrt.c copy the bgrt image
> then drivers/acpi/bgrt.c will populate the image in sysfs.
>
> Can you do more debugging ie. adding more printk see why bgrt image
> sysfs dir is not created?
>
> If we get the reason then we can start to see what we missed in new
> code.
Please ignore the request, I observed in your old kernel boot log there
is a ioremap error message about invalid physical address, so that is
clear since ioremap failed then efi_bgrt_init bails out.
In new code we use early_memremap, it seems lacks of checking invalid
physical address, The firmware provides garbage in efi bgrt image
addresses, I will work on a fix for this.
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
