Older UltraSPARC-III chips have a P-Cache bug that makes us disable it
by default at boot time.

However, this does hurt performance substantially, particularly with
memcpy(), and the bug is _incredibly_ obscure.  I have never seen it
triggered in practice, ever.

So provide a "-P" boot option that forces the P-Cache on.  It taints
the kernel, so if it does trigger and cause some data corruption or
OOPS, we will find out in the logs that this option was on when it
happened.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The recent change to add a timeout to strbuf flushing had
a negative performance impact.  The udelay()'s are too long,
and they were done in the wrong order wrt. the register read
checks.  Fix both, and things are happy again.

There are more possible improvements in this area.  In fact,
PCI streaming buffer flushing seems to be part of the bottleneck
in network receive performance on my SunBlade1000 box.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If some hardware error occurs and the flush flag never updates,
we will hang forever in these routines.  Add a timeout, and
print out a diagnostic if it is reached.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently sparc and sparc64's UP cpu_idle() checks current pid. This
is old time legacy. Now it's paranoia.
Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
Acked-by: NWilliam Irwin <wli@holomorphy.com>
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>

There is some race whereby IRQs get stuck, the IRQ status
is pending but no processor actually handles the IRQ vector
and thus the interrupt.
 
This is a temporary workaround.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We would never advance the goal_cpu counter like we
should, so all IRQs would go to a single processor.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Convert most of the current code that uses _NSIG directly to instead use
valid_signal().  This avoids gcc -W warnings and off-by-one errors.
Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

void * __iomem foo is not a pointer to iomem - it's an iomem variable
containing void *.  A pile of such guys in arch/sparc64/kernel/time.c,
drivers/sbus/char/rtc.c and include/asm-sparc64/mostek.h turned into
intended void __iomem *. 
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

CONFIG_HW_CONSOLE selects vt.c; without the stuff pulled by CONFIG_VT it
will not build.  Normally we get both in drivers/char/Kconfig and there
HW_CONSOLE depends on VT.  sparc64 does not pull drivers/char/Kconfig
and has that sutff in arch/sparc64/Kconfig instead.  However, it forgets
to add the same dependency.  As the result, turning VT off [which is
possible] will end up with broken build.  For no good reason... 
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Provide support for drivers/char/rtc.c ioctls in the
Mostek rtc driver as well as the Sparc specific RTCGET
and RTCSET.

This allows userspace to be much less messy.  Currently
util-linux and other spots jump through hoops trying
various ioctl variants until it hits the right one whatever
driver actually being used supports.

Eventually all of this should move over to the genrtc.c
driver, but not today...

While we are here, fix up the register types for sparse.

Thanks to Frans Pop for helping point out this issue.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Like Alpha, sparc64's struct stat was defined before we had the
nanosecond et al.  fields added.  So like Alpha I have to cons up a
struct stat64 to get this stuff.  I'll work on the glibc bits soon. 

Also, we were forgetting to fill in the nanosecond fields in the sparc
compat stat64 syscalls. 
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The compat routine to copy over this data structure was not
handling SI_POLL correctly, breaking various fcntl() variants
in compat tasks.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We were flushing the D-cache excessively for ptrace() processing
and this makes debugging threads so slow as to be totally unusable.

All process page accesses via ptrace() go via access_process_vm().
This routine, for each process page, uses get_user_pages().  That
in turn does a flush_dcache_page() on the child pages before we
copy in/out the ptrace request data.

Therefore, all we need to do after the data movement is:

1) Flush the D-cache pages if the kernel maps the page to a different
   color than userspace does.
2) If we wrote to the page, we need to flush the I-cache on older cpus.

Previously we just flushed the entire cache at the end of a ptrace()
request, and that was beyond stupid.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

SunOS aparently had this weird PTRACE_CONT semantic which
we copied.  If the addr argument is something other than
1, it sets the process program counter to whatever that
value is.

This is different from every other Linux architecture, which
don't do anything with the addr and data args.

This difference in particular breaks the Linux native GDB support
for fork and vfork tracing on sparc and sparc64.

There is no interest in running SunOS binaries using this weird
PTRACE_CONT behavior, so just delete it so we behave like other
platforms do.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A couple message queue system call entries for compat tasks
were not using the necessary compat_sys_*() functions, causing
some glibc test cases to fail.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!