aboutsummaryrefslogtreecommitdiff
path: root/arch/x86
AgeCommit message (Collapse)Author
2008-07-08x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systemsMatthew Garrett
Some HP laptops have a problem with their DSDT reporting as HP/SB400/10000, which includes some code which overrides all temperature trip points to 16C if the INTIN2 input of the I/O APIC is enabled. This input is incorrectly designated the ISA IRQ 0 via an interrupt source override even though it is wired to the output of the master 8259A and INTIN0 is not connected at all. So far two models have been identified, namely nx6125 and nx6325. Use a knob provided by the I/O APIC interrupt registration code to abandon any attempts to route IRQ 0 through the I/O APIC for these systems. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APICMaciej W. Rozycki
As discovered recently some systems exhibit problems when the 8254 timer IRQ is routed through the I/O APIC. These problems do not affect the timer IRQ itself and therefore cannot be detected when the correctness of operation of the interrupt is verified in check_timer(). Therefore the I/O APIC path of the timer IRQ has to be disabled entirely. This is a change that lets platforms ask for the timer IRQ not to be registered in the I/O APIC interrupt tables. The local APIC and ExtINTA paths are unaffected. This request is only taken into account for ACPI platforms as MP table systems seem unaffected so far. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: simplify x86_mpparse dependency checkYinghai Lu
"Maciej W. Rozycki" <macro@linux-mips.org> said: > Given X86_64 selects X86_LOCAL_APIC I am not sure the redundancy seen >above does not actually obscure the logic behind... I think: > > depends on X86_LOCAL_APIC && !X86_VISWS > >would be clearer and get the same. Suggested-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: fix compiling when CONFIG_X86_MPPARSE is not setYinghai Lu
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: let MPS support be selectable, v2Yinghai Lu
v2: seperate "fix for compiling when MPPARSE is not set" to another patch make X86_MPPARSE to be selectable only when acpi is set and X86_MPPARSE will be set if acpi is not set. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: update mptable fix with no ioapic v2Yinghai Lu
if the system doesn't have ioapic, we don't need to store entries for mptable update also let mp_config_acpi_gsi not call func in mpparse so later could decouple mpparse with acpi more easily Reported-by: Daniel Exner <dex@dragonslave.de> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Daniel Exner <dex@dragonslave.de> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: cleanup machine_specific_memory_setup, v2Yinghai Lu
1. let 64bit support 88 and e801 too 2. introduce default_machine_specific_memory_setup, and reuse it for voyager v2: fix 64 bit compiling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: use acpi_numa_init to parse on 32-bit numaYinghai Lu
seperate SRAT finding and parsing from get_memcfg_from_srat, and let getmemcfg_from_srat only handle array from previous step. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: Kconfig cleanup with genericarchYinghai Lu
we already have summit and etc depends on genericarch, so use genericarch only. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: move some function out of setup_bootmem_allocYinghai Lu
... to make it more like 64-bit. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: merge setup_memory_map with e820Yinghai Lu
... and kill e820_32/64.c and e820_32/64.h Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: kill bad_pproYinghai Lu
so don't punish all other cpus without that problem when init highmem Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: move e820_resource_resources to e820.cYinghai Lu
and make 32-bit resource registration more like 64 bit. also move probe_roms back to setup_32.c Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86 boot: pass E820 memory map entries more than 128 via linked list of ↵Huang, Ying
setup data Because of the size limits of struct boot_params (zero page), the maximum number of E820 memory map entries can be passed to kernel is 128. As pointed by Paul Jackson, there is some machine produced by SGI with so many nodes that the number of E820 memory map entries is more than 128. To enabling Linux kernel on these system, a new setup data type named SETUP_E820_EXT is defined to pass additional memory map entries to Linux kernel. This patch is based on x86/auto-latest branch of git-x86 tree and has been tested on x86_64 and i386 platform. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86, mm: use add_highpages_with_active_regions() for high pages init v2Yinghai Lu
use early_node_map to init high pages, so we can remove page_is_ram() and page_is_reserved_early() in the big loop with add_one_highpage also remove page_is_reserved_early(), it is not needed anymore. v2: fix the build of other platforms Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: rename two e820 related functionsYinghai Lu
rename update_memory_range to e820_update_range rename add_memory_region to e820_add_region to make it more clear that they are about e820 map operations. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: use dstapic in mp_config_acpi_legacy_irqsYinghai Lu
so we don't get the same value multiple times. also make mp_config_acpi_legacy_irqs more readable by moving assignments together. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: keep MP_intsrc_info untouched if we do not update mptableYinghai Lu
Daniel Exner reported IO-APIC enumeration breakage in linux-next. Alexey Starikovskiy found out that it might be related to commit 2944e16b25 "x86: update mptable". use enable_update_mptable to decide if need check before add mp_irqs array. Reported-by: Daniel Exner <webmaster@dragonslave.de> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: clean up relocate_initrdYinghai Lu
1. move that before zone_sizes_init ... 2. add free_early for one old one, otherwise it will be be reserved again when we init highmem. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: replace shrink_active_range() with remove_active_range()Yinghai Lu
in case we have kva before ramdisk on a node, we still need to use those ranges. v2: reserve_early kva ram area, in case there are holes in highmem, to avoid those area could be treat as free high pages. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: clean up reserve_bootmem_generic() and port it to 32-bitYinghai Lu
1. add reserve_bootmem_generic for 32bit 2. change len to unsigned long 3. make early_res_to_bootmem to use it Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: make generic arch support NUMAQ, fix #2Yinghai Lu
we are checking mptable early for numaq, so don't need to reserve_bootmem for it. bootmem is not there yet. do the same thing as 64-bit. found it on 64g above system from 64-bit kernel kexec to 32 bit kernel with numaq support. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: make generic arch support NUMAQ, fixYinghai Lu
fix typo in bigsmp switching. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: e820 merge parsing of the mem=/memmap= boot parametersYinghai Lu
since we now have 32-bit support for e820_register_active_regions(), we can merge the parsing of the mem=/memmap= boot parameters. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: unify the reserve_bootmem() behavior of early_res_to_bootmem()Ingo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: use reserve_bootmem_generic() to reserve crashkernel memory on x86_64Bernhard Walle
This patch uses reserve_bootmem_generic() instead of reserve_bootmem() to reserve the crashkernel memory on x86_64. That's necessary for NUMA machines, see 00212fef814612245ed0261cbac8426d0c9a31a5: [PATCH] Fix kdump Crash Kernel boot memory reservation for NUMA machines This patch will fix a boot memory reservation bug that trashes memory on the ES7000 when loading the kdump crash kernel. The code in arch/x86_64/kernel/setup.c to reserve boot memory for the crash kernel uses the non-numa aware "reserve_bootmem" function instead of the NUMA aware "reserve_bootmem_generic". I checked to make sure that no other function was using "reserve_bootmem" and found none, except the ones that had NUMA ifdef'ed out. I have tested this patch only on an ES7000 with NUMA on and off (numa=off) in a single (non-NUMA) and multi-cell (NUMA) configurations. Signed-off-by: Amul Shah <amul.shah@unisys.com> Looks-good-to: Vivek Goyal <vgoyal@in.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> The switch-back to reserve_bootmem() was accidentally introduced in 5c3391f9f749023a49c64d607da4fb49263690eb when adding the BOOTMEM_EXCLUSIVE parameter. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: add flags parameter to reserve_bootmem_generic()Bernhard Walle
This patch adds a 'flags' parameter to reserve_bootmem_generic() like it already has been added in reserve_bootmem() with commit 72a7fe3967dbf86cb34e24fbf1d957fe24d2f246. It also changes all users to use BOOTMEM_DEFAULT, which doesn't effectively change the behaviour. Since the change is x86-specific, I don't think it's necessary to add a new API for migration. There are only 4 users of that function. The change is necessary for the next patch, using reserve_bootmem_generic() for crashkernel reservation. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Merge branch 'linus' into tmp.x86.mpparse.newIngo Molnar
2008-07-08Merge branch 'x86/irq' into x86/develIngo Molnar
Conflicts: arch/x86/kernel/i8259.c arch/x86/kernel/irqinit_64.c Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Merge branches 'x86/mmio', 'x86/delay', 'x86/idle', 'x86/oprofile', ↵Ingo Molnar
'x86/debug', 'x86/ptrace' and 'x86/amd-iommu' into x86/devel
2008-07-08Merge branch 'x86/setup' into x86/develIngo Molnar
2008-07-08Merge branches 'x86/numa-fixes', 'x86/apic', 'x86/apm', 'x86/bitops', ↵Ingo Molnar
'x86/build', 'x86/cleanups', 'x86/cpa', 'x86/cpu', 'x86/defconfig', 'x86/gart', 'x86/i8259', 'x86/intel', 'x86/irqstats', 'x86/kconfig', 'x86/ldt', 'x86/mce', 'x86/memtest', 'x86/pat', 'x86/ptemask', 'x86/resumetrace', 'x86/threadinfo', 'x86/timers', 'x86/vdso' and 'x86/xen' into x86/devel
2008-07-08x86, arch/x86/kernel/io_apic_32.c: use kzalloc instead of kmalloc/memsetChristophe Jaillet
1) replace kmalloc/memset with equivalent kzalloc. Signed-off-by: Christophe Jaillet <jaillet.christophe@wanadoo.fr> Cc: cj <jaillet.christophe@wanadoo.fr> Cc: petero2@telia.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: fix IO APIC breakage on HP nx6325, v2Maciej W. Rozycki
> That helped a lot, the system seems to work normally now. > > Here's the relevant snippet from dmesg: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log Hmm, that only proved the 8259A is indeed wired to the pin #2 of the I/O APIC. > I, personally, don't have any and AMD only has SB600 documentation on its > web page (it's still marked as "AMD confidential" ;-)). Well, the IC block is most likely the same as that's not rocket science and once done there is no need to fiddle with that. That written, I am afraid there is nothing useful about the IC in the document, except that it's there and consists of an I/O APIC providing 24 inputs and the usual pair of 8259A cores. Thanks for the reference anyway. > There is an interrupt controller in there, but I'm not sure if there's any > 8259A. The northbridge is on the CPU, actually. I will praise the day someone ships an x86 machine without an 8259A core! As expressed in another mail I suspect there may actually be a direct route from the 8254 to INTIN0 in the southbridge -- this is what other bootstrap logs seen in the Internet suggest. This would mean this particular BIOS is buggy (is it the latest version?) and provides an incorrect IRQ override in its ACPI tables, for example because the responsible block has been blindly copied from a machine using a commoner wiring. This could be moderately easily fixed up with a quirk based on the PCI ID (after checking it again, we actually used to have a quirk for ATI in this area, but the way it was done suggests the issue was not understood well enough). Could you please remove the hack sent yesterday and test the patch provided below? I do hope it builds, but I have no immediate means to check it. Please report the output. The intent is to test INTIN0 directly before testing INTIN2 through the 8259A. Thanks. Aside of that, what I have gathered from your reports (please correct me if I have got it wrong) is that when the through-8259A mode is used, then after a while 8254 timer interrupts stop arriving. What's interesting, the "Virtual Wire IRQ" seems to work for you correctly (that's quite an odd setup where a local APIC input is used in the native mode -- please post /proc/interrupts for confirmation), which in turn implies the master 8259A drives its INT output as we expect. Why would the I/O APIC input have problems then? Hmm... [ mingo@elte.hu: revert the "x86: fix IO APIC breakage on HP nx6325" version. ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: fix IO APIC breakage on HP nx6325Maciej W. Rozycki
On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > > With such a configuration the "x86: I/O APIC: timer through 8259A > > second-chance" patch should not matter, because the only change it > > introduces is an attempt to try the same I/O APIC pin again, but with the > > IRQ0 line of the master 8259A enabled. That's not a terribly unusual > > configuration and nothing should get confused in the system. > > But it _does_ get confused, really. Something certainly gets confused, but so far I am not sure which bit exactly it is, are you? > > Barring the unlikely possibility of the 8259A actually being wired to > > INTIN2 of the I/O APIC I can see two possible explanations: > > > > 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > > as an ExtINTA interrupt. This would make the code in check_timer() > > decide it has found a working configuration, while actually it has been > > fooled. [...] > Here you go: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. > > The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log Thanks. In this case I suspect the case #1 quoted above happens, that is the 8259A manages to deliver its interrupt somehow. Note at this stage it is meant to be in the AEOI mode, so it can happily resubmit the interrupt indefinitely with no additional handling as long as it receives INTA cycles. Can you please try the patch below on top of "x86: I/O APIC: timer through 8259A second-chance" to see whether my hypothesis is true? It modifies the through-8259A setup path so that the APIC input gets masked, but the 8259A has the timer interrupt still enabled. Let me know how the timer interrupt is routed in this case. Bisected-by: "Rafael J. Wysocki" <rjw@sisk.pl> Tested-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: coding style fixes to arch/x86/kernel/io_apic_32.cPaolo Ciarrocchi
Before: total: 91 errors, 73 warnings, 2850 lines checked After: total: 1 errors, 47 warnings, 2848 lines checked Compile tested: paolo@paolo-desktop:/tmp$ size io* text data bss dec hex filename 13836 1756 11104 26696 6848 io_apic_32.o.after 13836 1756 11104 26696 6848 io_apic_32.o.before Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86, io-apic: use predefined names instead of numeric constantsCyrill Gorcunov
This patch replaces some hard-coded numbers with predefined names. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: APIC/SMP: Downgrade the NMI watchdog for "nosmp"Maciej W. Rozycki
If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip has been deactivated as a result of "nosmp". Downgrade to the local APIC watchdog similarly to what is done for the UP case. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: APIC/UP: Remove redundant NMI watchdog downgradeMaciej W. Rozycki
For the UP case the NMI watchdog downgrade is done consistently in APIC_init_uniprocessor() now. Remove redundant code used only when BIOS-disabled local APIC is activated. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: APIC/UP: Downgrade the NMI watchdog for no I/O APICMaciej W. Rozycki
If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip will not be used in the UP configuration, because "noapic" has been specified or the chip is simply not there. Downgrade to the local APIC watchdog to rectify. The new #ifdef is ugly, I know. A proper solution is to provide suitable definitions of smp_found_config, etc. for !CONFIG_X86_IO_APIC in a header. Likewise the whole if () condition should be moved to a static inline function. Such clean-ups are beyond the scope of this change and can be done once the whole issue of the timer has been sorted out. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08Revert "x86: APIC/SMP: downgrade the NMI watchdog for "nosmp""Ingo Molnar
This reverts commit 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63. A better fix from Maciej will be merged.
2008-07-08Revert "x86, io-apic: fix nmi_watchdog=1 bootup hang"Ingo Molnar
This reverts commit 2229ff84f01746d02fb6b79e156fb5cce48c908f. A better fix from Maciej will be merged.
2008-07-08x86, io-apic: fix nmi_watchdog=1 bootup hangIngo Molnar
nmi_watchdog=1 hangs on 64-bit: [ 0.250000] Detected 12.564 MHz APIC timer. [ 0.254178] APIC timer registered as dummy, due to nmi_watchdog=1! [ 0.260366] Testing NMI watchdog ... <4>WARNING: CPU#0: NMI appears to be stuck (0->0)! [ ... ] [ 0.470003] calling genl_init+0x0/0xd0 [ hard hang ] bisected it down to: git-bisect start git-bisect good 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 git-bisect bad 11582ece0aaa2d0f94f345c08a4ab9997078a083 git-bisect bad 5479c623bb44089844022c03d4c0eb16d5b7a15f git-bisect bad cfb4c7fabeb499e1c29f9d1878968e37a938e28a git-bisect good 246dd412d31e4f5de1d43aa6422a325b785f36e4 git-bisect bad 3f8237eaff7dc1e35fa791dae095574fd974e671 git-bisect good 90e23b13ab849e2a11f00c655eb3a2011b4623be git-bisect bad 833526a34eeefc117df3191a594c3c3a4f15a9ac git-bisect good 791b93d3dfaf16c23e978bec0cc0a3dd9d855d63 git-bisect bad 65767c64068f2c93e56a1accfed5c78230ac12d7 git-bisect bad 2abc5c05dd82c188e3bdf6641a274f013348d14b git-bisect bad 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | 317e1f2597ffb4d4db940577bbe56dc6e881ef07 is first bad commit | commit 317e1f2597ffb4d4db940577bbe56dc6e881ef07 | Author: Maciej W. Rozycki <macro@linux-mips.org> | Date: Wed May 21 22:10:22 2008 +0100 | x86: I/O APIC: clean up the 8259A on a NMI watchdog failure the problem is that in the dummy-lapic branch we rely on the i8259A but if the NMI watchdog fails we turn off IRQ 0 - which doesnt work too well ;-) Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: IO-APIC - use NMI_NONE instead of numeric constantCyrill Gorcunov
Not sure but maybe it is better to use NMI_DISABLED, will take a look. But for now this patch is not change anything in logic so it will not hurt/broke the kernel. For most cases nmi_watchdog assignment is by one of NMI_* macro so I think there it make sense too. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86 build fix:Ingo Molnar
arch/x86/kernel/io_apic_64.c: In function 'check_timer': arch/x86/kernel/io_apic_64.c:1688: error: 'vector' undeclared (first use in this function) arch/x86/kernel/io_apic_64.c:1688: error: (Each undeclared identifier is reported only once arch/x86/kernel/io_apic_64.c:1688: error: for each function it appears in.)
2008-07-08x86: apic_64.c fix sparse warnings about shadowed variablesThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: make irq_cfg staticThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: move pci_routirq declaration to pci.hThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: I/O APIC: timer through 8259A second-chanceMaciej W. Rozycki
Some systems incorrectly report the ExtINTA pin of the I/O APIC as the genuine target of the timer interrupt. Here is a change that copies timer pin information found to the other pin if one has been found only. This way both a direct and a through-8259A route is tested with the pin letting these problematic systems work well enough. If no timer pin information has been found for the I/O APIC, then local APIC variations are tried only, similarly to what is done without the change (except without the misleading messages). Obviously if we try the first-chance path without being told by the BIOS to do so, we should not complain either, so do not print the message in this case. The 64-bit variation should be updated with a call to replace_pin_at_irq() which can be done with the upcoming merge. Since add_pin_to_irq() is now always called in the first-chance path, the condition to require it in the second-chance path no longer happens. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08x86: I/O APIC: keep the timer IRQ masked during set-upMaciej W. Rozycki
Keep the timer interrupt line masked when reconfiguring its interrupt redirection entry in the I/O APIC. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-04 22:22:02 +0000