has the i915 "black screen" boot issue returned?

Robert P. J. Day rpjday at crashcourse.ca
Thu Jan 27 14:33:04 PST 2011


  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 at 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 at 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 at gmail.com>
>     Signed-off-by: Dave Airlie <airlied at 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 at 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 at 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
========================================================================


More information about the dri-devel mailing list