aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ia64
Commit message (Collapse)AuthorAge
* [IA64] kdump: Mask INIT first in panic-kdump pathHidetoshi Seto2009-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Asserting INIT might block kdump if the system is already going to start kdump via panic. Description: INIT can interrupt anywhere in panic path, so it can interrupt in middle of kdump kicked by panic. Therefore there is a race if kdump is kicked concurrently, via Panic and via INIT. INIT could fail to invoke kdump if the system is already going to start kdump via panic. It could not restart kdump from INIT handler if some of cpus are already playing dead with INIT masked. It also means that INIT could block kdump's progress if no monarch is entered in the INIT rendezvous. Panic+INIT is a rare, but possible situation since it can be assumed that the kernel or an internal agent decides to panic the unstable system while another external agent decides to send an INIT to the system at same time. How to reproduce: Assert INIT just after panic, before all other cpus have frozen Expected results: continue kdump invoked by panic, or restart kdump from INIT Actual results: might be hang, crashdump not retrieved Proposed Fix: This patch masks INIT first in panic path to take the initiative on kdump, and reuse atomic value kdump_in_progress to make sure there is only one initiator of kdump. All INITs asserted later should be used only for freezing all other cpus. This mask will be removed soon by rfi in relocate_kernel.S, before jump into kdump kernel, after all cpus are frozen and no-op INIT handler is registered. So if INIT was in the interval while it is masked, it will pend on the system and will received just after the rfi, and handled by the no-op handler. If there was a MCA event while psr.mc is 1, in theory the event will pend on the system and will received just after the rfi same as above. MCA handler is unregistered here at the time, so received MCA will not reach to OS_MCA and will result in warmboot by SAL. Note that codes in this masked interval are relatively simpler than that in MCA/INIT handler which also executed with the mask. So it can be said that probability of error in this interval is supposed not so higher than that in MCA/INIT handler. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] kdump: Don't return APs to SAL from kdumpHidetoshi Seto2009-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Asserting INIT on cpu going to be offline will result in unexpected behavior. It will be a real problem in kdump cases where INIT might be asserted to unstable APs going to be offline by returning to SAL. Description: Since psr.mc is cleared when bits in psr are set to SAL_PSR_BITS_TO_SET in ia64_jump_to_sal(), there is a small window (~few msecs) that the cpu can receive INIT even if the cpu enter there via INIT handler. In this window we do restore of registers for SAL, so INIT asserted here will not work properly. It is hard to remove this window by masking INIT (i.e. setting psr.mc) because we have to unmask it later in OS, because we have to use branch instruction (br.ret, not rfi) to return SAL, due to OS_BOOT_RENDEZ to SAL return convention. I suppose this window will not be a real problem on cpu offline if we can educate people not to push INIT button during hotplug operation. However, only exception is a race in kdump and INIT. Now kdump returns APs to SAL before processing dump, but the kernel might receive INIT at that point in time. Such INIT might be asserted by kdump itself if an AP doesn't react IPI soon and kdump decided to use INIT to stop the AP. Or it might be asserted by operator or an external agent to start dump on the unstable system. Such panic+INIT or INIT+INIT cases should be rare, but it will be happy if we can retrieve crashdump even in such cases. How to reproduce: panic+INIT or INIT+INIT, with kdump configured Expected results: crashdump is retrieved anyway Actual results: panic, hang etc. (unexpected) Proposed fix To avoid the window on the way to SAL, this patch stops returning APs to SAL in case of kdump. In other words, this patch makes APs spin in OS instead of spinning in SAL. (* Note: What impact would be there? If a cpu is spinning in SAL, the cpu is in BOOT_RENDEZ loop, as same as offlined cpu. In theory if an INIT is asserted there, cpus in the BOOT_RENDEZ loop should not invoke OS_INIT on it. So in either way, no matter where the cpu is spinning actually in, once cpu starts spin and act as "frozen," INIT on the cpu have no effects. From another point of view, all debug information on the cpu should have stored to memory before the cpu start to be frozen. So no more action on the cpu is required.) I confirmed that the kdump sometime hangs by concurrent INITs (another INIT after an INIT), and it doesn't hang after applying this patch. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] kexec: Unregister MCA handler before kexecHidetoshi Seto2009-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: MCA on the beginning of kdump/kexec kernel will result in unexpected behavior because MCA handler for previous kernel is invoked on the kdump kernel. Description: Once a cpu is passed to new kernel, all resources in previous kernel should not be used from the cpu. Even the resources for MCA handler are no exception. So we cannot handle MCAs and its machine check errors during kernel transition, until new handler for new kernel is registered with new resources ready for handling the MCA. How to reproduce: Assert MCA while kdump kernel is booting, before new MCA handler for kdump kernel is registered. Expected(Desirable) results: No recovery, cancel kdump and reboot the system. Actual results: MCA handler for previous kernel is invoked on the kdump kernel. => panic, hang etc. (unexpected) Proposed fix: To avoid entering MCA handler from early stage of new kernel, unregister the entry point from SAL before leave from current kernel. Then SAL will make all MCAs to warmboot safely, without invoking OS_MCA. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] kexec: Make INIT safe while transition toHidetoshi Seto2009-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kdump/kexec kernel Summary: Asserting INIT on the beginning of kdump/kexec kernel will result in unexpected behavior because INIT handler for previous kernel is invoked on new kernel. Description: In panic situation, we can receive INIT while kernel transition, i.e. from beginning of panic to bootstrap of kdump kernel. Since we initialize registers on leave from current kernel, no longer monarch/slave handlers of current kernel in virtual mode are called safely. (In fact system goes hang as far as I confirmed) How to Reproduce: Start kdump # echo c > /proc/sysrq-trigger Then assert INIT while kdump kernel is booting, before new INIT handler for kdump kernel is registered. Expected(Desirable) result: kdump kernel boots without any problem, crashdump retrieved Actual result: INIT handler for previous kernel is invoked on kdump kernel => panic, hang etc. (unexpected) Proposed fix: We can unregister these init handlers from SAL before jumping into new kernel, however then the INIT will fallback to default behavior, result in warmboot by SAL (according to the SAL specification) and we cannot retrieve the crashdump. Therefore this patch introduces a NOP init handler and register it to SAL before leave from current kernel, to start kdump safely by preventing INITs from entering virtual mode and resulting in warmboot. On the other hand, in case of kexec that not for kdump, it also has same problem with INIT while kernel transition. This patch handles this case differently, because for kexec unregistering handlers will be preferred than registering NOP handler, since the situation "no handlers registered" is usual state for kernel's entry. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] kdump: Mask MCA/INIT on frozen cpusHidetoshi Seto2009-09-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: INIT asserted on kdump kernel invokes INIT handler not only on a cpu that running on the kdump kernel, but also BSP of the panicked kernel, because the (badly) frozen BSP can be thawed by INIT. Description: The kdump_cpu_freeze() is called on cpus except one that initiates panic and/or kdump, to stop/offline the cpu (on ia64, it means we pass control of cpus to SAL, or put them in spinloop). Note that CPU0(BSP) always go to spinloop, so if panic was happened on an AP, there are at least 2cpus (= the AP and BSP) which not back to SAL. On the spinning cpus, interrupts are disabled (rsm psr.i), but INIT is still interruptible because psr.mc for mask them is not set unless kdump_cpu_freeze() is not called from MCA/INIT context. Therefore, assume that a panic was happened on an AP, kdump was invoked, new INIT handlers for kdump kernel was registered and then an INIT is asserted. From the viewpoint of SAL, there are 2 online cpus, so INIT will be delivered to both of them. It likely means that not only the AP (= a cpu executing kdump) enters INIT handler which is newly registered, but also BSP (= another cpu spinning in panicked kernel) enters the same INIT handler. Of course setting of registers in BSP are still old (for panicked kernel), so what happen with running handler with wrong setting will be extremely unexpected. I believe this is not desirable behavior. How to Reproduce: Start kdump on one of APs (e.g. cpu1) # taskset 0x2 echo c > /proc/sysrq-trigger Then assert INIT after kdump kernel is booted, after new INIT handler for kdump kernel is registered. Expected results: An INIT handler is invoked only on the AP. Actual results: An INIT handler is invoked on the AP and BSP. Sample of results: I got following console log by asserting INIT after prompt "root:/>". It seems that two monarchs appeared by one INIT, and one panicked at last. And it also seems that the panicked one supposed there were 4 online cpus and no one did rendezvous: : [ 0 %]dropping to initramfs shell exiting this shell will reboot your system root:/> Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=0 ia64_init_handler: Promoting cpu 0 to monarch. Delaying for 5 seconds... All OS INIT slaves have reached rendezvous Processes interrupted by INIT - 0 (cpu 0 task 0xa000000100af0000) : <<snip>> : Entered OS INIT handler. PSP=fff301a0 cpu=0 monarch=1 Delaying for 5 seconds... mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail. OS INIT slave did not rendezvous on cpu 1 2 3 INIT swapper 0[0]: bugcheck! 0 [1] : <<snip>> : Kernel panic - not syncing: Attempted to kill the idle task! Proposed fix: To avoid this problem, this patch inserts ia64_set_psr_mc() to mask INIT on cpus going to be frozen. This masking have no effect if the kdump_cpu_freeze() is called from INIT handler when kdump_on_init == 1, because psr.mc is already turned on to 1 before entering OS_INIT. I confirmed that weird log like above are disappeared after applying this patch. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Haren Myneni <hbabu@us.ibm.com> Cc: kexec@lists.infradead.org Acked-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] fix csum_ipv6_magic()Jiri Bohac2009-09-02
| | | | | | | | | | | The 32-bit parameters (len and csum) of csum_ipv6_magic() are passed in 64-bit registers in2 and in4. The high order 32 bits of the registers were never cleared, and garbage was sometimes calculated into the checksum. Fix this by clearing the high order 32 bits of these registers. Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Fix warning in dma-mapping.cLuck, Tony2009-09-02
| | | | | | | | | | arch/ia64/kernel/dma-mapping.c:14: warning: control reaches end of non-void function arch/ia64/kernel/dma-mapping.c:14: warning: no return statement in function returning non-void This warning was introduced by commit: 390bd132b2831a2ad0268e84bffbfc0680debfe5 Add dma_debug_init() for ia64 Signed-off-by: Tony Luck <tony.luck@intel.com>
* arch/ia64/kernel/iosapic: missing test after ioremap()Roel Kluin2009-08-11
| | | | | | | Missing test after ioremap() Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* ia64/topology.c: exit cache_add_dev when kobject_init_and_add failsFenghua Yu2009-08-11
| | | | | | | Make cache_add_dev exit sysfs when kobject_init_and_add returns an error. Signed-off-by: Xiaotian Feng <dfeng@redhat.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
* arch/ia64/Makefile: Remove -mtune=merced in IA64 kernel buildFenghua Yu2009-08-11
| | | | | | | | | | | | | | | | | | | | | Between GCC version 3.4.0 and 4.3.3 (including 3.4.0 and 4.3.3), -mtune=merced is implemented in GCC. Starting from 4.4.0, -mtune=merced is deprecated. Even implemented in versions between 3.4.0 and 4.3.3, the -mtune=merced feature has been broken in some of the versions. For example, GCC 4.1.2 reports interanl tuning function errors during kernel building with -mtune=merced. Or GCC Bugzilla 16130 reports another -mtune=merced issue on GCC 3.4.1. So I would remove the -mtune=merced from IA64 kernel build. Without this option, kernel on Merced will remain the same except losing an unstable and out-of-date performance tunning feature. Since GCC version 3.4.0, -mtune=mckinley has been implemented. The -mtune=mckinley option functions the same as mtune=itanium2. And mtune=itanium2 is the default option. So we don't need to add mtune=mckinley either since its been the default option in any GCC version which implements this option. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
* IA64: includecheck fix: ia64, pgtable.hJaswinder Singh Rajput2009-08-11
| | | | | | | | | fix the following 'make includecheck' warning: arch/ia64/include/asm/pgtable.h: asm/processor.h is included more than once. Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* IA64: includecheck fix: ia64, ia64_ksyms.cJaswinder Singh Rajput2009-08-11
| | | | | | | | | fix the following 'make includecheck' warning: arch/ia64/kernel/ia64_ksyms.c: asm/page.h is included more than once. Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* ia64: boolean __test_and_clear_bitJohannes Weiner2009-08-11
| | | | | | | | | __test_and_clear_bit() returns a bitfield with the tested-for bit set. Make it consistent with the other bitops - of ia64 but also every other architecture - and return a boolean value. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* Bug Fix arch/ia64/kernel/pci-dma.c: fix recursive dma_supported() call in ↵Fenghua Yu2009-08-11
| | | | | | | | | | | | | | | | iommu_dma_supported() In commit 160c1d8e40866edfeae7d68816b7005d70acf391, dma_ops->dma_supported = iommu_dma_supported; This dma_ops->dma_supported is first called in platform_dma_init() during kernel boot. Then dma_ops->dma_supported will be called recursively in iommu_dma_supported. Kernel can not boot because kernel can not get out of iommu_dma_supported until it runs out of stack memory. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
* KVM: ia64: fix build failures due to ia64/unsigned long mismatchesAvi Kivity2009-08-05
| | | | Signed-off-by: Avi Kivity <avi@redhat.com>
* mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()Benjamin Herrenschmidt2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | mm: Pass virtual address to [__]p{te,ud,md}_free_tlb() Upcoming paches to support the new 64-bit "BookE" powerpc architecture will need to have the virtual address corresponding to PTE page when freeing it, due to the way the HW table walker works. Basically, the TLB can be loaded with "large" pages that cover the whole virtual space (well, sort-of, half of it actually) represented by a PTE page, and which contain an "indirect" bit indicating that this TLB entry RPN points to an array of PTEs from which the TLB can then create direct entries. Thus, in order to invalidate those when PTE pages are deleted, we need the virtual address to pass to tlbilx or tlbivax instructions. The old trick of sticking it somewhere in the PTE page struct page sucks too much, the address is almost readily available in all call sites and almost everybody implemets these as macros, so we may as well add the argument everywhere. I added it to the pmd and pud variants for consistency. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: David Howells <dhowells@redhat.com> [MN10300 & FRV] Acked-by: Nick Piggin <npiggin@suse.de> Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Revert "Neither asm/types.h nor linux/types.h is required for ↵Aurelien Jarno2009-07-17
| | | | | | | | | | | | arch/ia64/include/asm/fpu.h" asm/fpu.h uses the __IA64_UL macro which is declared in asm/types.h, so this include is really required. Without it, GNU libc fails to build. This reverts commit 2678c07b07ac2076675e5d57653bdf02e9af1950. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* Add dma_debug_init() for ia64fujita2009-07-17
| | | | | | | | | The commit 9916219579d078c80377dd3988c2cc213536d868 was supposed to add CONFIG_DMA_API_DEBUG support to IA64 however I forgot to add dma_debug_init(). Signed-off-by: fujita <fujita@tulip.osrg.net> Acked-by: Fenghua Yu <fenghua.yu@intel.com>
* Fix ia64 compilation IS_ERR and PTE_ERR errors.Fenghua Yu2009-07-17
| | | | | | | | | | | | | | When building ia64 kernel with CONFIG_XEN_SYS_HYPERVISOR, compiler reports errors: drivers/xen/sys-hypervisor.c: In function ‘uuid_show’: drivers/xen/sys-hypervisor.c:125: error: implicit declaration of function ‘IS_ERR’ drivers/xen/sys-hypervisor.c:126: error: implicit declaration of function ‘PTR_ERR’ This patch fixes the errors. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Isaku Yamahata <yamahata@valinux.co.jp>
* headers: smp_lock.h reduxAlexey Dobriyan2009-07-12
| | | | | | | | | | | | | * Remove smp_lock.h from files which don't need it (including some headers!) * Add smp_lock.h to files which do need it * Make smp_lock.h include conditional in hardirq.h It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT This will make hardirq.h inclusion cheaper for every PREEMPT=n config (which includes allmodconfig/allyesconfig, BTW) Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* sched: INIT_PREEMPT_COUNTPeter Zijlstra2009-07-10
| | | | | | | | | | | | | | | | | | | | | Pull the initial preempt_count value into a single definition site. Maintainers for: alpha, ia64 and m68k, please have a look, your arch code is funny. The header magic is a bit odd, but similar to the KERNEL_DS one, CPP waits with expanding these macros until the INIT_THREAD_INFO macro itself is expanded, which is in arch/*/kernel/init_task.c where we've already included sched.h so we're good. Cc: tony.luck@intel.com Cc: rth@twiddle.net Cc: geert@linux-m68k.org Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'for-linus' of ↵Linus Torvalds2009-07-06
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: Fix IRQ swizzling for ARI-enabled devices ia64/PCI: adjust section annotation for pcibios_setup() x86/PCI: get root CRS before scanning children x86/PCI: fix boundary checking when using root CRS PCI MSI: Fix restoration of MSI/MSI-X mask states in suspend/resume PCI MSI: Unmask MSI if setup failed PCI MSI: shorten PCI_MSIX_ENTRY_* symbol names PCI: make pci_name() take const argument PCI: More PATA quirks for not entering D3 PCI: fix kernel-doc warnings PCI: check if bus has a proper bridge device before triggering SBR PCI: remove pci_dac_dma_... APIs on mn10300 PCI ECRC: Remove unnecessary semicolons PCI MSI: Return if alloc_msi_entry for MSI-X failed
| * ia64/PCI: adjust section annotation for pcibios_setup()Ingo Molnar2009-06-30
| | | | | | | | | | | | | | Should be __init. Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | [IA64] address compiler warnings perfmon.c/salinfo.cJan Beulich2009-06-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | perfmon.c has a dubious cast directly from "int" to "void *". Add an intermediate cast to "long" to keep gcc happy. salinfo.c uses "down_trylock()" in a highly creative way (explained in the comments in the file) ... but it does kick out this warning: arch/ia64/kernel/salinfo.c:195: warning: ignoring return value of 'down_trylock' which people occasionally try to "fix" in ways that do not work. Use some casts to keep gcc quiet. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | [IA64] Remove unnecessary semicolonsJoe Perches2009-06-30
| | | | | | | | | | Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | [IA64] sprintf should not be used with same source & destination addressAlan Cox2009-06-30
|/ | | | | | | | | | This happens to work at the moment but isn't a good idea so fix it the simple way. Resolves-bug: http://bugzilla.kernel.org/show_bug.cgi?id=13576 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* KVM: ia64: fix ia64 build due to missing kallsyms_lookup() and double exportJes Sorensen2009-06-28
| | | | | | | | | | | | Fix problem with double export of certain symbols from vsprintf.c which we do not wish to export from the kvm-intel.ko module. In addition, we do not have access to kallsyms_lookup() from the module, so make sure to #undef CONFIG_KALLSYMS Signed-off-by: Jes Sorensen <jes@sgi.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Avi Kivity <avi@redhat.com>
*-. Merge branches 'acerhdf', 'acpi-pci-bind', 'bjorn-pci-root', ↵Len Brown2009-06-24
|\ \ | | | | | | | | | 'bugzilla-12904', 'bugzilla-13121', 'bugzilla-13396', 'bugzilla-13533', 'bugzilla-13612', 'c3_lock', 'hid-cleanups', 'misc-2.6.31', 'pdc-leak-fix', 'pnpacpi', 'power_nocheck', 'thinkpad_acpi', 'video' and 'wmi' into release
| | * ACPI: pdc init related memory leak with physical CPU hotplugPallipadi, Venkatesh2009-06-20
| |/ | | | | | | | | | | | | | | | | | | | | arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated for _PDC objects that is never freed and will cause memory leak in case of physical CPU remove and add. Patch fixes the memory leak by freeing the objects soon after _PDC is evaluated. Reported-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge git://git.infradead.org/~dwmw2/iommu-2.6.31Linus Torvalds2009-06-23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.infradead.org/~dwmw2/iommu-2.6.31: intel-iommu: Fix one last ia64 build problem in Pass Through Support VT-d: support the device IOTLB VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps VT-d: add device IOTLB invalidation support VT-d: parse ATSR in DMA Remapping Reporting Structure PCI: handle Virtual Function ATS enabling PCI: support the ATS capability intel-iommu: dmar_set_interrupt return error value intel-iommu: Tidy up iommu->gcmd handling intel-iommu: Fix tiny theoretical race in write-buffer flush. intel-iommu: Clean up handling of "caching mode" vs. IOTLB flushing. intel-iommu: Clean up handling of "caching mode" vs. context flushing. VT-d: fix invalid domain id for KVM context flush Fix !CONFIG_DMAR build failure introduced by Intel IOMMU Pass Through Support Intel IOMMU Pass Through Support Fix up trivial conflicts in drivers/pci/{intel-iommu.c,intr_remapping.c}
| * | intel-iommu: Fix one last ia64 build problem in Pass Through SupportLuck, Tony2009-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On ia64 with CONFIG_DMAR=n and CONFIG_SWIOTLB=y (as used in arch/ia64/configs/tiger_defconfig) there is still a link error with iommu_pass_through listed as an undefined symbol: arch/ia64/kernel/built-in.o: In function `pci_swiotlb_init': (.init.text+0x7f70): undefined reference to `iommu_pass_through' Fix it by #defining iommu_pass_through away in asm/iommu.h Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | Fix !CONFIG_DMAR build failure introduced by Intel IOMMU Pass Through SupportFenghua Yu2009-05-01
| | | | | | | | | | | | | | | | | | | | | | | | This updated patch should fix the compiling errors and remove the extern iommu_pass_through from drivers/pci/intel-iommu.c file. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | Intel IOMMU Pass Through SupportFenghua Yu2009-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch adds kernel parameter intel_iommu=pt to set up pass through mode in context mapping entry. This disables DMAR in linux kernel; but KVM still runs on VT-d and interrupt remapping still works. In this mode, kernel uses swiotlb for DMA API functions but other VT-d functionalities are enabled for KVM. KVM always uses multi level translation page table in VT-d. By default, pass though mode is disabled in kernel. This is useful when people don't want to enable VT-d DMAR in kernel but still want to use KVM and interrupt remapping for reasons like DMAR performance concern or debug purpose. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Weidong Han <weidong@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* | | Move FAULT_FLAG_xyz into handle_mm_fault() callersLinus Torvalds2009-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the callers to now pass down the full set of FAULT_FLAG_xyz flags to handle_mm_fault(). All callers have been (mechanically) converted to the new calling convention, there's almost certainly room for architectures to clean up their code and then add FAULT_FLAG_RETRY when that support is added. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | dma-mapping: ia64: add CONFIG_DMA_API_DEBUG supportFUJITA Tomonori2009-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Cc: Ingo Molnar <mingo@elte.hu> Acked-by: "Luck, Tony" <tony.luck@intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> 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>
* | | dma-mapping: ia64: use asm-generic/dma-mapping-common.hFUJITA Tomonori2009-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Cc: Ingo Molnar <mingo@elte.hu> Acked-by: "Luck, Tony" <tony.luck@intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> 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>
* | | ia64: Fix resource assignment for root bussesMatthew Wilcox2009-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ia64 was assigning resources to root busses after allocations had been made for child busses. Calling pcibios_setup_root_windows() from pcibios_fixup_bus() solves this problem by assigning the resources to the root bus before child busses are scanned. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Tested-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Delete pcibios_select_rootMatthew Wilcox2009-06-17
| | | | | | | | | | | | | | | | | | | | | | | | This function was only used by pci_claim_resource(), and the last commit deleted that use. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Pull for-2.6.31 into releaseTony Luck2009-06-17
|\ \ \
| * | | [IA64] Convert ia64 to use int-ll64.hMatthew Wilcox2009-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is generally agreed that it would be beneficial for u64 to be an unsigned long long on all architectures. ia64 (in common with several other 64-bit architectures) currently uses unsigned long. Migrating piecemeal is too painful; this giant patch fixes all compilation warnings and errors that come as a result of switching to use int-ll64.h. Note that userspace will still see __u64 defined as unsigned long. This is important as it affects C++ name mangling. [Updated by Tony Luck to change efi.h:efi_freemem_callback_t to use u64 for start/end rather than unsigned long] Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] ia64 does not need umount2() syscallTony Luck2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ia64 doesn't have old and new versions of the umount system call. It just has the new version. Fixes this build warning: <stdin>:395:2: warning: #warning syscall umount2 not implemented Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] hook up new rt_tgsigqueueinfo syscallTony Luck2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | Assign syscall #1321 for rt_tgsigqueueinfo. Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] msi_ia64.c dmar_msi_type should be staticJaswinder Singh Rajput2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] remove obsolete hw_interrupt_typeThomas Gleixner2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have been kept around for migration reasons. After more than two years it's time to remove them finally. This patch cleans up one of the remaining users. When all such patches hit mainline we can remove the defines and typedefs finally. Impact: cleanup Convert the last remaining users to struct irq_chip and remove the define. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] remove obsolete irq_desc_t typedefThomas Gleixner2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have been kept around for migration reasons. After more than two years it's time to remove them finally. This patch cleans up one of the remaining users. When all such patches hit mainline we can remove the defines and typedefs finally. Impact: cleanup Convert the last remaining users and remove the typedef. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] remove obsolete no_irq_typeThomas Gleixner2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have been kept around for migration reasons. After more than two years it's time to remove them finally. This patch cleans up one of the remaining users. When all such patches hit mainline we can remove the defines and typedefs finally. Impact: cleanup convert the last remaining users to no_irq_chip Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
| * | | [IA64] unexport fpswa.hSam Ravnborg2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fpswa.h is not relevant for userspace, so do not export it. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | | | [IA64] Fix build error in paravirt_patchlist.cJes Sorensen2009-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Andrew cleaned up some #include tangles in: commit 0d9c25dde878a636ee9a9b53923569171bf9a55b headers: move module_bug_finalize()/module_bug_cleanup() definitions into module.h which resulted in this build error for ia64: CC arch/ia64/kernel/paravirt_patchlist.o arch/ia64/kernel/paravirt_patchlist.c:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__initdata' arch/ia64/kernel/paravirt_patchlist.c:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'paravirt_get_gate_patchlist' arch/ia64/kernel/paravirt_patchlist.c:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'paravirt_get_gate_section' make[1]: *** [arch/ia64/kernel/paravirt_patchlist.o] Error 1 The problem was that paravirt_patchlist.c was relying on some of the nested includes (specifically that linux/bug.h included linux/module.h Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | | | kmap_types: make most arches use generic header fileRandy Dunlap2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert most arches to use asm-generic/kmap_types.h. Move the KM_FENCE_ macro additions into asm-generic/kmap_types.h, controlled by __WITH_KM_FENCE from each arch's kmap_types.h file. Would be nice to be able to add custom KM_types per arch, but I don't yet see a nice, clean way to do that. Built on x86_64, i386, mips, sparc, alpha(tonyb), powerpc(tonyb), and 68k(tonyb). Note: avr32 should be able to remove KM_PTE2 (since it's not used) and then just use the generic kmap_types.h file. Get avr32 maintainer approval. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: <linux-arch@vger.kernel.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Bryan Wu <cooloney@kernel.org> Cc: Mikael Starvik <starvik@axis.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: "Luck Tony" <tony.luck@intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | remove put_cpu_no_resched()Thomas Gleixner2009-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | put_cpu_no_resched() is an optimization of put_cpu() which unfortunately can cause high latencies. The nfs iostats code uses put_cpu_no_resched() in a code sequence where a reschedule request caused by an interrupt between the get_cpu() and the put_cpu_no_resched() can delay the reschedule for at least HZ. The other users of put_cpu_no_resched() optimize correctly in interrupt code, but there is no real harm in using the put_cpu() function which is an alias for preempt_enable(). The extra check of the preemmpt count is not as critical as the potential source of missing a reschedule. Debugged in the preempt-rt tree and verified in mainline. Impact: remove a high latency source [akpm@linux-foundation.org: build fix] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Tony Luck <tony.luck@intel.com> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>