lkml.org 
[lkml]   [2012]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting
    >>> 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-08-07 10:02    [W:0.029 / U:30.324 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site