Re: has the i915 "black screen" boot issue returned?

[Chris Wilson <chris@chris-wilson.co.uk>]

On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
> 
>   one more observation which should nail things down:
> 
> On Thu, 27 Jan 2011, Robert P. J. Day wrote:
> 
> >   ok, i'm getting different results from this morning, not sure why,
> > but i'm fairly confident i've isolated it to this extent.  here's the
> > salient part of the git log i'm looking at:
> >
> > ===== git log =====
> >
> > commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
> > Merge: 58bbf01 8e934db
> > Author: Dave Airlie <airlied@gmail.com>
> > Date:   Tue Jan 25 08:41:58 2011 +1000
> >
> >     Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/g
> >
> >     * 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr
> >       drm/i915: Prevent uninitialised reads during error state capture
> >       drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >       drm/i915: Handle the no-interrupts case for UMS by polling
> >       drm/i915: Disable high-precision vblank timestamping for UMS
> >       drm/i915: Increase the amount of defense before computing vblank timestamps
> >       drm/i915,agp/intel: Do not clear stolen entries
> >       Remove MAYBE_BUILD_BUG_ON
> >       BUILD_BUG_ON: make it handle more cases
> >       module: fix missing semicolons in MODULE macro usage
> >       param: add null statement to compiled-in module params
> >       module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n
> >       module: show version information for built-in modules in sysfs
> >       selinux: return -ENOMEM when memory allocation fails
> >       tpm: fix panic caused by "tpm: Autodetect itpm devices"
> >       TPM: Long default timeout fix
> >       trusted keys: Fix a memory leak in trusted_update().
> >       keys: add trusted and encrypted maintainers
> >       encrypted-keys: rename encrypted_defined files to encrypted
> >       trusted-keys: rename trusted_defined files to trusted
> >       drm/i915: Recognise non-VGA display devices
> >       ...
> >
> > commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
> > Author: Alex Deucher <alexdeucher@gmail.com>
> > Date:   Mon Jan 24 17:14:26 2011 -0500
> >
> >     drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
> >
> >     Needed for timer queries in the 3D driver.
> >
> >     Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
> >     Signed-off-by: Dave Airlie <airlied@gmail.com>
> >
> > ===== git log =====
> >
> > now:
> >
> >   * commit 58bbf018 appears to be fine, boots reliably
> >   * commit 8e934dbf causes black screen issue
> >
> > as you can see, rather than test the *merge* above, i decided to back
> > up one level and test the commit that was part of that merge, and it
> > failed.  is this helpful?  here's the log entry:
> >
> > commit 8e934dbf264418afe4d1dff34ce074ecc14280db
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Mon Jan 24 12:34:00 2011 +0000
> >
> >     drm/i915: Prevent uninitialised reads during error state capture
> >
> >     error_bo and pinned_bo could be used uninitialised if there were no
> >     active buffers.
> >
> >     Caught by kmemcheck.
> >
> >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >
> >
> >   i'm going to go on and test the merge itself, abb72c82, since i
> > thought that was working fine earlier today.  but you can see which
> > commit now seems to fail.  does this make any sense?
> 
>   i did indeed test commit abb72c82 (the merge of the above), and it
> failed.  not sure why i posted earlier today that it worked, i must
> have built something incorrectly.  so, in conclusion:
> 
>   * commit 58bbf018 appears to be fine, boots reliably
>   * commit 8e934dbf causes black screen issue
>   * commit abb72c82 also causes black screen issue
> 
> and on that note, signing off for the evening.
> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                               Waterloo, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: has the i915 "black screen" boot issue returned?
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: dri-devel@lists.freedesktop.org
Bcc: chris@chris-wilson.co.uk
In-Reply-To: <alpine.DEB.2.00.1101271634260.2761@localhost6.localdomain6>
References: <alpine.DEB.2.00.1101260634300.10774@localhost6.localdomain6> <b9dded$hp9kfu@orsmga002.jf.intel.com> <alpine.DEB.2.00.1101270641490.2923@localhost6.localdomain6> <b9dded$hpa5rf@orsmga002.jf.intel.com> <alpine.DEB.2.00.1101270710510.17636@localhost6.localdomain6> <1bdc18$jdgfni@fmsmga002.fm.intel.com> <alpine.DEB.2.00.1101270840380.2736@localhost6.localdomain6> <0d30dc$ksovh8@orsmga001.jf.intel.com> <alpine.DEB.2.00.1101270854420.4898@localhost6.localdomain6> <b7da2f$q8lpcn@fmsmga001.fm.intel.com> <alpine.DEB.2.00.1101271634260.2761@localhost6.localdomain6>

On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>   ok, i'm getting different results from this morning, not sure why,
> but i'm fairly confident i've isolated it to this extent.  here's the
> salient part of the git log i'm looking at:

Well, we have two endpoints, so let git attack:

$ git bisect start
$ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
$ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e

That shouldn't take more than a few recompiles to identify the
troublemaker.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre