On Thu, 27 Jan 2011 17:33:04 -0500 (EST), "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> 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@xxxxxxxxx> > > 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@xxxxxxxxx> > > 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@xxxxxxxxx> > > Signed-off-by: Dave Airlie <airlied@xxxxxxxxx> > > > > ===== 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@xxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxxxxx> Subject: Re: has the i915 "black screen" boot issue returned? To: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx Bcc: chris@xxxxxxxxxxxxxxxxxx In-Reply-To: <alpine.DEB.2.00.1101271634260.2761@xxxxxxxxxxxxxxxxxxxxxxx> References: <alpine.DEB.2.00.1101260634300.10774@xxxxxxxxxxxxxxxxxxxxxxx> <b9dded$hp9kfu@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101270641490.2923@xxxxxxxxxxxxxxxxxxxxxxx> <b9dded$hpa5rf@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101270710510.17636@xxxxxxxxxxxxxxxxxxxxxxx> <1bdc18$jdgfni@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101270840380.2736@xxxxxxxxxxxxxxxxxxxxxxx> <0d30dc$ksovh8@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101270854420.4898@xxxxxxxxxxxxxxxxxxxxxxx> <b7da2f$q8lpcn@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101271634260.2761@xxxxxxxxxxxxxxxxxxxxxxx> On Thu, 27 Jan 2011 16:39:20 -0500 (EST), "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
