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.tatas...@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. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel