public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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)





  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