5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Hans de Goede]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Alex Deucher]

On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com> 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.

Might be a duplicate of:
https://gitlab.freedesktop.org/drm/amd/issues/1052

Alex

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

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Hans de Goede]

Hi,

On 2/26/20 4:29 PM, Alex Deucher wrote:
> On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com> 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.
> 
> Might be a duplicate of:
> https://gitlab.freedesktop.org/drm/amd/issues/1052

Looks like you are right, reverting the commit which the bisect
from that issue points to:

cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")

Fixes the issue for me. I will add a comment to the issue.

Note I'm using integrated Intel gfx, so that means that this issue
definitely is not amdgpu specific.

Regards,

Hans




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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Alex Deucher]

On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/26/20 4:29 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com> 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.
> >
> > Might be a duplicate of:
> > https://gitlab.freedesktop.org/drm/amd/issues/1052
>
> Looks like you are right, reverting the commit which the bisect
> from that issue points to:
>
> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
>
> Fixes the issue for me. I will add a comment to the issue.
>
> Note I'm using integrated Intel gfx, so that means that this issue
> definitely is not amdgpu specific.
>

I'm not too familiar with the mst code, but I wonder if we were
exceeding the bandwidth limits in some setups and it just happened to
work, but now that we enforcing them, they don't which is correct, but
a regression from some users' perspective?

Alex


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

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Hans de Goede]

Hi,

On 2/26/20 5:05 PM, Alex Deucher wrote:
> On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 2/26/20 4:29 PM, Alex Deucher wrote:
>>> On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com> 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.
>>>
>>> Might be a duplicate of:
>>> https://gitlab.freedesktop.org/drm/amd/issues/1052
>>
>> Looks like you are right, reverting the commit which the bisect
>> from that issue points to:
>>
>> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
>>
>> Fixes the issue for me. I will add a comment to the issue.
>>
>> Note I'm using integrated Intel gfx, so that means that this issue
>> definitely is not amdgpu specific.
>>
> 
> I'm not too familiar with the mst code, but I wonder if we were
> exceeding the bandwidth limits in some setups and it just happened to
> work, but now that we enforcing them, they don't which is correct, but
> a regression from some users' perspective?

I seriously doubt that is the case according to:
https://support.lenovo.com/nl/en/solutions/pd029622

The gen 2 tb3 dock can handle 2 external
displays at 3840*2160@60Hz together with the internal
panel being on and both my external displays run at
1920x1080@60 so I'm consuming less then half of the
maximum bandwidth.

There definitely is a bug somewhere in the
cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
commit (or somewhere else and triggered by that commit).

Regards,

Hans







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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Souza, Jose]

Hi Hans

Just commenting in the "[    3.309061] [drm:intel_dump_pipe_config
[i915]] MST master transcoder: <invalid>" message, it is the expected
behaviour for anything older than Tigerlake, from TGL+ this will be set
in MST mode.

On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
> 
> On 2/26/20 5:05 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com
> > > wrote:
> > > Hi,
> > > 
> > > On 2/26/20 4:29 PM, Alex Deucher wrote:
> > > > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <
> > > > hdegoede@redhat.com> 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.
> > > > 
> > > > Might be a duplicate of:
> > > > https://gitlab.freedesktop.org/drm/amd/issues/1052
> > > 
> > > Looks like you are right, reverting the commit which the bisect
> > > from that issue points to:
> > > 
> > > cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > atomic check")
> > > 
> > > Fixes the issue for me. I will add a comment to the issue.
> > > 
> > > Note I'm using integrated Intel gfx, so that means that this
> > > issue
> > > definitely is not amdgpu specific.
> > > 
> > 
> > I'm not too familiar with the mst code, but I wonder if we were
> > exceeding the bandwidth limits in some setups and it just happened
> > to
> > work, but now that we enforcing them, they don't which is correct,
> > but
> > a regression from some users' perspective?
> 
> I seriously doubt that is the case according to:
> https://support.lenovo.com/nl/en/solutions/pd029622
> 
> The gen 2 tb3 dock can handle 2 external
> displays at 3840*2160@60Hz together with the internal
> panel being on and both my external displays run at
> 1920x1080@60 so I'm consuming less then half of the
> maximum bandwidth.
> 
> There definitely is a bug somewhere in the
> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> atomic check")
> commit (or somewhere else and triggered by that commit).
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
> 
> > Alex
> > 
> > 
> > > Regards,
> > > 
> > > Hans
> > > 
> > > 
> > > 
> > > 
> > > > > 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
> > > > > 
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Mikita Lipski]

On 2/26/20 6:41 PM, Souza, Jose wrote:
> Hi Hans
> 
> Just commenting in the "[    3.309061] [drm:intel_dump_pipe_config
> [i915]] MST master transcoder: <invalid>" message, it is the expected
> behaviour for anything older than Tigerlake, from TGL+ this will be set
> in MST mode.
> 
> On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 2/26/20 5:05 PM, Alex Deucher wrote:
>>> On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com
>>>> wrote:
>>>> Hi,
>>>>
>>>> On 2/26/20 4:29 PM, Alex Deucher wrote:
>>>>> On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <
>>>>> hdegoede@redhat.com> 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.
>>>>>
>>>>> Might be a duplicate of:
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2Fissues%2F1052&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=AKmPhCqvvKtgzDBaobU4g74bErQQ7O3aL%2FJ8Al2Ey2I%3D&amp;reserved=0
>>>>
>>>> Looks like you are right, reverting the commit which the bisect
>>>> from that issue points to:
>>>>
>>>> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
>>>> atomic check")
>>>>
>>>> Fixes the issue for me. I will add a comment to the issue.
>>>>
>>>> Note I'm using integrated Intel gfx, so that means that this
>>>> issue
>>>> definitely is not amdgpu specific.
>>>>
>>>
>>> I'm not too familiar with the mst code, but I wonder if we were
>>> exceeding the bandwidth limits in some setups and it just happened
>>> to
>>> work, but now that we enforcing them, they don't which is correct,
>>> but
>>> a regression from some users' perspective?
>>
>> I seriously doubt that is the case according to:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.lenovo.com%2Fnl%2Fen%2Fsolutions%2Fpd029622&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=64uP50QojK2HkemDq3EGNKCVEgVl1ZxucyI%2F%2Bkk2Ng0%3D&amp;reserved=0
>>
>> The gen 2 tb3 dock can handle 2 external
>> displays at 3840*2160@60Hz together with the internal
>> panel being on and both my external displays run at
>> 1920x1080@60 so I'm consuming less then half of the
>> maximum bandwidth.
>>
>> There definitely is a bug somewhere in the
>> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
>> atomic check")
>> commit (or somewhere else and triggered by that commit).
>>
>> Regards,
>>
>> Hans

+ Lin Wyane, Lyude Paul

Hi,

Sorry I'm late responding to the thread.
The reason why this issue could have missed is because this patch was 
pushed as a part of DSC MST patch series and with DSC the pbn is much 
lower so it wouldn't fail this check.

Anyways this check might have exposed a different bug in DRM. It seems 
like the variable of available_pbn doesn't get updated on the ports in 
the topology so the calculation of branch's bandwidth limit is not 
correct, which would cause a branch bandwidth to be bottle-necked by 
pbn_limit variable.
 From DP 1.4 standart it seems like DRM should update available_pbn on 
each port, when processing RESOURCE_STATUS_NOTIFY sideband message when 
topology changes. Right now DRM doesn't seem to be doing anything about 
it. Was it the intention, or has it just never implemented? If it the 
intention, then the patch should be reverted till a new solution is 
delivered, otherwise it should be treated as a bug exposed by a branch 
bandwidth check.
I would appreciate any suggestions.

Thanks,
Mikita

>>
>>
>>
>>
>>
>>
>>
>>> Alex
>>>
>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>>
>>>>>> 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://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Ffedorapeople.org%2F~jwrdegoede%2Fdrm-debug.log&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=eHPlfCRZXIPp9O%2B9CHvwb1kg5ffIhO%2FFFgwTcuWFKHM%3D&amp;reserved=0
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> dri-devel mailing list
>>>>>> dri-devel@lists.freedesktop.org
>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&amp;reserved=0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&amp;reserved=0

-- 
Thanks,
Mikita Lipski
Software Engineer 2, AMD
mikita.lipski@amd.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Lyude Paul]

On Thu, 2020-02-27 at 10:04 -0500, Mikita Lipski wrote:
> 
> On 2/26/20 6:41 PM, Souza, Jose wrote:
> > Hi Hans
> > 
> > Just commenting in the "[    3.309061] [drm:intel_dump_pipe_config
> > [i915]] MST master transcoder: <invalid>" message, it is the expected
> > behaviour for anything older than Tigerlake, from TGL+ this will be set
> > in MST mode.
> > 
> > On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 2/26/20 5:05 PM, Alex Deucher wrote:
> > > > On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com
> > > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > On 2/26/20 4:29 PM, Alex Deucher wrote:
> > > > > > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <
> > > > > > hdegoede@redhat.com> 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.
> > > > > > 
> > > > > > Might be a duplicate of:
> > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2Fissues%2F1052&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=AKmPhCqvvKtgzDBaobU4g74bErQQ7O3aL%2FJ8Al2Ey2I%3D&amp;reserved=0
> > > > > 
> > > > > Looks like you are right, reverting the commit which the bisect
> > > > > from that issue points to:
> > > > > 
> > > > > cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > > > atomic check")
> > > > > 
> > > > > Fixes the issue for me. I will add a comment to the issue.
> > > > > 
> > > > > Note I'm using integrated Intel gfx, so that means that this
> > > > > issue
> > > > > definitely is not amdgpu specific.
> > > > > 
> > > > 
> > > > I'm not too familiar with the mst code, but I wonder if we were
> > > > exceeding the bandwidth limits in some setups and it just happened
> > > > to
> > > > work, but now that we enforcing them, they don't which is correct,
> > > > but
> > > > a regression from some users' perspective?
> > > 
> > > I seriously doubt that is the case according to:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.lenovo.com%2Fnl%2Fen%2Fsolutions%2Fpd029622&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=64uP50QojK2HkemDq3EGNKCVEgVl1ZxucyI%2F%2Bkk2Ng0%3D&amp;reserved=0
> > > 
> > > The gen 2 tb3 dock can handle 2 external
> > > displays at 3840*2160@60Hz together with the internal
> > > panel being on and both my external displays run at
> > > 1920x1080@60 so I'm consuming less then half of the
> > > maximum bandwidth.
> > > 
> > > There definitely is a bug somewhere in the
> > > cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > atomic check")
> > > commit (or somewhere else and triggered by that commit).
> > > 
> > > Regards,
> > > 
> > > Hans
> 
> + Lin Wyane, Lyude Paul
> 
> Hi,
> 
> Sorry I'm late responding to the thread.
> The reason why this issue could have missed is because this patch was 
> pushed as a part of DSC MST patch series and with DSC the pbn is much 
> lower so it wouldn't fail this check.
> 
> Anyways this check might have exposed a different bug in DRM. It seems 
> like the variable of available_pbn doesn't get updated on the ports in 
> the topology so the calculation of branch's bandwidth limit is not 
> correct, which would cause a branch bandwidth to be bottle-necked by 
> pbn_limit variable.
>  From DP 1.4 standart it seems like DRM should update available_pbn on 
> each port, when processing RESOURCE_STATUS_NOTIFY sideband message when 
> topology changes. Right now DRM doesn't seem to be doing anything about 
> it. Was it the intention, or has it just never implemented? If it the 
> intention, then the patch should be reverted till a new solution is 
> delivered, otherwise it should be treated as a bug exposed by a branch 
> bandwidth check.
> I would appreciate any suggestions.

This was definitely something on my to-do list to implement but I never got
around to it, and your explanation of the problem makes perfect sense to me so
this would probably be the place to start. Thanks for looking into this while
I was gone!

> 
> Thanks,
> Mikita
> 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > Alex
> > > > 
> > > > 
> > > > > Regards,
> > > > > 
> > > > > Hans
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > 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://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Ffedorapeople.org%2F~jwrdegoede%2Fdrm-debug.log&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=eHPlfCRZXIPp9O%2B9CHvwb1kg5ffIhO%2FFFgwTcuWFKHM%3D&amp;reserved=0
> > > > > > > 
> > > > > > > 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
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > dri-devel mailing list
> > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&amp;reserved=0
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Cmikita.lipski%40amd.com%7Ca48e7470afee41cb208508d7bb155ad0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183572706454329&amp;sdata=im2LrBE%2BgjCL%2FN4%2B%2BZOOu6Eci5SuaZrT8l3mOuDRQH0%3D&amp;reserved=0
-- 
Cheers,
	Lyude Paul (she/her)
	Associate Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Lyude Paul]

On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
> 
> On 2/26/20 5:05 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com>
> > wrote:
> > > Hi,
> > > 
> > > On 2/26/20 4:29 PM, Alex Deucher wrote:
> > > > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com>
> > > > 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.
> > > > 
> > > > Might be a duplicate of:
> > > > https://gitlab.freedesktop.org/drm/amd/issues/1052
> > > 
> > > Looks like you are right, reverting the commit which the bisect
> > > from that issue points to:
> > > 
> > > cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic
> > > check")
> > > 
> > > Fixes the issue for me. I will add a comment to the issue.
> > > 
> > > Note I'm using integrated Intel gfx, so that means that this issue
> > > definitely is not amdgpu specific.
> > > 
> > 
> > I'm not too familiar with the mst code, but I wonder if we were
> > exceeding the bandwidth limits in some setups and it just happened to
> > work, but now that we enforcing them, they don't which is correct, but
> > a regression from some users' perspective?
> 
> I seriously doubt that is the case according to:
> https://support.lenovo.com/nl/en/solutions/pd029622
> 
> The gen 2 tb3 dock can handle 2 external
> displays at 3840*2160@60Hz together with the internal
> panel being on and both my external displays run at
> 1920x1080@60 so I'm consuming less then half of the
> maximum bandwidth.

OK-so I wasn't actually able to reproduce this issue with my setup (I've got a
X1 Carbon 7th generation, but I don't have the 2nd generation dock - only the
first generation dock) but I'm certain I've actually fixed it now, since I
realized we did not have a very good understanding of how PBN limitations are
advertised with MST. I rewrote the bandwidth checks again, and in the process
also found a much more subtle regression that got introduced in 5.6, which
would sometimes cause MST probing to appear to just stop in it's tracks with
no messages.

I cc'd both patch series to you, so I'd recommend applying them both onto your
kernel and seeing if that fixes your issues. If it still doesn't, then get me
some kernel logs with:

drm.debug=0x116 log_buf_len=50M

And I'll take a closer look. I'm pretty confident this should fix everything
though :)

> 
> There definitely is a bug somewhere in the
> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic
> check")
> commit (or somewhere else and triggered by that commit).
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
> 
> > Alex
> > 
> > 
> > > Regards,
> > > 
> > > Hans
> > > 
> > > 
> > > 
> > > 
> > > > > 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
> > > > > 
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Cheers,
	Lyude Paul (she/her)
	Associate Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Hans de Goede]

Hi Lyude,

On 3/7/20 12:54 AM, Lyude Paul wrote:
> On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 2/26/20 5:05 PM, Alex Deucher wrote:
>>> On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede <hdegoede@redhat.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> On 2/26/20 4:29 PM, Alex Deucher wrote:
>>>>> On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede <hdegoede@redhat.com>
>>>>> 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.
>>>>>
>>>>> Might be a duplicate of:
>>>>> https://gitlab.freedesktop.org/drm/amd/issues/1052
>>>>
>>>> Looks like you are right, reverting the commit which the bisect
>>>> from that issue points to:
>>>>
>>>> cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic
>>>> check")
>>>>
>>>> Fixes the issue for me. I will add a comment to the issue.
>>>>
>>>> Note I'm using integrated Intel gfx, so that means that this issue
>>>> definitely is not amdgpu specific.
>>>>
>>>
>>> I'm not too familiar with the mst code, but I wonder if we were
>>> exceeding the bandwidth limits in some setups and it just happened to
>>> work, but now that we enforcing them, they don't which is correct, but
>>> a regression from some users' perspective?
>>
>> I seriously doubt that is the case according to:
>> https://support.lenovo.com/nl/en/solutions/pd029622
>>
>> The gen 2 tb3 dock can handle 2 external
>> displays at 3840*2160@60Hz together with the internal
>> panel being on and both my external displays run at
>> 1920x1080@60 so I'm consuming less then half of the
>> maximum bandwidth.
> 
> OK-so I wasn't actually able to reproduce this issue with my setup (I've got a
> X1 Carbon 7th generation, but I don't have the 2nd generation dock - only the
> first generation dock) but I'm certain I've actually fixed it now, since I
> realized we did not have a very good understanding of how PBN limitations are
> advertised with MST. I rewrote the bandwidth checks again, and in the process
> also found a much more subtle regression that got introduced in 5.6, which
> would sometimes cause MST probing to appear to just stop in it's tracks with
> no messages.
> 
> I cc'd both patch series to you, so I'd recommend applying them both onto your
> kernel and seeing if that fixes your issues. If it still doesn't, then get me
> some kernel logs with:
> 
> drm.debug=0x116 log_buf_len=50M
> 
> And I'll take a closer look. I'm pretty confident this should fix everything
> though :)

I can confirm that the v2 series you posted fixes the problem of only of the 2
FHD monitors on my Lenovo TB3 gen 2 dock lighting up, thank you!

Regards,

Hans

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Lyude Paul]

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

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
> 
-- 
Cheers,
	Lyude Paul (she/her)
	Associate Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 5.6 DP-MST regression: 1 of 2 monitors on TB3 (DP-MST) dock no longer light up

[Hans de Goede]

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
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel