aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86_64 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2007-04-28libata/IDE: remove combined mode quirkJeff Garzik1-1/+0
Both old-IDE and libata should be able handle all controllers and devices found using normal resource reservation methods. This eliminates the awful, low-performing split-driver configuration where old-IDE drove the PATA portion of a PCI device, in PIO-only mode, and libata drove the SATA portion of the /same/ PCI device, in DMA mode. Typically vendors would ship SATA hard drive / PATA optical configuration, which would lend itself to slow (PIO-only) CD-ROM performance. For Intel users running in combined mode, it is now wholly dependent on your driver choice (potentially link order, if you compile both drivers in) whether old-IDE or libata will drive your hardware. In either case, you will get full performance from both SATA and PATA ports now, without having to pass a kernel command line parameter. Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-04-24[PATCH] x86-64: Always flush all pages in change_page_attrAndi Kleen1-1/+1
change_page_attr on x86-64 only flushed the TLB for pages that got reverted. That's not correct: it has to be flushed in all cases. This bug was added in some earlier changes. Just flush all pages for now. This could be done more efficiently, but for this late in the release this seem to be the best fix. Pointed out by Jan Beulich Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-24[PATCH] x86-64: make GART PTEs uncacheableJoachim Deguara1-1/+5
This patches fixes the silent data corruption problems being seen using the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia CK804 systems). This fix, to mark the memory regin the GART PTEs reside on as uncacheable, also brings the code in line with the AGP specification. Signed-off-by: Joachim Deguara <joachim.deguara@amd.com> Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-17Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds1-1/+0
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [BRIDGE]: Unaligned access when comparing ethernet addresses [SCTP]: Unmap v4mapped addresses during SCTP_BINDX_REM_ADDR operation. [SCTP]: Fix assertion (!atomic_read(&sk->sk_rmem_alloc)) failed message [NET]: Set a separate lockdep class for neighbour table's proxy_queue [NET]: Fix UDP checksum issue in net poll mode. [KEY]: Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx. [NET]: Get rid of alloc_skb_from_cache
2007-04-17Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6Linus Torvalds2-5/+7
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: [PATCH] x86: Fix potential overflow in perfctr reservation [PATCH] x86: Fix gcc 4.2 _proxy_pda workaround
2007-04-17[NET]: Get rid of alloc_skb_from_cacheHerbert Xu1-1/+0
Since this was added originally for Xen, and Xen has recently (~2.6.18) stopped using this function, we can safely get rid of it. Good timing too since this function has started to bit rot. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-16cache_k8_northbridges() overflows beyond allocationBadari Pulavarty1-2/+2
cache_k8_northbridges() is storing config values to incorrect locations (in flush_words) and also its overflowing beyond the allocation, causing slab verification failures. Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-04-16[PATCH] x86: Fix potential overflow in perfctr reservationAndi Kleen1-4/+6
While reviewing this code again I found a potential overflow of the bitmap. The p4 oprofile can theoretically set bits beyond the reservation bitmap for specific configurations. Avoid that by sizing the bitmaps properly. Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-16[PATCH] x86: Fix gcc 4.2 _proxy_pda workaroundAndi Kleen1-1/+1
Due to an over aggressive optimizer gcc 4.2 cannot optimize away _proxy_pda in all cases (counter intuitive, but true). This breaks loading of some modules. The earlier workaround to just export a dummy symbol didn't work unfortunately because the module code ignores exports with 0 value. Make it 1 instead. Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-14failsafe mechanism to HPET clock calibrationRavikiran G Thirumalai1-3/+6
Provide a failsafe mechanism to avoid kernel spinning forever at read_hpet_tsc during early kernel bootup. This failsafe mechanism was originally introduced in commit 2f7a2a79c3ebb44f8b1b7d9b4fd3a650eb69e544, but looks like the hpet split from time.c lost it again. This reintroduces the failsafe mechanism Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Cc: Jack Steiner <steiner@sgi.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-04-08[PATCH] x86_64 early quirks: fix early_qrk[] section tagAndrew Morton1-1/+1
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:nvidia_bugs from .data between 'early_qrk' (at offset 0x8428) and 'enable_cpu_hotplug' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:via_bugs from .data between 'early_qrk' (at offset 0x8438) and 'enable_cpu_hotplug' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:ati_bugs from .data between 'early_qrk' (at offset 0x8448) and 'enable_cpu_hotplug' The compiler is putting it into .data because the __initdata is in the wrong place. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-04-02[PATCH] x86: Don't probe for DDC on VBE1.2Zwane Mwaikambo1-0/+14
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst uncompressing kernel with some video cards. Make sure we check VBE version before fiddling around with DDC. http://bugzilla.kernel.org/show_bug.cgi?id=1458 Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03 Much thanks to Tobias Hain for help in testing and investigating the bug. Tested on; i386, Chips & Technologies 65548 VESA VBE 1.2 CONFIG_VIDEO_SELECT=Y CONFIG_FIRMWARE_EDID=Y Untested on x86_64. Signed-off-by: Zwane Mwaikambo <zwane@infradead.org> Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-02[PATCH] x86-64: Increase NMI watchdog probing timeoutAndi Kleen1-1/+1
A 4 core Opteron needs longer than 10 ticks for this. Signed-off-by: Andi Kleen <ak@suse.de>
2007-04-02[PATCH] x86-64: Let oprofile reserve MSR on all CPUsAndi Kleen1-27/+91
The MSR reservation is per CPU and oprofile would only allocate them on the CPU it was initialized on. Change this to handle all CPUs. This also fixes a warning about unprotected use of smp_processor_id() in preemptible kernels. Signed-off-by: Andi Kleen <ak@suse.de>
2007-03-29[PATCH] x86_64 irq: Fix comments after changing IRQ0_VECTOR from 0x20 to 0x30Yinghai Lu1-3/+3
Signed-off-by: Yinghai Lu <yinghai.lu@amd.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-27[PATCH] Revert "swsusp: disable nonboot CPUs before entering platform suspend"Rafael J. Wysocki1-1/+3
This reverts commit 94985134b7b46848267ed6b734320db01c974e72 and insteads removes the WARN_ON() that caused that commit in the first place. The problem is that we call disable_nonboot_cpus() in swsusp before powering down the system in order to avoid triggering the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't work well on Thomas' system. So instead, remove the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c: init_low_mapping(), which triggers every time during the suspend to disk in the platform mode, as the potential problem it is related to doesn't seem to occur in practice. [ I think we might want to disallow the case of multiple users of that mm, or something. Normally, playing with the current process page tables on the current CPU should be fine as long as we don't have other threads using those tables at the same time.. Anyway, not pretty, but better than the warning or the lockup - Linus ] Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-23[PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itselfThomas Gleixner1-0/+8
Ray Lee reported, that on an UP kernel with "noapic" command line option set, the box locks hard during boot. Adding some debug printks revealed, that the last action on the box before stalling was "Send IPI" - a debug printk which was put into smp_send_timer_broadcast_ipi(). It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when "noapic" is set on the command line on an UP kernel. Aside of that it does not make much sense to trigger an interrupt instead of calling the function directly on the CPU which gets the PIT/HPET interrupt in case of broadcasting. Reported-by: Ray Lee <ray-lk@madrabbit.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ray Lee <ray-lk@madrabbit.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-23x86-64: add "local_apic_timer_c2_ok" here tooLinus Torvalds1-0/+11
Needed for any architecture that claims ARCH_APICTIMER_STOPS_ON_C3, not just i386. I'm hoping Thomas will clean this up a bit later.. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-18[PATCH] Fix atomicity of TIF update in flush_thread() for x86_64Mathieu Desnoyers1-5/+8
Fix atomicity of TIF update in flush_thread() for x86_64 Race : parent process executing : sys_ptrace() (lock_kernel()) (ptrace_get_task_struct(pid)) arch_ptrace() ptrace_detach() ptrace_disable(child); clear_singlestep(child); clear_tsk_thread_flag(child, TIF_SINGLESTEP); (which clears the TIF_SINGLESTEP flag atomically from a different process) (put_task_struct(child)) (unlock_kernel()) And at the same time, in the child process : sys_execve() do_execve() search_binary_handler() load_elf_binary() flush_old_exec() flush_thread() doing a non-atomic thread flag update Signed-off-by: Rebecca Schultz <rschultz@google.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-18[PATCH] X86_P4_CLOCKMOD must select CPU_FREQ_TABLEAdrian Bunk1-0/+1
CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m CONFIG_X86_P4_CLOCKMOD=y arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_verify':p4-clockmod.c:(.text.cpufreq_p4_verify+0x8): undefined reference to `cpufreq_frequency_table_verify' arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_exit':p4-clockmod.c:(.text.cpufreq_p4_cpu_exit+0x8): undefined reference to `cpufreq_frequency_table_put_attr' arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_init':p4-clockmod.c:(.text.cpufreq_p4_cpu_init+0x13b): undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Dave Jones <davej@redhat.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-16[PATCH] x86: Export _proxy_pda for gcc 4.2Andi Kleen1-0/+1
The symbol is not actually used, but the compiler unforunately generates a (unused) reference to it. This can happen even in modules. So export it. Signed-off-by: Andi Kleen <ak@suse.de>
2007-03-16[PATCH] x86-64: fix section mismatch warningsSam Ravnborg4-8/+8
Fix the following section mismatch warnings on x86_64: (build using defconfig) WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0x65eb) and 'IRQ0x20_interrupt' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'finish_e820_parsing' (at offset 0x7dc2) and 'early_panic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:e820_print_map from .text between 'finish_e820_parsing' (at offset 0x7de1) and 'early_panic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'acpi_unmap_lsapic' (at offset 0xc88f) and 'acpi_register_ioapic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:disabled_cpus from .text between 'MP_processor_info' (at offset 0x11f35) and 'mp_register_lapic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'MP_processor_info' (at offset 0x11f6e) and 'mp_register_lapic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:num_processors from .text between 'MP_processor_info' (at offset 0x11f93) and 'mp_register_lapic' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fix_aperture from .text between 'gart_parse_options' (at offset 0x15517) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fix_aperture from .text between 'gart_parse_options' (at offset 0x1552c) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x1553d) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15552) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15561) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'gart_parse_options' (at offset 0x15577) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fallback_aper_force from .text between 'gart_parse_options' (at offset 0x1558a) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:fallback_aper_order from .text between 'gart_parse_options' (at offset 0x155bf) and 'iommu_full' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:timer_over_8254 from .text between 'ati_bugs' (at offset 0x16344) and 'via_bugs' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:timer_over_8254 from .text between 'ati_bugs' (at offset 0x16356) and 'via_bugs' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_allowed from .text between 'via_bugs' (at offset 0x16380) and 'nvidia_bugs' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:iommu_aperture_disabled from .text between 'via_bugs' (at offset 0x16397) and 'nvidia_bugs' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:acpi_use_timer_override from .text between 'nvidia_bugs' (at offset 0x163a7) and 'arch_unregister_cpu' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:nvidia_hpet_check from .text between 'nvidia_bugs' (at offset 0x163b1) and 'arch_unregister_cpu' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'nvidia_bugs' (at offset 0x163be) and 'arch_unregister_cpu' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text between 'nvidia_bugs' (at offset 0x163d1) and 'arch_unregister_cpu' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data:acpi_skip_timer_override from .text between 'nvidia_bugs' (at offset 0x163e1) and 'arch_unregister_cpu' WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:quirk_intel_irqbalance from .text between 'intel_bugs' (at offset 0x1633c) and 'ati_bugs' But adds: WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:get_mtrr_state from .text between 'mtrr_bp_init' (at offset 0xb887) and 'ipi_handler' The warnings does not show up during a normal build due to kbuild failing to check for section mismatch in vmlinux. To see these warnings run: scripts/mod/modpost arch/x86_64/kernel/built-in.o kbuild will be fixed but the 'noise-level' had to be decresed first. There remains a few section mismatch warnigns for x86_64 for areas where I did not feel confident. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andi Kleen <ak@suse.de>
2007-03-16[PATCH] x86-64: wire up compat sched_rr_get_interval(2)Alexandr Andreev1-1/+1
sys32_sched_rr_get_interval() uses compat_timespec but wasn't used itself. Signed-off-by: Alexandr Andreev <aandreev@openvz.org> Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org> Signed-off-by: Andi Kleen <ak@suse.de>
2007-03-16[PATCH] x86-64: Update defconfigAndi Kleen1-16/+37
Signed-off-by: Andi Kleen <ak@suse.de>
2007-03-14Disable NMI watchdog by default properlyLinus Torvalds1-4/+1
This reverts commit 6ebf622b2577c50b1f496bd6a5e8739e55ae7b1c and replaces it with one that actually works. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-14[PATCH] misc NULL noiseAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-08[PATCH] ACPI: repair nvidia early quirk breakage on x86_64Len Brown1-8/+1
x86_64 nvidia_bugs() broke when we bailed out on not finding the HPET. However, the quirk works by checking for _not_ finding the HPET... Delete the nvidia_hpet_detected flag and simply test for not finding the HPET, which is simple to do now that acpi_table_parse returns 1 on failure. Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-08[PATCH] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be acceptedPaolo 'Blaisorblade' Giarrusso1-0/+1
Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and forced by binary compatibility. UML/32bit breaks because of this - since it is wise enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host kernels. Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had: default: return sys_ptrace(request, pid, addr, data); Instead here we have: case PTRACE_GET_THREAD_AREA: case ...: return sys_ptrace(request, pid, addr, data); default: return -EINVAL; This change was a style change - when a case is added, it must be explicitly tested this way. In this case, not enough testing was done. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-07[PATCH] CPU hotplug: call check_tsc_sync_source() with irqs offIngo Molnar1-1/+4
check_tsc_sync_source() depends on being called with irqs disabled (it checks whether the TSC is coherent across two specific CPUs). This is incidentally true during bootup, but not during cpu hotplug __cpu_up(). This got found via smp_processor_id() debugging. disable irqs explicitly and remove the unconditional enabling of interrupts. Add touch_nmi_watchdog() to the cpu_online_map busy loop. this bug is present both on i386 and on x86_64. Reported-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-05[PATCH] clocksource init adjustments (fix bug #7426)john stultz3-70/+48
This patch resolves the issue found here: http://bugme.osdl.org/show_bug.cgi?id=7426 The basic summary is: Currently we register most of i386/x86_64 clocksources at module_init time. Then we enable clocksource selection at late_initcall time. This causes some problems for drivers that use gettimeofday for init calibration routines (specifically the es1968 driver in this case), where durring module_init, the only clocksource available is the low-res jiffies clocksource. This may cause slight calibration errors, due to the small sampling time used. It should be noted that drivers that require fine grained time may not function on architectures that do not have better then jiffies resolution timekeeping (there are a few). However, this does not discount the reasonable need for such fine-grained timekeeping at init time. Thus the solution here is to register clocksources earlier (ideally when the hardware is being initialized), and then we enable clocksource selection at fs_initcall (before device_initcall). This patch should probably get some testing time in -mm, since clocksource selection is one of the most important issues for correct timekeeping, and I've only been able to test this on a few of my own boxes. Signed-off-by: John Stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-05[PATCH] x86_64: remove unusued 'flags' variableDavid Rientjes1-1/+0
Removes unused 'flags' variable from setup_IO_APIC_irq(). Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-28[PATCH] x86_64/i386 irq: Fix !CONFIG_SMP compilationEric W. Biederman1-4/+0
When removing set_native_irq I missed the fact that it was called in a couple of places that were compiled even when SMP support is disabled. And since the irq_desc[].affinity field only exists in SMP things broke. Thanks to Simon Arlott <simon@arlott.org> for spotting this. There are a couple of ways to fix this but the simplest one is to just remove the assignments. The affinity field is only used to display a value to the user, and nothing on either i386 or x86_64 reads it or depends on it being any particlua value, so skipping the assignment is safe. The assignment that is being removed is just for the initial affinity value before the user explicitly sets it. The irq_desc array initializes this field to CPU_MASK_ALL so the field is initialized to a reasonable value in the SMP case without being set. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds3-1/+2
* master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] constify some data tables. [CPUFREQ] constify cpufreq_driver where possible. {rd,wr}msr_on_cpu SMP=n optimization [CPUFREQ] cpufreq_ondemand.c: don't use _WORK_NAR rdmsr_on_cpu, wrmsr_on_cpu [CPUFREQ] Revert default on deprecated config X86_SPEEDSTEP_CENTRINO_ACPI
2007-02-26[PATCH] x86_64 irq: Safely cleanup an irq after moving it.Eric W. Biederman3-6/+81
The problem: After moving an interrupt when is it safe to teardown the data structures for receiving the interrupt at the old location? With a normal pci device it is possible to issue a read to a device to flush all posted writes. This does not work for the oldest ioapics because they are on a 3-wire apic bus which is a completely different data path. For some more modern ioapics when everything is using front side bus delivery you can flush interrupts by simply issuing a read to the ioapic. For other modern ioapics emperical testing has shown that this does not work. So it appears the only reliable way to know the last of the irqs from an ioapic have been received from before the ioapic was reprogrammed is to received the first irq from the ioapic from after it was reprogrammed. Once we know the last irq message has been received from an ioapic into a local apic we then need to know that irq message has been processed through the local apics. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Add constants for the reserved IRQ vectors.Eric W. Biederman2-36/+36
For the ISA irqs we reserve 16 vectors. This patch adds constants for those vectors and modifies the code to use them. Making the code a little clearer and making it possible to move these vectors in the future. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Remove unnecessary irq 0 setup.Eric W. Biederman1-6/+0
The code in io_apic.c and in i8259.c currently hardcode the same vector for the timer interrupt so there is no reason for a special assignment for the timer as the setup for the i8259 already takes care of this. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Simplify assign_irq_vector's arguments.Eric W. Biederman1-53/+56
Currently assign_irq_vector works mostly by side effect and returns the results of it's changes to the caller. Which makes for a lot of arguments to pass/return and confusion as to what to do if you need the status but you aren't calling assign_irq_vector. This patch stops returning values from assign_irq_vector that can be retrieved just as easily by examining irq_cfg, and modifies the callers to retrive those values from irq_cfg when they need them. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Begin consolidating per_irq data in structures.Eric W. Biederman1-61/+50
Currently the io_apic.c has several parallel arrays for different kinds of data that can be know about an irq. The parallel arrays make the code harder to maintain and make it difficult to remove the static limits on the number of the number of irqs. This patch pushes irq_data and irq_vector into a irq_cfg array and updates the code to use it. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Use NR_IRQS not NR_IRQ_VECTORSEric W. Biederman1-5/+5
NR_IRQ_VECTORS is currently a compatiblity define set to NR_IRQs. This patch updates the users of NR_IRQ_VECTORS to use NR_IRQs instead so that NR_IRQ_VECTORS can be removed. There is still shared code with arch/i386 that uses NR_IRQ_VECTORS so we can't remove the #define just yet :( Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: In __DO_ACTION perform the FINAL action for every entry.Eric W. Biederman1-1/+1
If we have an irq that comes from multiple io_apic pins the FINAL action (which is io_apic_sync or nothing) needs to be called for every entry or else if the two pins come from different io_apics we may not wait until after the action happens on the io_apic. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Simplfiy the set_affinity logic.Eric W. Biederman1-9/+3
For some reason the code has been picking TARGET_CPUS when asked to set the affinity to an empty set of cpus. That is just silly it's extra work. Instead if there are no cpus to set the affinity to we should just give up immediately. That is simpler and a little more intuitive. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Refactor setup_IO_APIC_irqEric W. Biederman1-92/+34
Currently we have two routines that do practically the same thing setup_IO_APIC_irq and io_apic_set_pci_routing. This patch makes setup_IO_APIC_irq the common factor of these two previous routines. For setup_IO_APIC_irq all that was needed was to pass the trigger and polarity to make the code a proper subset of io_apic_set_pci_routing. Hopefully consolidating these two routines will improve maintenance there were several differences that simply appear to be one routine or the other getting it wrong. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Remove the unused vector parameter from ioapic_register_intrEric W. Biederman1-3/+3
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Kill declaration of removed array, interruptEric W. Biederman1-2/+0
It's dead Jim. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] irq: Remove set_native_irq_infoEric W. Biederman1-5/+5
This patch replaces all instances of "set_native_irq_info(irq, mask)" with "irq_desc[irq].affinity = mask". The latter form is clearer uses fewer abstractions, and makes access to this field uniform accross different architectures. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-26[PATCH] x86_64 irq: Simplfy __assign_irq_vectorEric W. Biederman1-8/+5
By precomputing old_mask I remove an extra if statement, remove an indentation level and make the code slightly easier to read. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-20{rd,wr}msr_on_cpu SMP=n optimizationAdrian Bunk1-1/+2
Let's save a few bytes in the CONFIG_SMP=n case. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
2007-02-20rdmsr_on_cpu, wrmsr_on_cpuAlexey Dobriyan2-1/+2
There was OpenVZ specific bug rendering some cpufreq drivers unusable on SMP. In short, when cpufreq code thinks it confined itself to needed cpu by means of set_cpus_allowed() to execute rdmsr, some "virtual cpu" feature can migrate process to anywhere. This triggers bugons and does wrong things in general. This got fixed by introducing rdmsr_on_cpu and wrmsr_on_cpu executing rdmsr and wrmsr on given physical cpu by means of smp_call_function_single(). Dave Jones mentioned cpufreq might be not only user of rdmsr_on_cpu() and wrmsr_on_cpu(), so I'm putting them into arch/{i386,x86_64}/lib/ . Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-02-20[CPUFREQ] Revert default on deprecated config X86_SPEEDSTEP_CENTRINO_ACPIThomas Renninger1-1/+0
Revert default on deprecated config X86_SPEEDSTEP_CENTRINO_ACPI Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com> arch/i386/kernel/cpu/cpufreq/Kconfig | 1 - arch/x86_64/kernel/cpufreq/Kconfig | 1 - 2 files changed, 2 deletions(-)
2007-02-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivialLinus Torvalds1-1/+1
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (25 commits) Documentation/kernel-docs.txt update. arch/cris: typo in KERN_INFO Storage class should be before const qualifier kernel/printk.c: comment fix update I/O sched Kconfig help texts - CFQ is now default, not AS. Remove duplicate listing of Cris arch from README kbuild: more doc. cleanups doc: make doc. for maxcpus= more visible drivers/net/eexpress.c: remove duplicate comment add a help text for BLK_DEV_GENERIC correct a dead URL in the IP_MULTICAST help text fix the BAYCOM_SER_HDX help text fix SCSI_SCAN_ASYNC help text trivial documentation patch for platform.txt Fix typos concerning hierarchy Fix comment typo "spin_lock_irqrestore". Fix misspellings of "agressive". drivers/scsi/a100u2w.c: trivial typo patch Correct trivial typo in log2.h. Remove useless FIND_FIRST_BIT() macro from cardbus.c. ...