summaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)Author
2006-06-26[PATCH] x86_64: (resend) x86_64 stack overflow debuggingEric Sandeen
Take two, now without spurious whitespace :( Applies to git & 2.6.17-rc6 CONFIG_DEBUG_STACKOVERFLOW existed for x86_64 in 2.4, but seems to have gone AWOL in 2.6. I've pretty much just copied this over from the 2.4 code, with appropriate tweaks for the 2.6 kernel, plus a bugfix. I'd personally rather see it printed out the way other arches do it, i.e. bytes-remaining-until-overflow, rather than having to do the subtraction yourself. Also, only 128 bytes remaining seems awfully late to issue a warning. But I'll start here :) Signed-off-by: Eric Sandeen <sandeen@sgi.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: i386/x86-64 Add nmi watchdog support for new Intel CPUsVenkatesh Pallipadi
Intel now has support for Architectural Performance Monitoring Counters ( Refer to IA-32 Intel Architecture Software Developer's Manual http://www.intel.com/design/pentium4/manuals/253669.htm ). This feature is present starting from Intel Core Duo and Intel Core Solo processors. What this means is, the performance monitoring counters and some performance monitoring events are now defined in an architectural way (using cpuid). And there will be no need to check for family/model etc for these architectural events. Below is the patch to use this performance counters in nmi watchdog driver. Patch handles both i386 and x86-64 kernels. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Avoid broadcasting NMI IPIsKeith Owens
On some i386/x86_64 systems, sending an NMI IPI as a broadcast will reset the system. This seems to be a BIOS bug which affects machines where one or more cpus are not under OS control. It occurs on HT systems with a version of the OS that is not compiled without HT support. It also occurs when a system is booted with max_cpus=n where 2 <= n < cpus known to the BIOS. The fix is to always send NMI IPI as a mask instead of as a broadcast. Signed-off-by: Keith Owens <kaos@sgi.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: fix apic error on bootupSiddha, Suresh B
Appended patch fixes the "APIC error on CPUX: 00(40)" observed during bootup. From SDM Vol-3A "Valid Interrupt Vectors" section: "When an illegal vector value (0-15) is written to an LVT entry and the delivery mode is Fixed, the APIC may signal an illegal vector error, with out regard to whether the mask bit is set or whether an interrupt is actually seen on input." Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: enlarge window for stack growthChuck Ebbert
Allow stack growth so the 'enter' instruction works. Also fixes problem in compat_sys_kexec_load() which could allocate more than 128 bytes using compat_alloc_user_space(). Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Minor string functions optimizationsAndi Kleen
- Use tail call from clear_user to __clear_user to save some code size - Use standard memcpy for forward memmove Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Move export symbols to their C functionsAndi Kleen
Only exports for assembler files are left in x8664_ksyms.c Originally inspired by a patch from Al Viro Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Standardize i386/x86_64 handling of NMI_VECTORKeith Owens
x86_64 and i386 behave inconsistently when sending an IPI on vector 2 (NMI_VECTOR). Make both behave the same, so IPI 2 is sent as NMI. The crash code was abusing send_IPI_allbutself() by passing a code instead of a vector, it only worked because crash knew about the internal code of send_IPI_allbutself(). Change crash to use NMI_VECTOR instead, and remove the comment about how crash was abusing the function. This patch is a pre-requisite for fixing the problem where sending an IPI as NMI would reboot some Dell Xeon systems. I cannot fix that problem while crash continus to abuse send_IPI_allbutself(). It also removes the inconsistency between i386 and x86_64 for NMI_VECTOR. That will simplify all the RAS code that needs to bring all the cpus to a clean stop, even when one or more cpus are spinning disabled. Signed-off-by: Keith Owens <kaos@sgi.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Fix modular pc speakerPiotr Kaczuba
It turned out that the following change is needed when the speaker is compiled as a module. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: remove sys32_ni_syscall()Adrian Bunk
This patch removes the no longer used sys32_ni_syscall() Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Do not use -ffunction-sections for modulesSergey Vlasov
Currently CONFIG_REORDER uses -ffunction-sections for all code; however, creating a separate section for each function is not useful for modules and just adds bloat. Moving this option from CFLAGS to CFLAGS_KERNEL shrinks module object files (e.g., the module tree for a kernel built with most drivers as modules shrinked from 54M to 46M), and decreases the number of sysfs files in /sys/module/*/sections/ directories. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: adjust kstack_depth_to_print defaultJan Beulich
Defaulting to a value not evenly divisible by four makes little sense, as four values are displayed per line (and hence the rest of the line would otherwise be wasted). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386/x86-64: adjust /proc/interrupts column headingsJan Beulich
With (significantly) more than 10 CPUs online, the column headings drifted off the positions of the column contents with growing CPU numbers. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Fix fast check in safe_smp_processor_idAndi Kleen
The APIC ID returned by hard_smp_processor_id can be beyond NR_CPUS and then overflow the x86_cpu_to_apic[] array. Add a check for overflow. If it happens then the slow loop below will catch. Bug pointed out by Doug Thompson Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: x86_64 setup.c - printing cmp related boottime informationRohit Seth
Getting phys_proc_id and cpu_core_id information to be printed at boot time for AMD processors. Also matching the Node related boot time information that gets printed for Intel and AMD processors for NUMA configurations. Signed-off-by: Rohit Seth <rohitseth@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386/x86-64/ia64: Move polling flag into thread_info_statusAndi Kleen
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. Converted i386/x86-64/ia64 for now because that was the easiest way to fix ACPI which also manipulates these flags in its idle function. Cc: Nick Piggin <npiggin@novell.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Remove bogus RED-PEN comment in signal.cAndi Kleen
No red zone possible/needed on the alternative stack. It caused confusion. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: check_addr() cleanupsAndrew Morton
- Use DMA_32BIT_MASK - Use %z for size_t - 80-cols Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: miscellaneous mm/init.c fixesJan Beulich
- fix an off-by-one error in phys_pmd_init() - prevent phys_pmd_init() from removing mappings established earlier - fix the direct mapping early printk to in fact show the end of the range - remove an apparently orphan comment Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Mark mce_amd cpu notifier __cpuinit/__cpuinitdataAndi Kleen
Cc: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: mce_amd cleanupJacob Shin
Clean up mce_amd.c for readability and remove code no longer needed. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: mce_amd support for family 0x10 processorsJacob Shin
Add support for mce threshold registers found in future AMD family 0x10 processors. Backwards compatible with family 0xF hardware. AK: fixed build on !SMP Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: mce_amd relocate sysfs filesJacob Shin
Get rid of /sys/devices/system/threshold directory and move mce_amd thresholding files into the machine sysfs directory -- /sys/devices/system/machinecheck. AK: Fixed warning Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: apic support for extended apic interruptJacob Shin
Add support for extended APIC LVT found in future AMD processors. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Move VM86 config into arch/i386/KconfigAndi Kleen
Architecture specific configs like this have no business at all in init/Kconfig. This prevents it from being set on x86-64 Pointed out by H.Peter Anvin Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386/x86-64: Fix isoimage when syslinux is in /usr/shareAndi Kleen
It's like this on SUSE systems. Cc: hpa@zytor.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Update copyright in time.cVojtech Pavlik
Update my copyright dates in arch/x86-64/kernel/time.c Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Explain why HPET T0_CMP register is written twiceVojtech Pavlik
After writing the CFG register, the first value written to the T0_CMP register is the value at which next interrupt should be triggered, every value after that sets the period of the interrupt. For that reason, the code needs to write the value twice - to set both the phase and period. [AK: I had already figured it out by myself, but it's still useful to have a comment for this.] Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Make use of the *PER* constants in time.cVojtech Pavlik
This patch makes use of the newly added conversion constants in time.h to x86-64 time.c. The code gets significantly easier to understand. Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Remove hack to manually enable HPET on AMD8111 southbridgesVojtech Pavlik
Remove #ifdefed code to manually enable HPET on AMD8111, where the BIOS doesn't have ACPI HPET tables and doesn't enable it for us. Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Add X86_FEATURE_RDTSCP, fix rdtscp in /proc/cpuinfoVojtech Pavlik
This patch adds the X86_FEATURE_RDTSCP #define, so that kernel code can check for the feature easily and also fixes the location of the "rdtscp" string in the cpuinfo tables. Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Rename oem_force_hpet_timer to apic_is_clustered_boxVojtech Pavlik
Rename oem_force_hpet_timer to apic_is_clustered_box, to give the function a better fitting name - it really isn't at all about HPET. Signed-off-by: Vojtech Pavlik <vojtech@suse.cz> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: moving phys_proc_id and cpu_core_id to cpuinfo_x86Rohit Seth
Most of the fields of cpuinfo are defined in cpuinfo_x86 structure. This patch moves the phys_proc_id and cpu_core_id for each processor to cpuinfo_x86 structure as well. Signed-off-by: Rohit Seth <rohitseth@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Calgary IOMMU - Calgary specific bitsJon Mason
This patch hooks Calgary into the build, the x86-64 IOMMU initialization paths, and introduces the Calgary specific bits. The implementation draws inspiration from both PPC (which has support for the same chip but requires firmware support which we don't have on x86-64) and gart. Calgary is different from gart in that it support a translation table per PHB, as opposed to the single gart aperture. Changes from previous version: * Addition of boot-time disablement for bus-level translation/isolation (e.g, enable userspace DMA for things like X) * Usage of newer IOMMU abstraction functions Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Calgary IOMMU - IOMMU abstractionsJon Mason
This patch creates a new interface for IOMMUs by adding a centralized location for IOMMU allocation (for translation tables/apertures) and IOMMU initialization. In creating these, code was moved around for abstraction, uniformity, and consiceness. Take note of the move of the iommu_setup bootarg parsing code to __setup. This is enabled by moving back the location of the aperture allocation/detection to mem init (which while ugly, was already the location of the swiotlb_init). While a slight departure from the previous patch, I belive this provides the true intention of the previous versions of the patch which changed this code. It also makes the addition of the upcoming calgary code much cleaner than previous patches. [AK: Removed one broken change. iommu_setup still has to be called early] Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Calgary IOMMU - introduce iommu_detectedJon Mason
swiotlb relies on the gart specific iommu_aperture variable to know if we discovered a hardware IOMMU before swiotlb initialization. Introduce iommu_detected to do the same thing, but in a HW IOMMU neutral manner, in preparation for adding the Calgary HW IOMMU. Signed-Off-By: Muli Ben-Yehuda <muli@il.ibm.com> Signed-Off-By: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Change assembly to use regular cpuid_count macroRohit Seth
Minor cleanup patch: Replacing the asm statement with cpuid_count macro(which already provides the same functionality). Signed-off-by: Rohit Seth <rohitseth@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: use halt() instead of raw inline assemblyJan Beulich
Use abstractions whenever possible. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Get rid of pud_offset_k / __pud_offset_kAndi Kleen
pud_offset_k() equivalent to pud_offset() now. Pointed out by Jan Beulich Similar for __pud_offset_ok, which needs a small change in the callers. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386/x86-64: Consolidate arch/{i386,x86_64}/boot/compressed/misc.cCarl-Daniel Hailfinger
Clean up arch/{i386,x86_64}/boot/compressed/misc.c a bit to reduce their differences. Should have zero effect on code generation. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386/x86-64: fall back to old-style call trace if no unwindingJan Beulich
If no unwinding is possible at all for a certain exception instance, fall back to the old style call trace instead of not showing any trace at all. Also, allow setting the stack trace mode at the command line. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386: reliable stack trace support i386 entry.SJan Beulich
To increase the usefulness of reliable stack unwinding, this adds CFI unwind annotations to many low-level i386 routines. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] i386: reliable stack trace support (i386)Jan Beulich
These are the i386-specific pieces to enable reliable stack traces. This is going to be even more useful once CFI annotations get added to he assembly code, namely to entry.S. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: reliable stack trace support (x86-64 syscallJan Beulich
Adjust the CFA offset for 64- and 32-bit syscall entries so that the five slots pre-subtracted from the stack pointer do not appear to reside outside of the current frame. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: reliable stack trace support (x86-64 IRQ stackJan Beulich
Change the switching to/from the IRQ stack so that unwind annotations can be added for it without requiring CFA expressions. AK: I cleaned it up a bit, making it unconditional and removing the obsolete DEBUG_INFO full frame code. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: reliable stack trace support (x86-64)Jan Beulich
These are the x86_64-specific pieces to enable reliable stack traces. The only restriction with this is that it currently cannot unwind across the interrupt->normal stack boundary, as that transition is lacking proper annotation. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: x86_86 msi miss one entry handlerbibo,mao
In x86_64 architecture, if device driver with msi function gets 0xee vector by assign_irq_vector() function, system will crash if this interrupt happens. It is because 0xee interrupt entry is empty. This patch modifies this. This patch is based on 2.6.17-rc6. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded.Andi Kleen
- Rename the GART_IOMMU option to IOMMU to make clear it's not just for AMD - Rewrite the help text to better emphatise this fact - Make it an embedded option because too many people get it wrong. To my astonishment I discovered the aacraid driver tests this symbol directly. This looks quite broken to me - it's an internal implementation detail of the PCI DMA API. Can the maintainer please clarify what this test was intended to do? Cc: linux-scsi@vger.kernel.org Cc: alan@redhat.com Cc: markh@osdl.org Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: Make sure is_compat_task works earlyAndi Kleen
Previously it would only work in the first 32bit system call, not during early process setup. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26[PATCH] x86_64: fix vector_lock deadlock in io_apic.cIngo Molnar
Fix a potential deadlock scenario introduced by io_apic.c's new vector_lock on i386 and x86_64. Found by the locking correctness validator. The patch was boot-tested on x86. For details of the deadlock scenario, see the validator output: ====================================================== [ BUG: hard-safe -> hard-unsafe lock order detected! ] ------------------------------------------------------ idle/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (msi_lock){....}, at: [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35 and this task is already holding: (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107 which would create a new lock dependency: (&irq_desc[i].lock){++..} -> (msi_lock){....} but this new dependency connects a hard-irq-safe lock: (&irq_desc[i].lock){++..} ... which became hard-irq-safe at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad to a hard-irq-unsafe lock: (vector_lock){--..} ... which became hard-irq-unsafe at: ... [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb which could potentially lead to deadlocks! other info that might help us debug this: 3 locks held by idle/1: #0: (port_mutex){--..}, at: [<c067070d>] uart_add_one_port+0x61/0x289 #1: (&state->mutex){--..}, at: [<c067071f>] uart_add_one_port+0x73/0x289 #2: (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107 the hard-irq-safe lock's dependencies: -> (&irq_desc[i].lock){++..} ops: 9861 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c015b415>] setup_irq+0x9b/0x14d [<c1aaa4c4>] time_init_hook+0xf/0x11 [<c1a9f320>] time_init+0x44/0x46 [<c1a9955f>] start_kernel+0x191/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c1ea31e0>] irq_desc_lock_type+0x0/0x20 -> (i8259A_lock){++..} ops: 5149 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0108090>] init_8259A+0x11/0x8f [<c1aa0d22>] init_ISA_irqs+0x12/0x4d [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa [<c1aa0cb9>] init_IRQ+0xe/0x65 [<c1a99546>] start_kernel+0x178/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c142f174>] i8259A_lock+0x14/0x40 ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107eb2>] enable_8259A_irq+0x10/0x47 [<c0107f12>] startup_8259A_irq+0x8/0xc [<c015b45e>] setup_irq+0xe4/0x14d [<c1aaa4c4>] time_init_hook+0xf/0x11 [<c1a9f320>] time_init+0x44/0x46 [<c1a9955f>] start_kernel+0x191/0x38f [<c0100210>] 0xc0100210 -> (ioapic_lock){+...} ops: 122 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c1aa71db>] io_apic_get_version+0x16/0x55 [<c1aa5c73>] mp_register_ioapic+0xc6/0x127 [<c1aa382e>] acpi_parse_ioapic+0x2d/0x39 [<c1abe031>] acpi_table_parse_madt_family+0xb4/0x100 [<c1abe093>] acpi_table_parse_madt+0x16/0x18 [<c1aa3c8a>] acpi_boot_init+0x132/0x251 [<c1aa08ea>] setup_arch+0xd36/0xe37 [<c1a99434>] start_kernel+0x66/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c011bce1>] mask_IO_APIC_irq+0x11/0x31 [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41 [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c1432514>] ioapic_lock+0x14/0x3c -> (i8259A_lock){++..} ops: 5149 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0108090>] init_8259A+0x11/0x8f [<c1aa0d22>] init_ISA_irqs+0x12/0x4d [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa [<c1aa0cb9>] init_IRQ+0xe/0x65 [<c1a99546>] start_kernel+0x178/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c142f174>] i8259A_lock+0x14/0x40 ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107e6b>] disable_8259A_irq+0x10/0x47 [<c011bdbd>] startup_edge_ioapic_vector+0x31/0x58 [<c015b45e>] setup_irq+0xe4/0x14d [<c015b5a1>] request_irq+0xda/0xf9 [<c1ac983a>] rtc_init+0x6a/0x1a7 [<c0100457>] init+0x14a/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c011bce1>] mask_IO_APIC_irq+0x11/0x31 [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41 [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad the hard-irq-unsafe lock's dependencies: -> (vector_lock){--..} ops: 31 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb softirq-on-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb hardirq-on-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb } ... key at: [<c1432574>] vector_lock+0x14/0x3c stack backtrace: [<c0104f36>] show_trace+0xd/0xf [<c010543e>] dump_stack+0x17/0x19 [<c0144e34>] check_usage+0x1f6/0x203 [<c0146395>] __lockdep_acquire+0x8c2/0xaa5 [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35 [<c015b932>] probe_irq_on+0x44/0x107 [<c0673d58>] serial8250_config_port+0x84b/0x986 [<c06707b1>] uart_add_one_port+0x105/0x289 [<c1ace54b>] serial8250_init+0xc3/0x10a [<c0100457>] init+0x14a/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Jan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>