Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

["Yinghai Lu" <yhlu.kernel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On Sun, Aug 24, 2008 at 12:29 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Sun, Aug 24, 2008 at 6:05 AM, David Witbrodt <dawitbro@sbcglobal.net> wrote:
>>
>>
>>> > - Is there any chance I can get it into the stable 2.6.26.X updates?
>>> > (Who should I ask, or are only developers allowed to lobby for this
>>> > sort of thing?)
>>>
>>> after the patch get into linus tree. Greg will put the patch into 2.6.26.X
>>
>> OK, thanks a bunch.
>>
>>
>>> > - Are you worried about the potential problems of a quirk-based approach?
>>> > What if many more people experience a similar regression once 2.6.26 or
>>> > later appears in their distribution?  I'm sure you don't want to have to
>>> > write a different quirk for each individual's hardware, and this problem
>>> > did not arise with the approach used for resource management in 2.6.25.
>>>
>>> this patch should be safe.
>>>
>>> 2.6.26 is fixing one bug about reserving local apic address and that
>>> in e820 table.
>>> and it reveals one bios bug.
>>
>> Correction -- it revealed at least two.  See the link I posted earlier in
>> this thread:
>>
>> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0808.2/1807.html
>>
>> Scroll down to the line that starts with "[blog]" for the link. You can see
>> the discussion I had encouraging him to come here to help us troubleshoot
>> if you go to that blog and click "Comments".
>>
>> I only mention this as a warning, in case it could lead to a lot of extra
>> problems for you later.  If you're quite sure that everything is OK, then
>> all I can do is thank you again and keep my fingers crossed for you and the
>> kernel team that nothing bad happens when 2.6.2[67] hit the major distros.
>
> after discussing with Ingo, we have one more generic way to detect the
> same situation.
>
> please help to verify the attached patch. ( don't apply previous patch)
>

and please test attached patch too. ( could test it without two patches)

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: only_put_e820_ram_in_res_tree.patch --]
[-- Type: text/x-patch; name=only_put_e820_ram_in_res_tree.patch, Size: 952 bytes --]

From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: only put e820 ram entries in resource tree

may need user to have new kexec tools that could create e820 table
from /sys/firmware/memmap instead of /proc/iomem for second kernel

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Bernhard Walle <bwalle@suse.de>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1279,6 +1279,10 @@ void __init e820_reserve_resources(void)
 
 	res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
 	for (i = 0; i < e820.nr_map; i++) {
+		if (e820.map[i].type != E820_RAM) {
+			res++;
+			continue;
+		}
 		end = e820.map[i].addr + e820.map[i].size - 1;
 #ifndef CONFIG_RESOURCES_64BIT
 		if (end > 0x100000000ULL) {