I traced the NFS root boot failure to a change made in the the function
arch_get_unmapped_area(...). The system goes from functional to
non-functional with a single function change made in 2.4.18.
linux/arch/mips/kernel/syscall.c :: arch_get_unmapped_area(...),
The virtual mappings are now aligned on a 256k boundary instead of a page
boundary whenever the mapping is to be shared (as in an executable file
mapping). The COLOUR_ALIGN macro was added and is used in place of
PAGE_ALIGN as found in the file arch/mips/kernel/syscall.c.
As our system boots from a disk such as ide, all calls to this function pass
in a requested address of 0x0. The function then chooses a free virtual
address space accordingly. Upon nfsroot booting, calls to this function
pass in a requested address that is non-zero (such as 0x0fb60000). This
address is page aligned, so in the old version of
arch_get_unmapped_area(...) the exact requested address was fine and
returned from the get_unmapped_area(). In the new version of the function,
the alignment requirement is 256k, however the nfs requested address is not
aligned on a 256k boundary, and is therefore pushed up to the next 256k
boundary. The system does not like this and fails. (the function is never
called again, further booting does not take place)
Several questions that arise:
- In the nfs case, should the file structure have its
file->f_op->get_unmapped_area() member assigned, causing a file specific
get_unmapped_area to be called instead of this arch_get_unmapped_area?
- Or should the mapping request pass in a requested address which already
has valid 256k alignment?
- Or should requested addresses that are misaligned be handled well by the
calling code once the translated/aligned address is returned to the calller?
- Why does nfsroot booting cause apecific non-zero virtual addresses to be
requested, whereas in the ide disk booting case, addressed are left
unspecified (0x0) (no requested mapping)?
Thanks for any information anyone might lend.