linux/arch, branch v2.6.25.7

x86: fix recursive dependencies

2008-06-16T20:20:06Z

commit 823c248e7cc75b4f22da914b01f8e5433cff197e in mainline The proper dependency check uncovered a few dependency problems, the subarchitecture used a mixture of selects and depends on SMP and PCI dependency was messed up. Signed-off-by: Roman Zippel Signed-off-by: Ingo Molnar Signed-off-by: Ravikiran Thirumalai

Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LIST

2008-06-16T20:20:05Z

commit 73531905ed53576d9e8707659a761e7046a60497 in mainline. init/Kconfig contains a list of configs that are searched for if 'make *config' are used with no .config present. Extend this list to look at the config identified by ARCH_DEFCONFIG. With this change we now try the defconfig targets last. This fixes a regression reported by: Linus Torvalds Signed-off-by: Sam Ravnborg Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Greg Kroah-Hartman

x86: fix bad pmd ffff810000207xxx(9090909090909090)

2008-06-09T18:27:06Z

upstream commit: 2884f110d5409714f3a04eeb6d2ecd77da66b242 OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages: mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090). Initialization's cleanup_highmap was leaving alignment filler behind in the pmd for MODULES_VADDR: when vmalloc's guard page would occupy a new page table, it's not allocated, and then module unload's vfree hits the bad 9090 pmd entry left over. Signed-off-by: Hugh Dickins Signed-off-by: Ingo Molnar Hugh notes: It's actually not a serious problem, but it does look as if it's a serious problem, so we should stamp it out. Signed-off-by: Chris Wright

x86, fpu: fix CONFIG_PREEMPT=y corruption of application's FPU stack

2008-06-09T18:27:04Z

upstream commit: 870568b39064cab2dd971fe57969916036982862 Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT, and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU optimization". Add tsk_used_math() checks to prevent calling math_state_restore() which can sleep in the case of !tsk_used_math(). This prevents making a blocking call in __switch_to(). Apparently "fpu_counter > 5" check is not enough, as in some signal handling and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible. It's a side effect though. This is the failing scenario: process 'A' in save_i387_ia32() just after clear_used_math() Got an interrupt and pre-empted out. At the next context switch to process 'A' again, kernel tries to restore the math state proactively and sees a fpu_counter > 0 and !tsk_used_math() This results in init_fpu() during the __switch_to()'s math_state_restore() And resulting in fpu corruption which will be saved/restored (save_i387_fxsave and restore_i387_fxsave) during the remaining part of the signal handling after the context switch. Bisected-by: Jürgen Mell Signed-off-by: Suresh Siddha Tested-by: Jürgen Mell Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Chris Wright

CPUFREQ: Make acpi-cpufreq more robust against BIOS freq changes behind our back.

2008-06-09T18:27:03Z

upstream commit: e56a727b023d40d1adf660168883f30f2e6abe0a We checked the hardware freq with OS cached freq value in get_cur_freqon_cpu(). Signed-off-by: Venkatesh Pallipadi Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones Cc: Thomas Renninger Cc: "Anthony L. Awtrey" [chrisw: backport to 2.6.25.4] Signed-off-by: Chris Wright

Revert "PCI: remove default PCI expansion ROM memory allocation"

2008-06-09T18:27:03Z

upstream commit: 8d539108560ec121d59eee05160236488266221c This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, which was reported to break X startup (xf86-video-ati-6.8.0). See http://bugs.freedesktop.org/show_bug.cgi?id=15523 for details. Reported-by: Laurence Withers Cc: Gary Hade Cc: Greg KH Cc: Jan Beulich Cc: "Jun'ichi Nomura" Cc: Andrew Morton Cc: Ingo Molnar Cc: Thomas Gleixner Signed-off-by: Linus Torvalds [cebbert@redhat.com: backport, remove first hunk to make port easier] [chrisw@sous-sol.org: add back first hunk] Signed-off-by: Chris Wright

x86: disable TSC for sched_clock() when calibration failed

2008-06-09T18:27:02Z

upstream commit: 74dc51a3de06aa516e3b9fdc4017b2aeb38bf44b When the TSC calibration fails then TSC is still used in sched_clock(). Disable it completely in that case. Signed-off-by: Thomas Gleixner Cc: stable@kernel.org Signed-off-by: Chris Wright

x86: distangle user disabled TSC from unstable

2008-06-09T18:27:02Z

upstream commit: 9ccc906c97e34fd91dc6aaf5b69b52d824386910 tsc_enabled is set to 0 from the command line switch "notsc" and from the mark_tsc_unstable code. Seperate those functionalities and replace tsc_enable with tsc_disable. This makes also the native_sched_clock() decision when to use TSC understandable. Preparatory patch to solve the sched_clock() issue on 32 bit. Signed-off-by: Thomas Gleixner Signed-off-by: Chris Wright

x86: if we cannot calibrate the TSC, we panic.

2008-06-09T18:27:02Z

upstream commit: 3c2047cd32b1a8c782d7efab72707e7daa251625 The current tsc_init() clears the TSC feature bit if the TSC khz cannot be calculated, causing us to panic in arch/x86/kernel/cpu/bugs.c check_config(). We should simply mark it unstable. Frankly, someone should take an axe to this code. mark_tsc_unstable() not only marks it unstable, but sets tsc_enabled to 0, which seems redundant but is actually important here because means it won't be used by sched_clock() either. Perhaps a tristate enum "UNUSABLE, UNSTABLE, OK" would be clearer, and separate mark_tsc_unstable() and mark_tsc_broken() functions? Signed-off-by: Rusty Russell Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright

x86: fix setup of cyc2ns in tsc_64.c

2008-06-09T18:27:02Z

upstream commit: b6db80ee1331e7beaeb91b4b3d946dd16c72e388 When the TSC is calibrated against the PIT due to the nonavailability of PMTIMER/HPET or due to SMI interference then the setup of the per CPU cyc2ns variables is skipped. This is unlikely to happen but it would definitely render sched_clock() unusable. This was introduced with commit 53d517cdbaac704352b3d0c10fecb99e0b54572e x86: scale cyc_2_nsec according to CPU frequency Update the per CPU cyc2ns variables in all exit pathes of tsc_calibrate. Signed-off-by: Thomas Gleixner Cc: stable@kernel.org Signed-off-by: Chris Wright