linux-kernel - Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)

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: <alpine.DEB.2.21.1907250810530.1791@nanos.tec.linutronix.de>
Date:   Thu, 25 Jul 2019 08:28:45 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Rui Salvaterra <rsalvaterra@...il.com>
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)

Rui,

On Thu, 25 Jul 2019, Rui Salvaterra wrote:
> Looks like we have a winner. Actually, I did a full bisection between
> 5.2 and 5.3-rc1. Full log follows:
> 
> git bisect start
> # good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2
> git bisect good 0ecfebd2b52404ae0c54a878c872bb93363ada36
>
> # first bad commit: [3222daf970f30133cc4c639cbecdc29c4ae91b2b]
> x86/hpet: Separate counter check out of clocksource register code
> 
> I haven't tried reverting this commit and recompiling (it's already

'Revert' on top of Linus tree below.

> past 1:00 here, need to sleep), but I'll try it tomorrow, if required.
> Note that on this machine (i945G) the HPET is disabled at boot and is
> forcefully enabled by the kernel…
 
> [    0.147527] pci 0000:00:1f.0: Force enabled HPET at 0xfed00000

Ok. 

> … and the commit message reads…
> 
> "The init code checks whether the HPET counter works late in the init
> function when the clocksource is registered. That should happen right
> with the other sanity checks."
> 
> … maybe now the check is happening a bit too early…?

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.

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?

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

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

Thanks,

	tglx

8<--------------------
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -827,10 +827,6 @@ int __init hpet_enable(void)
 	if (!hpet_cfg_working())
 		goto out_nohpet;
 
-	/* Validate that the counter is counting */
-	if (!hpet_counting())
-		goto out_nohpet;
-
 	/*
 	 * Read the period and check for a sane value:
 	 */
@@ -896,6 +892,14 @@ int __init hpet_enable(void)
 	}
 	hpet_print_config();
 
+	/*
+	 * Validate that the counter is counting. This needs to be done
+	 * after sanitizing the config registers to properly deal with
+	 * force enabled HPETs.
+	 */
+	if (!hpet_counting())
+		goto out_nohpet;
+
 	clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq);
 
 	if (id & HPET_ID_LEGSUP) {