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@xxxxxx> wrote: > >>Am 18.07.2014 18:25, schrieb Daniel Vetter: > >>> > >>>On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann <jn@xxxxxx> 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@xxxxxxxx> > >>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@xxxxxxxxx> > >> 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@xxxxxxxxx> > >> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > >> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx> > >> > >>: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. Can you please retest with latest upstream (3.16 or even drm-intel-nightly)? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
