[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1901112054220.1661@nanos.tec.linutronix.de>
Date: Fri, 11 Jan 2019 21:17:12 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Daniel Drake <drake@...lessm.com>
cc: suresh.b.siddha@...el.com,
Linux Upstreaming Team <linux@...lessm.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: APIC timer checked before it is set up, boot fails on Connex
L1430
On Mon, 7 Jan 2019, Daniel Drake wrote:
> I asked the motherboard vendor if they have any idea why the 8254 is
> not ticking and they sent me a new BIOS where it is now working. So we
> can probably consider this a non issue, although there are a few other
> curious points to mention:
>
> 1. Other platforms with the same Intel N3350 SoC use the HPET timer
> instead of PIC during early boot; on this platform there is no HPET
> ACPI table though, so it uses PIT instead.
Right. PIT is the ultimate fallback.
> 2. It does seem a little redundant that the Linux APIC code goes to
> these lengths to check that the legacy 8254 timer interrupt is working
> before it then gets disabled a bit later during boot (when
> setup_APIC_timer happens, the clocksource layer disables the previous
> timer source, in this case the PIT or HPET). Although I can see this
> is not a trivial patch to write.
Well, it'd be trivial if we could rely on the APIC timer being functional
on all CPUs and if we could figure out the APIC timer frequency without
calibrating it against the PIT/HPET on older CPUs. Plus a gazillion of
other issues (e.g. APIC stops in C states ....)
> 3. Windows 10 boots fine with no HPET & no 8254 timer ticks, so if we
> find more platforms that appear in this state, we may want to look for
> how to work around this strange situation on the Linux side.
Under certain conditions we actually might avoid touching PIT/HPET and
solely rely on the CPUID/MSR calibration values. Needs quite some thought
though.
Thanks,
tglx
Powered by blists - more mailing lists