Yinghai,
Please advise me on how you would like me to handle 2.6.27 kernels.

If I use your patch on 2.6.27-rc3, the message scroll off the 80x25

screen before I can see them... and then the kernel hangs.  I can run

the kernel with "hpet=disable", but I'm not sure you want that.  If

you _do_ want that, just let me know.
As an alternative, I can alter your patch to use a log level of

something lower, like KERN_WARNING.  Then I could see the messages

from your patch if I set a "loglevel=4" boot parameter, even on a

kernel that hangs.  The normal messages should disappear, only

leaving the messages from your patch.
In the meantime, here is what I _did_ do to test your patch:
==================================

$ git checkout -f v2.6.27-rc3

HEAD is now at 30a2f3c... Linux 2.6.27-rc3
$ git apply --verbose --check ../yh_insert_resource_debug.patch

Checking patch kernel/resource.c...
$ git apply --verbose ../yh_insert_resource_debug.patch

Checking patch kernel/resource.c...

Applied patch kernel/resource.c cleanly.
$ git status

# Not currently on any branch.

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#

#    modified:   kernel/resource.c

#

no changes added to commit (use "git add" and/or "git commit -a")

==================================
This kernel boots and hangs, and I cannot see your patch messages.  But

I am sure they are there.  (See below.)
To see your patch messages without altering the patch, I checked out

an older revision that will boot.  Also, I just realized why I never get

the earliest boot log messages from 'dmesg':  the standard value of

CONFIG_LOG_BUF_SHIFT is 15 (32 KB), which is too small to capture all

of my early boot messages.
In view of these things, I checked out the last kernel that will run for

me without hanging,
$ git checkout -f 700efc1b
and set CONFIG_LOG_BUF_SHIFT=18.  Your patch messages show up nicely this

way:

==================================

$ uname -r

2.6.2...
[ message continues ]

Couldn't you play with CONFIG_BOOT_PRINTK_DELAY?
--

 i.

--

so old kernel doesn't register [fec00000, ffffffff] from e820 as

reserved. because lapic address register at first.
lapic, ioapic, and hpet0 addr all should be children of [fec00000,

fffffffff] as reserved from e820.
please use my print out patch with current kernel.
YH

--