Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1013523imu; Fri, 11 Jan 2019 13:17:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN6F6MmsNtxrtQydC768YJXaMI5QtnASYOMSsAzWaqQMr6D9+kOwLWzdjO5QBJvYBDUvt3hx X-Received: by 2002:a17:902:e290:: with SMTP id cf16mr16589035plb.81.1547241428242; Fri, 11 Jan 2019 13:17:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547241428; cv=none; d=google.com; s=arc-20160816; b=kTjXgE9HAk/LbLKpwZs80+7X8u6b7LMqy5tkZCMeHO6VVNhtzS8h20vbrwAtxs31M6 PuUd6dlrwTiMc67/1XK4GLahLJPQdqErP2Qy+hlLinCYV22jvsRSe2elW6Aoyf42z6H2 r0c5Mw8YulbRjrsSAo/Cqs6rlNZWuu3FubiptoswZ6jHz2ZdtiElqwN5c+PIwesWHw5/ pwM3pUB3zb+KesSHpHU4sYc1BLqx5UUHuWjszSHnv2r5BWc6qIUfRodjP2sM2B/r606E W6qWrY67WdVOs5mn7NvLMMj0+glMCRG9FjO5PmAsopLwuqAvfRGXvd09IknRX4G7iGtu bSsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=AujB188ed4THJqxeQlXzszieX7ccPjsLwvsyKlgvUfQ=; b=Qfk6fsHFQqiY8YBe5Uejgv6gzc9fo0oOY0Io/uFk0KdrrJu6LMxUmgvS6CRXJ/qZ62 9T/kUdjzEd7brUlfjGOVbnzmzXrt/s36+a1Lx+EvQwlEE6Tqd+pnJM683KAX4U86B9NQ QmDZUK6ao9EhY2qQ2hP6aKqkSoMKih2vltojlR2O7t74YIXZ1iZvbeRy7LKQVZmB/jY8 cOd0OXMq3LnofNTYWK21F5P7sXkunCA1AMBKKfFhM+Phc3eSGKRxdOqsA93QOjXh8UpV mlMIpvzCrMHnc+yIjfS/TZpvnLj52PL0ZOnFKbH0FozDXT86U2vwpB/hZCXZ6wwXHug8 VH8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w16si72485690pga.328.2019.01.11.13.16.52; Fri, 11 Jan 2019 13:17:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390642AbfAKURU (ORCPT + 99 others); Fri, 11 Jan 2019 15:17:20 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:34625 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387847AbfAKURT (ORCPT ); Fri, 11 Jan 2019 15:17:19 -0500 Received: from p4fea4364.dip0.t-ipconnect.de ([79.234.67.100] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gi3Eu-0003av-Eh; Fri, 11 Jan 2019 21:17:12 +0100 Date: Fri, 11 Jan 2019 21:17:12 +0100 (CET) From: Thomas Gleixner To: Daniel Drake cc: suresh.b.siddha@intel.com, Linux Upstreaming Team , Linux Kernel Subject: Re: APIC timer checked before it is set up, boot fails on Connex L1430 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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