From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5539163CB for ; Tue, 3 Mar 2026 14:45:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772549129; cv=none; b=kJ/OBdxIg+3LnipcL41rz8Dm93qZoPFLjc09paQvHrUQ9oW/wHN53eOWFp16Z+wlP1XzXNR8D1UBDovMumGFIryz2w7JP+MhII+R7IKfoeXNoa4EA+gJbrA0g25ZJbjwRE9Fnw/0XWyJd6kFZL7K2lCa19DT/Zy6tP0KvpFb8s8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772549129; c=relaxed/simple; bh=IXllmu8qXYnnQMbY6LN5kGZBF2VmAp69HeiLFSA24gk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DWr0os3QPuWXeZazZILtuTlrfp4h3XlXWXAb3aZYKlnryG7Iz40ryFiOoY2g/lx+bBvqvnqmRvLx71rkBQCNXbTMjvwGcOv0GlBZtAe1mDfisCl8JPMuoATkc32XDfYQ0MpcGknx7/jM29lj+5Mn+K1jABhr+P3uD3j3uTsZW04= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jqquEaSW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jqquEaSW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0508DC116C6; Tue, 3 Mar 2026 14:45:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772549128; bh=IXllmu8qXYnnQMbY6LN5kGZBF2VmAp69HeiLFSA24gk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jqquEaSWWpEY0LVKPkDY4miW7gX/0uYUC+uAX++hCkmGDIJeVSJi7QXUuXH3gIYSB 6+cT9p8RpOuDh554JlnwyOBOObxkPu3vu+/bAeElzhlM9PUMeUYM5ZpMFjBuRBmiy4 jv0t9wSoOkzhbHHGlb6J3v8C2HMgFf3m9DSKVlT0vkLezDmSfNY0jmiQYzwIrr7RNn 55zjPNNm0Ag/2J3RinH41uqGtXXExQff7BDviGgHAyZNybCWM/zty5Zu7hTVv6fwTk mhSqlr2dIP9X+nLW49v9tBJYlXQebS7oJHQNcnvgCH7SLRfWmBRue+ch01KsHCDY5A FzgIOJmLsAsjw== From: Thomas Gleixner To: Nathan Chancellor Cc: LKML , Anna-Maria Behnsen , John Stultz , Stephen Boyd , Daniel Lezcano , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , x86@kernel.org, Peter Zijlstra , Frederic Weisbecker , Eric Dumazet Subject: Re: [patch 20/48] x86/apic: Enable TSC coupled programming mode In-Reply-To: <87jyvtyo6o.ffs@tglx> References: <20260224163022.795809588@kernel.org> <20260224163430.076565985@kernel.org> <20260303012905.GA978396@ax162> <87jyvtyo6o.ffs@tglx> Date: Tue, 03 Mar 2026 15:45:24 +0100 Message-ID: <87h5qxynsr.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Mar 03 2026 at 15:37, Thomas Gleixner wrote: > On Mon, Mar 02 2026 at 18:29, Nathan Chancellor wrote: >> >> After this change landed in -next as commit f246ec3478cf ("x86/apic: >> Enable TSC coupled programming mode"), two of my Intel-based test >> machines fail to boot. Unfortunately, I do not think I have any serial >> access on these, so I have little introspective ability. Is there any >> information I can provide or patches I can test to try and help figure >> out what is going on here? I have attached the output of lscpu of both >> machines, in case there is some common thread there. > > Grmbl. I stared at it for a while and I have a suspicion. Can you try > the patch below and also provide from one of the machines the output of > > dmesg | grep -i tsc > > In case that does not work, I'll send a debug patch in reply to this > mail. Here you go. It fails the coupled mode, but emits all relevant data via trace_printk. Just collect it right after booting and please tell me where the boot stops in the boot process so I can narrow down the search. Thanks, tglx --- --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -424,9 +424,10 @@ static int lapic_next_deadline(unsigned * There is no weak_wrmsr_fence() required here as all of this is purely * CPU local. Avoid the [ml]fence overhead. */ - u64 tsc = rdtsc(); + u64 dl = rdtsc() + (((u64) delta) * TSC_DIVISOR); - native_wrmsrq(MSR_IA32_TSC_DEADLINE, tsc + (((u64) delta) * TSC_DIVISOR)); + native_wrmsrq(MSR_IA32_TSC_DEADLINE, dl); + trace_printk("APIC deadline: %16llu\n", dl); return 0; } --- a/kernel/time/clockevents.c +++ b/kernel/time/clockevents.c @@ -310,11 +310,9 @@ static inline bool clockevent_set_next_c if (unlikely(!ktime_expiry_to_cycles(dev->cs_id, expires, &cycles))) return false; - if (IS_ENABLED(CONFIG_GENERIC_CLOCKEVENTS_COUPLED_INLINE)) - arch_inlined_clockevent_set_next_coupled(cycles, dev); - else - dev->set_next_coupled(cycles, dev); - return true; + trace_printk("Coupled deadline: %16llu Exp: %16lld\n", cycles, expires); + + return false; } #else --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -404,6 +404,7 @@ static void tk_setup_internals(struct ti */ clocks_calc_mult_shift(&tk->cs_ns_to_cyc_mult, &tk->cs_ns_to_cyc_shift, NSEC_PER_MSEC, clock->freq_khz, 3600 * 1000); + tk->cs_ns_to_cyc_maxns = div_u64(clock->mask, tk->cs_ns_to_cyc_mult); } } @@ -762,6 +763,11 @@ static inline void tk_update_ns_to_cyc(s shift = tkrs->shift + tks->cs_ns_to_cyc_shift; tks->cs_ns_to_cyc_mult = (u32)div_u64(1ULL << shift, tkrs->mult); tks->cs_ns_to_cyc_maxns = div_u64(tkrs->clock->mask, tks->cs_ns_to_cyc_mult); + trace_printk("CSM: %8u CSS: %8u CEM: %8u CES: %8u MNS: %16llu BNS: %16lld BCY: %16llu\n", + tkrs->shift, tkrs->mult, tks->cs_ns_to_cyc_mult, + tks->cs_ns_to_cyc_shift, tks->cs_ns_to_cyc_maxns, + tkrs->base + (tkrs->xtime_nsec >> tkrs->shift), + tkrs->cycle_last); } /*