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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
