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@oracle.com 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.