On Nov 21, 2005, at 12:00 AM, Mike Small wrote:
This worked for me, and I've enclosed a patch with the a similar loop to the one used for the linux command. It also has debugging messages before the grub_claimmap calls.
Looks good, thanks! I've just committed this.
I'm wondering though, does it matter very much how grub grabs memory? Once the operating system takes over it takes all of memory and whatever grub allocated doesn't matter anymore. Is that correct?
Correct.
The reason I ask is that I tried making that loop retry the claim at every 4 bytes instead of at every megabyte and found it settled on an address only four bytes higher than the one it failed on. So maybe it's possible to be more precise than the code in this patch is. My guess would be that open firmware allocates with a resolution of 8 bytes, at least on my machine. In that second test, the address that the grub_claimmap failed on was 1b99F84 and the one it succeeded on was 1b99F88. 1b99F84 was the exact end of the space allocated by the linux command (at 1400000, size 799f84), so if o.f. grabbed in 8 bytes increments it would have had up to 1b99F88, causing the failure. Plausible?
Hmm, yeah, that's a good theory. On the one hand, it would be easy to align the initrd address up (to say a 4KB boundary), and that would avoid this problem. On the other hand, the loop solves the more general case, and I guess that solves this particular problem too.
The increment (1MB) does seem a bit excessive, but on the other hand we could have really run into an area reserved by firmware itself, which is likely to be several MB at least. After initially being tempted to muck with it, I'm now inclined to leave the code as-is (until the next person reports a problem ;).
Thanks! -Hollis _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
