On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" <rpjday at 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 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 > ======================================================================== From: Chris Wilson <ch...@chris-wilson.co.uk> Subject: Re: has the i915 "black screen" boot issue returned? To: "Robert P. J. Day" <rpjday at crashcourse.ca> Cc: dri-devel at lists.freedesktop.org Bcc: chris at chris-wilson.co.uk In-Reply-To: <alpine.DEB.2.00.1101271634260.2761 at localhost6.localdomain6> References: <alpine.DEB.2.00.1101260634300.10774 at localhost6.localdomain6> <b9dded$hp9kfu at orsmga002.jf.intel.com> <alpine.DEB.2.00.1101270641490.2923 at localhost6.localdomain6> <b9dded$hpa5rf at orsmga002.jf.intel.com> <alpine.DEB.2.00.1101270710510.17636 at localhost6.localdomain6> <1bdc18$jdgfni at fmsmga002.fm.intel.com> <alpine.DEB.2.00.1101270840380.2736 at localhost6.localdomain6> <0d30dc$ksovh8 at orsmga001.jf.intel.com> <alpine.DEB.2.00.1101270854420.4898 at localhost6.localdomain6> <b7da2f$q8lpcn at fmsmga001.fm.intel.com> <alpine.DEB.2.00.1101271634260.2761 at localhost6.localdomain6>
On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" <rpjday at 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
