On Tue, 24 Aug 2010 09:49:02 +0100, Sitsofe Wheeler sitsofe@yahoo.com wrote:
On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
Ok, I'm a little happier that the hangcheck could be just another symptom of the problem...
I think it is safe to assume that the bug is in i915, so restricting the bisect to just drm seems plausible:
git bisect start drivers/gpu/drm git bisect good 2.6.36-rc1 git bisect bad 2.6.36-rc2
I should mention that I ran a similar bisect yesterday but it led to a dead end:
[snip]
All the bad kernels above boot EXTREMELY slowly and it's not clear why. Using the results above to run your tests produced the following:
I was hoping that git would be more intelligent than that. Is there a way to simply bisect down one side of a merge?
The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde. A trivial patch you can apply on each step is:
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 33dbcc4..88f3b6c 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -837,7 +837,7 @@ static int hpet_clocksource_register(void) * cyc/sec = FSEC_PER_SEC/hpet_period(fsec/cyc) * cyc/sec = (FSEC_PER_NSEC * NSEC_PER_SEC)/hpet_period */ - hpet_freq = FSEC_PER_NSEC * NSEC_PER_SEC; + hpet_freq = (u64) FSEC_PER_NSEC * NSEC_PER_SEC; do_div(hpet_freq, hpet_period); clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq);