On Sun, 09 Mar, at 04:31:41PM, Matthew Garrett wrote:
> On Sun, Mar 09, 2014 at 04:20:20PM +0000, Matt Fleming wrote:
>
> > We have tried to use the time functions before, with little success
> > because of various bugs in the runtime implementations, e.g. see commit
> > bacef661acdb ("x86-64/efi: Use EFI to deal with platform wall clock")
> > and commit bd52276fa1d4 ("x86-64/efi: Use EFI to deal with platform wall
> > clock (again)").
>
> I'd naively expected that these would be more reliable after the 1:1
> mapping patches, so it might actually be time to give them another go.
Is there any value in that? Do machines exist where we absolutely must
have access to the EFI time services? Either because there's no other
method or no other working one?
I can check again, but I'm pretty sure this ASUS machine under my desk
always returns a vendor-specific error code when invoked, even with
Borislav's 1:1 patches. Enabling EFI services just because they exist
hasn't worked out well for us in the past.
So enabling them is fine, but we certainly need some kind of priority
mechanism so they're used as a last resort and some ironclad use case of
why we absolutely must have this.
And of course, the GPF_KERNEL alloc under spinlock bug that started this
thread needs to be fixed.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
