Hi,
On 2/27/20 7:41 PM, Lyude Paul wrote:
hi - I almost certainly know the solution to this, the patches that we got from amd to do bandwidth checking in the DP MST helpers don't actually work correctly in a lot of cases and I need to fix them. I've just been busy on PTO and only just got back today, and have been busy with fixing a lot of RHEL stuff at the same time. I'll take a closer look at this soonb
Great, I'm a bit worried about the timing for getting this fixed though. We are not that far into the cycle yet, but still I have the feeling it might be better to just revert the commit triggering the probably pre-existing problems here and then queue up the necessary fixes + a new version of that commit when we have everything in place ?
This way you can take your time to fix this properly instead of having to do a rush job to fix the regression before 5.6 ships. I think rushing things never is a good idea. So my vote on this goes to just reverting the commit triggering this for now and taking our time to get this right.
Regards,
Hans
On Wed, 2020-02-26 at 16:15 +0100, Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of work on DP MST, but if this rings a bell to anyone else feel free to weigh in on this.
I'm currently using a Lenovo X1 7th gen + a Lenovo TB3 gen 2 dock as my daily rider for testing purposes. When 5.6-rc1 came out I noticed that only 1 of the 2 1920x1080@60 monitors on the dock lights up.
There are no kernel errors in the logs, but mutter/gnome-shell says:
gnome-shell[1316]: Failed to post KMS update: Page flip of 93 failed
With 93 being the crtc-id of the crtc used for the monitor which is displaying black. Since then I've waited for 5.6-rc3 hoping that a fix was already queued up, but 5.6-rc3 still has this problem.
gnome-shell does behave as if all monitors are connected, so the monitor is seen, but we are failing to actually send any frames to it.
I've put a log collected with drm.debug=0x104 here: https://fedorapeople.org/~jwrdegoede/drm-debug.log
This message stands out as pointing to the likely cause of this problem:
[ 3.309061] [drm:intel_dump_pipe_config [i915]] MST master transcoder:
<invalid>
Regards,
Hans