Testing shows that the prom_unmap() calls do absolutely
nothing.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Because we don't access the PAGE_OFFSET linear mappings
any longer before we take over the trap table from the
firmware, we don't need to load dummy mappings there
into the TLB and we don't need the bootmap_base hack
any longer either.

While we are here, check for a larger than 8MB kernel
and halt the boot with an error message.  We know that
doesn't work, so instead of failing mysteriously we
should let the user know exactly what's wrong.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Just allocate them physically starting from the end of
the kernel image.  This incredibly simplifies our MM
bootstrap in that we don't need any mappings in the linear
PAGE_OFFSET area working in order to bootstrap ourselves and
take over the trap table from the firmware.

Many further simplifications are possible now, and this also
sets the stage for CONFIG_DEBUG_PAGEALLOC support.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This thing was just a huge monolithic mess, so chop it up.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use __initdata instead.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This was kind of ugly, and actually buggy.  The bug was that
we didn't handle a machine with memory starting > 4GB.  If
the 'prompmd' was allocated in physical memory > 4GB we'd
croak because the obp_iaddr_patch and obp_daddr_patch things
only supported a 32-bit physical address.

So fix this by just loading the appropriate values from two
variables in the kernel image, which is locked into the TLB
and thus accesses to them can't cause a recursive TLB miss.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch contains the sparc64 architecture specific changes to prevent the
possible race conditions.
Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The page->flags D-cache dirty state tracking depended upon
NR_CPUS being a power-of-2 via it's "NR_CPUS - 1" masking.

Fix that to use a fixed (256 - 1) mask as that is the limit
imposed by thread_info->cpu which is a "u8".

Finally, add a compile time check that NR_CPUS is not greater
than 256.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In particular, avoid membar instructions in the delay
slot of a jmpl instruction.

UltraSPARC-I, II, IIi, and IIe have a bug, documented in
the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51

The long and short of it is that if the IMU unit misses
on a branch or jmpl, and there is a store buffer synchronizing
membar in the delay slot, the chip can stop fetching instructions.

If interrupts are enabled or some other trap is enabled, the
chip will unwedge itself, but performance will suffer.

We already had a workaround for this bug in a few spots, but
it's better to have the entire tree sanitized for this rule.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

warning: untested, but it there's not too much chance for screwups
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This case actually can get exercised a lot during an ELF
coredump of a process which contains a lot of non-COW'd
anonymous pages.  GDB has this test case which in partiaular
creates near terabyte process full of ZERO_PAGEes.  It takes
forever to just walk through the page tables because of
all of these spurious cache flushes on sparc64.

With this change it takes only a second or so.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!