lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ