When the sparse mem changes and the kexec changes
were merged into setup.c they came in, in the wrong order.
This patch changes the order so we don't run sparse_init
which uses the bootmem allocator until we all of the
reserve_bootmem calls has been made.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Another x86 subarchitecture bit I missed.  This adds both
machine_emergency_restart missed in my reboot fixes and
machine_shutdown needed for kexec support.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Here is one more bit of breakage my x86 sub-architecture
confusion caused.

Add machine_shutdown to voyager so it will compile with CONFIG_KEXEC.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When we did the handle_mm_fault cleanup and get_user_page() race fixes,
handle_mm_fault turned into an inline function that called the real
__handle_mm_fault() code.  The export needed for MOL on ppc wasn't
updated to match the new world order, though.

Turn it into a GPL export while at it, since this is all about internal
interfaces and MOL is GPL'd anwyay.

These bugs have been fixed in the standard zlib for a while.

See for example

 a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
 b) http://bugs.gentoo.org/show_bug.cgi?id=94584Signed-off-by: NTim Yamin <plasmaroo@gentoo.org>
Signed-off-by: NTavis Ormandy <taviso@gentoo.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

[PATCH] i386: Implement machine_emergency_reboot

introduced this new function into arch/i386/reboot.c.  However,
subarchitectures are entitled to implement their own copies of reboot.c
from which this new function is now missing.

It looks like visws will also need a similar fixup
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In yenta_socket, we default to using the resource setting of the CardBus
bridge.  However, this is a PCI-bus-centric view of resources and thus needs
to be converted to generic resources first.  Therefore, add a call to
pcibios_bus_to_resource() call in between.  This function is a mere wrapper on
x86 and friends, however on some others it already exists, is added in this
patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where
is its pcibios_resource_to_bus() ?).
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0.  This leaves such
a device in an inaccessible state.  The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot.  Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification.  This is
especially true since often many devices are covered by the same
driver.  It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register.  I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource.  Unfortunately, that does not currently exist
for the sparc64 architecture.  The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The IA32 ptrace emulation currently returns the wrong registers for fs/gs;
it's returning what x86_64 calls gs_base.  We need regs.gsindex in order
for GDB to correctly locate the TLS area.  Without this patch, the 32-bit
GDB testsuite bombs on a 64-bit kernel.  With it, results look about like
I'd expect, although there are still a handful of kernel-related failures
(vsyscall related?).
Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
Acked-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We had a user whose apps weren't working correctly because his "rtc" wasn't
working fully.

For the sake of simplicity, it seems sensible to always enable HPET RTC
emulation.

Remove a special config option for HPET_EMULATE_RTC and make it directly
depend on HPET_TIMER and RTC. This will avoid the hangs when EMULATE_RTC
is not configured and when some userlevel script depends on RTC interrupt,
as in:

http://bugzilla.kernel.org/show_bug.cgi?id=4904Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The kexec boot is not successful on some power machines since all CPUs are
getting removed from global interrupt queue (GIQ) before kexec boot.  Some
systems always expect at least one CPU in GIQ.  Hence, this patch will make
sure that only secondary CPUs are removed from GIQ.
Signed-off-by: NHaren Myneni <hbabu@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

CONFIG_KEXEC breaks UP builds because of a misspelled smp_release_cpus().
Also, the function isn't defined unless built with CONFIG_SMP but it is
needed if we are to go from a UP to SMP kernel.  Enable it and document it.

Thanks to Steven Winiecki for reporting this and to Milton for remembering
how it's supposed to work and why.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch from Michael Gernoth

As discussed on the handhelds.org Jornada mailinglist, I take over
maintainership of the currently unmaintained Jornada 720-port in
the mainline kernel.
Signed-off-by: NMichael Gernoth <michael@gernoth.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix up arm26, cris, frv, m68k, parisc and sh64 too..

x86_64 had hardcoded the VM_ numbers so it broke down when the numbers
were changed.
Signed-off-by: NAlexander Nyberg <alexn@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch from Richard Purdie

Fix a typo causing a warning in the arm oprofile backtrace code.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ARM fault handler is optimised to make the fast path, err, fast.
The renumbering of the VM_FAULT_* codes broke this because numbers
were used instead of the definitions.  Fix this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Deepak Saxena

This allows the serial driver autconf to work properly on all the IXP
serial ports. W/o it we basically put the serial port in an unrecoverable
state and lose console.
Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Catalin Marinas

The IEEE 754 standard specifies that the result of (x - x), where x is
a valid number, should be -0 if the rounding mode is towards minus
infinity or +0 otherwise.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Deepak Saxena

The XScale locking code is not something that has been validated
on 2.6 and needs to be replaced with a more generic API to use
with other ARMs that support locking features.
Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Richard Purdie

NWFPE used global variables which meant it wasn't safe for use with
preemptive kernels. This patch removes them and communicates the
information between functions in a preempt safe manner. Generation
of some exceptions was broken and this has also been corrected.
Tests with glibc's maths test suite show no change in the results
before/after this patch.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The default clock rate does not specify a maximum, so the
default of 400KHz is used. This rate is too fast for the PMU
on the EB2410ITX, so we now specify platform data with a rate
of around 100KHz.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

For soft reset during system hang, got an error "CPU did not take
control" for some CPUs even though they responded to soft-reset (called
SystemReset, die and called debugger - xmon).   First these CPUs entered
into xmon by IPI callback and then got a soft-reset exception and
re-entered into xmon again. The first CPU which re-entered into xmon got
the output lock and made into xmon successfully without unlocking.
Hence, the next CPU(s) which re-entered into xmon try to acquire a lock
(get_output_lock). Therefore, we can not view state of those CPU(s).

[This is a simple, very low risk, obvious fix for an obvious bug, and
should go into 2.6.13.  -- paulus]
Signed-off-by: NHaren Myneni <hbabu@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If CONFIG_NUMA is set, some POWER 4 systems will fail to boot.  This is
because of special processing needed to handle invalid node IDs (0xffff) on
POWER 4.  My previous patch to handle memory 'holes' within nodes forgot to
add this special case for POWER 4 in one place.

In reality, I'm not sure that configuring the kernel for NUMA on POWER 4 makes
much sense.  Are there POWER 4 based systems with NUMA characteristics that
are presented by the firmware?  But, distros want one kernel for all systems
so NUMA is on by default in their kernels.  The patch handles those cases.
Signed-off-by: NMike Kravetz <kravetz@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There was a scheduling problem of the m32r SMP kernel; A process rarely
stopped and gave no responding but the other process have been handled by
the other CPU still lives, then if we did something in the other terminal
or something like that, the stopped process came back to life and continued
its operation...  (ex.  LMbench: lat_sig)

In the m32r SMP kernel, a local-timer event is delivered by using an
IPI(inter processor interrupts); LOCAL_TIMER_IPI.  And a function
smp_send_timer() is prepared to send the LOCAL_TIMER_IPI from the current
CPU to the other CPUs.

The funtion smp_send_timer() was placed and used in do_IRQ() in
former times (before 2.6.10-rc3-mm1 kernel), however, it was
unintentionally removed when arch/m32r/kernel/irq.c was modified to
employ the generic hardirq framework (CONFIG_GENERIC_HARDIRQ) in
my previous patch.

  [PATCH 2.6.10-rc3-mm1] m32r: Use generic hardirq framework
  http://www.ussg.iu.edu/hypermail/linux/kernel/0412.2/0358.html

The following patch fixes the above problem.
Signed-off-by: NHitoshi Yamamoto <hitoshiy@isl.melco.co.jp>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add system calls for io priorities and inotify.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Disable pseudo page fault handling before starting the new kernel and try
to use diag308 to reset the machine.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add Bamboo platform defconfig
Signed-off-by: NWade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: NMatt Porter <mporter@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add Bamboo platform support.  This is an AMCC 440EP-based reference platform.
Signed-off-by: NWade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: NMatt Porter <mporter@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add PPC440EP core support.  PPC440EP is a PPC440-based SoC with a classic PPC
FPU and another set of peripherals.
Signed-off-by: NWade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: NMatt Porter <mporter@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Marked APUS and GEMINI as BROKEN since they do not build at the platform
level.  We have requested that the maintainers of these boards/platforms
fix them by the time 2.6.15 is released or we plan on concerning them
unmaintained and thus removing them.
Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The code that sets the altivec capability of the CPU based on firmware
informations can enable altivec when the kernel has CONFIG_ALTIVEC
disabled.  This results in "interesting" crashes.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We know that the randomisation slows down some workloads on Transmeta CPUs
by quite large amounts.  We think it's because the CPU needs to recode the
same x86 instructions when they pop up at a different virtual address after
a fork+exec.

So disable randomization by default on those CPUs.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This removes sys_set_zone_reclaim() for now.  While i'm sure Martin is
trying to solve a real problem, we must not hard-code an incomplete and
insufficient approach into a syscall, because syscalls are pretty much
for eternity.  I am quite strongly convinced that this syscall must not
hit v2.6.13 in its current form.

Firstly, the syscall lacks basic syscall design: e.g. it allows the
global setting of VM policy for unprivileged users. (!) [ Imagine an
Oracle installation and a SAP installation on the same NUMA box fighting
over the 'optimal' setting for this flag. What will they do? Will they
try to set the flag to their own preferred value every second or so? ]

Secondly, it was added based on a single datapoint from Martin:

 http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2

where Martin characterizes the numbers the following way:

 ' Run-to-run variability for "make -j" is huge, so these numbers aren't
   terribly useful except to see that with reclaim the benchmark still
   finishes in a reasonable amount of time. '

in other words: the fundamental problem has likely not been solved, only
a tendential move into the right direction has been observed, and a
handful of numbers were picked out of a set of hugely variable results,
without showing the variability data. How much variance is there
run-to-run?

I'd really suggest to first walk the walk and see what's needed to get
stable & predictable kernel compilation numbers on that NUMA box, before
adding random syscalls to tune a particular aspect of the VM ... which
approach might not even matter once the whole picture has been analyzed
and understood!

The third, most important point is that the syscall exposes VM tuning
internals in a completely unstructured way. What sense does it make to
have a _GLOBAL_ per-node setting for 'should we go to another node for
reclaim'? If then it might make sense to do this per-app, via numalib or
so.

The change is minimalistic in that it doesnt remove the syscall and the
underlying infrastructure changes, only the user-visible changes.  We
could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
/proc/sys/vm/swappiness, but even that looks quite counterproductive
when the generic approach is that we are trying to reduce the number of
external factors in the VM balance picture.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The patch adds boundary check for the MAX_GSI_NUM.  Same as the update for
i386, the patch addresses a problem with ACPI SCI IRQ.  The patch corrects
the code such that SCI IRQ is skipped and duplicate entry is avoided.  The
VIA chipset uses 4-bit IRQ register for internal interrupt routing, and
therefore cannot handle IRQ numbers assigned to its devices.  The patch
corrects this problem by allowing PCI IRQs below 16.
Signed-off-by: NNatalie Protasevich <Natalie.Protasevich@unisys.com>
Acked-by: NAndi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I was observing reproducible crashes on the "movw %bx,(%rsi)" instruction
below while a process in a recvfrom() system call was copying packet data
to user space.  The patch below fixes the exception table and causes the
crash to no longer reproduce.  Please apply.
Acked-by: NAndi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix 44x early serial debugging for big RAM configurations (more than 512M).
 We cannot use default OpenBIOS virtual mapping, because it interferes with
pinned TLB entry.

While we are at it, move early UART mapping to TLB slot 0, so it can
survive longer during boot process (slot 1 is used by the first ioremap
call, effectively killing UART mapping if it occupies this slot).  Also,
change UART TLB entry size to 4K (256M is too much for a bunch of registers
:).  Squash some warnings on the way.

Tested on Ebony and Ocotea with 1G of RAM.

Thanks to Scott Coulter <scott.coulter@cyclone.com> for diagnosing this
problem.
Signed-off-by: NEugene Surovegin <ebs@ebshome.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

inotify system call support for PPC64

[ I don't think we need sys32 compatibility versions--and if we do, I
failed in life. ]
Signed-off-by: NRobert Love <rml@novell.com>
Acked-by: NPaul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add inotify system call stubs to PPC32.
Signed-off-by: NRobert Love <rml@novell.com>
Acked-by: NPaul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>