Commit Graph

107 Commits

Author SHA1 Message Date
David S. Miller
1ac4f5ebaa [SPARC64]: Remove ktlb.S instruction patching.
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: David S. Miller <davem@davemloft.net>
2005-09-21 21:49:32 -07:00
Prasanna S Panchamukhi
05e14cb3ba [PATCH] Kprobes: prevent possible race conditions sparc64 changes
This patch contains the sparc64 architecture specific changes to prevent the
possible race conditions.

Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:58:00 -07:00
David S. Miller
48b0e5487f [SPARC64]: Fix ugly dependency on NR_CPUS being a power-of-2.
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: David S. Miller <davem@davemloft.net>
2005-07-27 16:08:44 -07:00
David S. Miller
b445e26cbf [SPARC64]: Avoid membar instructions in delay slots.
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: David S. Miller <davem@davemloft.net>
2005-06-27 15:42:04 -07:00
Christoph Hellwig
8edf72ebce [SPARC64]: Kill useless __pte_alloc_one_kernel indirection
warning: untested, but it there's not too much chance for screwups

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-05-05 14:27:56 -07:00
David S. Miller
a9546f59e9 [PATCH] sparc64: Do not flush dcache for ZERO_PAGE.
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: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-17 18:03:09 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00