[Top] [All Lists]

Re: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN

To: "TWEDE,ROGER (HP-Boise,ex1)" <>
Subject: Re: NFS Root failure in 2.4.18 - Traced to 256k COLOUR_ALIGN
From: Jun Sun <>
Date: Wed, 6 Nov 2002 14:29:54 -0800
Cc: "'Ralf Baechle'" <>, "''" <>,
In-reply-to: <>; from on Fri, Nov 01, 2002 at 01:28:32PM -0800
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.2.5i
On Fri, Nov 01, 2002 at 01:28:32PM -0800, TWEDE,ROGER (HP-Boise,ex1) wrote:
> 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?

Don't really know about this question.

But in general if the pages are going to be shared, you will hit cache 
aliasing problem.  Then you need to implement something like cache 
coloring, which must be an unique one for the whole system, which naturally
means you need to use arch_get_unmapped_area().

> - Or should the mapping request pass in a requested address which already
> has valid 256k alignment?

Not necessarily, as long as caller is prepared for a possibly different
return value.

> - Or should requested addresses that are misaligned be handled well by the
> calling code once the translated/aligned address is returned to the calller?

I don't think so.

> 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)?

I am curious too.  At least it should move along fine once it is given the
the new aligned address.


<Prev in Thread] Current Thread [Next in Thread>