lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Feb 2020 22:08:52 +0100
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     narmstrong@...libre.com, laurent.pinchart@...asonboard.com,
        jernej.skrabec@...l.net, jonas@...boo.se,
        linux-kernel@...r.kernel.org
Subject: Re: drm/bridge and lockup on boot

On Mon, 17 Feb 2020 21:09:42 +0100
Dominik Brodowski <linux@...inikbrodowski.net> 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/99fb887f-4a1b-6c15-64a6-9d089773cdd4@4net.rs/
> 
> though I do not see such a warning, but nothing new once the line "fb0: switching
> to inteldrmfb from simple" is printed.
> 
> Thanks,
> 	Dominik

Powered by blists - more mailing lists