[REGRESSION] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Chris Wilson]

On Wed, May 17, 2017 at 11:29:13PM +0200, Nicolai Stange wrote:
> Hi,
> 
> my system (always) locks up when booting a next-20170515 kernel.
> 
> No oops. Sending magic sysrqs over serial doesn't cause any reaction.
> 
> Last few console messages before death are:
> 
>   [    7.089221] Console: switching to colour frame buffer device 128x48
>   [    7.101470] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
>   [    7.111292] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 1
>   [    7.113056] [drm] Initialized i915 1.6.0 20170403 for 0000:00:02.0 on minor 0
>   [    7.113446] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
>   [    7.114227] ACPI: Video Device [PEGP] (multi-head: yes  rom: no  post: no)
>   [    7.114798] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4f/LNXVIDEO:00/input/input12
>   [    7.116253] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
>   [    7.130432] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input13
>   [    7.130481] [drm] Initialized i915 1.6.0 20170403 for 0000:00:02.0 on minor 0
> 
> 
> Bisection lead to commit 25112b64b3d2 ("drm/i915: Wait for all engines
> to be idle as part of i915_gem_wait_for_idle()"). Reverting this commit
> on top of next-20170515 fixes the issue for me.

That's really odd as it adds a loop around a previous used function with
a timeout. If the timeout is hit, we get a loud bang, but nothing that
should take the machine out, just one portion of the driver.

drm.debug=0xff would be one step to see more breadcrumbs prior to
death. Did you enable the i915 debugging? I hope not, we tried walling
it off to prevent it being accidentally enabled... Otherwise, it looks
like we need a bit of printk debugging to work out just what it doesn't
like.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre