On Thu, Sep 16, 2021 at 07:57:13PM -0700, Jakub Kicinski wrote:
> On Thu, 16 Sep 2021 09:35:47 -0700 Paul E. McKenney wrote:
> > > > How did you pick v5.13? force_disable_hpet() was added by
> > > > 62187910b0fc ("x86/intel: Add quirk to disable HPET for the Baytrail
> > > > platform"), which appeared in v3.15.
> > >
> > > Erm, good question, it started happening for me (and others with the
> > > same laptop) with v5.13. I just sort of assumed it was 2e27e793e280
> > > ("clocksource: Reduce clocksource-skew threshold").
> > >
> > > It usually takes a day to repro (4 hours was the quickest repro I've
> > > seen) so bisection was kind of out of question.
> >
> > OK, so this is an intermittent condition where HPET is sometimes slow to
> > access for a short period of time? If that is the case, my thought is
> > to set the clocksource to be reinitialized (without a splat and without
> > marking the clocksource unstable), and to splat (and mark the clocksource
> > unstable) if it is not get a good read after 100 subsequent attempts.
> >
> > So as long as the period of slowness lasts for less than 50 seconds,
> > things would work fine.
> >
> > Seem reasonable?
>
> Could well be. Initially I thought it was suspend/resume related, then
> I looked closer and it did happen mostly after resume... but anywhere
> between 20 minutes to few hours after the resume.
>
> I'm here to test less crude patches but since that may take some time
> I'd hope we can get this merged and into stable ASAP. Hopefully it can
> make it to 5.13 while that branch is alive and into Fedora. It really
> makes Coffee Lake machines pretty much unusable.
Indeed, I could see where your reproducer is at best rather annoying.
But a good data point for me either way, so thank you!
Thanx, Paul
