Recently we have uncovered a bug in the kernel exception exit path
which can cause iSeries machines to hang with interrupts disabled,
typically when unloading a module.  This patch fixes the bug and
should go in 2.6.10.  Here is the detailed explanation:

There are a couple of places in the exception exit path in entry.S
where we disable interrupts and then later reenable them.  We
hard-disable interrupts even on legacy iSeries (rather than
soft-disabling them) because the final part of the exception exit path
needs interrupts hard-disabled (even on legacy iSeries), because
otherwise an incoming interrupt could trash SRR0 and SRR1 and cause us
to lose state.

The intention was that each path that hard-disabled interrupts would
hard-enable them again, either explicitly or by executing an rfid
instruction (return from interrupt, doubleword).  However there was
one path where we didn't correctly hard-enable interrupts.  This meant
we could end up calling schedule() with interrupts hard-disabled and
then switch to the stopmachine thread (used in removing a module),
which spins polling a variable until another cpu changes it.  Since
local_irq_enable() etc. on legacy iSeries only soft-enable interrupts,
we got into the stopmachine thread with interrupts hard-disabled, and
the machine hung at that point.

This patch fixes it by making sure that when we go to re-enable
interrupts, the MSR value we are loading up actually does have the
MSR.EE (external interrupt enable) bit set.  Stephen Rothwell has
verified that this actually does fix the bug on iSeries.  The bug
also potentially exists on pSeries (and this patch fixes it), but
there it doesn't really matter, because schedule() will enable
interrupts (and on pSeries that means hard-enabling them), and because
the hypervisor doesn't mind you having interrupts hard-disabled for
extended periods on pSeries.  Note that all these comments about
pSeries also apply to POWER5 iSeries (i5) machines.

While I was there I noticed that we were jumping to ret_from_except
after calling do_IRQ on iSeries, rather than ret_from_except_lite,
meaning that we will restore registers 14-31 twice, unnecessarily.  I
changed it to jump to ret_from_except_lite instead, and Stephen
checked that this change doesn't cause any breakage.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

IA64 is also vulnerable to the huge-vma-in-executable bug in 64 bit elf
support, it just insert a vma of zero page without checking overlap, so user
can construct a elf with section begin from 0x0 to trigger this BUGON().

However, I think it's safe to check overlap before we actually insert a vma
into vma list.  And I also feel check vma overlap everywhere is unnecessary,
because invert_vm_struct will check it again, so the check is duplicated.
It's better to have invert_vm_struct return a value then let caller check if
it successes.  Here is a patch against 2.6.10.rc2-mm3 I have tested it on
i386, x86_64 and ia64 machines.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Zou Nan hai <Nanhai.zou@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The ppc32 PowerMac cpufreq code, when using the PMU to switch the
frequency, would eventually lose interrupts.  The solution is to raise the
CPU priority at the controller level.  It's also unnecessary to call the
full PIC suspend/resume code in this case as the IO chip isn't reset,
unlike the sleep code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

A trivial fix for the __iomem warnings in arch/ppc/syslib/todc_time.c
Signed-off-by: Randy Vinson <rvinson@mvista.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Borut Lukic <borutlukic@email.si> brought to my attention that in
platform_init() on 8260 the board hook was being called too early to allow for
overrides (e.g.  different memory sizings functions or rtc, or anything else).
 This moves the call to the end of platform_init() and I suspect fixes some
unnoticed yet bugs in a number of 8260 platforms.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix more uninitialized variables in the PPC40x code.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This changes the early CPU spinup code to be based on physical CPU ID
instead of logical.  This will make it possible to kexec off of a
different cpu than 0, for example after it's been hot-unplugged.

The booted cpu will still be mapped as logical cpu 0, since there's various
stuff in the early boot that assumes logical boot cpuid is 0.

Also, it expands the kexec boot param structure to allow the booted physical
cpuid to be passed in.  This includes bumping the version number to 2 for
backwards compat.
Signed-off-by: Olof Johansson <olof@austin.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Remove linux,has-tce-table since we can just look for linux,tce-base and
linux,tce-size.  Make linux,tce-base store real addresses instead of virtual
ones, the wrapper may not know the translation the kernel will use.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Reserve the kernel memory (0 - klimit) in the kernel instead of the wrapper.
Remove an old comment that incorrectly referred to klimit.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Move the linux,rtas* properties into the /rtas node and make them 32bit.  Use
rtas-size and avoid duplicating it in linux,rtas-size.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Let's revert this for now so all those warnings do not soil our 2.6.10
release.  We'll get Rusty's kernel-wide-sweep fixup patches in for 2.6.11, and
then we can put this warning back.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Remove the volatile from cpus_in_xmon, and put a barrier() in the loop that
waits for the other cpus to come in to xmon.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The ppc64 toolchains don't create dot symbols (i.e. a globally
visible ".foo" symbol for the text of function foo) any more.

This breaks the kernel compile because we refer to function text
addresses in the system call table.

Fortunately there is an option, -mcall-aixdesc, which restores the
previous behaviour, and even more fortunately, old ppc64 toolchains
understand the option as well as new ones.

This patch adds -mcall-aixdesc to CFLAGS in arch/ppc64/Makefile.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

This patch adds pci_disable_device in the appropriate places to
eliminate the following message when removing the module.

pcnet32 0000:00:05.0: Device was removed without properly calling pci_disable_device(). This may need fixing.
pcnet32 0000:02:05.0: Device was removed without properly calling pci_disable_device(). This may need fixing.

Tested ia32.
signed-off-by: Don Fry <brazilnut@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

From: Geert Uytterhoeven <geert@linux-m68k.org>

M68k: Update HP300 defconfig (enable DIO and HP Lance Ethernet)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

From: Santiago Leon <santil@us.ibm.com>

The attached patch makes the ibmveth driver indicate that its link is
always up rather than always down, thus allowing the userspace side of
booting to configure the network interface correctly.
Signed-Off-By: Santiago Leon <santil@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

From: Geert Uytterhoeven <geert@linux-m68k.org>

HP Lance Ethernet: There's tons of leaks in the hplcance probing code, and it
doesn't release the memory region on removal either (from Christoph Hellwig)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

From: Geert Uytterhoeven <geert@linux-m68k.org>

M68k: Update Atari defconfig (enable Ethernet and MII)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

From: "John W. Linville" <linville@tuxdriver.com>

tulip_stop_rxtx() doesn't wait for DMA to fully stop like the function
call name implies.

This was submitted through my employer -- I am not the original author of this
patch.  However, I passed it by Jeff Garizk and he expressed interest in
having it upstream.
Signed-off-by: Grant Grundler <iod00d@hp.com>
Acked-by: Charlie Brett <charlie.brett@hp.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

Gents, what do we think of the below fix?

Thanks.

My IBM A21P laptop is getting an IRQ storm at boot.

IRQ #11 is shared between USB and e100, and USB is getting in there first.
Consequently, when e100 initialises the hardware, that interrupt line is ready
to go.  As soon as e100.c runs pci_set_master(), the interrupt hits the CPU.
But of course the e100 driver isn't ready to handle the interrupt yet, so the
system disables IRQ #11.

This only happens on warm boots (/sbin/reboot).  Things work OK from power-on.
 So I assume that the BIOS is failing to fully reset the NIC and that some
sort of interrupt is internally pending.

The patch rearranges e100_probe() so that we issue e100_hw_reset() prior to
running pci_set_master(), and fixes the problem.

Note that e100_probe() is now running e100_hw_reset() twice - I didn't remove
the later call for general paranoia reasons.

eepro100.c has the same lockup, and needs a similar fix.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

With help from Patrick McHardy.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: walter harms <wharms@bfs.de>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: walter harms <wharms@bfs.de>
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: David S. Miller <davem@davemloft.net>

Building with gcc -W revealed this warning:
arch/i386/kernel/traps.c: In function `do_general_protection':
arch/i386/kernel/traps.c:506: warning: empty body in an if-statement

upon inspecting the code I see what looks like a mistakenly placed ";"

        if (!fixup_exception(regs)) {
                if (notify_die(DIE_GPF, "general protection fault", regs,
                                error_code, 13, SIGSEGV) == NOTIFY_STOP);
                        return;
                die("general protection fault", regs, error_code);
        }

That ";" after the second if should go away so the return; before die()
is not unconditional.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The patch 'Fix policy update bug when increasing
priority of last policy' broke this, when a policy
with lower priority than an existing policy is inserted
xfrm_policy_insert loops forever.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Was using 'inline static int' for some strange reason.
GCC now complains about this so...
Signed-off-by: Jesped Juhl <juhl-lkml@dif.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Tony Luck <tony.luck@intel.com>

into intel.com:/data/home/aegl/BK/linux-ia64-release-2.6.10

Patch from Ben Dooks

Since alarm fields can be ints, there is the posibility
that the alarm set code needs to check for <0 as a
valid posibility for `any`

Signed-off-by: Ben Dooks
Signed-off-by: Russell King

Patch below fixes a typo in init/Kconfig for option CC_ALIGN_FUNCTIONS.
Signed-off-by: Cal Peake <cp@absolutedigital.net>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Included some of the information given to people developing external modules.
This should answer the typical questions and lay a better ground for adding
new information as needed.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Patch from Deepak Saxena

arch/arm/kernel/head-armv.S is now simply head.S.  This patches updates
references in kernel comments.

Signed-off-by: Deepak Saxena
Signed-off-by: Russell King

Len Brown convinced me that the problem with disabling
PCI routing entries wasn't the disable as much as the
fact that ELCR needs to be updated when removing the PCI
routing. So this reverts the previous cset and updates
ELCR as suggested by Len.

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