lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALjTZvb6aiUEgLN9BxOxBZCBXHoFxOx4TpBxkRQbZjgCna4WUA@mail.gmail.com>
Date:   Thu, 25 Jul 2019 10:02:52 +0100
From:   Rui Salvaterra <rsalvaterra@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Daniel Drake <drake@...lessm.com>
Subject: Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)

Hi again, Thomas,

On Thu, 25 Jul 2019 at 07:28, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> The only reason I can think of is that the HPET on that machine has a weird
> register state (it's not advertised by the BIOS ... )
>
> But that does not explain the boot failure completely. If the HPET is not
> available then the kernel should automatically do the right thing and fall
> back to something else.

This may be a useful data point, the relevant part of the dmesg on a
pristine 5.3-rc1 with clocksource=jiffies:

[    0.028964] clocksource: refined-jiffies: mask: 0xffffffff
max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.113537] clocksource: tsc-early: mask: 0xffffffffffffffff
max_cycles: 0x30e24b1e83d, max_idle_ns: 440795362670 ns
[    0.127048] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.175604] clocksource: hpet: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 133484882848 ns
[    0.185029] clocksource: acpi_pm: mask: 0xffffff max_cycles:
0xffffff, max_idle_ns: 2085701024 ns
[    1.123548] clocksource: timekeeping watchdog on CPU1: Marking
clocksource 'tsc-early' as unstable because the skew is too large:
[    1.123552] clocksource:                       'hpet' wd_now: 33
wd_last: 33 mask: ffffffff
[    1.123554] clocksource:                       'tsc-early' cs_now:
922361204 cs_last: 8bc8d8390 mask: ffffffffffffffff
[    1.123556] tsc: Marking TSC unstable due to clocksource watchdog

available_clocksource: hpet acpi_pm refined-jiffies jiffies
current_clocksource: jiffies

> Can you please provide the output of:
>
>  cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> and
>  cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> from a successful boot with 5.2 and 5.3 head with the 'fix' applied?

Here we go…

Linux 5.2:
available_clocksource: tsc hpet acpi_pm
current_clocksource: tsc

Linux 5.3-rc1 patched:
available_clocksource: tsc hpet acpi_pm
current_clocksource: tsc

> Then boot these kernels with 'hpet=disable' on the command line and see
> whether they come up. If so please provide the same output.

Fortunately (as I'm doing this remotely) they did come up.
With hpet=disabled…

Linux 5.2:
available_clocksource: tsc acpi_pm
current_clocksource: tsc

Linux 5.3-rc1 patched:
available_clocksource: tsc acpi_pm
current_clocksource: tsc

> The dmesg output of each boot would be useful as well.

Attached is the dmesg output of each case.

Thanks,
Rui

Download attachment "5.3-rc1-patched-hpet-disable-dmesg.log" of type "application/octet-stream" (42322 bytes)

Download attachment "5.2-dmesg.log" of type "application/octet-stream" (42172 bytes)

Download attachment "5.2-hpet-disable-dmesg.log" of type "application/octet-stream" (42011 bytes)

Download attachment "5.3-rc1-patched-dmesg.log" of type "application/octet-stream" (42488 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ