On Fri, Mar 19, 2010 at 17:33 +0100, Raymund Will wrote: > Chris McDermott wrote on 2010-03-09T16:01:46 -0800: > [...] > > So, what do folks think about moving the code that relocates the initrd to > > INITRD_START from start_kernel() to sysdeps_create_boot_params()? > > Isn't that asking for trouble? > Given, that the firmware didn't hand out that memory, when it's been > kindly asked, I'd consider it dangerous to just ignore that and simply > overwrite it, especially way before ExitBootServices is called.
No. The firmware DID hand out the memory. It just handed out a chunk of memory at an address (above 4GB) that elilo can't correctly manage. > > > Another possible fix would be to have load_file() use the AllocateAddress > > allocation type, which it appears to conditionally do now, but the code > > looks suspect to me. > > And rightly so: it's buggy! The call to 'sysdeps_initrd_get_addr()' > is ignored twice, first when 'start_addr' is initialized as NULL and > second, when alloc_pages() is given a '0' even when 'start_addr' should > happen to be non-null! Yep. Agreed. > [...] > > See above. We should simply avoid allocating the initrd above the > kernel-specified 'initrd_addr_max' (which is significantly below 4GB ATM). > (BTW, this will be addressed by patch #2 in the series I'm about to send!) Yes, I agree this seems like the safest approach. Particularly since the x64 elilo->kernel handoff restricts the initrd start address to < 4GB. thanks, -- Chris McDermott <[email protected]> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ elilo-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/elilo-discuss
