I really start believing that what I got is a GRUB2 bug
Similar issues was seen in this bug report:
http://goo.gl/7j5ll

I did the experiment you suggested to check what the e820 output is.
I wanted to do this as comparable as possible so I have compared
9front booted from CD and booted from 9fat

9fat:
"e820: 0000 0000 0009 f800 memory"

cdboot:
"e820: 0000000000000000 000000000009f800 0000000000100000 000000007fed0000"

I guess the first thing I should try is to boot using another
bootloader (or google for "e820 hooked by grub2" and see if I can
disable it).

Thanks a lot for the help I would never have figured this one out myself!
Now the big mystery is just how the 9pcf from Bell labs plan9 was able
to boot...
I attach the diff of the pcf configuration files for my version of
9pcf from 9front and Bell labs Plan9.
Are there any stuff in there that could influence an overide in RAM
detection in the stock kernel?

2011/5/31  <cinap_lenrek@gmx.de>:
> but it would be more interesting figuring out why this
> happens :-)
>
> sure, you could backport bcm driver to bell labs plan9,
> but this memory detection problem might happen to others
> too...
>
> one tip (i think i wrote this in my first mail) is that
> you can break 9boot into a prompt where it will sit
> there until you type boot. just hit any key like space
> or enter. (it waits for one second and then does
> automatically boot if it had a bootfile= in plan9.ini)
>
> you could also comment out the bootfile= line and
> type it at the prompt every time when experimenting.
>
> the command syntax of the prompt is the same
> syntax used in plan9.ini (sections/menus are not
> supported by 9boot)
>
> it would be very interesting what e820= is and also
> the e820 prints from the bell-labs kernel.
>
> i think we have some problem with the e820 call... but
> its hard to tell what exactly is wrong without any
> data.
>
> if you are interested, the e820= format is just a list
> of 2 64bit hex numbers. the first is the start address
> of a memory block, and the 2nd is the end address of
> the block...
>
> e820= should really be memory= but we had no choice
> as 9atom is already using it.
>
> --
> cinap
>