Found the bug, very probably.
It seems to be an upstream bug: a 32bits multiplication overflow on TSC
frequency introduced in recent TSC cleanup:
--------------------------------------------------------------------------------
commit cf7a63ef4e0203f6f33284c69e8188d91422de83
Author: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Date: Thu Jul 19 16:55:38 2018 -0400
x86/tsc: Calibrate tsc only once
During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(),
and the second time in tsc_init().
Rename tsc_early_delay_calibrate() to tsc_early_init(), and rework it so
the calibration is done only early, and make tsc_init() to use the values
already determined in tsc_early_init().
Sometimes it is not possible to determine tsc early, as the subsystem that
is required is not yet initialized, in such case try again later in
tsc_init().
--------------------------------------------------------------------------------
One nasty thing: this commit is broken, it does not compile, hence it's a
bisect "skipped" commit.
Roughly, if you have a cpu with a frequency above 4.2GHz (max unsigned 32bits),
linux time subsystem gets broken leading to the timeouts in displayport
programming. Ofc, my cpu runs at 4.7GHz.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
