Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Jul 2019 11:37:46 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Rui Salvaterra <rsalvaterra@gmail.com>
cc:     LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Daniel Drake <drake@endlessm.com>
Subject: Re: [BUG] Linux 5.3-rc1: timer problem on x86-64 (Pentium D)
In-Reply-To: <CALjTZvb6aiUEgLN9BxOxBZCBXHoFxOx4TpBxkRQbZjgCna4WUA@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.1907251127430.1791@nanos.tec.linutronix.de>
References: <CALjTZvbrS3dGrTrMMkGRkk=hRL38rrGiYTZ4REX9rJ0T+wcGoQ@mail.gmail.com> <alpine.DEB.2.21.1907241257240.1791@nanos.tec.linutronix.de> <CALjTZvZtu8sSycu2soSXCEP1yZiVNFKkxs4JY_puFahwFuuRcQ@mail.gmail.com> <alpine.DEB.2.21.1907250810530.1791@nanos.tec.linutronix.de>
 <CALjTZvb6aiUEgLN9BxOxBZCBXHoFxOx4TpBxkRQbZjgCna4WUA@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-442860888-1564047204=:1791"
Content-ID: <alpine.DEB.2.21.1907251135370.1791@nanos.tec.linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-442860888-1564047204=:1791
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.21.1907251135371.1791@nanos.tec.linutronix.de>

Rui,

On Thu, 25 Jul 2019, Rui Salvaterra wrote:
> On Thu, 25 Jul 2019 at 07:28, Thomas Gleixner <tglx@linutronix.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:

Duh. Yes, this explains it nicely.

> [    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

The HPET counter check succeeded, but the early enable and the following
reconfiguration confused it completely. So the HPET is not counting:

	'hpet' wd_now: 33 wd_last: 33 mask: ffffffff

Which is a full explanation for the boot fail because if the counter is not
working then the HPET timer is not expiring and the early boot is waiting
for HPET to fire forever.

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

That's consistent with the above. 5.3-rc1 unpatched would of course boot as
well with hpet=disable now that we know the root cause.

I'll write a changelog and route it to Linus for -rc2.

Thanks a lot for debugging this and providing all the information!

       tglx
--8323329-442860888-1564047204=:1791--