Re: Grub 2 command : uppermem (patch proposal)

[Bandan]

Hi, 

(Somehow I lost some of my emails, so copy pasting for reference.)

Robert, please have a look at http://savannah.gnu.org/bugs/?18471 for the 
related bug report on grub-legacy. This description is wrt grub-legacy and I 
will soon follow up with my observations with grub2.

In short, the systems have a memory hole somewhere at the beginning of the 
map, and the main problem is due to the fact that grub(legacy) does not find a 
contiguous memory region. So, if we have a large initrd or if we try to load a 
multiboot module (as in XEN), grub will bail out with error 28. 

With load_initrd(), we came up with a way to get away with the initial read of 
the initrd (please see patch attached with the above bug) and place it where 
the Linux kernel expects it to be. But with load_module(), it appeared there 
was no easy way out. So, we used uppermem to fool grub and place the multiboot 
module somewhere around 15M beyond the uppermem limit set by us. This took 
care of the problem temporarily.

I hadn't had a chance to try Grub2 on these machines, a first glance at 
grub_multiboot() and related functions tells me that things are significantly 
different from the way load_module() used to  work. I will soon try out grub2 
on these machines and come up with my observations.

Thanks,
Bandan

 
On Tue, Jan 27, 2009 at 08:30:32PM -0500, Bandan Das wrote:
> Hello List,
> 
> I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList 
and 
> I see that one of the many commands that need to be implemented is 
> "uppermem". 

The text in that list was a bit confusing.  We don't have to implement _all_
missing commands, only those we find useful.

> Having played around with uppermem quite a bit (thanks to the weird systems 
I 
> have to work with) on Grub Legacy, I was wondering if a patch for the same 
> would be considered for inclusion? Please note that I haven't started work 
on 
> it yet. I wanted to make sure that it's something desirable before putting 
up 
> a patch.

Could you describe your problem in more detail, so we can discuss if it's
something that makes uppermem worthy or we'd rather solve it in some other
way?  We don't want to leave your use case out in the cold, only to see if it
can be supported in a better way.

-- 
Robert Millan