[Intel-gfx] i915 / 3.15 intermittently boots into blank screeen

Wed Jul 30 19:39:00 CEST 2014

Am 30.07.2014 11:33, schrieb Daniel Vetter:
> On Wed, Jul 30, 2014 at 12:01:38AM +0200, Jan Niggemann wrote:
>> Am 29.07.2014 23:35, schrieb Daniel Vetter:
>> >On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann <jn at hz6.de> wrote:
>> >>Am 18.07.2014 18:25, schrieb Daniel Vetter:
>> >>>
>> >>>On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann <jn at hz6.de> wrote:
>> >>>
>> >>>>
>> >>>>Am 18.07.2014 15:27, schrieb Daniel Vetter:
>> >>>>>
>> >>>>>
>> >>>>>On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>I'm experiencing an issue with 3.15.5 on my Lenovo T400:
>> >>>>>>Since 3.15 (or 3.14, can't say for sure), the boot starts
>> >>>>>>normally, but
>> >>>>>>the
>> >>>>>>first mode change doesn't occur, resulting in a black screen
>> >>>>>>with
>> >>>>>>backlight
>> >>>>>>on. The system is entirely unresponsive and I can only press 
>> the
>> >>>>>>power
>> >>>>>>button until to switch it off.
>> >>>>>
>> >>>>>
>> >>>>>I think the only way to move forward here is to double-check 
>> that
>> >>>>>3.14
>> >>>>>
>> >>>>>works and 3.15 is broken by recompiling with the same .config
>> >>>>>(occasionally config changes cause regressions). And then do a
>> >>>>>full git
>> >>>>>bisect to find the offending commit.
>> >>>>
>> >>>>
>> >>>>thank you for the feedback.
>> >>>>I still have all my custom built kernels, I will test 3.14.0 
>> through
>> >>>>3.14.8
>> >>>>to make sure those were OK and report back.
>> >>>
>> >>>
>> >>>You only need to test 3.14.0, since the backported fixes only 
>> contain
>> >>>a very small subset of all patches for 3.15. So it's more 
>> efficient to
>> >>>then switch to git bisect between 3.14 and 3.15 directly (after 
>> you've
>> >>>confirmed that 3.15.0 is indeed busted).
>> >>
>> >>I familiarized with git bisect, that was something I had never 
>> used
>> >>before.
>> >>
>> >>I started it with "git bisect start v3.15 v3.14 -- 
>> drivers/gpu/drm/i915"
>> >>
>> >>This lead me to this:
>> >>
>> >>cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit
>> >>commit cfa7c862982b431add7f2b362526bf31372fc7b0
>> >>Author: Daniel Vetter <daniel.vetter at ffwll.ch>
>> >>Date:   Tue Apr 29 11:53:58 2014 +0200
>> >>
>> >>    drm/i915: Sanitize the enable_ppgtt module option once
>> >>
>> >>    Otherwise we'll end up spamming dmesg on every context 
>> creation on
>> >>snb
>> >>    with vt-d enabled. This regression was introduced in
>> >>
>> >>    commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
>> >>    Author: Ben Widawsky <benjamin.widawsky at intel.com>
>> >>    Date:   Fri Dec 6 14:11:14 2013 -0800
>> >>
>> >>        drm/i915: Reorganize intel_enable_ppgtt
>> >>
>> >>    As the i915.enable_ppgtt is read-only it cannot be changed 
>> after the
>> >>    module is loaded and so we can perform an early sanitization 
>> of the
>> >>    values.
>> >>
>> >>    v2:
>> >>    - Add comment and pimp commit message (Chris)
>> >>    - Use the param consistently (Jani)
>> >>
>> >>    v3:
>> >>    - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt 
>> call to
>> >>      gtt_init. Fixes boot hangs on pre-gen6.
>> >>    - Add a debug output for the sanitize ppgtt mode.
>> >>
>> >>    References: https://lkml.org/lkml/2014/4/17/599
>> >>    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916
>> >>    Cc: Alessandro Suardi <alessandro.suardi at gmail.com>
>> >>    Cc: Ben Widawsky <ben at bwidawsk.net>
>> >>    Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> >>    Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
>> >>    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>> >>    Signed-off-by: Jani Nikula <jani.nikula at intel.com>
>> >>
>> >>:040000 040000 5488e397a1aaa28dca4a252452e9463b0a8f8d10
>> >>214c8e98b3c72844e48ab7aef02cba7daf139fab M      drivers
>> >>
>> >>I realized that the issue does always show, contrary to the 
>> subject
>> >>initially chosen.
>> >>
>> >>Unfortunately I can't say anything else, but maybe this will help 
>> you
>> >>experts spot the issue.
>> >>If I can help more, be it with testing or anything else, just let 
>> me
>> >>know.
>> >
>> >Hm, I'm not aware of this breaking any gm45 machines, mine here is
>> >still happy. Can you please make sure that you don't have any i915
>> >module options set anywhere, either on the kernel cmdline, 
>> modeprobe
>> >config files in /etc or anywhere else?
>> My kernel cmdline doesn't have anything, but 
>> /etc/modprobe.d/i915-kms.conf
>> exists. Its content is this single line: options i915 modeset=1
>> Can't remember if I created that (it's from 2010) or if it's Debian
>> default...
>> grep -Ri i915 /etc/ doesn't show anything else.
>>
>> grep 915 config-3.15
>> CONFIG_DRM_I915=m
>> CONFIG_DRM_I915_KMS=y
>> CONFIG_DRM_I915_FBDEV=y
>> # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
>> # CONFIG_DRM_I915_UMS is not set
>> CONFIG_SND_HDA_I915=y
>>
>> Would it help if I included the driver instead of building a module?
> Shouldn't change anything really, and config all looks sane.
Didn't change anything indeed.

> Can you
> please retest with latest upstream (3.16 or even drm-intel-nightly)?
Retested with drm-intel-nightly, this comes to a halt just before the 
first modeswitch.
At least the screen didn't become blank - it displays:
ACPI Warning: SystemIO range 0x00001028-0x0000102f conflicts with 
OpRegion 0x00001000-0x0000107f (\SB_.PCI0.LPC_.PMIO) 
(20140424/utaddress-258)
ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver.

ACPI Warning: SystemIO range 0x000011b0-0x000011bf conflicts with 
OpRegion 0x00001180-0x000011ff (\SB_.PCI0.LPC_.PMIO) 
(20140424/utaddress-258)
ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver.

ACPI Warning: SystemIO range 0x00001180-0x000011af conflicts with 
OpRegion 0x00001180-0x000011ff (\SB_.PCI0.LPC_.PMIO) 
(20140424/utaddress-258)
ACPI: If an ACPI driver is available for this device, you should use it 
instead of the native driver.
lpc_ich: Resource conflict(s) found affecting gpio_ich

Jan