On Tue, Mar 15, 2005 at 02:37:45PM -0800, Ed Martini wrote: > Ok. Then let's get rid of it completly, and provide a replacement that > works. Way to go. > There were vestiges of embedded initrd in the ld script that were > confusing when trying to sort things out. That, in conjunction with > Documentation/initrd.txt made it hard to discover early user space and > initramfs when coming from the old world (2.4). Correct and I've applied that part of your patch already while thinking about the problem you describe below. > Also, unless you move the location of .init.ramfs, it gets freed twice, > leading to a panic. Interesting one. When I tested the code recently it did work for me and it shouldn't have changed since. The way this is supposed to work is by setting the page_count to 1 by using set_page_count and unmarking the page as reserved, so after that point a free_page should actually succeed - even if done twice as you've observed, first in populate_rootfs then once more in free_initmem. It seems a frighteningly bad idea though since it relies on no memory from the initrd range being allocated between the two calls - or it would end being freed by force, in use or not. On startup Linux tends to allocate memory starting from high address towards low addresses which must be why we usually get away with this one. > From the documentation alone it's impossible to figure out how to build > your initramfs. In various places the docs refer to the initial > executable as /linuxrc, /kinit, /init, and possibly others. If you read > init/main.c you see that for an initramfs, your initial process will be > started from /init. I guess I read the code so I didn't notice the lacking qualities of the documentation ... Ralf
