>>> On 07.08.12 at 05:06, JérômeCarretero <cj...@zougloub.eu> wrote:
> On Mon, 6 Aug 2012 22:32:08 -0400
> Jérôme Carretero <cj...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
