aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2010-07-28x86,kgdb: Fix hw breakpoint regressionJason Wessel1-2/+7
HW breakpoints events stopped working correctly with kgdb as a result of commit: 018cbffe6819f6f8db20a0a3acd9bab9bfd667e4 (Merge commit 'v2.6.33' into perf/core). The regression occurred because the behavior changed for setting NOTIFY_STOP as the return value to the die notifier if the breakpoint was known to the HW breakpoint API. Because kgdb is using the HW breakpoint API to register HW breakpoints slots, it must also now implement the overflow_handler call back else kgdb does not get to see the events from the die notifier. The kgdb_ll_trap function will be changed to be general purpose code which can allow an easy way to implement the hw_breakpoint API overflow call back. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Dongdong Deng <dongdong.deng@windriver.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
2010-07-26Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds2-11/+16
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: Do not try to disable hpet if it hasn't been initialized before x86, i8259: Only register sysdev if we have a real 8259 PIC
2010-07-26Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds2-27/+25
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] powernow-k8: Limit Pstate transition latency check [CPUFREQ] Fix PCC driver error path [CPUFREQ] fix double freeing in error path of pcc-cpufreq [CPUFREQ] pcc driver should check for pcch method before calling _OSC [CPUFREQ] fix memory leak in cpufreq_add_dev [CPUFREQ] revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)"
2010-07-26[CPUFREQ] powernow-k8: Limit Pstate transition latency checkBorislav Petkov1-6/+5
The Pstate transition latency check was added for broken F10h BIOSen which wrongly contain a value of 0 for transition and bus master latency. Fam11h and later, however, (will) have similar transition latency so extend that behavior for them too. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-07-26[CPUFREQ] Fix PCC driver error pathMatthew Garrett1-8/+9
The PCC cpufreq driver unmaps the mailbox address range if any CPUs fail to initialise, but doesn't do anything to remove the registered CPUs from the cpufreq core resulting in failures further down the line. We're better off simply returning a failure - the cpufreq core will unregister us cleanly if we end up with no successfully registered CPUs. Tidy up the failure path and also add a sanity check to ensure that the firmware gives us a realistic frequency - the core deals badly with that being set to 0. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-07-26[CPUFREQ] fix double freeing in error path of pcc-cpufreqDaniel J Blueman1-12/+6
Prevent double freeing on error path. Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-07-26[CPUFREQ] pcc driver should check for pcch method before calling _OSCMatthew Garrett1-1/+5
The pcc specification documents an _OSC method that's incompatible with the one defined as part of the ACPI spec. This shouldn't be a problem as both are supposed to be guarded with a UUID. Unfortunately approximately nobody (including HP, who wrote this spec) properly check the UUID on entry to the _OSC call. Right now this could result in surprising behaviour if the pcc driver performs an _OSC call on a machine that doesn't implement the pcc specification. Check whether the PCCH method exists first in order to reduce this probability. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
2010-07-26Merge branch 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2-2/+3
* 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSR KVM: MMU: fix conflict access permissions in direct sp
2010-07-24Merge branch 'bugzilla-16396' into releaseLen Brown1-2/+7
2010-07-24ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAMRafael J. Wysocki1-2/+7
Commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2 (ACPI: Store NVS state even when entering suspend to RAM) caused the ACPI suspend code save the NVS area during suspend and restore it during resume unconditionally, although it is known that some systems need to use acpi_sleep=s4_nonvs for hibernation to work. To allow the affected systems to avoid saving and restoring the NVS area during suspend to RAM and resume, introduce kernel command line option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its alias temporarily (add acpi_sleep=s4_nonvs to the feature removal file). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 . Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: tomas m <tmezzadra@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-23x86: Do not try to disable hpet if it hasn't been initialized beforeStefano Stabellini1-1/+1
hpet_disable is called unconditionally on machine reboot if hpet support is compiled in the kernel. hpet_disable only checks if the machine is hpet capable but doesn't make sure that hpet has been initialized. [ tglx: Made it a one liner and removed the redundant hpet_address check ] Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Venkatesh Pallipadi <venki@google.com> LKML-Reference: <alpine.DEB.2.00.1007211726240.22235@kaball-desktop> Cc: stable@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2010-07-23KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSRAvi Kivity1-2/+2
We don't need more than a page, and vmalloc() is slower (much slower recently due to a regression). Signed-off-by: Avi Kivity <avi@redhat.com>
2010-07-23KVM: MMU: fix conflict access permissions in direct spXiao Guangrong1-0/+1
In no-direct mapping, we mark sp is 'direct' when we mapping the guest's larger page, but its access is encoded form upper page-struct entire not include the last mapping, it will cause access conflict. For example, have this mapping: [W] / PDE1 -> |---| P[W] | | LPA \ PDE2 -> |---| [R] P have two children, PDE1 and PDE2, both PDE1 and PDE2 mapping the same lage page(LPA). The P's access is WR, PDE1's access is WR, PDE2's access is RO(just consider read-write permissions here) When guest access PDE1, we will create a direct sp for LPA, the sp's access is from P, is W, then we will mark the ptes is W in this sp. Then, guest access PDE2, we will find LPA's shadow page, is the same as PDE's, and mark the ptes is RO. So, if guest access PDE1, the incorrect #PF is occured. Fixed by encode the last mapping access into direct shadow page Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
2010-07-22Merge branch 'bugzilla-15886' into releaseLen Brown1-0/+9
2010-07-22ACPI: skip checking BM_STS if the BIOS doesn't ask for itLen Brown1-0/+9
It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886 Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-21x86: auditsyscall: fix fastpath return value after rescheduleRoland McGrath1-2/+2
In the CONFIG_AUDITSYSCALL fast-path for x86 64-bit system calls, we can pass a bad return value and/or error indication for the system call to audit_syscall_exit(). This happens when TIF_NEED_RESCHED was set as the system call returned, so we went out to schedule() and came back to the exit-audit fast-path. The fix is to reload the user return value register from the pt_regs before using it for audit_syscall_exit(). Both the 32-bit kernel's fast path and the 64-bit kernel's 32-bit system call fast paths work slightly differently, so that they always leave the fast path entirely to reschedule and don't return there, so they don't have the analogous bugs. Reported-by: Alexander Viro <aviro@redhat.com> Signed-off-by: Roland McGrath <roland@redhat.com>
2010-07-21Fix up trivial spelling errors ('taht' -> 'that')Linus Torvalds1-1/+1
Pointed out by Lucas who found the new one in a comment in setup_percpu.c. And then I fixed the others that I grepped for. Reported-by: Lucas <canolucas@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-07-20x86, numa: fix boot without RAM on node0 againYinghai Lu1-8/+9
Commit e534c7c5f8d6 ("numa: x86_64: use generic percpu var numa_node_id() implementation") broke numa systems that don't have ram on node0 when MEMORY_HOTPLUG is enabled, because cpu_up() will call cpu_to_node() before per_cpu(numa_node) is setup for APs. When Node0 doesn't have RAM, on x86, cpus already round it to nearest node with RAM in x86_cpu_to_node_map. and per_cpu(numa_node) is not set up until in c_init for APs. When later cpu_up() calling cpu_to_node() will get 0 again, and make it online even there is no RAM on node0. so later all APs can not booted up, and later will have panic. [ 1.611101] On node 0 totalpages: 0 ......... [ 2.608558] On node 0 totalpages: 0 [ 2.612065] Brought up 1 CPUs [ 2.615199] Total of 1 processors activated (3990.31 BogoMIPS). ... 93.225341] calling loop_init+0x0/0x1a4 @ 1 [ 93.229314] PERCPU: allocation failed, size=80 align=8, failed to populate [ 93.246539] Pid: 1, comm: swapper Tainted: G W 2.6.35-rc4-tip-yh-04371-gd64e6c4-dirty #354 [ 93.264621] Call Trace: [ 93.266533] [<ffffffff81125e43>] pcpu_alloc+0x83a/0x8e7 [ 93.270710] [<ffffffff81125f15>] __alloc_percpu+0x10/0x12 [ 93.285849] [<ffffffff8140786c>] alloc_disk_node+0x94/0x16d [ 93.291811] [<ffffffff81407956>] alloc_disk+0x11/0x13 [ 93.306157] [<ffffffff81503e51>] loop_alloc+0xa7/0x180 [ 93.310538] [<ffffffff8277ef48>] loop_init+0x9b/0x1a4 [ 93.324909] [<ffffffff8277eead>] ? loop_init+0x0/0x1a4 [ 93.329650] [<ffffffff810001f2>] do_one_initcall+0x57/0x136 [ 93.345197] [<ffffffff827486d0>] kernel_init+0x184/0x20e [ 93.348146] [<ffffffff81034954>] kernel_thread_helper+0x4/0x10 [ 93.365194] [<ffffffff81c7cc3c>] ? restore_args+0x0/0x30 [ 93.369305] [<ffffffff8274854c>] ? kernel_init+0x0/0x20e [ 93.386011] [<ffffffff81034950>] ? kernel_thread_helper+0x0/0x10 [ 93.392047] loop: out of memory ... Try to assign per_cpu(numa_node) early [akpm@linux-foundation.org: tidy up code comment] Signed-off-by: Yinghai <yinghai@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Tejun Heo <tj@kernel.org> Cc: Denys Vlasenko <vda.linux@googlemail.com> Acked-by: Lee Schermerhorn <lee.schermerhorn@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-07-20x86, i8259: Only register sysdev if we have a real 8259 PICAdam Lackorzynski1-10/+15
My platform makes use of the null_legacy_pic choice and oopses when doing a shutdown as the shutdown code goes through all the registered sysdevs and calls their shutdown method which in my case poke on a non-existing i8259. Imho the i8259 specific sysdev should only be registered if the i8259 is actually there. Do not register the sysdev function when the null_legacy_pic is used so that the i8259 resume, suspend and shutdown functions are not called. Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de> LKML-Reference: <201007202218.o6KMIJ3m020955@imap1.linux-foundation.org> Cc: Jacob Pan <jacob.jun.pan@intel.com> Cc: <stable@kernel.org> 2.6.34 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2010-07-19mm: add context argument to shrinker callbackDave Chinner1-1/+1
The current shrinker implementation requires the registered callback to have global state to work from. This makes it difficult to shrink caches that are not global (e.g. per-filesystem caches). Pass the shrinker structure to the callback so that users can embed the shrinker structure in the context the shrinker needs to operate on and get back to it in the callback via container_of(). Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2010-07-19Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds4-9/+23
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chain x86: Fix x2apic preenabled system with kexec x86: Force HPET readback_cmp for all ATI chipsets
2010-07-18Merge branch 'x86/kprobes' of git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-rolandLinus Torvalds1-1/+1
* 'x86/kprobes' of git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland: x86: kprobes: fix swapped segment registers in kretprobe
2010-07-18x86: kprobes: fix swapped segment registers in kretprobeRoland McGrath1-1/+1
In commit f007ea26, the order of the %es and %ds segment registers got accidentally swapped, so synthesized 'struct pt_regs' frames have the two values inverted. It's almost sure that these values never matter, and that they also never differ. But wrong is wrong. Signed-off-by: Roland McGrath <roland@redhat.com>
2010-07-16x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chainJacob Pan1-3/+4
The fixed bar capability structure is searched in PCI extended configuration space. We need to make sure there is a valid capability ID to begin with otherwise, the search code may stuck in a infinite loop which results in boot hang. This patch adds additional check for cap ID 0, which is also invalid, and indicates end of chain. End of chain is supposed to have all fields zero, but that doesn't seem to always be the case in the field. Suggested-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2010-07-16x86: Fix x2apic preenabled system with kexecYinghai Lu1-1/+1
Found one x2apic system kexec loop test failed when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip) first kernel can kexec second kernel, but second kernel can not kexec third one. it can be duplicated on another system with BIOS preenabled x2apic. First kernel can not kexec second kernel. It turns out, when kernel boot with pre-enabled x2apic, it will not execute disable_local_APIC on shutdown path. when init_apic_mappings() is called in setup_arch, it will skip setting of apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic()) Then later, disable_local_APIC() will bail out early because !apic_phys. So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys. another solution could be updating init_apic_mappings() to set apic_phys even for preenabled x2apic system. Actually even for x2apic system, that lapic address is mapped already in early stage. BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4C3EB22B.3000701@kernel.org> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: stable@kernel.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2010-07-16PCI: fall back to original BIOS BAR addressesBjorn Helgaas1-0/+1
If we fail to assign resources to a PCI BAR, this patch makes us try the original address from BIOS rather than leaving it disabled. Linux tries to make sure all PCI device BARs are inside the upstream PCI host bridge or P2P bridge apertures, reassigning BARs if necessary. Windows does similar reassignment. Before this patch, if we could not move a BAR into an aperture, we left the resource unassigned, i.e., at address zero. Windows leaves such BARs at the original BIOS addresses, and this patch makes Linux do the same. This is a bit ugly because we disable the resource long before we try to reassign it, so we have to keep track of the BIOS BAR address somewhere. For lack of a better place, I put it in the struct pci_dev. I think it would be cleaner to attempt the assignment immediately when the claim fails, so we could easily remember the original address. But we currently claim motherboard resources in the middle, after attempting to claim PCI resources and before assigning new PCI resources, and changing that is a fairly big job. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263 Reported-by: Andrew <nitr0@seti.kr.ua> Tested-by: Andrew <nitr0@seti.kr.ua> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-07-15x86: Force HPET readback_cmp for all ATI chipsetsThomas Gleixner2-5/+18
commit 30a564be (x86, hpet: Restrict read back to affected ATI chipset) restricted the workaround for the HPET bug to SMX00 chipsets. This was reasonable as those were the only ones against which we ever got a bug report. Stephan Wolf reported now that this patch breaks his IXP400 based machine. Though it's confirmed to work on other IXP400 based systems. To error out on the safe side, we force the HPET readback workaround for all ATI SMbus class chipsets. Reported-by: Stephan Wolf <stephan@letzte-bankreihe.de> LKML-Reference: <alpine.LFD.2.00.1007142134140.3321@localhost.localdomain> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Stephan Wolf <stephan@letzte-bankreihe.de> Acked-by: Borislav Petkov <borislav.petkov@amd.com>
2010-07-13Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds3-1/+15
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: input: i8042 - add runtime check in x86's i8042_platform_init Revert "Input: fixup X86_MRST selects" Revert "Input: do not force selecting i8042 on Moorestown" x86, mrst: Add i8042_detect API for Moorestwon platform x86: Add i8042 pre-detection hook to x86_platform_ops x86, platform: Export x86_platform to modules
2010-07-13Merge branch 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2-5/+4
* 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: MMU: flush remote tlbs when overwriting spte with different pfn KVM: VMX: Fix host MSR_KERNEL_GS_BASE corruption
2010-07-12KVM: MMU: flush remote tlbs when overwriting spte with different pfnXiao Guangrong1-0/+2
After remove a rmap, we should flush all vcpu's tlb Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-07-07x86, mrst: Add i8042_detect API for Moorestwon platformFeng Tang1-0/+7
It will just return 0 as there is no i8042 controller Signed-off-by: Feng Tang <feng.tang@intel.com> LKML-Reference: <1278342202-10973-3-git-send-email-feng.tang@intel.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2010-07-07x86: Add i8042 pre-detection hook to x86_platform_opsFeng Tang2-1/+5
Some x86 platforms like Intel MID platforms don't have i8042 controllers, and i8042 driver's probe to some legacy IO ports may hang the MID processor. With this hook, i8042 driver can runtime check and skip the probe when the pretection fail which also saves some probe time [ hpa note: this is currently a compile-time check, which breaks the i386 allyesconfig build. This patch series thus does fix a regression. ] Signed-off-by: Feng Tang <feng.tang@intel.com> LKML-Reference: <1278342202-10973-2-git-send-email-feng.tang@intel.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2010-07-07x86, platform: Export x86_platform to modulesH. Peter Anvin1-0/+3
Export x86_platform to modules in preparation of using it for i8042 discovery control. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> LKML-Reference: <1278342202-10973-1-git-send-email-feng.tang@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Feng Tang <feng.tang@intel.com> Cc: Dmitry Torokhov <dtor@mail.ru>
2010-07-06Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds2-31/+7
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: rbtree: Undo augmented trees performance damage and regression x86, Calgary: Limit the max PHB number to 256
2010-07-06KVM: VMX: Fix host MSR_KERNEL_GS_BASE corruptionAvi Kivity1-5/+2
enter_lmode() and exit_lmode() modify the guest's EFER.LMA before calling vmx_set_efer(). However, the latter function depends on the value of EFER.LMA to determine whether MSR_KERNEL_GS_BASE needs reloading, via vmx_load_host_state(). With EFER.LMA changing under its feet, it took the wrong choice and corrupted userspace's %gs. This causes 32-on-64 host userspace to fault. Fix not touching EFER.LMA; instead ask vmx_set_efer() to change it. Signed-off-by: Avi Kivity <avi@redhat.com>
2010-07-05rbtree: Undo augmented trees performance damage and regressionPeter Zijlstra1-28/+6
Reimplement augmented RB-trees without sprinkling extra branches all over the RB-tree code (which lives in the scheduler hot path). This approach is 'borrowed' from Fabio's BFQ implementation and relies on traversing the rebalance path after the RB-tree-op to correct the heap property for insertion/removal and make up for the damage done by the tree rotations. For insertion the rebalance path is trivially that from the new node upwards to the root, for removal it is that from the deepest node in the path from the to be removed node that will still be around after the removal. [ This patch also fixes a video driver regression reported by Ali Gholami Rudi - the memtype->subtree_max_end was updated incorrectly. ] Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Tested-by: Ali Gholami Rudi <ali@rudi.ir> Cc: Fabio Checconi <fabio@gandalf.sssup.it> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <1275414172.27810.27961.camel@twins> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-07-04Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds2-3/+12
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: perf, x86: Fix incorrect branches event on AMD CPUs perf tools: Fix find tids routine by excluding "." and ".." x86: Send a SIGTRAP for user icebp traps
2010-07-03perf, x86: Fix incorrect branches event on AMD CPUsVince Weaver1-2/+2
While doing some performance counter validation tests on some assembly language programs I noticed that the "branches:u" count was very wrong on AMD machines. It looks like the wrong event was selected. Signed-off-by: Vince Weaver <vweaver1@eecs.utk.edu> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Robert Richter <robert.richter@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: <stable@kernel.org> LKML-Reference: <alpine.DEB.2.00.1007011526010.23160@cl320.eecs.utk.edu> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-06-30x86, Calgary: Limit the max PHB number to 256Darrick J. Wong1-3/+1
The x3950 family can have as many as 256 PCI buses in a single system, so change the limits to the maximum. Since there can only be 256 PCI buses in one domain, we no longer need the BUG_ON check. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2010-06-30x86: Send a SIGTRAP for user icebp trapsFrederic Weisbecker1-1/+10
Before we had a generic breakpoint layer, x86 used to send a sigtrap for any debug event that happened in userspace, except if it was caused by lazy dr7 switches. Currently we only send such signal for single step or breakpoint events. However, there are three other kind of debug exceptions: - debug register access detected: trigger an exception if the next instruction touches the debug registers. We don't use it. - task switch, but we don't use tss. - icebp/int01 trap. This instruction (0xf1) is undocumented and generates an int 1 exception. Unlike single step through TF flag, it doesn't set the single step origin of the exception in dr6. icebp then used to be reported in userspace using trap signals but this have been incidentally broken with the new breakpoint code. Reenable this. Since this is the only debug event that doesn't set anything in dr6, this is all we have to check. This fixes a regression in Wine where World Of Warcraft got broken as it uses this for software protection checks purposes. And probably other apps do. Reported-and-tested-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Prasad <prasad@linux.vnet.ibm.com> Cc: 2.6.33.x 2.6.34.x <stable@kernel.org>
2010-06-28Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds1-0/+1
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: tracing: Fix undeclared ENOSYS in include/linux/tracepoint.h perf record: prevent kill(0, SIGTERM); perf session: Remove threads from tree on PERF_RECORD_EXIT perf/tracing: Fix regression of perf losing kprobe events perf_events: Fix Intel Westmere event constraints perf record: Don't call newt functions when not initialized
2010-06-28Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tipLinus Torvalds13-24/+39
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, Calgary: Increase max PHB number x86: Fix rebooting on Dell Precision WorkStation T7400 x86: Fix vsyscall on gcc 4.5 with -Os x86, pat: Proper init of memtype subtree_max_end um, hweight: Fix UML boot crash due to x86 optimized hweight x86, setup: Set ax register in boot vga query percpu, x86: Avoid warnings of unused variables in per cpu x86, irq: Rename gsi_end gsi_top, and fix off by one errors x86: use __ASSEMBLY__ rather than __ASSEMBLER__
2010-06-25x86, Calgary: Increase max PHB numberDarrick J. Wong1-5/+10
Newer systems (x3950M2) can have 48 PHBs per chassis and 8 chassis, so bump the limits up and provide an explanation of the requirements for each class. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Acked-by: Muli Ben-Yehuda <muli@il.ibm.com> Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com> Cc: <stable@kernel.org> LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com> [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-06-20x86: Fix rebooting on Dell Precision WorkStation T7400Thomas Backlund1-0/+8
Dell Precision WorkStation T7400 freezes on reboot unless reboot=b is used. Reference: https://qa.mandriva.com/show_bug.cgi?id=58017 Signed-off-by: Thomas Backlund <tmb@mandriva.org> LKML-Reference: <4C1CC6E9.6000701@mandriva.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-06-18x86: Fix vsyscall on gcc 4.5 with -OsAndi Kleen1-1/+1
This fixes the -Os breaks with gcc 4.5 bug. rdtsc_barrier needs to be force inlined, otherwise user space will jump into kernel space and kill init. This also addresses http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129 I believe. Signed-off-by: Andi Kleen <ak@linux.intel.com> LKML-Reference: <20100618210859.GA10913@basil.fritz.box> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@kernel.org>
2010-06-12Merge branch 'bugzilla-13931-sleep-nvs' into releaseLen Brown1-1/+1
Conflicts: drivers/acpi/sleep.c Signed-off-by: Len Brown <len.brown@intel.com>
2010-06-11Merge branch 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6Linus Torvalds3-0/+8
* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6: PM / x86: Save/restore MISC_ENABLE register
2010-06-11Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6Linus Torvalds1-0/+2
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: clear bridge resource range if BIOS assigned bad one PCI: hotplug/cpqphp, fix NULL dereference Revert "PCI: create function symlinks in /sys/bus/pci/slots/N/" PCI: change resource collision messages from KERN_ERR to KERN_INFO
2010-06-11x86, pat: Proper init of memtype subtree_max_endVenkatesh Pallipadi2-1/+2
subtree_max_end that was recently added to struct memtype was not getting properly initialized resulting in WARNING: kmemcheck: Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb() reported here https://bugzilla.kernel.org/show_bug.cgi?id=16092 This change fixes the problem. Reported-by: Christian Casteyde <casteyde.christian@free.fr> Tested-by: Christian Casteyde <casteyde.christian@free.fr> Signed-off-by: Venkatesh Pallipadi <venki@google.com> LKML-Reference: <1276217101-11515-1-git-send-email-venki@google.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com>
2010-06-11PCI: clear bridge resource range if BIOS assigned bad oneYinghai Lu1-0/+2
Yannick found that video does not work with 2.6.34. The cause of this bug was that the BIOS had assigned the wrong range to the PCI bridge above the video device. Before 2.6.34 the kernel would have shrunk the size of the bridge window, but since d65245c PCI: don't shrink bridge resources the kernel will avoid shrinking BIOS ranges. So zero out the old range if we fail to claim it at boot time; this will cause us to allocate a new range at startup, restoring the 2.6.34 behavior. Fixes regression https://bugzilla.kernel.org/show_bug.cgi?id=16009. Reported-by: Yannick <yannick.roehlly@free.fr> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>