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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.