From: Fab Stz <fabstz-it@yahoo.fr>
To: Thomas Gleixner <tglx@linutronix.de>,
John Stultz <jstultz@google.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [REGRESSION] ? system is stuck in clocksource, >60s delay at boot time without tsc=unstable
Date: Fri, 27 Dec 2024 13:39:28 +0100 [thread overview]
Message-ID: <22539099.EfDdHjke4D@debian> (raw)
In-Reply-To: <10cf96aa-1276-4bd4-8966-c890377030c3@yahoo.fr>
Hello,
It's been one month now that I sent this email. Do you have any clue on this?
Regards
Fab
Le mercredi 27 novembre 2024, 08:18:41 CET Fab Stz a écrit :
> Hi,
>
> While upgrading from Debian bullseye (kernel 5.10) to bookworm (6.1) I
> noticed that the newer kernel is at the beginning of the boot stuck for
> more than 60 seconds.
>
> This is apparently related to the clocksource module. If I boot with
> tsc=unstable there is no more delay.
>
> In the kernel logs, I have:
>
> clocksource: Long readout interval, skipping watchdog check: cs_nsec:
> 512010551 wd_nsec: 39243763320
> clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as
> unstable because the skew is too large:
> clocksource: 'hpet' wd_nsec: 537773520 wd_now:
> 3f0f7632 wd_last: 3e425140 mask: ffffffff
> clocksource: 'tsc' cs_nsec: 511996079 cs_now:
> 18b0866e6a cs_last: 185f8d68ba mask: ffffffffffffffff
> clocksource: 'tsc' is current clocksource.
> tsc: Marking TSC unstable due to clocksource watchdog
> TSC found unstable after boot, most likely due to broken BIOS. Use
> 'tsc=unstable'.
> sched_clock: Marking unstable (3765559657, 1276001)<-(3775071370, -8235646)
> clocksource: Checking clocksource tsc synchronization from CPU 1 to CPUs 0.
> clocksource: Switched to clocksource hpet
>
>
> I already had such a warning with 5.10, but there was no >60sec freeze
> with it like with 6.1
>
> The delay is still present in kernel 6.11.
>
> I attach the output of dmesg. On screen, the last line that is displayed
> before being frozen for >60sec is
>
> [ 2.898668] hub 2-0:1.0: 5 ports detected
>
> Because of that, I initially thought that there is a problem with USB,
> but actually not since tsc=unstable "fixes" the delay. The kernel
> mentions clocksource only later in the logs, but the timestamps don't
> reflect the delay. My last measure is a freeze of about 70seconds.
>
> I also noticed that if during that period I do a short press on the
> power button of the system, it stops the freeze and the boot process
> continues immediately.
>
> Regards
>
> ==== System information ====
>
> It's an Apple iMac 9.1
>
> # cat /proc/version
> Linux version 6.1.0-28-amd64 (debian-kernel@lists.debian.org) (gcc-12
> (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
> PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22)
>
> # hostnamectl | grep "Operating System"
> Operating System: Debian GNU/Linux 12 (bookworm)
>
> # uname -mi
> x86_64 unknown
>
> # lspci -nn
> 00:00.0 Host bridge [0600]: NVIDIA Corporation MCP79 Host Bridge
> [10de:0a82] (rev b1)
> 00:00.1 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller
> [10de:0a88] (rev b1)
> 00:03.0 ISA bridge [0601]: NVIDIA Corporation MCP79 LPC Bridge
> [10de:0aae] (rev b2)
> 00:03.1 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller
> [10de:0aa4] (rev b1)
> 00:03.2 SMBus [0c05]: NVIDIA Corporation MCP79 SMBus [10de:0aa2] (rev b1)
> 00:03.3 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller
> [10de:0a89] (rev b1)
> 00:03.4 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller
> [10de:0a98] (rev b1)
> 00:03.5 Co-processor [0b40]: NVIDIA Corporation MCP79 Co-processor
> [10de:0aa3] (rev b1)
> 00:04.0 USB controller [0c03]: NVIDIA Corporation MCP79 OHCI USB 1.1
> Controller [10de:0aa5] (rev b1)
> 00:04.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0
> Controller [10de:0aa6] (rev b1)
> 00:06.0 USB controller [0c03]: NVIDIA Corporation MCP79 OHCI USB 1.1
> Controller [10de:0aa7] (rev b1)
> 00:06.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0
> Controller [10de:0aa9] (rev b1)
> 00:08.0 Audio device [0403]: NVIDIA Corporation MCP79 High Definition
> Audio [10de:0ac0] (rev b1)
> 00:09.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Bridge
> [10de:0aab] (rev b1)
> 00:0a.0 Ethernet controller [0200]: NVIDIA Corporation MCP79 Ethernet
> [10de:0ab0] (rev b1)
> 00:0b.0 SATA controller [0106]: NVIDIA Corporation MCP79 AHCI Controller
> [10de:0ab9] (rev b1)
> 00:0c.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Express Bridge
> [10de:0ac4] (rev b1)
> 00:10.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Express Bridge
> [10de:0aa0] (rev b1)
> 00:15.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Express Bridge
> [10de:0ac6] (rev b1)
> 00:16.0 PCI bridge [0604]: NVIDIA Corporation MCP79 PCI Express Bridge
> [10de:0ac7] (rev b1)
> 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79
> [GeForce 9400] [10de:0867] (rev b1)
> 04:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries
> BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)
> 05:00.0 FireWire (IEEE 1394) [0c00]: LSI Corporation FW643 [TrueFire]
> PCIe 1394b Controller [11c1:5901] (rev 07)
next prev parent reply other threads:[~2024-12-27 13:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <10cf96aa-1276-4bd4-8966-c890377030c3.ref@yahoo.fr>
2024-11-27 7:18 ` [REGRESSION] ? system is stuck in clocksource, >60s delay at boot time without tsc=unstable Fab Stz
2024-12-27 12:39 ` Fab Stz [this message]
2025-01-02 21:49 ` John Stultz
2025-01-02 21:56 ` John Stultz
2025-01-03 15:38 ` Fab Stz
2025-01-03 19:02 ` John Stultz
2025-01-04 22:02 ` Fab Stz
2025-01-15 16:59 ` Thomas Gleixner
2025-02-23 17:01 ` Fab Stz
2025-02-24 8:13 ` Thomas Gleixner
2025-02-25 8:11 ` Fab Stz
2025-02-25 19:35 ` Thomas Gleixner
2025-02-25 22:37 ` [PATCH] intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctly Thomas Gleixner
2025-02-26 10:24 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22539099.EfDdHjke4D@debian \
--to=fabstz-it@yahoo.fr \
--cc=anna-maria@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=frederic@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox