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(...), COLOUR_ALIGN 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? And generally: - 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. Roger
