2020-02-17 20:10:12

by Dominik Brodowski

[permalink] [raw]
Subject: drm/bridge and lockup on boot

On my old Dell XPS 13 laptop with

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])

booting 5.6-rc1 and -rc2 fails after the dmesg line

fb0: switching to inteldrmfb from simple

while the next lines should be something like (v5.5):

Console: switching to colour dummy device 80x25
i915 0000:00:02.0: vgaarb: deactivate vga console
[drm] ACPI BIOS requests an excessive sleep of 25000 ms, using 1500 ms instead
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem

A git bisect lead to

commit b86d895524ab ("drm/bridge: Add an ->atomic_check() hook")

as the first bad commit, as unlikely as that sounds. f7619a58ef92 is good,
as is bf046007641a, and 3cacb2086e41 is definitely broken on my setup.
Any ideas?

Oh, and this might be the same issue as reported here:

https://lore.kernel.org/lkml/[email protected]/

though I do not see such a warning, but nothing new once the line "fb0: switching
to inteldrmfb from simple" is printed.

Thanks,
Dominik


2020-02-17 21:10:54

by Boris Brezillon

[permalink] [raw]
Subject: Re: drm/bridge and lockup on boot

On Mon, 17 Feb 2020 21:09:42 +0100
Dominik Brodowski <[email protected]> wrote:

> On my old Dell XPS 13 laptop with
>
> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
>
> booting 5.6-rc1 and -rc2 fails after the dmesg line
>
> fb0: switching to inteldrmfb from simple
>
> while the next lines should be something like (v5.5):
>
> Console: switching to colour dummy device 80x25
> i915 0000:00:02.0: vgaarb: deactivate vga console
> [drm] ACPI BIOS requests an excessive sleep of 25000 ms, using 1500 ms instead
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
>
> A git bisect lead to
>
> commit b86d895524ab ("drm/bridge: Add an ->atomic_check() hook")

This commit has been reverted: you should ignore any failures between
b86d895524ab ("drm/bridge: Add an ->atomic_check() hook") and
099126352303 ("Revert "drm/bridge: Add a drm_bridge_state object").

>
> as the first bad commit, as unlikely as that sounds. f7619a58ef92 is good,
> as is bf046007641a, and 3cacb2086e41 is definitely broken on my setup.
> Any ideas?
>
> Oh, and this might be the same issue as reported here:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> though I do not see such a warning, but nothing new once the line "fb0: switching
> to inteldrmfb from simple" is printed.
>
> Thanks,
> Dominik

2020-02-18 11:49:06

by Dominik Brodowski

[permalink] [raw]
Subject: lockup on boot -- drm/i915/display: Force the state compute phase once to enable PSR

On Mon, Feb 17, 2020 at 10:08:52PM +0100, Boris Brezillon wrote:
> On Mon, 17 Feb 2020 21:09:42 +0100
> Dominik Brodowski <[email protected]> wrote:
>
> > On my old Dell XPS 13 laptop with
> >
> > 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
> > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
> >
> > booting 5.6-rc1 and -rc2 fails after the dmesg line
> >
> > fb0: switching to inteldrmfb from simple
> >
> > while the next lines should be something like (v5.5):
> >
> > Console: switching to colour dummy device 80x25
> > i915 0000:00:02.0: vgaarb: deactivate vga console
> > [drm] ACPI BIOS requests an excessive sleep of 25000 ms, using 1500 ms instead
> > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [drm] Driver supports precise vblank timestamp query.
> > i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >
> > A git bisect lead to
> >
> > commit b86d895524ab ("drm/bridge: Add an ->atomic_check() hook")
>
> This commit has been reverted: you should ignore any failures between
> b86d895524ab ("drm/bridge: Add an ->atomic_check() hook") and
> 099126352303 ("Revert "drm/bridge: Add a drm_bridge_state object").

A new bisect now points to

60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR").

Please note that bisecting this is quite a hassle, in particular due to
various reverts in between and back-merges (such as ec027b33c8bb, which has
two parents in "bad" state). As 60c6a14b489b does not revert cleanly, I
can't test a revert on top of 5.6-rc2.

Thanks,
Dominik

2020-02-18 18:02:08

by José Roberto de Souza

[permalink] [raw]
Subject: Re: lockup on boot -- drm/i915/display: Force the state compute phase once to enable PSR

Hi

Yes this patch has a issue and we have a fix, I'm trying to find
someone to review it, more information:
https://gitlab.freedesktop.org/drm/intel/issues/1151

On Tue, 2020-02-18 at 12:48 +0100, Dominik Brodowski wrote:
> On Mon, Feb 17, 2020 at 10:08:52PM +0100, Boris Brezillon wrote:
> > On Mon, 17 Feb 2020 21:09:42 +0100
> > Dominik Brodowski <[email protected]> wrote:
> >
> > > On my old Dell XPS 13 laptop with
> > >
> > > 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge
> > > -OPI (rev 09)
> > > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics
> > > 5500 (rev 09) (prog-if 00 [VGA controller])
> > >
> > > booting 5.6-rc1 and -rc2 fails after the dmesg line
> > >
> > > fb0: switching to inteldrmfb from simple
> > >
> > > while the next lines should be something like (v5.5):
> > >
> > > Console: switching to colour dummy device 80x25
> > > i915 0000:00:02.0: vgaarb: deactivate vga console
> > > [drm] ACPI BIOS requests an excessive sleep of 25000 ms, using
> > > 1500 ms instead
> > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > [drm] Driver supports precise vblank timestamp query.
> > > i915 0000:00:02.0: vgaarb: changed VGA decodes:
> > > olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > >
> > > A git bisect lead to
> > >
> > > commit b86d895524ab ("drm/bridge: Add an ->atomic_check()
> > > hook")
> >
> > This commit has been reverted: you should ignore any failures
> > between
> > b86d895524ab ("drm/bridge: Add an ->atomic_check() hook") and
> > 099126352303 ("Revert "drm/bridge: Add a drm_bridge_state object").
>
> A new bisect now points to
>
> 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR").
>
> Please note that bisecting this is quite a hassle, in particular due
> to
> various reverts in between and back-merges (such as ec027b33c8bb,
> which has
> two parents in "bad" state). As 60c6a14b489b does not revert cleanly,
> I
> can't test a revert on top of 5.6-rc2.
>
> Thanks,
> Dominik

2020-02-18 18:59:27

by Dominik Brodowski

[permalink] [raw]
Subject: Re: lockup on boot -- drm/i915/display: Force the state compute phase once to enable PSR

On Tue, Feb 18, 2020 at 06:01:37PM +0000, Souza, Jose wrote:
> Hi
>
> Yes this patch has a issue and we have a fix, I'm trying to find
> someone to review it, more information:
> https://gitlab.freedesktop.org/drm/intel/issues/1151

Alas, that patch does not apply cleanly to -master.

Thanks,
Dominik

2020-03-01 15:17:23

by Dominik Brodowski

[permalink] [raw]
Subject: 5.5.6-rc1+: lockup on boot -- drm/i915/display: Force the state compute phase once to enable PSR

On Tue, Feb 18, 2020 at 07:58:47PM +0100, Dominik Brodowski wrote:
> On Tue, Feb 18, 2020 at 06:01:37PM +0000, Souza, Jose wrote:
> > Hi
> >
> > Yes this patch has a issue and we have a fix, I'm trying to find
> > someone to review it, more information:
> > https://gitlab.freedesktop.org/drm/intel/issues/1151
>
> Alas, that patch does not apply cleanly to -master.

Any update on this patch? It doesn't seem to have landed in -master yet,
though it solves a clear regression and without such a patch, my laptops
refuse to boot. So it'd be much appreciated if that patch (or a variant
thereof) is pushed upstream rather sooner than later.

Thanks,
Dominik