Adds basic infrastructure to allow subsystems to reserve performance
counters on the x86 chips.  Only UP kernels are supported in this patch to
make reviewing easier.  The SMP portion makes a lot more changes.

Think of this as a locking mechanism where each bit represents a different
counter.  In addition, each subsystem should also reserve an appropriate
event selection register that will correspond to the performance counter it
will be using (this is mainly neccessary for the Pentium 4 chips as they
break the 1:1 relationship to performance counters).

This will help prevent subsystems like oprofile from interfering with the
nmi watchdog.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

This makes merging easier.  They are readded a few patches later.
Signed-off-by: NAndi Kleen <ak@suse.de>

There are some machines around (large xSeries or Unisys ES7000) that
need physical IO-APIC destination mode to access all of their IO
devices. This currently doesn't work in UP kernels as used in
distribution installers.

This patch allows to compile even UP kernels as GENERICARCH which
allows to use physical or clustered APIC mode.
Signed-off-by: NAndi Kleen <ak@suse.de>

This is based on the x86-64 defconfig which works on a wide range of systems.
Signed-off-by: NAndi Kleen <ak@suse.de>

If there is only 1 node in the system cpus should think they are apart of
some other node.

If cases where a real numa system boots the Flat numa option make sure the
cpus don't claim to be apart on a non-existent node.
Signed-off-by: NKeith Mannthey <kmannth@us.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With CONFIG_PHYSICAL_START set to a non default values the i386
boot_ioremap code calculated its pte index wrong and users of boot_ioremap
have their areas incorrectly mapped (for me SRAT table not mapped during
early boot).  This patch removes the addr < BOOT_PTE_PTRS constraint.

[ Keith says this is applicable to 2.6.16 and 2.6.17 as well ]

Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: <stable@kernel.org>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

sw_any_bug_dmi_table can be used on resume, so it isn't initdata.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NDave Jones <davej@redhat.com>

Now that the tfm is passed directly to setkey instead of the ctx, we no
longer need to pass the &tfm->crt_flags pointer.

This patch also gets rid of a few unnecessary checks on the key length
for ciphers as the cipher layer guarantees that the key length is within
the bounds specified by the algorithm.

Rather than testing dia_setkey every time, this patch does it only once
during crypto_alloc_tfm.  The redundant check from crypto_digest_setkey
is also removed.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The patch passed the trycpt tests and automated filesystem tests.
This rewrite resulted in some nice perfomance increase over my last patch.

Short summary of the tcrypt benchmarks:

Twofish Assembler vs. Twofish C (256bit 8kb block CBC)
encrypt: -33% Cycles
decrypt: -45% Cycles

Twofish Assembler vs. AES Assembler (128bit 8kb block CBC)
encrypt: +3%  Cycles
decrypt: -22% Cycles

Twofish Assembler vs. AES Assembler (256bit 8kb block CBC)
encrypt: -20% Cycles
decrypt: -36% Cycles

Full Output:
http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-asm-i586.txt
http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-twofish-c-i586.txt
http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-aes-asm-i586.txt


Here is another bonnie++ benchmark with encrypted filesystems. All runs with
the twofish assembler modules max out the drivespeed. It should give some
idea what the module can do for encrypted filesystem performance even though
you can't see the full numbers.

http://homepages.tu-darmstadt.de/~fritschi/twofish/output_20060611_205432_x86.htmlSigned-off-by: NJoachim Fritschi <jfritschi@freenet.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This reverts commits 11012d41 and
40dd2d20, which allowed us to use the
MMIO accesses for PCI config cycles even without the area being marked
reserved in the e820 memory tables.

Those changes were needed for EFI-environment Intel macs, but broke some
newer Intel 965 boards, so for now it's better to revert to our old
2.6.17 behaviour and at least avoid introducing any new breakage.

Andi Kleen has a set of patches that work with both EFI and the broken
Intel 965 boards, which will be applied once they get wider testing.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

(And reset it on new thread creation)

It turns out that eflags is important to save and restore not just
because of iopl, but due to the magic bits like the NT bit, which we
don't want leaking between different threads.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add the CPU identification needed by oprofile for Intel (r) Core (tm) 2
CPUs.
Signed-off-by: NBenjamin LaHaise <benjamin.c.lahaise@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: "Arun Sharma" <aruns@google.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Take default arch/*/kernel/audit.c to lib/, have those with special
needs (== biarch) define AUDIT_ARCH in their Kconfig.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

add support for AUDIT_PERM predicate
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Some buggy BIOSes do a "software any" kind of coordination without telling
about it to OS. So, when OS sets frequency on one CPU on these platforms,
it will also impact all the other logical CPUs that are in the same power
domain. Attached patch is a workaround for those buggy BIOSes.
Patch should be a noop on the normal non-buggy platforms.

Applies over previously sent acpi-cpufreq and software coordination
bug fix patch
Signed-off-by: NDenis Sadykov <denis.m.sadykov@intel.com>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Rename option "dont_scale_voltage" to "scale_voltage" because
don't will be default.
Use "pos" for calculating voltage. In this way driver don't need
to know mV value or low level value. Simply min U is one pos and
max U is second pos. All pos between these two are used.
Assume that min U is for min f and max U for max f. For frequency
between min and max calculate pos based on difference between
current frequency and min f.
Values in mobile VRM table changed to values from
C3-M datasheet.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

Apparently some systems export valid HPET addresses, but hpet_enable()
fails.  Then when the HPET clocksource starts up, it only checks for a
valid HPET address, and the result is a system where time does not advance.

See http://bugme.osdl.org/show_bug.cgi?id=7062 for details.

This patch just makes sure we better check that the HPET is functional
before registering the HPET clocksource.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There was a bogus hunk from the genirq merge that essentially
broke stack switching for hard interrupts. Remove it since it isn't
needed.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

As a replacement for the earlier removal of the e820 MCFG check
we blacklist the Intel SDV with the original BIOS bug that
motivated that check. On those machines don't use MMCONFIG.

This also adds a new pci=mmconf parameter to override the blacklist.

Cc: Greg KH <gregkh@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The unwinder fallback logic still had potential for falling through to
the legacy stack trace code without printing an indication (at once
serving as a separator) of this.

Further, the stack pointer retrieval for the fallback should be as
restrictive as possible (in order to avoid having the legacy stack
tracer try to access invalid memory). The patch tightens that, but
this could certainly be further improved.

Also making the call_trace command line option now conditional upon
CONFIG_STACK_UNWIND (as it's meaningless otherwise).
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

One open question: Should this added push perhaps be made conditional
upon CONFIG_STACK_UNWIND or CONFIG_UNWIND_INFO?
[AK: not needed, these are all very slow paths]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The check for the MCFG table being reserved in the e820 map was originally
added to detect a broken BIOS in a preproduction Intel SDV. However it also
breaks the Apple x86 Macs, which can't supply this properly, but need
a working MCFG. With this patch they wouldn't use the MCFG and not work.

After some discussion I think it's best to remove the heuristic again.
It also failed on some other boxes (although it didn't cause much
problems there because old style port access for PCI config space
still works as fallback), but the preproduction SDVs can just use
pci=nommcfg. Supporting production machines properly is more
important.

Edgar Hucek did all the debugging work.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When we select NUMA with i386, the system is only X86_NUMAQ or using ACPI.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Ignore the return value of early_init_acpi(), as it can give false error
messages.  If there is something really wrong, then register_driver will
fail cleanly with EINVAL later.

[ background: modprobe acpi-cpufreq on systems not capable of speed-scaling
  started failing with 'invalid argument', where previously it would only
  ever -ENODEV

  I'm not 100% happy with the solution. It'd be better to handle
  failure properly, but this is a low-impact change for 2.6.18
  We can always revisit doing this better in .19   --davej.]
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On i386 PCI mmconfig forgets the bus number when setting the fallback_slots
bits which means fallback to conf1 only works for bus 0.
Signed-off-by: NDaniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

there was a change in 2.6.17 which affected the order in which the PCI
access methods are probed.  this gives regressions on some machines with
broken BIOS.  the problem is that PCBIOS sometimes reports last bus wrong,
leaving cardbus non-funcational.  previously those system worked fine with
direct access.

The patch changes the PCI init code to have PCBIOS as last fallback, yet
the PCBIOS code still has to run first to set pcibios_last_bus to the value
reported by the BIOS.  this is needed in case legacy PCI probing
(arch/i386/pci/legacy.c) is used to detect peer busses.  using direct
access if available fixes the cardbus problems.
Signed-off-by: NDaniel Ritz <daniel.ritz@gmx.ch>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ACPI 3.0 appended a variable length UID string to the LAPIC structure
as part of support for > 256 processors.  So the BAD_MADT_ENTRY() sanity
check can no longer compare for equality with a fixed structure length.
Signed-off-by: NAlexey Y Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

A BIOS has been found that resumes from S3 to the routine that invoked suspend,
ignoring the resume vector.  This appears to the OS as a failed S3 attempt.

This same system suspend/resume's properly with Windows.

It is possible to invoke the protected mode register restore routine (which
would normally restore the sysenter registers) when the BIOS returns from
S3.  This has no effect on a correctly running system and repairs the
damage from the deviant BIOS.
Signed-off-by: NWilliam Morrow <william.morrow@amd.com>
Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Previously the message was "Fatal exception: panic_on_oops", as introduced
in a recent patch whith removed a somewhat dangerous call to ssleep() in
the panic_on_oops path.  However, Paul Mackerras suggested that this was
somewhat confusing, leadind people to believe that it was panic_on_oops
that was the root cause of the fatal exception.  On his suggestion, this
patch changes the message to simply "Fatal exception".  A suitable oops
message should already have been displayed.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some laptops with VIA C3 processor, CLE266 chipset and
AMI BIOS have incorrect latency values in FADT table. These
laptops seems to be C3 capable, but latency values are to
big: 101 for C2 and 1017 for C3. This option will allow
user to skip C3 latency test but not C3 address test. AMI
BIOS is setting C3 address to correct value in DSDT table.
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

ACPI C3 works for "Powersaver" processors, so use it only for them.

Older CPU will change frequency on "halt" only. But we can protect transition
in two ways:
- by ACPI PM2 register, there is "bus master arbiter disable" bit.
  This isn't tested because VIA mainboards don't have PM2 register,
- by PLE133 PCI/AGP arbiter disable register.
  There are two bits in this register. First is "PCI arbiter disable",
  second "AGP arbiter disable". This is working on VIA Epia 800 mainboards.

Test on bm_control is more proper because this is true
when PM2 register exist.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

Note how any error from acpi_processor_preregister_performance is ignored.

From: bert hubert <bert.hubert@netherlabs.nl>
Signed-off-by: NDave Jones <davej@redhat.com>

This table is only used by Ezra-T CPUs currently, and has values
for some other CPU. Fix them to match the values used by that CPU,
and for now make it clearer by renaming the variable.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This is changing "always true" test to something usefull.
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

I lost very important line in do_powersaver
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch makes the needlessly global longhaul_walk_callback() static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>

It seems commit 32ee8c3e accidentially
reverted cdc9cc1d, IOW, it reintroduced
the following compile error with CONFIG_PCI=n:

<--  snip  -->

...
  CC      arch/i386/kernel/cpu/cpufreq/gx-suspmod.o
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c: In function ‘gx_detect_chipset’:
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: error: implicit declaration of function ‘pci_match_id’
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:193: warning: comparison between pointer and integer
make[3]: *** [arch/i386/kernel/cpu/cpufreq/gx-suspmod.o] Error 1

<--  snip  -->

This patch therefore re-adds the dependency of X86_GX_SUSPMOD on PCI.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>

Without this longhaul will always fail when compiled into kernel,
as it needs to initialise after the ACPI processor module.

I lost this when I was splitting patches. Sorry.
Signed-off-by: NRafa Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>

There is no need to worry about local APIC.
There is need to worry about I/O APIC, because I/O APIC
is replacing good old 8259. According to Nehemiah datasheet VIA is
using 3-wire bus to connect local APIC to I/O APIC.

"[...] When IA32_APIC_BASE[11] is set to 0, processor APICs based on the 3-wire APIC
 bus cannot be generally re-enabled until a system hardware reset. The 3-wire bus
 looses track of arbitration that would be necessary for complete re-enabling. Certain
 (local) APIC functionality can be enabled. [...]"

So we must set disable bit for each interrupt in I/O APIC registers.
Same situation as for PIC - we must poke registers direcly.
How to do this? I don't know. So at the moment it is better to fail.
Signed-off-by: NRafa³ Bilski <rafalbilski@interia.pl>
Signed-off-by: NDave Jones <davej@redhat.com>