aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86
Commit message (Collapse)AuthorAge
* x86: fix percpu_{to,from}_op()Jan Beulich2009-05-11
| | | | | | | | | | - the byte operand constraints were wrong for 32-bit - the to-op's input operands weren't properly parenthesized [ Impact: fix possible miscompilation or build failure ] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86: mtrr: Fix high_width computation when phys-addr is >= 44bitYinghai Lu2009-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | found one system where cpu address line is 44bits, mtrr printout is not right: [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0 00000000 mask FF0 00000000 write-back [ 0.000000] 1 base 10 00000000 mask FFF 80000000 write-back [ 0.000000] 2 base 0 80000000 mask FFF 80000000 uncachable [ 0.000000] 3 base 0 7F800000 mask FFF FF800000 uncachable Li Zefan and Frederic pointed out the high_width could be -4 some how. It turns out when phys_addr is 44bit, size_or_mask will be ffffffff,00000000 so ffs(size_or_mask) will be 0. Try to check low 32 bit, to get correct high_width. Signed-off-by: Yinghai Lu <yinghai@kerne.org> Also-analyzed-by: Frederic Weisbecker <fweisbec@gmail.com> Also-analyzed-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Zhaolei <zhaolei@cn.fujitsu.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <4A026540.8060504@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: Fix false positive section mismatch warnings in the apic codeSam Ravnborg2009-05-10
| | | | | | | | | | | [ Impact: reduce kernel image size a bit, annotate away warnings ] Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [ modified and tested it ] Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Cc: Marcin Slusarz <marcin.slusarz@gmail.com> LKML-Reference: <b9df5fa10905090235s4bfd26a8o979f93809c9727ad@mail.gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: MCE: make cmci_discover_lock irq-safeHidetoshi Seto2009-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | Lockdep reports the warning below when Li tries to offline one cpu: [ 110.835487] ================================= [ 110.835616] [ INFO: inconsistent lock state ] [ 110.835688] 2.6.30-rc4-00336-g8c9ed89 #52 [ 110.835757] --------------------------------- [ 110.835828] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [ 110.835908] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ 110.835982] (cmci_discover_lock){?.+...}, at: [<ffffffff80236dc0>] cmci_clear+0x30/0x9b cmci_clear() can be called via smp_call_function_single(). It is better to disable interrupt while holding cmci_discover_lock, to turn it into an irq-safe lock - we can deadlock otherwise. [ Impact: fix possible deadlock in the MCE code ] Reported-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <4A03ED38.8000700@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Reported-by: Shaohua Li<shaohua.li@intel.com>
* x86: xen, i386: reserve Xen pagetablesJeremy Fitzhardinge2009-05-08
| | | | | | | | | | | | | | | | The Xen pagetables are no longer implicitly reserved as part of the other i386_start_kernel reservations, so make sure we explicitly reserve them. This prevents them from being released into the general kernel free page pool and reused. [ Impact: fix Xen guest crash ] Also-Bisected-by: Bryan Donlan <bdonlan@gmail.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Xen-devel <xen-devel@lists.xensource.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <4A032EEC.30509@goop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86, kexec: fix crashdump panic with CONFIG_KEXEC_JUMPHuang Ying2009-05-08
| | | | | | | | | | | | | | | | | | | | | | Tim Starling reported that crashdump will panic with kernel compiled with CONFIG_KEXEC_JUMP due to null pointer deference in machine_kexec_32.c: machine_kexec(), when deferencing kexec_image. Refering to: http://bugzilla.kernel.org/show_bug.cgi?id=13265 This patch fixes the BUG via replacing global variable reference: kexec_image in machine_kexec() with local variable reference: image, which is more appropriate, and will not be null. Same BUG is in machine_kexec_64.c too, so fixed too in the same way. [ Impact: fix crash on kexec ] Reported-by: Tim Starling <tstarling@wikimedia.org> Signed-off-by: Huang Ying <ying.huang@intel.com> LKML-Reference: <1241751101.6259.85.camel@yhuang-dev.sh.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86-64: finish cleanup_highmaps()'s job wrt. _brk_endJan Beulich2009-05-08
| | | | | | | | | | | | | | With the introduction of the .brk section, special care must be taken that no unused page table entries remain if _brk_end and _end are separated by a 2M page boundary. cleanup_highmap() runs very early and hence cannot take care of that, hence potential entries needing to be removed past _brk_end must be cleared once the brk allocator has done its job. [ Impact: avoids undesirable TLB aliases ] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86: fix boot hang in early_reserve_e820()Jan Beulich2009-05-08
| | | | | | | | | | | | If the first non-reserved (sub-)range doesn't fit the size requested, an endless loop will be entered. If a range returned from find_e820_area_size() turns out insufficient in size, the range must be skipped before calling the function again. [ Impact: fixes boot hang on some platforms ] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86: Fix a typo in a printk messageNikanth Karthikesan2009-05-06
| | | | | | | | [ Impact: printk message cleanup ] Signed-off-by: Nikanth Karthikesan <knikanth@suse.de> LKML-Reference: <200905040908.27299.knikanth@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86, srat: do not register nodes beyond e820 mapDavid Rientjes2009-05-06
| | | | | | | | | | | | | | | | | The mem= option will truncate the memory map at a specified address so it's not possible to register nodes with memory beyond the e820 upper bound. unparse_node() is only called when then node had memory associated with it, although with the mem= option it is no longer addressable. [ Impact: fix boot hang on certain (large) systems ] Reported-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Jack Steiner <steiner@sgi.com> LKML-Reference: <alpine.DEB.2.00.0905051248150.20021@chino.kir.corp.google.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'tracing-fixes-for-linus' of ↵Linus Torvalds2009-05-05
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: tracing: x86, mmiotrace: fix range test tracing: fix ref count in splice pages
| * tracing: x86, mmiotrace: fix range testStuart Bennett2009-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | Matching on (addr == (p->addr + p->len)) causes problems when mappings are adjacent. [ Impact: fix mmiotrace confusion on adjacent iomaps ] Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Acked-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2009-05-05
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo amd-iommu: fix iommu flag masks x86: initialize io_bitmap_base on 32bit x86: gettimeofday() vDSO: fix segfault when tv == NULL
| * | x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfoAndreas Herrmann2009-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7ad728f98162cb1af06a85b2a5fc422dddd4fb78 (cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t) changed the output of /proc/cpuinfo for siblings: Example on an AMD Phenom: physical id : 0 siblings : 1 core id : 3 cpu cores : 4 Before that commit it was: physical id : 0 siblings : 4 core id : 3 cpu cores : 4 Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings. This is due to the following hunk of above commit: | --- a/arch/x86/kernel/cpu/proc.c | +++ b/arch/x86/kernel/cpu/proc.c | @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf | if (c->x86_max_cores * smp_num_siblings > 1) { | seq_printf(m, "physical id\t: %d\n", c->phys_proc_id); | seq_printf(m, "siblings\t: %d\n", | - cpus_weight(per_cpu(cpu_core_map, cpu))); | + cpumask_weight(cpu_sibling_mask(cpu))); | seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id); | seq_printf(m, "cpu cores\t: %d\n", c->booted_cores); | seq_printf(m, "apicid\t\t: %d\n", c->apicid); This was a mistake, because the impact line shows that this side-effect was not anticipated: Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y So revert the respective hunk to restore the old behavior. [ Impact: fix sibling-info regression in /proc/cpuinfo ] Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <20090504182859.GA29045@alberich.amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | amd-iommu: fix iommu flag masksJoerg Roedel2009-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The feature bits should be set via bitmasks, not via feature IDs. [ Impact: fix feature enabling in newer IOMMU versions ] Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> LKML-Reference: <20090504102028.GA30307@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | x86: initialize io_bitmap_base on 32bitThomas Gleixner2009-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit db949bba3c7cf2e664ac12e237c6d4c914f0c69d (x86-32: use non-lazy io bitmap context switching) broke ioperm for 32bit because it removed the lazy initialization of io_bitmap_base and did not set it to the real bitmap offset. [ Impact: fix non-working sys_ioperm() on 32-bit kernels ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | x86: gettimeofday() vDSO: fix segfault when tv == NULLJohn Wright2009-04-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the gettimeofday(2) manual: If either tv or tz is NULL, the corresponding structure is not set or returned. Since it is legal to give NULL as the tv argument, the code should make sure tv is not NULL before trying to dereference it. This issue manifests itself on x86_64 when vdso=0 is not on the kernel command-line and libc uses the vDSO for gettimeofday() (e.g. glibc >= 2.7). A simple reproducer: #include <stdio.h> #include <sys/time.h> int main(void) { struct timezone tz; gettimeofday(NULL, &tz); return 0; } See http://bugs.debian.org/466491 for more details. [ Impact: fix gettimeofday(NULL, &tz) segfault ] Signed-off-by: John Wright <john.wright@hp.com> Cc: Andi Kleen <ak@suse.de> Cc: John Wright <john.wright@hp.com> LKML-Reference: <1241037121-14805-1-git-send-email-john.wright@hp.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | Merge branch 'x86-mce-for-linus' of ↵Linus Torvalds2009-05-02
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip * 'x86-mce-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip: x86, mce: fix boot logging logic x86, mce: make polling timer interval per CPU
| * | x86, mce: fix boot logging logicAndi Kleen2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The earlier patch to change the poller to a separate function subtly broke the boot logging logic. This could lead to machine checks getting logged at boot even when disabled or defaulting to off on some systems. Fix that. [ Impact: bug fix - avoid spurious MCE in log ] Signed-off-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| * | x86, mce: make polling timer interval per CPUAndi Kleen2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The polling timer while running per CPU still uses a global next_interval variable, which lead to some CPUs either polling too fast or too slow. This was not a serious problem because all errors get picked up eventually, but it's still better to avoid it. Turn next_interval into a per cpu variable. v2: Fix check_interval == 0 case (Hidetoshi Seto) [ Impact: minor bug fix ] Signed-off-by: Andi Kleen <ak@linux.intel.com> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
* | | Merge branch 'for-linus' of ↵Linus Torvalds2009-04-27
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: only save/restore existent registers in the PCIe capability x86/PCI: don't bother with root quirks if _CRS is used docbooks: add/fix PCI kernel-doc PCI: cleanup debug output resources x86/PCI: set_pci_bus_resources_arch_default cleanups x86/PCI: Move set_pci_bus_resources_arch_default into arch/x86 x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case PCI quirk: disable MSI on VIA VT3364 chipsets
| * | | x86/PCI: don't bother with root quirks if _CRS is usedYinghai Lu2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It will be overwriten later if _CRS is used, so don't bother to set it. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | x86/PCI: set_pci_bus_resources_arch_default cleanupsYinghai Lu2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename set_pci_bus_resources_arch_default to x86_pci_root_bus_res_quirks, move the weak version from common.c to i386.c, and before calling, make sure it's a root bus. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | x86/PCI: Move set_pci_bus_resources_arch_default into arch/x86Matthew Wilcox2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029 introduced a new function to set the PCI bus resources. Unfortunately, neither the author, nor the committers seemed to know that we already have somewhere to do that -- pcibios_fixup_bus(). This patch moves the hook (used only by the K8 code) into x86-specific code where it should have been in the first place. Cc: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | x86/PCI: don't call e820_all_mapped with -1 in the mmconfig caseYinghai Lu2009-04-22
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | e820_all_mapped need end is (addr + size) instead of (addr + size - 1) Cc: stable@kernel.org Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | | Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2009-04-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, hpet: Stop soliciting hpet=force users on ICH4M x86: check boundary in setup_node_bootmem() uv_time: add parameter to uv_read_rtc() x86: hpet: fix periodic mode programming on AMD 81xx x86: more than 8 32-bit CPUs requires X86_BIGSMP x86: avoid theoretical spurious NMI backtraces with CONFIG_CPUMASK_OFFSTACK=y x86: fix boot crash in NMI watchdog with CONFIG_CPUMASK_OFFSTACK=y and flat APIC x86-64: fix FPU corruption with signals and preemption x86/uv: fix for no memory at paddr 0 docs, x86: add nox2apic back to kernel-parameters.txt x86: mm/numa_32.c calculate_numa_remap_pages should use __init x86, kbuild: make "make install" not depend on vmlinux x86/uv: fix init of cpu-less nodes x86/uv: fix init of memory-less nodes
| * | | x86, hpet: Stop soliciting hpet=force users on ICH4MLen Brown2009-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HPET in the ICH4M is not documented in the data sheet because it was not officially validated. While it is fine for hackers to continue to use "hpet=force" to enable the hardware that they have, it is not prudent to solicit additional "hpet=force" users on this hardware. [ Impact: remove hpet=force syslog message on old-ICH systems ] Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <alpine.LFD.2.00.0904231918510.15843@localhost.localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86: check boundary in setup_node_bootmem()Yinghai Lu2009-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit dc09855 ("x86/uv: fix init of memory-less nodes") causes a two sockets system (where node-1 doesn't have RAM installed) to crash. That commit makes node_possible include cpu nodes that do not have memory. So check boundary in setup_node_bootmem(). [ Impact: fix boot crash on RAM-less NUMA node system ] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Jack Steiner <steiner@sgi.com> LKML-Reference: <49EF89DF.9090404@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | uv_time: add parameter to uv_read_rtc()Coly Li2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uv_read_rtc() is referenced by read member of struct clocksource clocksource_uv. In include/linux/clocksource.h, read of struct clocksource is declared as: cycle_t (*read)(struct clocksource *cs) This got introduced recently in: 8e19608: clocksource: pass clocksource to read() callback But arch/x86/kernel/uv_time.c was not properly converted by that pach. This patch adds a dummy parameter (struct clocksource type) to uv_read_rtc() to fix the incompatible reference in clocksource_uv, and add a NULL parameter in all places where uv_read_rtc() gets called. [ Impact: cleanup, address compiler warning ] Signed-off-by: Coly Li <coly.li@suse.de> Cc: Dimitri Sivanich <sivanich@sgi.com> Cc: Magnus Damm <damm@igel.co.jp> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hugh@veritas.com> LKML-Reference: <49EF3614.1050806@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Dimitri Sivanich <sivanich@sgi.com>
| * | | x86: hpet: fix periodic mode programming on AMD 81xxAndreas Herrmann2009-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (See http://bugzilla.kernel.org/show_bug.cgi?id=12961) It partially reverts commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403 (x86: hpet: stop HPET_COUNTER when programming periodic mode) HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL cleared) to T0_CMP register to set the period in periodic mode. With this patch HPET_COUNTER is still stopped but not reset when HPET is programmed in periodic mode. This should help to avoid races when HPET is programmed in periodic mode and fixes a boot time hang that I've observed on a machine when using 1000HZ. [ Impact: fix boot time hang on machines with AMD 81xx chipset ] Reported-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Tested-by: Jeff Mahoney <jeffm@suse.com> LKML-Reference: <20090421180037.GA2763@alberich.amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | Merge commit 'v2.6.30-rc3' into x86/urgentIngo Molnar2009-04-22
| |\| | | | | | | | | | | | | | | | | | | | | | Merge reason: hpet.c changed upstream, make sure we test against that Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86: more than 8 32-bit CPUs requires X86_BIGSMPMichael K. Johnson2009-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | $ cat x86-more-than-8-cpus-requires-bigsmp.patch Enforce NR_CPUS <= 8 limitation if X86_BIGSMP not set Configuring more than 8 logical CPUs on 32-bit x86 requires X86_BIGSMP to be set in order to boot successfully, if more than 8 logical CPUs are actually found at boot time. The X86_BIGSMP help text describes that it is required to be set if more than 8 CPUs are configured, but this was previously not enforced. This configuration error has affected multiple distributions: https://bugzilla.redhat.com/show_bug.cgi?id=480844 https://issues.rpath.com/browse/RPL-3022 Signed-off-by: Michael K Johnson <johnsonm@rpath.com> LKML-Reference: <20090422014448.GB32541@logo.rdu.rpath.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| * | | x86: avoid theoretical spurious NMI backtraces with CONFIG_CPUMASK_OFFSTACK=yRusty Russell2009-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory (though not shown in practice) alloc_cpumask_var() doesn't zero memory, so CPUs might print an "NMI backtrace for cpu %d" once on boot. (Bug introduced in fcef8576d8a64fc603e719c97d423f9f6d4e0e8b). [ Impact: avoid theoretical syslog noise in rare configs ] Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86: fix boot crash in NMI watchdog with CONFIG_CPUMASK_OFFSTACK=y and flat APICRusty Russell2009-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fcef8576d8a64fc603e719c97d423f9f6d4e0e8b converted backtrace_mask to a cpumask_var_t, and assumed check_nmi_watchdog was called before nmi_watchdog_tick was ever called. Steven's oops shows I was wrong. This is something of a bandaid: I'm not sure we *should* be calling nmi_watchdog_tick before check_nmi_watchdog. Note that gcc eliminates this test for the CONFIG_CPUMASK_OFFSTACK=n case. [ Impact: fix boot crash in rare configs ] Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86-64: fix FPU corruption with signals and preemptionSuresh Siddha2009-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: <stable@kernel.org> [2.6.28.x, 2.6.29.x] Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| * | | x86/uv: fix for no memory at paddr 0Jack Steiner2009-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix endcase where the memory at physical address 0 does not really exist AND one of the sockets on blade 0 has no active cpus. The memory that _appears_ to be at physical address 0 is actually memory that located at a different address but has been remapped by the chipset so that it appears to be at physical address 0. When determining the UV pnode, the algorithm for determining the pnode incorrectly used the relocated physical address instead of the actual (global) address. [ Impact: boot failure on partitioned systems ] Signed-off-by: Jack Steiner <steiner@sgi.com> LKML-Reference: <20090420132530.GA23156@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | Merge branch 'linus' into x86/urgentIngo Molnar2009-04-20
| |\ \ \ | | | |/ | | |/| | | | | | | | | | | | | | | | | Merge reason: We need the x86/uv updates from upstream, to queue up dependent fix. Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86: mm/numa_32.c calculate_numa_remap_pages should use __initJaswinder Singh Rajput2009-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | calculate_numa_remap_pages() is called only by __init initmem_init() further calculate_numa_remap_pages is calling: __init find_e820_area() and __init reserve_early() So calculate_numa_remap_pages() should be __init calculate_numa_remap_pages(). WARNING: arch/x86/built-in.o(.text+0x82ea3): Section mismatch in reference from the function calculate_numa_remap_pages() to the function .init.text:find_e820_area() The function calculate_numa_remap_pages() references the function __init find_e820_area(). This is often because calculate_numa_remap_pages lacks a __init annotation or the annotation of find_e820_area is wrong. WARNING: arch/x86/built-in.o(.text+0x82f5f): Section mismatch in reference from the function calculate_numa_remap_pages() to the function .init.text:reserve_early() The function calculate_numa_remap_pages() references the function __init reserve_early(). This is often because calculate_numa_remap_pages lacks a __init annotation or the annotation of reserve_early is wrong. [ Impact: save memory, address Section mismatch warning ] Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> LKML-Reference: <1239991281.3153.4.camel@ht.satnam> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86, kbuild: make "make install" not depend on vmlinuxH. Peter Anvin2009-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is common to use "make install" in restricted environments which differ from the one which was actually used to build the kernel. In such environments it is highly undesirable to trigger a rebuild of any part of the system. Worse, the rebuild may be spurious, triggered by differences in the environment. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Sam Ravnborg <sam@ravnborg.org> LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>
| * | | x86/uv: fix init of cpu-less nodesJack Steiner2009-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix an endcase in the UV initialization code for the "UV large system mode" of apicids. If node zero contains no cpus, cpus on another node will be the boot cpu. The percpu data that contains the extra apicid bits was not being initialized early enough. [ Impact: fix potential boot crash on cpu-less UV nodes ] Signed-off-by: Jack Steiner <steiner@sgi.com> LKML-Reference: <20090417142447.GA23759@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | x86/uv: fix init of memory-less nodesJack Steiner2009-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for nodes that have cpus but no memory. The current code was failing to add these nodes to the nodes_present_map. v2: Fixes case caught by David Rientjes - missed support for the x2apic SRAT table. [ Impact: fix potential boot crash on memory-less UV nodes. ] Reported-by: David Rientjes <rientjes@google.com> Signed-off-by: Jack Steiner <steiner@sgi.com> LKML-Reference: <20090417142242.GA23743@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | | Merge branch 'irq-fixes-for-linus' of ↵Linus Torvalds2009-04-26
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86/irq: mark NUMA_MIGRATE_IRQ_DESC broken x86, irq: Remove IRQ_DISABLED check in process context IRQ move
| * | | | x86/irq: mark NUMA_MIGRATE_IRQ_DESC brokenYinghai Lu2009-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It causes crash on system with lots of cards with MSI-X when irq_balancer enabled... The patches fixing it were both complex and fragile, according to Eric they were also doing quite dangerous things to the hardware. Instead we now have patches that solve this problem via static NUMA node mappings - not dynamic allocation and balancing. The patches are much simpler than this method but are still too large outside of the merge window, so we mark the dynamic balancer as broken for now, and queue up the new approach for v2.6.31. [ Impact: deactivate broken kernel feature ] Reported-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <49E68C41.4020801@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | | | x86, irq: Remove IRQ_DISABLED check in process context IRQ movePallipadi, Venkatesh2009-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in the thread here: http://marc.info/?l=linux-kernel&m=123964468521142&w=2 Eric W. Biederman observed: > It looks like some additional bugs have slipped in since last I looked. > > set_irq_affinity does this: > ifdef CONFIG_GENERIC_PENDING_IRQ > if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) { > cpumask_copy(desc->affinity, cpumask); > desc->chip->set_affinity(irq, cpumask); > } else { > desc->status |= IRQ_MOVE_PENDING; > cpumask_copy(desc->pending_mask, cpumask); > } > #else > > That IRQ_DISABLED case is a software state and as such it has nothing to > do with how safe it is to move an irq in process context. [...] > > The only reason we migrate MSIs in interrupt context today is that there > wasn't infrastructure for support migration both in interrupt context > and outside of it. Yes. The idea here was to force the MSI migration to happen in process context. One of the patches in the series did disable_irq(dev->irq); irq_set_affinity(dev->irq, cpumask_of(dev->cpu)); enable_irq(dev->irq); with the above patch adding irq/manage code check for interrupt disabled and moving the interrupt in process context. IIRC, there was no IRQ_MOVE_PCNTXT when we were developing this HPET code and we ended up having this ugly hack. IRQ_MOVE_PCNTXT was there when we eventually submitted the patch upstream. But, looks like I did a blind rebasing instead of using IRQ_MOVE_PCNTXT in hpet MSI code. Below patch fixes this. i.e., revert commit 932775a4ab622e3c99bd59f14cc and add PCNTXT to HPET MSI setup. Also removes copying of desc->affinity in generic code as set_affinity routines are doing it internally. Reported-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "Li Shaohua" <shaohua.li@intel.com> Cc: Gary Hade <garyhade@us.ibm.com> Cc: "lcm@us.ibm.com" <lcm@us.ibm.com> Cc: suresh.b.siddha@intel.com LKML-Reference: <20090413222058.GB8211@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | | | Merge branch 'core-fixes-for-linus' of ↵Linus Torvalds2009-04-26
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: locking: clarify kernel-taint warning message lockdep, x86: account for irqs enabled in paranoid_exit lockdep: more robust lockdep_map init sequence
| * | | | | lockdep, x86: account for irqs enabled in paranoid_exitSteven Rostedt2009-04-18
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I hit the check_flags error of lockdep: WARNING: at kernel/lockdep.c:2893 check_flags+0x1a7/0x1d0() [...] hardirqs last enabled at (12567): [<ffffffff8026206a>] local_bh_enable+0xaa/0x110 hardirqs last disabled at (12569): [<ffffffff80610c76>] int3+0x16/0x40 softirqs last enabled at (12566): [<ffffffff80514d2b>] lock_sock_nested+0xfb/0x110 softirqs last disabled at (12568): [<ffffffff8058454e>] tcp_prequeue_process+0x2e/0xa0 The check_flags warning of lockdep tells me that lockdep thought interrupts were disabled, but they were really enabled. The numbers in the above parenthesis show the order of events: 12566: softirqs last enabled: lock_sock_nested 12567: hardirqs last enabled: local_bh_enable 12568: softirqs last disabled: tcp_prequeue_process 12566: hardirqs last disabled: int3 int3 is a breakpoint! Examining this further, I have CONFIG_NET_TCPPROBE enabled which adds break points into the kernel. The paranoid_exit of the return of int3 does not account for enabling interrupts on return to kernel. This code is a bit tricky since it is also used by the nmi handler (when lockdep is off), and we must be careful about the swapgs. We can not call kernel code after the swapgs has been performed. [ Impact: fix lockdep check_flags warning + self-turn-off ] Acked-by: Peter Zijlsta <a.p.zijlstra@chello.nl> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | | | Merge branch 'release' of ↵Linus Torvalds2009-04-24
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (34 commits) ACPI, i915: Register ACPI video even when not modesetting Revert "ACPICA: delete check for AML access to port 0x81-83" I/O port protection: update for windows compatibility. sony-laptop: always try to unblock rfkill on load sony-laptop: fix bogus error message display on resume ACPI: EC: Fix ACPI EC resume non-query interrupt message sony-laptop: SNC input event 38 fix sony-laptop: SNC 127 Initialization Fix sony-laptop: Duplicate SNC 127 Event Fix ACPI: prevent processor.max_cstate=0 boot crash ACPI/hpet: prevent boot hang when hpet=force used on ICH-4M ACPI: delete obsolete "bus master activity" proc field ACPI: idle: mark_tsc_unstable() at init-time, not run-time ACPI: add /sys/firmware/acpi/interrupts/sci_not counter ACPI video: fix an error when the brightness levels on AC and on Battery are same acpi-cpufreq: Do not let get_measured perf depend on internal variable acpi-cpufreq: style-only: add parens to math expression acpi-cpufreq: Cleanup: Use printk_once x86, acpi_cpufreq: Fix the NULL pointer dereference in get_measured_perf thinkpad-acpi: bump up version to 0.23 ...
| * \ \ \ \ Merge branch 'cpufreq' into releaseLen Brown2009-04-24
| |\ \ \ \ \ | | |_|_|_|/ | |/| | | |
| | * | | | acpi-cpufreq: Do not let get_measured perf depend on internal variableThomas Renninger2009-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take already available policy->cpuinfo.max_freq and get rid of acpi-cpufreq specific max_freq variable. This implies that P0 is always the highest frequency which should always be true as ACPI spec says: As a result, the zeroth entry describes the highest performance state Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | | | acpi-cpufreq: style-only: add parens to math expressionThomas Renninger2009-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-06 17:40:01 -0500