Bug#493479: linux-image-2.6.26-1-amd64: Bisecting complete, and LKML message sent
> Bisecting. See http://kerneltrap.org/node/11753.
OK, I bisected from 1 PM to 6 PM today. I ended up building 16 kernels
which would have seemed like a LOT, except for how many I built on
Saturday night and all day Sunday!
I used my custom '.config', instead of the enormous Debian stock
config, in order to save time. If I ever do bisecting again, I will cut
a lot of unnecessary stuff out of my config so that the builds take even
less time.
Each build only takes me 5 minutes, luckily, because the machine with
the problem has an AMD Athlon X2 4850e, 2.5 GHz, dual core CPU. After
each 'git bisect <status>', I would run 'make-kpkg clean' and
'make oldconfig' before building with something like this:
CONCURRENCY_LEVEL=3 make-kpkg --rootcmd=fakeroot \
--append-to-version=.bisect01 \
--revision=b01
kernel_image
Then I would fix up GRUB's 'menu.lst' and reboot.
Here is a summary of the process, some of which I posted on LKML:
=================================================================
Iteration ID status
--------- ---------- ------
1 2.6.25 good
2 2.6.26-rc4 bad
3 10c993a6b5418cb1026775765ba4c70ffb70853d bad
4 334d094504c2fe1c44211ecb49146ae6bca8c321 bad
5 eddeb0e2d863e3941d8768e70cb50c6120e61fa0 bad
6 77ad386e596c6b0930cc2e09e3cce485e3ee7f72 bad
7 ede1389f8ab4f3a1343e567133fa9720a054a3aa bad
8 c048fdfe6178e082be918d4062c86d9764979112 bad
9 f73920cd63d316008738427a0df2caab6cc88ad7 bad
10 04aaa7ba096c707a8df337b29303f1a5a65f0462 good
11 8fa6878ffc6366f490e99a1ab31127fb599657c9 good
12 1180e01de50c0c7683c6648251f32957bc2d7850 good
13 1e934dda0c77c8ad13fdda02074f2cfcea118a56 bad
14 322850af8d93735f67b8ebf84bb1350639be3f34 good
15 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f bad
16 700efc1b9f6afe34caae231b87d129ad8ffb559f good
First commit causing failure:
commit 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f
Author: Yinghai Lu <Yinghai.Lu@Sun.COM>
Date: Fri Feb 22 17:07:16 2008 -0800
x86: clean up e820_reserve_resources on 64-bit
e820_resource_resources could use insert_resource instead of request_resource
also move code_resource, data_resource, bss_resource, and crashk_res
out of e820_reserve_resources.
Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
$ git diff 700efc1b9f6afe34caae231b87d129ad8ffb559f 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f
diff --git a/arch/x86/kernel/e820_64.c b/arch/x86/kernel/e820_64.c
index a8694a3..8b914a8 100644
--- a/arch/x86/kernel/e820_64.c
+++ b/arch/x86/kernel/e820_64.c
@@ -229,8 +229,7 @@ unsigned long __init e820_end_of_ram(void)
/*
* Mark e820 reserved areas as busy for the resource manager.
*/
-void __init e820_reserve_resources(struct resource *code_resource,
- struct resource *data_resource, struct resource *bss_resource)
+void __init e820_reserve_resources(void)
{
int i;
for (i = 0; i < e820.nr_map; i++) {
@@ -245,21 +244,7 @@ void __init e820_reserve_resources(struct resource *code_resource,
res->start = e820.map[i].addr;
res->end = res->start + e820.map[i].size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- request_resource(&iomem_resource, res);
- if (e820.map[i].type == E820_RAM) {
- /*
- * We don't know which RAM region contains kernel data,
- * so we try it repeatedly and let the resource manager
- * test it.
- */
- request_resource(res, code_resource);
- request_resource(res, data_resource);
- request_resource(res, bss_resource);
-#ifdef CONFIG_KEXEC
- if (crashk_res.start != crashk_res.end)
- request_resource(res, &crashk_res);
-#endif
- }
+ insert_resource(&iomem_resource, res);
}
}
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 187f084..e3cb3ea 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -248,6 +248,7 @@ static void __init reserve_crashkernel(void)
(unsigned long)(total_mem >> 20));
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
+ insert_resource(&iomem_resource, &crashk_res);
}
}
#else
@@ -322,6 +323,11 @@ void __init setup_arch(char **cmdline_p)
finish_e820_parsing();
+ /* after parse_early_param, so could debug it */
+ insert_resource(&iomem_resource, &code_resource);
+ insert_resource(&iomem_resource, &data_resource);
+ insert_resource(&iomem_resource, &bss_resource);
+
early_gart_iommu_check();
e820_register_active_regions(0, 0, -1UL);
@@ -454,7 +460,7 @@ void __init setup_arch(char **cmdline_p)
/*
* We trust e820 completely. No explicit ROM probing in memory.
*/
- e820_reserve_resources(&code_resource, &data_resource, &bss_resource);
+ e820_reserve_resources();
e820_mark_nosave_regions();
/* request I/O space for devices used on all i[345]86 PCs */
diff --git a/include/asm-x86/e820_64.h b/include/asm-x86/e820_64.h
index 9e06c6e..ef653a4 100644
--- a/include/asm-x86/e820_64.h
+++ b/include/asm-x86/e820_64.h
@@ -23,8 +23,7 @@ extern void update_memory_range(u64 start, u64 size, unsigned old_type,
extern void setup_memory_region(void);
extern void contig_e820_setup(void);
extern unsigned long e820_end_of_ram(void);
-extern void e820_reserve_resources(struct resource *code_resource,
- struct resource *data_resource, struct resource *bss_resource);
+extern void e820_reserve_resources(void);
extern void e820_mark_nosave_regions(void);
extern int e820_any_mapped(unsigned long start, unsigned long end, unsigned type);
extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned type);
=================================================================
I'm hoping to get some suggestions on how to fix the problem from
developers or other contributors on LKML. I do know that the
'arch/x86/kernel/setup_64.c' file is not the problem because the code
that changed is in an #ifdef block depending on CONFIG_KEXEC, which is
_not_ enabled in my custom '.config' (though it is in the Debian config).
Maybe someone will be able to help me, now that I've been able to point at
before/after commits which cause kernels to freeze on my ECS machine!
Dave W.
Reply to: