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: <CALjTZvZtu8sSycu2soSXCEP1yZiVNFKkxs4JY_puFahwFuuRcQ@mail.gmail.com>
Date:   Thu, 25 Jul 2019 01:13:56 +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)

On Wed, 24 Jul 2019 at 12:02, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Rui,
>
> On Wed, 24 Jul 2019, Rui Salvaterra wrote:
> > I don't know if this has been reported before, but from a cursory
> > search it doesn't seem to be the case.
> > I have a x86-64 Pentium (4) D machine which always worked perfectly
> > with Linux 5.2 using the TSC as the clock source. With Linux 5.3-rc1 I
> > can't, for the life of me, boot it with anything other than
> > clocksource=jiffies, it completely hangs without even a backtrace.
>
> The obvious candidate for this is the following section:
>
> c8c4076723da ("x86/timer: Skip PIT initialization on modern chipsets")
> dde3626f815e ("x86/apic: Use non-atomic operations when possible")
> 748b170ca19a ("x86/apic: Make apic_bsp_setup() static")
> 2420a0b1798d ("x86/tsc: Set LAPIC timer period to crystal clock frequency")
> 52ae346bd26c ("x86/apic: Rename 'lapic_timer_frequency' to 'lapic_timer_period'")
> 604dc9170f24 ("x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency")

Hi again, everyone,

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
# bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
git bisect bad 5f9e832c137075045d15cd6899ab0505cfb2ca4b
# bad: [e786741ff1b52769b044b7f4407f39cd13ee5d2d] Merge tag
'staging-5.3-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad e786741ff1b52769b044b7f4407f39cd13ee5d2d
# bad: [8f6ccf6159aed1f04c6d179f61f6fb2691261e84] Merge tag
'clone3-v5.3' of
git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
git bisect bad 8f6ccf6159aed1f04c6d179f61f6fb2691261e84
# bad: [ed63b9c873601ca113da5c7b1745e3946493e9f3] Merge tag
'media/v5.3-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad ed63b9c873601ca113da5c7b1745e3946493e9f3
# bad: [4d2fa8b44b891f0da5ceda3e5a1402ccf0ab6f26] Merge branch 'linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect bad 4d2fa8b44b891f0da5ceda3e5a1402ccf0ab6f26
# bad: [46f1ec23a46940846f86a91c46f7119d8a8b5de1] Merge branch
'core-rcu-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 46f1ec23a46940846f86a91c46f7119d8a8b5de1
# good: [2a1ccd31420a7b1acd6ca37b2bec2d723aa093e4] Merge branch
'irq-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 2a1ccd31420a7b1acd6ca37b2bec2d723aa093e4
# good: [ab2486a9ee3243c8342549f58a13cdfa9abb497a] Merge branch
'x86-fpu-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good ab2486a9ee3243c8342549f58a13cdfa9abb497a
# bad: [2f0f6503e37551eb8d8d5e4d27c78d28a30fed5a] Merge branch
'x86-timers-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 2f0f6503e37551eb8d8d5e4d27c78d28a30fed5a
# good: [fd329f276ecaad7a371d6f91b9bbea031d0c3440] x86/mtrr: Skip
cache flushes on CPUs with cache self-snooping
git bisect good fd329f276ecaad7a371d6f91b9bbea031d0c3440
# bad: [e37f0881e9d9ec8b12f242cc2b78d93259aa7f0f] x86/hpet: Introduce
struct hpet_base and struct hpet_channel
git bisect bad e37f0881e9d9ec8b12f242cc2b78d93259aa7f0f
# good: [8c273f2c81f0756f65b24771196c0eff7ac90e7b] x86/hpet: Move
static and global variables to one place
git bisect good 8c273f2c81f0756f65b24771196c0eff7ac90e7b
# bad: [3535aa12f7f26fc755514b13aee8fac15741267e] x86/hpet:
Decapitalize and rename EVT_TO_HPET_DEV
git bisect bad 3535aa12f7f26fc755514b13aee8fac15741267e
# bad: [3222daf970f30133cc4c639cbecdc29c4ae91b2b] x86/hpet: Separate
counter check out of clocksource register code
git bisect bad 3222daf970f30133cc4c639cbecdc29c4ae91b2b
# good: [6bdec41a0cbcbda35c9044915fc8f45503a595a0] x86/hpet: Shuffle
code around for readability sake
git bisect good 6bdec41a0cbcbda35c9044915fc8f45503a595a0
# 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
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

… 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…?

Thanks,
Rui