Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures that
kernel_ulong_t is correct, but it can't cope with different padding on
different architectures.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

When using Ski to debug early startup, it's a bit of a pain not to
have printk.

This patch enables the simulated console very early.
It may be worth conditionalising on the command line... but this is
enough for now.
Signed-off-by: NPeter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The "ri" field in the processor status register only has defined
values of 0, 1, 2.  Do not let ptrace set this to 3.  As with
other reserved fields in registers we silently discard the value.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

There is a bug in the ia64_do_page_fault code that can cause a failure
to grow the register backing store, or any mapping that is marked as
VM_GROWSUP if the mapping is the highest mapped area of memory.

When the address accessed is below the first mapping the previous mapping
is returned as NULL, and this case is handled.  However, when the address
accessed is above the highest mapping the vma returned is NULL, this
case is not handled correctly, and it fails to spot that this access
might require an existing mapping to grow upwards.
Signed-off-by: NAndrew Burgess <andrew@transitive.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The core cpufreq code doesn't appear to understand returning -EAGAIN
for the get() function of the cpufreq_driver.  If PAL_GET_PSTATE returns
-1, such as when running on Xen, scaling_cur_freq is happy to return
4294967285 kHz (ie. (unsigned)-11).  The other drivers appear to return
0 for a failure, and doing so gives me the max frequency from
scaling_cur_frequency and "<unknown>" from cpuinfo_cur_frequency.  I
believe that's the desired behavior.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

If the interrupt has been disabled, don't call the force_interrupt provider.
Doing so can result in an infinite runaway interrupt loop.
Signed-off-by: NMike Habeck <habeck@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The slab allocator was changed in 2.6.23 to default to SLUB. However,
the config files in arch/ia64/configs still use SLAB. Switch them to SLUB.

Added same change to arch/ia64/defconfig ... Tony
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Explicitly put the unwind section into its own program-header.  This
used to be unnecessary (probably because binutils did it for us), but
with current binutils (e.g., v2.17.50.20070804) we won't get
the PT_IA_64_UNWIND header without this patch which will break
unwinding in a debugger and simulators such as Ski.
Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add NOTES to linker script such that the kernel can be built with
recent versions of binutils.  Without this patch, final link fails
with this error:

ld: .tmp_vmlinux1: section `.text' can't be allocated in segment 0
ld: final link failed: Bad value

This error is due to the fact that the --build-id option is used
with newer linkers to include a .notes section on the kernel, but
without the NOTES macro, that section won't be included in the kernel
which then leads to the above error message.
Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add a dummy nop at the end of _start() to maintain the invariant that
the return-pointer (rp) always point to the calling function.  This
makes unwinding stop at the last frame, as it should.
Signed-off-by: NDavid Mosberger-Tang <dmosberger@gmail.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Use local_vector_to_irq() instead of looping through all NR_IRQS.
This avoids registering the CPE handler on multiple irqs.  Only
register if the irq is valid.  If no valid irq is found, print an
error message and set up polling.
Signed-off-by: NRuss Anderson <rja@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

arch/ia64/Kconfig failed to include kernel/Kconfig.preempt that meant it
did not support PREEMPT_VOLUNTARY and PREEMPT_BKL (inadvertently).
This was recently noticed when the newly-added PREEMPT_NOTIFIERS in
Kconfig.preempt that was "select"ed from drivers/kvm/Kconfig (therefore)
started giving bogus warnings ('select' used by config symbol 'KVM' refers
to undefined symbol 'PREEMPT_NOTIFIERS') on ia64 builds.

So let's remove the open-coded definition of CONFIG_PREEMPT in
arch/ia64/Kconfig and replace it with just including Kconfig.preempt
instead, like the other archs do.
Signed-off-by: NSatyam Sharma <satyam@infradead.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add base support for implementing platform_irq_to_vector(), and
then use it on SN2.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The routines ia64_atomic64_{add,sub} mistakenly use
atomic_read() to grab the old value instead of using
atomic64_read().
Signed-off-by: NAndreas Schwab <schwab@suse.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

While sending interrupts to a cpu to repeatedly wake a thread, on occasion
that thread will take a full timer tick cycle (4002 usec in my case)
to wakeup.

The problem concerns a race condition in the code around the safe_halt()
call in the default_idle() routine.  Setting 'nohalt' on the kernel
command line causes the long wakeups to disappear.

void
default_idle (void)
{
        local_irq_enable();
        while (!need_resched()) {
-->             if (can_do_pal_halt)
-->                     safe_halt();
                else

A timer tick could arrive between the check for !need_resched and the
actual call to safe_halt() (which does a pal call to PAL_HALT_LIGHT).
By the time the timer tick completes, a thread that might now need to run
could get held up for as long as a timer tick waiting for the halted cpu.

I'm proposing that we disable irq's and check need_resched again before
calling safe_halt().  Does anyone see any problem with this approach?
Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched:
  sched: run_rebalance_domains: s/SCHED_IDLE/CPU_IDLE/
  sched: fix sleeper bonus
  sched: make global code static

Level type interrupts do not need to be resent.  It was also found that
some chipsets get confused in case of the resend.

Mark the ioapic level type interrupts as such to avoid the resend
functionality in the generic irq code.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Level type interrupts are resent by the interrupt hardware when they are
still active at irq_enable().

Suppress the resend mechanism for interrupts marked as level.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 5a43a066: "genirq: Allow fasteoi
handler to retrigger disabled interrupts" was erroneously applied to
handle_level_irq().  This added the irq retrigger / resend functionality
to the level irq handler.

Revert the offending bits.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

rebalance_domains(SCHED_IDLE) looks strange (typo), change it to CPU_IDLE.

the effect of this bug was slightly more agressive idle-balancing on
SMP than intended.
Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Peter Ziljstra noticed that the sleeper bonus deduction code
was not properly rate-limited: a task that scheduled more
frequently would get a disproportionately large deduction.
So limit the deduction to delta_exec.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This patch makes the following needlessly global code static:

- arch_reinit_sched_domains()
- struct attr_sched_mc_power_savings
- struct attr_sched_smt_power_savings
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (28 commits)
  ACPI: thermal: add DMI hooks to handle AOpen's broken Award BIOS
  ACPI: thermal: create "thermal.act=" to disable or override active trip point
  ACPI: thermal: create "thermal.nocrt" to disable critical actions
  ACPI: thermal: create "thermal.psv=" to override passive trip points
  ACPI: thermal: expose "thermal.tzp=" to set global polling frequency
  ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support
  ACPI: thinkpad-acpi: fix sysfs paths in documentation
  ACPI: static
  ACPI EC: remove potential deadlock from EC
  ACPI: dock: Send key=value pair instead of plain value
  ACPI: bay: send envp with uevent - fix
  acpi-cpufreq: Fix some x86/x86-64 acpi-cpufreq driver issues
  ACPI: fix "Time Problems with 2.6.23-rc1-gf695baf2"
  ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
  ACPI: EC: fix run-together printk lines
  ACPI: sbs: remove dead code
  ACPI: EC: acpi_ec_remove(): fix use-after-free
  ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT.
  ACPI: EC: fix build warning
  ACPI: EC: If ECDT is not found, look up EC in DSDT.
  ...

Commit 3320ad99 broke mmio config space
accesses totally on i386 - it dropped the "reg" offset to the address.

Cc: dean gaudet <dean@arctic.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

apply_alternatives uses memcpy() to apply alternatives.  Which has the
unfortunate effect that while applying memcpy alternative to memcpy
itself it tries to overwrite itself with nops - which causes #UD fault
as it overwrites half of an instruction in copy loop, and from this
point on only possible outcome is triplefault and reboot.

So let's overwrite only first two instructions of memcpy - as long as
the main memcpy loop is not in first two bytes it will work fine.
Signed-off-by: NPetr Vandrovec <petr@vandrovec.name>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use DMI to:
1. enable polling (BIOS thermal events are broken)
2. disable active trip points (BIOS fan control is broken)
3. disable passive trip point (BIOS hard-codes it too low)

The actual temperature reading does work,
and with the aid of polling, the critical
trip point should work too.

http://bugzilla.kernel.org/show_bug.cgi?id=8842Signed-off-by: NLen Brown <len.brown@intel.com>

thermal.act=-1 disables all active trip points
in all ACPI thermal zones.

thermal.act=C, where C > 0, overrides all lowest temperature
active trip points in all thermal zones to C degrees Celsius.
Raising this trip-point may allow you to keep your system silent
up to a higher temperature.  However, it will not allow you to
raise the lowest temperature trip point above the next higher
trip point (if there is one).  Lowering this trip point may
kick in the fan sooner.

Note that overriding this trip-point will disable any BIOS attempts
to implement hysteresis around the lowest temperature trip point.
This may result in the fan starting and stopping frequently
if temperature frequently crosses C.

WARNING: raising trip points above the manufacturer's defaults
may cause the system to run at higher temperature and shorten
its life.
Signed-off-by: NLen Brown <len.brown@intel.com>

thermal.nocrt=1 disables actions on _CRT and _HOT
ACPI thermal zone trip-points.  They will be marked
as <disabled> in /proc/acpi/thermal_zone/*/trip_points.

There are two cases where this option is used:

1. Debugging a hot system crossing valid trip point.

   If your system fan is spinning at full speed,
   be sure that the vent is not clogged with dust.
   Many laptops have very fine thermal fins that are easily blocked.

   Check that the processor fan-sink is properly seated,
   has the proper thermal grease, and is really spinning.

   Check for fan related options in BIOS SETUP.
   Sometimes there is a performance vs quiet option.
   Defaults are generally the most conservative.

   If your fan is not spinning, yet /proc/acpi/fan/
   has files in it, please file a Linux/ACPI bug.

   WARNING: you risk shortening the lifetime of your
   hardware if you use this parameter on a hot system.
   Note that this refers to all system components,
   including the disk drive.

2. Working around a cool system crossing critical
   trip point due to erroneous temperature reading.

   Try again with CONFIG_HWMON=n
   There is known potential for conflict between the
   the hwmon sub-system and the ACPI BIOS.
   If this fixes it, notify lm-sensors@lm-sensors.org
   and linux-acpi@vger.kernel.org

   Otherwise, file a Linux/ACPI bug, or notify
   just linux-acpi@vger.kernel.org.
Signed-off-by: NLen Brown <len.brown@intel.com>

"thermal.psv=-1" disables passive trip points
for all ACPI thermal zones.

"thermal.psv=C", where 'C' is degrees Celsius,
overrides all existing passive trip points
for all ACPI thermal zones.

thermal.psv is checked at module load time,
and in response to trip-point change events.

Note that if the system does not deliver thermal zone
temperature change events near the new trip-point,
then it will not be noticed.  To force your custom
trip point to be noticed, you may need to enable polling:
eg. thermal.tzp=3000 invokes polling every 5 minutes.

Note that once passive thermal throttling is invoked,
it has its own internal Thermal Sampling Period (_TSP),
that is unrelated to _TZP.

WARNING: disabling or raising a thermal trip point
may result in increased running temperature and
shorter hardware lifetime on some systems.
Signed-off-by: NLen Brown <len.brown@intel.com>

Thermal Zone Polling frequency (_TZP) is an optional ACPI object
recommending the rate that the OS should poll the associated thermal zone.

If _TZP is 0, no polling should be used.
If _TZP is non-zero, then the platform recommends that
the OS poll the thermal zone at the specified rate.
The minimum period is 30 seconds.
The maximum period is 5 minutes.

(note _TZP and thermal.tzp units are in deci-seconds,
 so _TZP = 300 corresponds to 30 seconds)

If _TZP is not present, ACPI 3.0b recommends that the
thermal zone be polled at an "OS provided default frequency".

However, common industry practice is:
1. The BIOS never specifies any _TZP
2. High volume OS's from this century never poll any thermal zones

Ie. The OS depends on the platform's ability to
provoke thermal events when necessary, and
the "OS provided default frequency" is "never":-)

There is a proposal that ACPI 4.0 be updated to reflect
common industry practice -- ie. no _TZP, no polling.

The Linux kernel already follows this practice --
thermal zones are not polled unless _TZP is present and non-zero.

But thermal zone polling is useful as a workaround for systems
which have ACPI thermal control, but have an issue preventing
thermal events.  Indeed, some Linux distributions still
set a non-zero thermal polling frequency for this reason.

But rather than ask the user to write a polling frequency
into all the /proc/acpi/thermal_zone/*/polling_frequency
files, here we simply document and expose the already
existing module parameter to do the same at system level,
to simplify debugging those broken platforms.

Note that thermal.tzp is a module-load time parameter only.
Signed-off-by: NLen Brown <len.brown@intel.com>