Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting

["Jan Beulich" <JBeulich@suse.com>]

>>> On 07.08.12 at 05:06, JérômeCarretero <cJ-ko@zougloub.eu> wrote:
> On Mon, 6 Aug 2012 22:32:08 -0400
> Jérôme Carretero <cJ-ko@zougloub.eu> wrote:
> 
>> For troubleshooting purposes I edited over your patch.
>> So far:
>> [...]
>> Maybe I can get more...
> 
> With the following:
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 2dc29f5..46729f3 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -97,8 +97,9 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, 
> efi_time_cap_t *tc)
>         unsigned long flags;
>         efi_status_t status;
>  
> +       printk("%s: get_time=0x%p\n", __func__, 
> efi.systab->runtime->get_time);
>         spin_lock_irqsave(&rtc_lock, flags);
> -       status = efi_call_virt2(get_time, tm, tc);
> +       status = EFI_SUCCESS + 1;// efi_call_virt2(get_time, tm, tc);
>         spin_unlock_irqrestore(&rtc_lock, flags);
>         return status;
>  }
> @@ -270,8 +271,10 @@ static unsigned long efi_get_time(void)
>         efi_time_cap_t cap;
>  
>         status = efi.get_time(&eft, &cap);
> -       if (status != EFI_SUCCESS)
> -               pr_err("Oops: efitime: can't read time!\n");
> +       if (status != EFI_SUCCESS) {
> +               /* fall back to RTC time */
> +               return mach_get_cmos_time();
> +       }
>  
>         return mktime(eft.year, eft.month, eft.day, eft.hour,
>                       eft.minute, eft.second);
> 
> The system boots, at that point...

That's not surprising. The question really is what goes wrong
when the call is being made - page fault, some other fault, or
silent hang. A page fault would point to an incorrect memory
map as the prime candidate for causing the problem. My
primary suspect would be #NM, i.e. the implementation using
floating point (SSE to be precise) instructions when they're
unavailable.

> I would say my BIOS is broken,
> but it can be expected that others can have the same issue.

Likely. The question is whether we could make Linux be spec
compliant on sane systems _and_ tolerate broken ones like
this. But whether e.g. adding a command line option (or DMI-
based quirk) is appropriate depends on whether this really is
a firmware issue or a flaw in the patch.

Jan