summaryrefslogtreecommitdiffstats
path: root/arch/x86_64 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] Consolidate bust_spinlocks()Kirill Korotaev2007-02-111-21/+0
| | | | | | | | | | | | | | | | | Part of long forgotten patch http://groups.google.com/group/fa.linux.kernel/msg/e98e941ce1cf29f6?dmode=source Since then, m32r grabbed two copies. Leave s390 copy because of important absence of CONFIG_VT, but remove references to non-existent timerlist_lock. ia64 also loses timerlist_lock. Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org> Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Common compat_sys_sysinfoKyle McMartin2007-02-112-67/+1
| | | | | | | | | | | | | | | | I noticed that almost all architectures implemented exactly the same sys32_sysinfo... except parisc, where a bug was to be found in handling of the uptime. So let's remove a whole whack of code for fun and profit. Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it would be the best tested. This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but instead extracting out the common code from sys_sysinfo. Cc: Christoph Hellwig <hch@infradead.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Remove unnecessary memset(0) calls after kzalloc() calls.Robert P. J. Day2007-02-111-2/+0
| | | | | | | | | | | | Delete the few remaining unnecessary calls to memset(0) after a call to kzalloc(). Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Cc: Andi Kleen <ak@suse.de> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Adam Belay <ambx1@neo.rr.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Transform kmem_cache_alloc()+memset(0) -> kmem_cache_zalloc().Robert P. J. Day2007-02-111-3/+1
| | | | | | | | | | | | | | | | | | | | | | Replace appropriate pairs of "kmem_cache_alloc()" + "memset(0)" with the corresponding "kmem_cache_zalloc()" call. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Roland McGrath <roland@redhat.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Greg KH <greg@kroah.com> Acked-by: Joel Becker <Joel.Becker@oracle.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Jan Kara <jack@ucw.cz> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: James Morris <jmorris@namei.org> Cc: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] disable init/initramfs.c: architecturesJean-Paul Saman2007-02-111-0/+4
| | | | | | | | | | | | Update all arch/*/kernel/vmlinux.lds.S to not include space for initramfs when CONFIG_BLK_DEV_INITRAMFS is not selected. This saves another 4 kbytes on most platfoms (some reserve PAGE_SIZE for initramfs). Signed-off-by: Jean-Paul Saman <jean-paul.saman@nxp.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMAChristoph Lameter2007-02-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA channel management. Other functionality may still expect GFP_DMA to provide memory below 16M. So we need to make sure that CONFIG_ZONE_DMA is set independent of CONFIG_GENERIC_ISA_DMA. Undo the modifications to mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set theses explicitly in each arches Kconfig. Reviews must occur for each arch in order to determine if ZONE_DMA can be switched off. It can only be switched off if we know that all devices supported by a platform are capable of performing DMA transfers to all of memory (Some arches already support this: uml, avr32, sh sh64, parisc and IA64/Altix). In order to switch ZONE_DMA off conditionally, one would have to establish a scheme by which one can assure that no drivers are enabled that are only capable of doing I/O to a part of memory, or one needs to provide an alternate means of performing an allocation from a specific range of memory (like provided by alloc_pages_range()) and insure that all drivers use that call. In that case the arches alloc_dma_coherent() may need to be modified to call alloc_pages_range() instead of relying on GFP_DMA. Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] x86_64 ia32 vDSO: use install_special_mappingRoland McGrath2007-02-091-46/+13
| | | | | | | | | | | | | This patch uses install_special_mapping for the ia32 vDSO setup, consolidating duplicated code. Signed-off-by: Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6Linus Torvalds2007-02-081-5/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (41 commits) Revert "PCI: remove duplicate device id from ata_piix" msi: Make MSI useable more architectures msi: Kill the msi_desc array. msi: Remove attach_msi_entry. msi: Fix msi_remove_pci_irq_vectors. msi: Remove msi_lock. msi: Kill msi_lookup_irq MSI: Combine pci_(save|restore)_msi/msix_state MSI: Remove pci_scan_msi_device() MSI: Replace pci_msi_quirk with calls to pci_no_msi() PCI: remove duplicate device id from ipr PCI: remove duplicate device id from ata_piix PCI: power management: remove noise on non-manageable hw PCI: cleanup MSI code PCI: make isa_bridge Alpha-only PCI: remove quirk_sis_96x_compatible() PCI: Speed up the Intel SMBus unhiding quirk PCI Quirk: 1k I/O space IOBL_ADR fix on P64H2 shpchp: delete trailing whitespace shpchp: remove DBG_XXX_ROUTINE ...
| * msi: Make MSI useable more architecturesEric W. Biederman2007-02-081-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The arch hooks arch_setup_msi_irq and arch_teardown_msi_irq are now responsible for allocating and freeing the linux irq in addition to setting up the the linux irq to work with the interrupt. arch_setup_msi_irq now takes a pci_device and a msi_desc and returns an irq. With this change in place this code should be useable by all platforms except those that won't let the OS touch the hardware like ppc RTAS. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | Merge branch 'release' of ↵Linus Torvalds2007-02-086-51/+54
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: (140 commits) ACPICA: reduce table header messages to fit within 80 columns asus-laptop: merge with ACPICA table update ACPI: bay: Convert ACPI Bay driver to be compatible with sysfs update. ACPI: bay: new driver is EXPERIMENTAL ACPI: bay: make drive_bays static ACPI: bay: make bay a platform driver ACPI: bay: remove prototype procfs code ACPI: bay: delete unused variable ACPI: bay: new driver adding removable drive bay support ACPI: dock: check if parent is on dock ACPICA: fix gcc build warnings Altix: Add ACPI SSDT PCI device support (hotplug) Altix: ACPI SSDT PCI device support ACPICA: reduce conflicts with Altix patch series ACPI_NUMA: fix HP IA64 simulator issue with extended memory domain ACPI: fix HP RX2600 IA64 boot ACPI: build fix for IBM x440 - CONFIG_X86_SUMMIT ACPICA: Update version to 20070126 ACPICA: Fix for incorrect parameter passed to AcpiTbDeleteTable during table load. ACPICA: Update copyright to 2007. ...
| * ACPICA: Remove duplicate table definitions (non-conflicting), contAlexey Starikovskiy2007-02-033-39/+42
| | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPICA: use new ACPI headers.Alexey Starikovskiy2007-02-032-3/+3
| | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPICA: minimal patch to integrate new tables into LinuxAlexey Starikovskiy2007-02-031-9/+9
| | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
* | [IA64] swiotlb cleanupJan Beulich2007-02-061-1/+1
|/ | | | | | | | | | | | | - add proper __init decoration to swiotlb's init code (and the code calling it, where not already the case) - replace uses of 'unsigned long' with dma_addr_t where appropriate - do miscellaneous simplicfication and cleanup Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] x86_64 ia32 vDSO: define arch_vma_nameRoland McGrath2007-01-261-0/+8
| | | | | | | | | | | | | | This patch makes x86_64 define arch_vma_name for CONFIG_IA32_EMULATION. This makes the ia32 vDSO mapping appear in /proc/PID/maps with "[vdso]" for ia32 processes, as it does on native i386. Signed-off-by: Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] x86_64 ia32 vDSO: use VM_ALWAYSDUMPRoland McGrath2007-01-262-49/+7
| | | | | | | | | | | | | | | | | | This patch fixes ia32 core dumps on x86_64 to include just one phdr for the vDSO vma. Currently it writes a confused format with two phdrs for the address, one without contents and one with. This patch removes the special-case core writing macros for the ia32 vDSO. Instead, it uses VM_ALWAYSDUMP in the vma. This changes core dumps so they no longer include the non-PT_LOAD phdrs from the vDSO, consistent with fixed native i386 core dumps. Signed-off-by: Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Revert nmi_known_cpu() check during boot option parsingVenkatesh Pallipadi2007-01-231-2/+0
| | | | | | | | | | | | | | | | | | | | | | | Commit f2802e7f571c05f9a901b1f5bd144aa730ccc88e and its x86 version (b7471c6da94d30d3deadc55986cc38d1ff57f9ca) adds nmi_known_cpu() check while parsing boot options in x86_64 and i386. With that, "nmi_watchdog=2" stops working for me on Intel Core 2 CPU based system. The problem is, setup_nmi_watchdog is called while parsing the boot option and identify_cpu is not done yet. So, the return value of nmi_known_cpu() is not valid at this point. So revert that check. This should not have any adverse effect as the nmi_known_cpu() check is done again later in enable_lapic_nmi_watchdog(). Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Andi Kleen <ak@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] x86-64: Fix warnings in ia32_aout.cAndi Kleen2007-01-111-2/+2
| | | | | | | | | | | Fix linux/arch/x86_64/ia32/ia32_aout.c: In function ‘create_aout_tables’: linux/arch/x86_64/ia32/ia32_aout.c:244: warning: cast from pointer to integer of different size linux/arch/x86_64/ia32/ia32_aout.c:253: warning: cast from pointer to integer of different size with gcc 4.3 Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] x86-64: tighten up printksMuli Ben-Yehuda2007-01-111-3/+8
| | | | | | | Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
* [PATCH] x86-64: - Ignore long SMI interrupts in clock calibrationJack Steiner2007-01-111-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that no SMI interrupts occur between the read of the HPET & TSC in the clock calibration loop. I noticed that a 2.66GHz system incorrectly detected the processor clock speed about 1/7 of the time: time.c: Detected 2660.005 MHz processor. (most of the time) time.c: Detected 2988.203 MHz processor. (sometime) The problem is caused by an SMI interrupt occuring in hpet_calibrate_tsc() between the read of the HPET & TSC. Prior to switching the BIOS into ACPI mode, it appears that every 27msec an SMI interrupt occurs. The SMI interrupt takes 4.8 msec to process. Note: On my test system, TICK_MIN had to be >380. I picked 5000 to minimize risk of having a value that is too small for other platforms. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Andi Kleen <ak@suse.de> arch/x86_64/kernel/time.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)
* [PATCH] x86-64: Update defconfigAndi Kleen2007-01-111-4/+12
| | | | Signed-off-by: Andi Kleen <ak@suse.de>
* Revert "[PATCH] x86-64: Try multiple timer variants in check_timer"Linus Torvalds2007-01-092-51/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b026872601976f666bae77b609dc490d1834bf77, which has been linked to several problem reports with IO-APIC and the timer. Machines either don't boot because the timer doesn't happen, or we get double timer interrupts because we end up double-routing the timer irq through multiple interfaces. See for example http://lkml.org/lkml/2006/12/16/101 http://lkml.org/lkml/2007/1/3/9 http://bugzilla.kernel.org/show_bug.cgi?id=7789 about some of the discussion. Patches to fix this cleanup exist (and have been confirmed to work fine at least for some of the affected cases) and we'll revisit it for 2.6.21, but this late in the -rc series we're better off just reverting the incomplete commit that caused the problems. Suggested-by: Adrian Bunk <bunk@stusta.de> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Yinghai Lu <yinghai.lu@amd.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds2007-01-041-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] longhaul: Kill off warnings introduced by recent changes. [CPUFREQ] Uninitialized use of cmd.val in arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:acpi_cpufreq_target() [CPUFREQ] Longhaul - Always guess FSB [CPUFREQ] Longhaul - Fix up powersaver assumptions. [CPUFREQ] longhaul: Fix up unreachable code. [CPUFREQ] speedstep-centrino: missing space and bracket [CPUFREQ] Bug fix for acpi-cpufreq and cpufreq_stats oops on frequency change notification [CPUFREQ] select consistently
| * [CPUFREQ] select consistentlyRandy Dunlap2006-12-231-0/+1
| | | | | | | | | | | | | | | | | | Make x86_64 ACPI_CPU_FREQ select CPU_FREQ_TABLE like other methods do. (although we should still eliminate as much use of 'select' as possible) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
* | [PATCH] x86_64: Fix dump_trace()OGAWA Hirofumi2007-01-031-1/+1
| | | | | | | | | | | | | | | | If caller passed the tsk, we should use it to validate a stack ptr. Otherwise, sysrq-t and other debugging stuff doesn't work. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | Revert "[PATCH] x86_64: fix boot hang caused by ↵Linus Torvalds2007-01-011-2/+3
| | | | | | | | | | | | | | | | | | | | CALGARY_IOMMU_ENABLED_BY_DEFAULT" This reverts commit a9622f6219ce58faba1417743bf3078501eb3434. Now that the Calgary code apparently detects itself properly, it's not needed any more. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] make fn_keys work again on power/macbooksSoeren Sonnenburg2006-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The apple fn keys don't work anymore with 2.6.20-rc1. The reason is that USB_HID_POWERBOOK appears in several files although USB_HIDINPUT_POWERBOOK is the thing to be used. The patch fixes this. Cc: Greg KH <greg@kroah.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and ↵Ingo Molnar2006-12-221-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APM idle code Fernando Lopez-Lezcano reported frequent scheduling latencies and audio xruns starting at the 2.6.18-rt kernel, and those problems persisted all until current -rt kernels. The latencies were serious and unjustified by system load, often in the milliseconds range. After a patient and heroic multi-month effort of Fernando, where he tested dozens of kernels, tried various configs, boot options, test-patches of mine and provided latency traces of those incidents, the following 'smoking gun' trace was captured by him: _------=> CPU# / _-----=> irqs-off | / _----=> need-resched || / _---=> hardirq/softirq ||| / _--=> preempt-depth |||| / ||||| delay cmd pid ||||| time | caller \ / ||||| \ | / IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (try_to_wake_up) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup <<...>-5856> (37 0) IRQ_19-1479 1D..1 0us : __trace_start_sched_wakeup (c01262ba 0 0) IRQ_19-1479 1D..1 0us : resched_task (try_to_wake_up) IRQ_19-1479 1D..1 0us : __spin_unlock_irqrestore (try_to_wake_up) ... <idle>-0 1...1 11us!: default_idle (cpu_idle) ... <idle>-0 0Dn.1 602us : smp_apic_timer_interrupt (c0103baf 1 0) ... <...>-5856 0D..2 618us : __switch_to (__schedule) <...>-5856 0D..2 618us : __schedule <<idle>-0> (20 162) <...>-5856 0D..2 619us : __spin_unlock_irq (__schedule) <...>-5856 0...1 619us : trace_stop_sched_switched (__schedule) <...>-5856 0D..1 619us : trace_stop_sched_switched <<...>-5856> (37 0) what is visible in this trace is that CPU#1 ran try_to_wake_up() for PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task() for CPU#0. But it decided to not send an IPI that no CPU - due to TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set, and only rescheduled to PID:5856 upon the next lapic timer IRQ. The result was a 600+ usecs latency and a missed wakeup! the bug turned out to be an idle-wakeup bug introduced into the mainline kernel this summer via an optimization in the x86_64 tree: commit 495ab9c045e1b0e5c82951b762257fe1c9d81564 Author: Andi Kleen <ak@suse.de> Date: Mon Jun 26 13:59:11 2006 +0200 [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status During some profiling I noticed that default_idle causes a lot of memory traffic. I think that is caused by the atomic operations to clear/set the polling flag in thread_info. There is actually no reason to make this atomic - only the idle thread does it to itself, other CPUs only read it. So I moved it into ti->status. the problem is this type of change: if (!hlt_counter && boot_cpu_data.hlt_works_ok) { - clear_thread_flag(TIF_POLLING_NRFLAG); + current_thread_info()->status &= ~TS_POLLING; smp_mb__after_clear_bit(); while (!need_resched()) { local_irq_disable(); this changes clear_thread_flag() to an explicit clearing of TS_POLLING. clear_thread_flag() is defined as: clear_bit(flag, &ti->flags); and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms: static inline void clear_bit(int nr, volatile unsigned long * addr) { __asm__ __volatile__( LOCK_PREFIX "btrl %1,%0" hence smp_mb__after_clear_bit() is defined as a simple compile barrier: #define smp_mb__after_clear_bit() barrier() but the explicit TS_POLLING clearing introduced by the patch: + current_thread_info()->status &= ~TS_POLLING; is not an atomic op! So the clearing of the TS_POLLING bit is freely reorderable with the reading of the NEED_RESCHED bit - and both now reside in different memory addresses. CPU idle wakeup very much depends on ordered memory ops, the clearing of the TS_POLLING flag must always be done before we test need_resched() and hit the idle instruction(s). [Symmetrically, the wakeup code needs to set NEED_RESCHED before it tests the TS_POLLING flag, so memory ordering is paramount.] Fernando's dual-core Athlon64 system has a sufficiently advanced memory ordering model so that it triggered this scenario very often. ( And it also turned out that the reason why these latencies never triggered on my testsystems is that i routinely use idle=poll, which was the only idle variant not affected by this bug. ) The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to act as an absolute barrier between the TS_POLLING write and the NEED_RESCHED read. This affects almost all idling methods (default, ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64. Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] x86_64: fix boot time hang in detect_calgary()Ingo Molnar2006-12-211-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | if CONFIG_CALGARY_IOMMU is built into the kernel via CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT, or is enabled via the iommu=calgary boot option, then the detect_calgary() function runs to detect the presence of a Calgary IOMMU. detect_calgary() first searches the BIOS EBDA area for a "rio_table_hdr" BIOS table. It has this parsing algorithm for the EBDA: while (offset) { ... /* The next offset is stored in the 1st word. 0 means no more */ offset = *((unsigned short *)(ptr + offset)); } got that? Lets repeat it slowly: we've got a BIOS-supplied data structure, plus Linux kernel code that will only break out of an infinite parsing loop once the BIOS gives a zero offset. Ok? Translation: what an excellent opportunity for BIOS writers to lock up the Linux boot process in an utterly hard to debug place! Indeed the BIOS jumped on that opportunity on my box, which has the following EBDA chaining layout: 384, 65282, 65535, 65535, 65535, 65535, 65535, 65535 ... see the pattern? So my, definitely non-Calgary system happily locks up in detect_calgary()! the patch below fixes the boot hang by trusting the BIOS-supplied data structure a bit less: the parser always has to make forward progress, and if it doesnt, we break out of the loop and i get the expected kernel message: Calgary: Unable to locate Rio Grande Table in EBDA - bailing! Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY_DEFAULTIngo Molnar2006-12-211-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | one of my boxes didnt boot the 2.6.20-rc1-rt0 kernel rpm, it hung during early bootup. After an hour or two of happy debugging i narrowed it down to the CALGARY_IOMMU_ENABLED_BY_DEFAULT option, which was freshly added to 2.6.20 via the x86_64 tree and /enabled by default/. commit bff6547bb6a4e82c399d74e7fba78b12d2f162ed claims: [PATCH] Calgary: allow compiling Calgary in but not using it by default This patch makes it possible to compile Calgary in but not use it by default. In this mode, use 'iommu=calgary' to activate it. but the change does not actually practice it: config CALGARY_IOMMU_ENABLED_BY_DEFAULT bool "Should Calgary be enabled by default?" default y depends on CALGARY_IOMMU help Should Calgary be enabled by default? if you choose 'y', Calgary will be used (if it exists). If you choose 'n', Calgary will not be used even if it exists. If you choose 'n' and would like to use Calgary anyway, pass 'iommu=calgary' on the kernel command line. If unsure, say Y. it's both 'default y', and says "If unsure, say Y". Clearly not a typo. disabling this option makes my box boot again. The patch below fixes the Kconfig entry. Grumble. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | Remove stack unwinder for nowLinus Torvalds2006-12-155-123/+0
|/ | | | | | | | | | It has caused more problems than it ever really solved, and is apparently not getting cleaned up and fixed. We can put it back when it's stable and isn't likely to make warning or bug events worse. In the meantime, enable frame pointers for more readable stack traces. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge ../linusDave Jones2006-12-1248-671/+1064
|\ | | | | | | | | | | Conflicts: drivers/cpufreq/cpufreq.c
| * [PATCH] Fix typo in 'EXPERIMENTAL' in CC_STACKPROTECTOR on x86_64Brice Goglin2006-12-111-1/+1
| | | | | | | | | | | | | | Fix typo in 'EXPERIMENTAL' in config CC_STACKPROTECTOR in arch/x86_64/Kconfig. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| * [PATCH] sysctl: remove unused "context" paramAlexey Dobriyan2006-12-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Andi Kleen <ak@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Howells <dhowells@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| * [PATCH] x86: Work around gcc 4.2 over aggressive optimizerAndi Kleen2006-12-091-0/+1
| | | | | | | | | | | | | | | | | | | | The new PDA code uses a dummy _proxy_pda variable to describe memory references to the PDA. It is never referenced in inline assembly, but exists as input/output arguments. gcc 4.2 in some cases can CSE references to this which causes unresolved symbols. Define it to zero to avoid this. Signed-off-by: Andi Kleen <ak@suse.de>
| * [PATCH] x86: Fix boot hang due to nmi watchdog init codeRavikiran G Thirumalai2006-12-091-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2.6.19 stopped booting (or booted based on build/config) on our x86_64 systems due to a bug introduced in 2.6.19. check_nmi_watchdog schedules an IPI on all cpus to busy wait on a flag, but fails to set the busywait flag if NMI functionality is disabled. This causes the secondary cpus to spin in an endless loop, causing the kernel bootup to hang. Depending upon the build, the busywait flag got overwritten (stack variable) and caused the kernel to bootup on certain builds. Following patch fixes the bug by setting the busywait flag before returning from check_nmi_watchdog. I guess using a stack variable is not good here as the calling function could potentially return while the busy wait loop is still spinning on the flag. AK: I redid the patch significantly to be cleaner Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Signed-off-by: Andi Kleen <ak@suse.de>
| * [PATCH] x86-64: Update defconfigAndi Kleen2006-12-091-7/+22
| | | | | | | | Signed-off-by: Andi Kleen <ak@suse.de>
| * [PATCH] LOG2: Implement a general integer log2 facility in the kernelDavid Howells2006-12-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This facility provides three entry points: ilog2() Log base 2 of unsigned long ilog2_u32() Log base 2 of u32 ilog2_u64() Log base 2 of u64 These facilities can either be used inside functions on dynamic data: int do_something(long q) { ...; y = ilog2(x) ...; } Or can be used to statically initialise global variables with constant values: unsigned n = ilog2(27); When performing static initialisation, the compiler will report "error: initializer element is not constant" if asked to take a log of zero or of something not reducible to a constant. They treat negative numbers as unsigned. When not dealing with a constant, they fall back to using fls() which permits them to use arch-specific log calculation instructions - such as BSR on x86/x86_64 or SCAN on FRV - if available. [akpm@osdl.org: MMC fix] Signed-off-by: David Howells <dhowells@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Howells <dhowells@redhat.com> Cc: Wojtek Kaniewski <wojtekka@toxygen.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| * [PATCH] x86_64: change uses of f_{dentry, vfsmnt} to use f_pathJosef "Jeff" Sipek2006-12-081-4/+4
| | | | | | | | | | | | | | | | | | Change all the uses of f_{dentry,vfsmnt} to f_path.{dentry,mnt} in the x86_64 arch code. Signed-off-by: Josef "Jeff" Sipek <jsipek@cs.sunysb.edu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| * [PATCH] Generic BUG for x86-64Jeremy Fitzhardinge2006-12-084-25/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes x86-64 use the generic BUG machinery. The main advantage in using the generic BUG machinery for x86-64 is that the inlined overhead of BUG is just the ud2a instruction; the file+line information are no longer inlined into the instruction stream. This reduces cache pollution. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Andi Kleen <ak@muc.de> Cc: Hugh Dickens <hugh@veritas.com> Cc: Michael Ellerman <michael@ellerman.id.au> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| * Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6Linus Torvalds2006-12-0731-356/+647
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (156 commits) [PATCH] x86-64: Export smp_call_function_single [PATCH] i386: Clean up smp_tune_scheduling() [PATCH] unwinder: move .eh_frame to RODATA [PATCH] unwinder: fully support linker generated .eh_frame_hdr section [PATCH] x86-64: don't use set_irq_regs() [PATCH] x86-64: check vector in setup_ioapic_dest to verify if need setup_IO_APIC_irq [PATCH] x86-64: Make ix86 default to HIGHMEM4G instead of NOHIGHMEM [PATCH] i386: replace kmalloc+memset with kzalloc [PATCH] x86-64: remove remaining pc98 code [PATCH] x86-64: remove unused variable [PATCH] x86-64: Fix constraints in atomic_add_return() [PATCH] x86-64: fix asm constraints in i386 atomic_add_return [PATCH] x86-64: Correct documentation for bzImage protocol v2.05 [PATCH] x86-64: replace kmalloc+memset with kzalloc in MTRR code [PATCH] x86-64: Fix numaq build error [PATCH] x86-64: include/asm-x86_64/cpufeature.h isn't a userspace header [PATCH] unwinder: Add debugging output to the Dwarf2 unwinder [PATCH] x86-64: Clarify error message in GART code [PATCH] x86-64: Fix interrupt race in idle callback (3rd try) [PATCH] x86-64: Remove unwind stack pointer alignment forcing again ... Fixed conflict in include/linux/uaccess.h manually Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| | * [PATCH] x86-64: Export smp_call_function_singleAndi Kleen2006-12-071-0/+1
| | | | | | | | | | | | | | | | | | smp_call_function() is exported, makes sense to export this one too. Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] unwinder: move .eh_frame to RODATAJan Beulich2006-12-071-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .eh_frame section contents is never written to, so it can as well benefit from CONFIG_DEBUG_RODATA. Diff-ed against firstfloor tree. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] x86-64: check vector in setup_ioapic_dest to verify if need ↵Yinghai Lu2006-12-071-43/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | setup_IO_APIC_irq setup_IO_APIC_irqs could fail to get vector for some device when you have too many devices, because at that time only boot cpu is online. So check vector for irq in setup_ioapic_dest and call setup_IO_APIC_irq to make sure IO-APIC irq-routing table is initialized. Also seperate setup_IO_APIC_irq from setup_IO_APIC_irqs. Signed-off-by: Yinghai Lu <yinghai.lu@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org>
| | * [PATCH] x86-64: Clarify error message in GART codeAndi Kleen2006-12-071-2/+1
| | | | | | | | | | | | | | | | | | | | | - Remove "Disabling IOMMU" message because it confuses people - Clarify that the GART IOMMU is refered to in other message Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] x86-64: Fix interrupt race in idle callback (3rd try)Venkatesh Pallipadi2006-12-071-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Idle callbacks has some races when enter_idle() sets isidle and subsequent interrupts that can happen on that CPU, before CPU goes to idle. Due to this, an IDLE_END can get called before IDLE_START. To avoid these races, disable interrupts before enter_idle and make sure that all idle routines do not enable interrupts before entering idle. Note that poll_idle() still has a this race as it has to enable interrupts before going to idle. But, all other idle routines have the race fixed. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] x86-64: Remove unwind stack pointer alignment forcing againAndi Kleen2006-12-071-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This was added as a workaround for the fallback unwinder not supporting unaligned stack pointers properly. But now it was fixed to do that, so it's not needed anymore Cc: mingo@elte.hu Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] unwinder: more sanity checks in Dwarf2 unwinderJan Beulich2006-12-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Tighten the requirements on both input to and output from the Dwarf2 unwinder. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] unwinder: always use unlocked module list access in unwinder fallbackAndi Kleen2006-12-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're already well protected against module unloads because module unload uses stop_machine(). The only exception is NMIs, but other users already risk lockless accesses here. This avoids some hackery in lockdep and also a potential deadlock This matches what i386 does. Signed-off-by: Andi Kleen <ak@suse.de>
| | * [PATCH] x86-64: Mark rdtsc as sync only for netburst, not for core2Arjan van de Ven2006-12-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the Core2 cpus, the rdtsc instruction is not serializing (as defined in the architecture reference since rdtsc exists) and due to the deep speculation of these cores, it's possible that you can observe time go backwards between cores due to this speculation. Since the kernel already deals with this with the SYNC_RDTSC flag, the solution is simple, only assume that the instruction is serializing on family 15... The price one pays for this is a slightly slower gettimeofday (by a dozen or two cycles), but that increase is quite small to pay for a really-going-forward tsc counter. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 16:57:41 +0100