Not all of the PAL VM calls are implemented for the SKI simulator.
Don't just give up if one fails, print information from the calls
that succeed.

Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Tony Luck <tony.luck@intel.com>

This patch implements PAL_VM_SUMMARY (and PAL_MEM_ATTRIB for good
measure) and pretends that the simulated machine is a McKinley.

Some extra comments and clean-up by Tony Luck.

Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Tony Luck <tony.luck@intel.com>

Fix build problem found by compiling driver with DEBUG defined that used tcp.h.
Since pr_debug(arg) expands to printk("<7>" arg) the argument
needs to be string that can be concatenated.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Damir Perisa <damir.perisa@solnet.ch> reports:

drivers/net/s2io.h:765: error: invalid lvalue in assignment
drivers/net/s2io.h:766: error: invalid lvalue in assignment

That's a gcc4 error. I don't see why the casts are there anyway..

Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

The {BEGIN,END}_FTR_SECTION asm macros used in ppc64 to nop out
sections of code at runtime cannot be nested. However, we do nest
them in hash_low.S. We get away with it there, because there is
nothing between the BEGIN markers for each section. However, that's
confusing to someone reading the code.

This patch removes the nested ifset and ifclr feature sections,
replacing them with a single feature section in the full mask/value
form.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

It appears that a memory barrier soon after a mispredicted
branch, not just in the delay slot, can cause the hang
condition of this cpu errata.

So move them out-of-line, and explicitly put them into
a "branch always, predict taken" delay slot which should
fully kill this problem.

Signed-off-by: David S. Miller <davem@davemloft.net>

Defer copying of ptes until fault time when it is possible to reconstruct
the pte from backing store. Idea from Andi Kleen and Nick Piggin.

Thanks to input from Rik van Riel and Linus and to Hugh for correcting
my blundering.

Ray Fucillo <fucillo@intersystems.com> reports:

"I applied this latest patch to a 2.6.12 kernel and found that it does
resolve the problem. Prior to the patch on this machine, I was
seeing about 23ms spent in fork for ever 100MB of shared memory
segment.

After applying the patch, fork is taking about 1ms regardless of the
shared memory size."

Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This makes the send rate calculations behave way more closely to what
is specified, with the jitter previously seen on x and x_recv
disappearing completely on non lossy setups.

This resembles the tcp_data_snd_check code, that possibly we'll end up
using in DCCP as well, perhaps moving this code to
inet_connection_sock.

For now I'm doing the simplest implementation tho.

Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch fixes a rare memory leak found by Coverity.

Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

When the spinlock routines were moved out of line into
kernel/spinlock.c this made it so that the debugging
spinlocks record lock acquisition program counts in the
kernel/spinlock.c functions not in their callers.
This makes the debugging info kind of useless.

So record the correct caller's program counter and
now this feature is useful once more.

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

So that applications can set dccp_sock->dccps_pkt_size, that in turn
is used in the CCID3 half connection init routines to set
ccid3hc[tr]x_s and use it in its rate calculations.

Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Coverity found more unused code.

Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

Bugfix (usage of uninitialized pointer in zfcp_port_dequeue) and compile
fixes for the zfcp device driver.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Removed sparc architecture specific users of asm/segment.h and
asm-sparc/segment.h itself

Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

- changes license of all code from OSL+GPL to plain ole GPL
- except for NVIDIA, who hasn't yet responded about sata_nv
- copyright holders were already contacted privately

- adds info in each driver about where hardware/protocol docs may be
obtained

- where I have made major contributions, updated copyright dates

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Paulus, I think this is now a reasonable candidate for the post-2.6.13
queue.

Relax address restrictions for hugepages on ppc64

Presently, 64-bit applications on ppc64 may only use hugepages in the
address region from 1-1.5T. Furthermore, if hugepages are enabled in
the kernel config, they may only use hugepages and never normal pages
in this area. This patch relaxes this restriction, allowing any
address to be used with hugepages, but with a 1TB granularity. That
is if you map a hugepage anywhere in the region 1TB-2TB, that entire
area will be reserved exclusively for hugepages for the remainder of
the process's lifetime. This works analagously to hugepages in 32-bit
applications, where hugepages can be mapped anywhere, but with 256MB
(mmu segment) granularity.

This patch applies on top of the four level pagetable patch
(http://patchwork.ozlabs.org/linuxppc64/patch?id=1936).

Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

This target allows users to modify the hoplimit header field of the
IPv6 header.

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

While ppc64 has the CONFIG_HZ Kconfig option, it wasnt actually being
used. Connect it up and set all platforms to 250Hz.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>

struct zfcp_port::scsi_id was removed by commit
3859f6a248cbdfbe7b41663f3a2b51f48e30b281

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Removed sparc64 architecture specific users of asm/segment.h and
asm-sparc64/segment.h itself

Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Too many changes to release a final 2.6.13.

* ieee1394_device_id has kernel_ulong_t field after an odd number of
__u32 ones. Since mod_devicetable.h is included both from kernel and
from host build helper, we may be in trouble if we are building on
32bit host for 64bit target - userland sees unsigned long long,
kernel sees unsigned long and while their sizes match, alignments
might not. Fixed by forcing alignment. Fortunately, almost nobody
else needs that - the rest of such fields is naturally aligned as it
is.

* of_device_id has void * in it. Host userland helpers need
kernel_ulong_t instead, since their void * might have nothing to do
with the kernel one. Fixed in the same way it's done for similar
problems in pcmcia_device_id (ifdef __KERNEL__).

* pcmcia_device_id has the same problem as ieee1394_device_id. Fixed
the same way.

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

You can't call get_property() on a NULL node, so check if of_chosen is set
in check_for_initrd().

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

arch/ppc64/kernel/setup.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
Signed-off-by: Paul Mackerras <paulus@samba.org>

This new iptables target allows manipulation of the TTL of an IPv4 packet.

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Here's the 970MP's PVR (processor version register) entry for oprofile.

Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

Current uncorrectable error handling was poor enough
that the processor could just loop taking the same
trap over and over again. Fix things up so that we
at least get a log message and perhaps even some register
state.

In the process, much consolidation became possible,
particularly with the correctable error handler.

Prefix assembler and C function names with "spitfire"
to indicate that these are for Ultra-I/II/IIi/IIe only.

More work is needed to make these routines robust and
featureful to the level of the Ultra-III error handlers.

Signed-off-by: David S. Miller <davem@davemloft.net>

As pointed out in the following thread, the CLOCK_TICK_RATE setting for
IXP4xx is incorrect b/c the HW ignores the lowest 2 bits of the LATCH
value.

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-August/030950.html

Tnx to George Anziger and Egil Hjelmeland for finding the issue.

Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We've had Woozy Numbat for a while now. Here's an updated name care of
Jeff Garzik and myself.

Signed-off-by: Benjamin LaHaise <bcrl@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

unflatten_device_tree() doesn't check if lmb_alloc() succeeds or not, it
should. All it can do is panic, but at least there's an error message
(assuming you have some sort of console at that point).

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

arch/ppc64/kernel/prom.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
Signed-off-by: Paul Mackerras <paulus@samba.org>

Renaming it to dccp_rx_hist_detect_loss.

Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Some RS64-based machines (p620, F80, others) have problems with firmware
returning 0xdeadbeef instead of failure to allocations that end at the
1GB mark.

We have two options:
1. Detect the undocumented 0xdeadbeef return value and interpret it as
a failure.
2. Avoid allocating that high.

(2) is really the cleaner solution here. 768MB is plenty of room so use
that as the max alloc_top instead of 1GB.

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

[ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]

I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.

What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data. Then process A closes that and concurrently process
B opens /dev/tty6. Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1. However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).

So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data. Then when the
process tries to do anything with that fd, it oopses.

The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open. The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem. We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called. Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.

Signed-off-by: Paul Mackerras <paulus@samba.org>
[ Same patch
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Don't check type of sax25_family; dev_set_mac_address has already done
that before and anyway, the type to check against would have been
ARPHRD_AX25. We only got away because AF_AX25 and ARPHRD_AX25 both happen
to be defined to the same value.

Don't check sax25_ndigis either; it's value is insignificant for the
purpose of setting the MAC address and the check has shown to break
some application software for no good reason.

Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

Verify we really are taking a data access exception trap, at TL1, from
one of the window spill/fill handlers.

Else call a new function, data_access_exception_tl1, to log the error.

Signed-off-by: David S. Miller <davem@davemloft.net>

This keeps the kernel/cpuset.c routine update_cpu_domains() from
invoking the sched.c routine partition_sched_domains() if the cpuset in
question doesn't fall on node boundaries.

I have boot tested this on an SN2, and with the help of a couple of ad
hoc printk's, determined that it does indeed avoid calling the
partition_sched_domains() routine on partial nodes.

I did not directly verify that this avoids setting up bogus sched
domains or avoids the oops that Hawkes saw.

This patch imposes a silent artificial constraint on which cpusets can
be used to define dynamic sched domains.

This patch should allow proceeding with this new feature in 2.6.13 for
the configurations in which it is useful (node alligned sched domains)
while avoiding trying to setup sched domains in the less useful cases
that can cause the kernel corruption and oops.

Signed-off-by: Paul Jackson <pj@sgi.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Dinakar Guniguntala <dino@in.ibm.com>
Acked-by: John Hawkes <hawkes@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When unflatten_dt_node() fails to find an OF_DT_END_NODE tag it prints
"Weird tag at start of node", this should be "Weird tag at end of node".

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

arch/ppc64/kernel/prom.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Paul Mackerras <paulus@samba.org>

Renaming it to dccp_rx_hist_add_packet.

Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

They differed in either simple comments or in the protecting ifdefs.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>

This patch fixes a severe problem with 2.6.13-rc7.

Due to recent SCSI changes it is not possible to add any LUNs to the zfcp
device driver anymore. With registration of remote ports this is fixed.

Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>
Acked-by: James Bottomley <jejb@steeleye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I dropped the timer initialization bits by accident when sending the
p-persistence fix. This patch gets the driver to work again on halfduplex
links.

Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

1) Read ASI_IMMU SFSR not ASI_DMMU.
2) IMMU has no SFAR, read TPC instead
3) Delete old and incorrect comment about the DTLB protection
trap having a dependency on the SFSR contents in order to
function correctly

Signed-off-by: David S. Miller <davem@davemloft.net>

Move the InfiniBand headers from drivers/infiniband/include to include/rdma.
This allows InfiniBand-using code to live elsewhere, and lets us remove the
ugly EXTRA_CFLAGS include path from the InfiniBand Makefiles.

Signed-off-by: Roland Dreier <rolandd@cisco.com>