lwn.git/arch/x86_64/kernel/setup.c, branch docs-next

x86_64: prepare shared kernel/setup.c

2007-10-11T09:14:31+00:00

Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar

Revert "x86-64: Disable local APIC timer use on AMD systems with C1E"

2007-09-26T22:43:41+00:00

This reverts commit e66485d747505e9d960b864fc6c37f8b2afafaf0, since Rafael Wysocki noticed that the change only works for his in -mm, not in mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken on his hardware, but that's apparently not a regression, just a symptom of the same issue that causes the automatic apic timer disable to not work). It turns out that it really doesn't work correctly on x86-64, since x86-64 doesn't use the generic clock events for timers yet. Thanks to Rafal for testing, and here's the ugly details on x86-64 as per Thomas: "I just looked into the code and the logic vs. noapictimer on SMP is completely broken. On i386 the noapictimer option not only disables the local APIC timer, it also registers the CPUs for broadcasting via IPI on SMP systems. The x86-64 code uses the broadcast only when the local apic timer is active, i.e. "noapictimer" is not on the command line. This defeats the whole purpose of "noapictimer". It should be there to make boxen work, where the local APIC timer actually has a hardware problem, e.g. the nx6325. The current implementation of x86_64 only fixes the ACPI c-states related problem where the APIC timer stops in C3(2), nothing else. On nx6325 and other AMD X2 equipped systems which have the C1E enabled we run into the following: PIT keeps jiffies (and the system) running, but the local APIC timer interrupts can get out of sync due to this C1E effect. I don't think this is a critical problem, but it is wrong nevertheless. I think it's safe to revert the C1E patch and postpone the fix to the clock events conversion." On further reflection, Thomas noted: "It's even worse than I thought on the first check: "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot CPU apic timer from being used. But the secondary CPU is still unconditionally setting up the APIC timer and uses the non calibrated variable calibration_result, which is of course 0, to setup the APIC timer. Wreckage guaranteed." so we'll just have to wait for the x86 merge to hopefully fix this up for x86-64. Tested-and-requested-by: Rafael J. Wysocki Acked-by: Thomas Gleixner Signed-off-by: Linus Torvalds

x86-64: Disable local APIC timer use on AMD systems with C1E

2007-09-26T16:22:04+00:00

commit 3556ddfa9284a86a59a9b78fe5894430f6ab4eef titled [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64 X2) with C1E enabled: When both cores go into idle at the same time, then the system switches into C1E state, which is basically the same as C3. This stops the local apic timer. This was debugged right after the dyntick merge on i386 and despite the patch title it fixes only the 32 bit path. x86_64 is still missing this fix. It seems that mainline is not really affected by this issue, as the PIT is running and keeps jiffies incrementing, but that's just waiting for trouble. -mm suffers from this problem due to the x86_64 high resolution timer patches. This is a quick and dirty port of the i386 code to x86_64. I spent quite a time with Rafael to debug the -mm / hrt wreckage until someone pointed us to this. I really had forgotten that we debugged this half a year ago already. Sigh, is it just me or is there something yelling arch/x86 into my ear? Signed-off-by: Thomas Gleixner Tested-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds

ACPI: restore CONFIG_ACPI_SLEEP

2007-07-29T23:53:59+00:00

Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, but now shadowing the new CONFIG_PM_SLEEP option. Signed-off-by: Len Brown [ Modified to work with the PM config setup changes. ] Signed-off-by: Linus Torvalds

ACPI: Kconfig: remove CONFIG_ACPI_SLEEP from source

2007-07-25T05:29:39+00:00

As it was a synonym for (CONFIG_ACPI && CONFIG_X86), the ifdefs for it were more clutter than they were worth. For ia64, just add a few stubs in anticipation of future S3 or S4 support. Signed-off-by: Len Brown

x86_64: Set K8 CPUID flag for K8/Fam10h/Fam11h

2007-07-22T18:03:38+00:00

Previously this flag was only used on 32bit, but some shared code can use it now. Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds

i386: Add L3 cache support to AMD CPUID4 emulation

2007-07-22T01:37:08+00:00

With that an L3 cache is correctly reported in the cache information in /sys With fixes from Andreas Herrmann and Dean Gaudet and Joachim Deguara Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds

x86_64: Use string instruction memcpy/memset on AMD Fam10

2007-07-22T01:37:08+00:00

Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds

Use a new CPU feature word to cover features that are spread around

2007-07-12T17:55:54+00:00

Some Intel features are spread around in different CPUID leafs like 0x5, 0x6 and 0xA. Make this feature detection code common across i386 and x86_64. Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver. Refer to Intel Software Developer's Manual for more details about the feature. Thanks to hpa (H Peter Anvin) for the making the actual code detecting the scattered features data-driven. Signed-off-by: Venkatesh Pallipadi Signed-off-by: H. Peter Anvin Signed-off-by: Linus Torvalds

Unify the CPU features vectors between i386 and x86-64

2007-07-12T17:55:54+00:00

Unify the handling of the CPU features vectors between i386 and x86-64. This also adopts the collapsing of features which are required at compile-time into constant tests from x86-64 to i386. Signed-off-by: H. Peter Anvin Signed-off-by: Linus Torvalds