Andrew Morton wrote: > On Fri, 22 Aug 2008 19:16:51 +0200 > Petr Baudis <pasky@xxxxxxx> wrote: > >> On Fri, Aug 22, 2008 at 09:25:49AM -0700, Andrew Morton wrote: >>> On Fri, 22 Aug 2008 11:37:33 -0400 "Alan D. Brunelle" <Alan.Brunelle@xxxxxx> wrote: >>> >>>> I /did/ bisect it down to the aforementioned merge, the question is: How >>>> to crack open that merge into it's composite pieces? (Where do I go to >>>> bisect within that?) >>> urgh, it's irritating when git-bisect directs you to a merge commit - it >>> hasn't done it for me for ages. >> Hmm, but doesn't that happen only when it's actually really the merge >> commit that introduces the bug? Both parents of the merge commit were >> marked as good by the user, so... > > A merge commit doesn't contain any kernel changes? It's the individual > commits (aka "patches") which were in that merge which broke stuff. > Confused. > > We're trying to dive inside that merge commit to find out which of the > real commits caused the regression. > >>> One (probably wrong) approach is to run >>> >>> gitk 1c89ac55017f982355c7761e1c912c88c941483d >>> >>> then peer at the output, work out which real commits were in that >>> merge. >>> >>> It looks like the merge ended with >>> b1b135c8d619cb2c7045d6ee4e48375882518bb5 and started with >>> 40c42076ebd362dc69210cccea101ac80b6d4bd4, so perhaps you can do >>> >>> git bisect bad b1b135c8d619cb2c7045d6ee4e48375882518bb5 >>> git bisect good 40c42076ebd362dc69210cccea101ac80b6d4bd4 >> ...I don't quite get this - according to the bisection log, >> >> # good: [b1b135c8d619cb2c7045d6ee4e48375882518bb5] fix spinlock recursion in hvc_console >> >> and now you want to mark it as bad? > > <what bisection log?> > > I assume that Alan's bisection search ended up saying that the merge > commit (1c89ac55017f982355c7761e1c912c88c941483d) was the first bad > commit. > > Now I don't know what's going on. > >> You could try to revert some of the merged commits at the point of the >> merge, though. You're right - this is where the bisection ended up (in fact, just removing this merge commit allowed later kernels to boot just fine). I've patched the kernel w/ your suggestion, and now I'm getting something a bit different - and I'm looking into this... Begin: Loading essential drivers... ... [ 6.594525] fuse init (API version 7.9) [ 6.618686] ACPI: SSDT CFFD0D0A, 08C4 (r1 HPQOEM CPU_TM2 1 MSFT 100000E) [ 6.621481] BUG: unable to handle kernel NULL pointer dereference at 0000000000000858 [ 6.625017] IP: [<ffffffff8025e282>] debug_mutex_add_waiter+0x32/0x80 [ 6.625017] PGD 21a456067 PUD 21a45f067 PMD 0 [ 6.625017] Oops: 0002 [1] SMP [ 6.625017] CPU 1 [ 6.625017] Modules linked in: processor(+) fan thermal_sys fuse [ 6.625017] Pid: 1259, comm: modprobe Not tainted 2.6.27-rc3 #24 [ 6.625017] RIP: 0010:[<ffffffff8025e282>] [<ffffffff8025e282>] debug_mutex_add_waiter+0x32/0x80 [ 6.625017] RSP: 0018:ffff88021a073998 EFLAGS: 00010002 [ 6.625017] RAX: 0000000000000000 RBX: ffff88021a0739d8 RCX: 0000000000000000 [ 6.625017] RDX: 0000000000000001 RSI: ffff88021a0739d8 RDI: ffffffffa0091a60 [ 6.625017] RBP: ffff88021a0739b8 R08: ffffffff811deea0 R09: ffff8800a6fdb000 [ 6.625017] R10: ffffffffa008f524 R11: 0000000000000000 R12: ffffffffa0091a60 [ 6.625017] R13: ffff88021a072000 R14: ffff88021a9840a0 R15: ffffffffa0091a98 [ 6.625017] FS: 00007f40ce2de6e0(0000) GS:ffff88022fc02a00(0000) knlGS:0000000000000000 [ 6.625017] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 6.625017] CR2: 0000000000000858 CR3: 000000022d86b000 CR4: 00000000000006e0 [ 6.625017] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6.625017] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 6.625017] Process modprobe (pid: 1259, threadinfo ffff88021a072000, task ffff88021a9840a0) [ 6.625017] Stack: 0000000000000000 ffffffffa0091a60 0000000000000246 ffffffffa008f524 [ 6.625017] ffff88021a073a38 ffffffff8049f556 ffffffffa008f524 ffffffffa0091a18 [ 6.625017] ffff88021a0739d8 ffff88021a0739d8 1111111111111111 1111111111111111 [ 6.625017] Call Trace: [ 6.625017] [<ffffffffa008f524>] ? get_idr+0x44/0xa0 [thermal_sys] [ 6.625017] [<ffffffff8049f556>] mutex_lock_nested+0xa6/0x250 [ 6.625017] [<ffffffffa008f524>] ? get_idr+0x44/0xa0 [thermal_sys] [ 6.625017] [<ffffffff80363584>] ? idr_pre_get+0x44/0x90 [ 6.625017] [<ffffffffa008f524>] get_idr+0x44/0xa0 [thermal_sys] [ 6.625017] [<ffffffffa008fe43>] thermal_cooling_device_register+0x83/0x250 [thermal_sys] [ 6.625017] [<ffffffffa019b2a3>] acpi_processor_start+0x64b/0x774 [processor] [ 6.625017] [<ffffffff8031a90b>] ? __sysfs_add_one+0x6b/0xa0 [ 6.625017] [<ffffffff8031b9fc>] ? sysfs_do_create_link+0xbc/0x150 [ 6.625017] [<ffffffff803a7f1e>] acpi_start_single_object+0x2d/0x52 [ 6.625017] [<ffffffff803a9516>] acpi_device_probe+0x7e/0x92 [ 6.625017] [<ffffffff803dd3ab>] driver_probe_device+0x9b/0x1a0 [ 6.625017] [<ffffffff803dd536>] __driver_attach+0x86/0x90 [ 6.625017] [<ffffffff803dd4b0>] ? __driver_attach+0x0/0x90 [ 6.625017] [<ffffffff803dc8fd>] bus_for_each_dev+0x5d/0x90 [ 6.625017] [<ffffffff803dd1ec>] driver_attach+0x1c/0x20 [ 6.625017] [<ffffffff803dcf39>] bus_add_driver+0x1e9/0x260 [ 6.625017] [<ffffffffa0222000>] ? acpi_processor_init+0x0/0x107 [processor] [ 6.625017] [<ffffffff803dd70f>] driver_register+0x5f/0x140 [ 6.625017] [<ffffffffa0222000>] ? acpi_processor_init+0x0/0x107 [processor] [ 6.625017] [<ffffffff803a9826>] acpi_bus_register_driver+0x3e/0x40 [ 6.625017] [<ffffffffa0222094>] acpi_processor_init+0x94/0x107 [processor] [ 6.625017] [<ffffffff80209040>] _stext+0x40/0x180 [ 6.625017] [<ffffffff802a88d1>] ? __vunmap+0xa1/0x110 [ 6.625017] [<ffffffff80267642>] sys_init_module+0x142/0x1dc0 [ 6.625017] [<ffffffff80367ad6>] ? __up_read+0x46/0xb0 [ 6.625017] [<ffffffff8048e530>] ? cpu_down+0x0/0x70 [ 6.625017] [<ffffffff8020c34b>] system_call_fastpath+0x16/0x1b [ 6.625017] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
