lkml.org 
[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed
[Yinghai, please note that I did not request a patch to revert the
problem commit. I was merely experimenting -- on my own time, so
you folks would not have to bother -- to see if I could make it
work. I should have made that more clear! Having said that, I am
glad to test changes of any kind on my machine: reverts, code for
debugging or info, experiments, etc.]


I have two agendas here:

1. A selfish interest in seeing future kernels work properly on
my "server" machines. (I did not request a revert because I'm
not yet convinced that the commit which introduced the problem
was broken. That commit certainly is NOT broken on 1 of my 3
machines, and on none of your machines. It may just expose
breakage elsewhere.)

2. To provide a patch for Debian against the 2.6.26 line, in case
they get flooded with bug reports when their next stable release
happens. (Such a flood is unlikely since no one here has the same
problem, and the users of Debian unstable haven't filed similar bug
reports in the last 2 weeks. But, just in case...)


Pursuing #2 above, my first experiment was to attempt a revert for
2.6.26-rc1. The files involved are much more similar to those in
the problem commit, so performing the revert was much easier than
what I tried with 2.6.27-rc3. I hoped to inch my way forward from
2.6.26-rc1 to 2.6.26, and end up with a patch useful for the Debian
Kernel Team.

Assuming I didn't botch the revert -- and I successfully carried
out this revert yesterday using the git version where the lockup
first occured -- it looks like there were enough changes between
Feb. 22 and May 3 that the simple, naive sort of revert that I
can do already cannot work. The kernel freezes at boot, in spite
of the changes.


I will continue to try to work on identifying the first commit for
which my naive revert process will not work. If I play a game
where revertible = "good" and nonrevertible = "bad", I can use
'git bisect' to locate the place where it no longer works. I
already have a "good" (3def3d6d...) and a "bad" (v2.6.26-rc1) by
those rules.

If this process succeeds, it could provide evidence about why
reverting in 2.6.27 is not working.


====== DETAILS ==================

$ git show
commit 2ddcca36c8bcfa251724fe342c8327451988be0d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat May 3 11:59:44 2008 -0700

Linux 2.6.26-rc1

diff --git a/Makefile b/Makefile
index 5cf8258..4492984 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
-SUBLEVEL = 25
-EXTRAVERSION =
+SUBLEVEL = 26
+EXTRAVERSION = -rc1
NAME = Funky Weasel is Jiggy wit it

# *DOCUMENTATION*
$ git diff
diff --git a/arch/x86/kernel/e820_64.c b/arch/x86/kernel/e820_64.c
index 124480c..e168fa0 100644
--- a/arch/x86/kernel/e820_64.c
+++ b/arch/x86/kernel/e820_64.c
@@ -325,7 +325,8 @@ unsigned long __init e820_end_of_ram(void)
/*
* Mark e820 reserved areas as busy for the resource manager.
*/
-void __init e820_reserve_resources(void)
+void __init e820_reserve_resources(struct resource *code_resource,
+ struct resource *data_resource, struct resource *bss_resource)
{
int i;
struct resource *res;
@@ -341,7 +342,21 @@ void __init e820_reserve_resources(void)
res->start = e820.map[i].addr;
res->end = res->start + e820.map[i].size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- insert_resource(&iomem_resource, res);
+ 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
+ }
res++;
}
}
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 22c14e2..368c672 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -254,7 +254,6 @@ 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
@@ -365,11 +364,6 @@ 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);
@@ -512,7 +506,7 @@ void __init setup_arch(char **cmdline_p)
/*
* We trust e820 completely. No explicit ROM probing in memory.
*/
- e820_reserve_resources();
+ e820_reserve_resources(&code_resource, &data_resource, &bss_resource);
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 71c4d68..10d6288 100644
--- a/include/asm-x86/e820_64.h
+++ b/include/asm-x86/e820_64.h
@@ -26,7 +26,8 @@ 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(void);
+extern void e820_reserve_resources(struct resource *code_resource,
+ struct resource *data_resource, struct resource *bss_resource);
extern void e820_mark_nosave_regions(void);
extern int e820_any_mapped(unsigned long start, unsigned long end,
unsigned type);

\
 
 \ /
  Last update: 2008-08-13 17:43    [W:0.052 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site