From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) (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 AB0C324E4C6 for ; Sat, 15 Aug 2026 18:17:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.72.192.75 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786817854; cv=none; b=dPmwpRHqCgfGyEwjnIFAbeFcxHeyFphrRxK3XVi6lkcNY0YmlHRD1rxKMEmzrG6gGNXCZs/bn8App0spqvZSEeaLp3GQZHDf+QJL88etrmmG242Wios11JY2VJR8s2rVUHdIS5OC0HugVyTqQyO52FDpa6aN+OYZpzYoIWK08Io= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786817854; c=relaxed/simple; bh=odeNxGRG0G8MLeej4yW28QwjmllA6gUAxn2JB9PSbxM=; h=Date:From:To:Cc:Message-ID:Subject:MIME-Version:Content-Type; b=fuqRZs0A0Cyx8Emt1LQCzYZ4NoLO9ytu4rVOuOIALcQwkGWlNBybiX6G8Tl97cVsRn5nSma4CKuuVI0eUt6AdGz6QEuGQUE+8rU1jZM7iTF6Ku1nPtXuur73xLfNF/6Vnox00Z6ijEFgD9b6/OoaahH5AgfG+ynf1hou//ZMwTk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=david-kostial.de; spf=pass smtp.mailfrom=david-kostial.de; dkim=pass (2048-bit key) header.d=david-kostial.de header.i=mail@david-kostial.de header.b=NzTR/tcL; arc=none smtp.client-ip=217.72.192.75 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=david-kostial.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=david-kostial.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=david-kostial.de header.i=mail@david-kostial.de header.b="NzTR/tcL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=david-kostial.de; s=s1-ionos; t=1786817845; x=1787422645; i=mail@david-kostial.de; bh=PXV457TKTBn3oqdxFyUsKzM/fdb6cKZj9BT9yM3Zc7A=; h=X-UI-Sender-Class:Date:From:To:Cc:Message-ID:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=NzTR/tcLsKn8yUGHtSNIdOdrY7wIbYfc0CAvlSVeOIYPhFciz5R+3Sy5wIzCPccY YnDE+v7aFyKPrZ+A7ZvupWG/LkwQ+xskF/ezSBBfA3Dv19NNadPuVdJiaCqkvfdo7 qdm81WjYy8YWb8Pb86Lsilc/fjFuvMMb4XLL3eKTljivtFQRny3a3/Tg3bV0rHIXl NhraNyTAkCaFAk7X3T0uwz+v6htby1E0yymq3ppy/0jzFgdpbf76ZoF/dE1sgb/Pb h0D4aIOylU35lVnO2L/shlL2EZeYtZ1JYKsj2Lp3IqHiIf4pDbKpa0Fsary5RKLdE vSOfrkRq2dXdMDibiA== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from client.hidden.invalid by mrelayeu.kundenserver.de (mreue108 [10.74.24.7]) with ESMTPSA (Nemesis) id 1MBDrM-1x7uOJ16o2-004KZf; Sat, 15 Aug 2026 20:17:25 +0200 Date: Sat, 15 Aug 2026 20:17:24 +0200 (CEST) From: David Kostial To: "x86@kernel.org" Cc: "linux-kernel@vger.kernel.org" Message-ID: <2058267156.513331.1786817844981@mailbusiness.ionos.de> Subject: [BUG] x86/tsc: ~1 second TSC skew when bringing a secondary CPU online on Ryzen 7 8840HS Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v8.46.152 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:dGhv4h/zg1sjLzeW//95PFEkIEfX+y76032+jPY+KXAXjAydyS1 lXEg9z9FvdH5roTnjdTtW14LqMSvjs/ttssRDUKKIPEcqROKodyJcmi4MINgLDNg5WeIMHC TgFLWTmq4yclAgflKw4jUFckWNvUj5JcjS8lpA0hwi51/Clu2lKVn2zoGLfYmLhjbrMC8z5 A19k0pRjGeWZJ+rS/+j4A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Cs1WqTsXxsY=;FaZWPYoRmkil/yFHiXrtJ++QOy0 qjVP5ZKBUYUht7PHcJ5NY1l+9AfFGvYs5rChH7O676jElwm8Dfh5YA+hWwN1JO75qGVceYzPH WnIPi7XA0ZRqFy62+c8WrZBThObdtOb0ZS/q6vPuT8jtObeOFFvp7XaD1lhv9gP0rxKzpqcW3 pjEXJvGsca64l5D3YPQRuetvfm+dq+ORkwELDznBp/cmkFa/iiWoBL3ifDvaizVMt+PYJmKVg nZXCG7jCG5TxtRHTn41mzexrXwga95+6TnLfKxH48m9PnK+os4+PB82t4zMgy1Uw9Su6pzeAW AqkbVRsMGtwi4G52lpQ0IK/e98cPEixF4S9gZ68Z4B4Suxby647qbGf/Qz/UKZQgicypsOd47 /ZJmRSABKIwUBjumM8yZIrj3IWj77dkQpsnVPRjEbbAL7IKsl8ZD5WK6vvMw+UA2Tbz74L9KH rsmnTiCHkMBUdf0AAi5WriTnkemeFCpeS/0c444te65z4i3opaBpc2mqNL/4AlB/5pnrDvJCJ xr+ERurJ+uSCzUeI0bFYiQYBmEigHV4yJcrL9LFQzCgBS82iR2Ri3DP7UhphcHgIPof/Dt46Z Zbd9a2NkEVCDBl5sZ+UpSmXLeRs4nbFdCAlqFx3JqExQWj5Xb96wb9slDVU9PCzAMdibCDMEj H6dywjI8KIydzS28LXG56SheFZC0AG70Ub+OAaPwRQSh+NIe2qYbseSZqlx55jwUmhJISHVHE +Rpiyk6MDcUzXfCmlMn3Du7FHCfsjgKs3hJ6bSNXwYwRNyeDlLdIXCX9uF80Y6TvWFmDhZ4wU BIcgNtR4fE/10GnLTI7vfUCBsnABcpBEP3/8BQQ6zcpzk4E8Ghc6dKX/MubsWYejlDJdwuJOK hzDee79ZEA28AgavuD9wftlSNlTbr2jqlhzqRhYCs6JjzECDFSaeZ60o8Q22qGuRu5Hlk2PkP 5bP0e6u2BarqvZiE/IYiaMGPoLcOsdQ34OfNaDM7U5MP1GPvCz/cUHNxPzppPJEE0od0o5KsJ CQBdyn4saxTd9opx/qVNpw6doGQO32XCvtp4QhNR9SelXIkuOqpKd8Sc9HIc53EH3BaFZxhu3 rvoL8pyglD1Ag+pxOLf1bvZ6YQW4jp6+GG4GcRQuT3vhkdSBl+gG9Pp4c19tRKxJQFiHun1v9 NyRfNe4A5+bPI6sWw9ZDK7h4EQ+2jW3LhAqktlvpEuh68TIWY6Iw9KbmgLgb7faFl+urm1PQj TUa3/jYutFD84npGrHpCepfXBHyYu310mzyIdWkH5ZHv3myZ1n2HJev2GkMAbZH8YueYxSy3C O6CO0AVdEjkD9smzjTvkaHcToLBriJzK8t0xPtOB7v6jOu2gfbd2SXihissrs0wzzkaUGouul eZGeFNXnMsAbRBbb6d7V6cVJrXeVZgpEt3ZKM6DX2vyf4zSExPup21QPhk9YdCYEMP6/OjrwR nz6aWMTq7dWC8V2LFdyRtlEfxRsaQoISv8RJs0MSUh8F4Q4nzTgfPJ4u2eqpxw5xx97t+88ts 05w6m/ZIKkS+a4/9CoDlPMhqaWyGGHRjr0OHjV02ZPMqK08lE96wthZNGceZhr9QXT/caNeqS uYEmCmPjQ0HGI7u05LS2F2CYkdrdwqLSogpEIXFHxu0bFvft0Xbxueeu5humNWRLrE/fOhenD mJzdxz9wWKU0alLg/qsKWQo9oEfBdlE+SUXrsKEFTa5oJxaoshckfutRMEMCUgL6lv1ZR7PhW GmSWpcR31Kh5MLYQJPfURohT0HYrMcVMQgsNS0DgFHqhZWRkwlbU5BdHF0qeLhd+8PKOqIvrx J0QxDuhFqia15IqsOoykoDlIbDELH94m5z8FI6nEBjcDwsz2NoBwxD69aykwCwSN1dSqtwMOr nd4V+ylZAMaunqdwGlHYHqM1rUVwJolp/ZQ3Bnrw9tdA3l709rwFwIKNpX05tUGMYKY/DA5Is qA4taCKS7mUMR9SvItohrGzLmILTulUwa0VedjsztSVaTw9gxf Hi, I'm seeing a large and reproducible TSC synchronization error on a Lenovo Yoga 7 2-in-1 14AHP9 with an AMD Ryzen 7 8840HS. It also reproduces with a vanilla kernel built from Linus' tree: commit 15ef2f78c49d20d53ec7c0f1c9b40b02e089f2d6 v7.2-rc7-219-g15ef2f78c49d 7.2.0-rc7-katinka-tsc-00219-g15ef2f78c49d The kernel was untainted during the tests and no DKMS or other out-of-tree modules were loaded. Hardware / firmware: System: Lenovo Yoga 7 2-in-1 14AHP9 (83DK) CPU: AMD Ryzen 7 8840HS Family: 0x19 (25) Model: 0x75 (117) Stepping: 2 BIOS: P9CN33WW, 2026-03-27 AGESA: PhoenixPI-FP8-FP7 1.2.0.0f Microcode: 0x0a70520a The CPU reports constant_tsc and nonstop_tsc. A normal boot with all 16 logical CPUs already triggers the problem. TSC synchronization fails while the secondary CPUs are brought up, TSC is marked unstable, and the kernel switches to HPET. I found a simple deterministic reproducer using CPU hotplug. Boot with: maxcpus=1 With only CPU0 online: $ cat /sys/devices/system/cpu/online 0 $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc $ cat /proc/sys/kernel/tainted 0 Before CPU1 is brought online, TSC is selected as the current clocksource and no TSC synchronization failure is logged. Then bring CPU1 online: # echo 1 > /sys/devices/system/cpu/cpu1/online This immediately gives: smpboot: Booting Node 0 Processor 1 APIC 0x1 TSC synchronization [CPU#0 -> CPU#1]: Measured 3360957369 cycles TSC warp between CPUs, turning off TSC clock. tsc: Marking TSC unstable due to check_tsc_sync_source failed TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. clocksource: Switched to clocksource hpet After that: $ cat /sys/devices/system/cpu/online 0-1 $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet $ cat /proc/sys/kernel/tainted 0 With the full CPU topology online, CPU0 and CPU1 are SMT siblings of the same physical core. The result is very repeatable. Across different tests I have seen TSC warps between roughly 3.25 and 3.36 billion cycles. I have reproduced the same type of failure with Debian kernels based on Linux 6.12.101, 7.1.3, and 7.2-rc7. I also tried: - cold boot: affected - BIOS Fast Boot setting enabled/disabled: no difference - BIOS AMD SVM setting enabled/disabled: no difference - CPU0 only: TSC is selected - bringing a secondary logical CPU online: TSC becomes unstable The kernel falls back to HPET after detecting the skew. I also saw the following KVM warning on the affected system when starting an SMP guest: kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable I'm not sure whether the root cause is firmware/AGESA or whether there is anything x86/tsc should handle differently here. Is there any additional TSC instrumentation, MSR data, trace data, or firmware information that would be useful? I also have a redacted 92 KiB diagnostic archive containing the full vanilla dmesg, kernel config, lscpu output, CPU/APIC topology, microcode and firmware information, and the normal-boot and CPU-hotplug reproducer logs. I can provide it if useful. Regards, David Kostial