aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386/kernel/apic.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2006-03-23[PATCH] fix implicit declaration of GET_APIC_ID in arch/i386/kernel/apic.cJesper Juhl1-0/+1
arch/i386/kernel/apic.c:840: warning: implicit declaration of function `GET_APIC_ID' Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-14[PATCH] Plug kdump shutdown race windowManeesh Soni1-2/+4
lapic_shutdown() re-enables interrupts which is un-desirable for panic case, so use local_irq_save() and local_irq_restore() to keep the irqs disabled for kexec on panic case, and close a possible race window while kdump shutdown as shown in this stack trace -- BUG: spinlock lockup on CPU#1, bash/4396, c52781a0 [<c01c1870>] _raw_spin_lock+0xb7/0xd2 [<c029e148>] _spin_lock+0x6/0x8 [<c011b33f>] scheduler_tick+0xe7/0x328 [<c0128a7c>] update_process_times+0x51/0x5d [<c0114592>] smp_apic_timer_interrupt+0x4f/0x58 [<c01141ff>] lapic_shutdown+0x76/0x7e [<c0104d7c>] apic_timer_interrupt+0x1c/0x30 [<c01141ff>] lapic_shutdown+0x76/0x7e [<c0116659>] machine_crash_shutdown+0x83/0xaa [<c013cc36>] crash_kexec+0xc1/0xe3 [<c029e148>] _spin_lock+0x6/0x8 [<c013cc22>] crash_kexec+0xad/0xe3 [<c0215280>] __handle_sysrq+0x84/0xfd [<c018d937>] write_sysrq_trigger+0x2c/0x35 [<c015e47b>] vfs_write+0xa2/0x13b [<c015ea73>] sys_write+0x3b/0x64 [<c0103c69>] syscall_call+0x7/0xb Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-07[PATCH] Fix bad apic fix on i386Andi Kleen1-1/+1
Fix wrong '!' in bad apic fix I forgot to remove the ! when moving the code from x86-64 to i386 x86-64 tested !disable_apic, but of course for cpu_has_apic it shouldn't be negated. Credit goes to Jan Beulich for spotting it with eagle eyes. Cc: Jan Beulich <jbeulich@novell.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-04[PATCH] i386/x86-64: Don't ack the APIC for bad interrupts when the APIC is not enabledAndi Kleen1-1/+4
It's bad juju to touch the APIC when it hasn't been enabled. I also moved ack_bad_irq for x86-64 out of line following i386. Signed-off-by: Andi Kleen <ak@suse.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-11[PATCH] i386: Handle missing local APIC timer interrupts on C3 stateVenkatesh Pallipadi1-2/+76
Whenever we see that a CPU is capable of C3 (during ACPI cstate init), we disable local APIC timer and switch to using a broadcast from external timer interrupt (IRQ 0). This is needed because Intel CPUs stop the local APIC timer in C3. This is currently only enabled for Intel CPUs. Patch below adds the code for i386 and also the ACPI hunk. 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-01-11[PATCH] i386/x86-64: Remove sub jiffy profile timer supportVenkatesh Pallipadi1-55/+6
Remove the finer control of local APIC timer. We cannot provide a sub-jiffy control like this when we use broadcast from external timer in place of local APIC. Instead of removing this only on systems that may end up using broadcast from external timer (due to C3), I am going the "I'm feeling lucky" way to remove this fully. Basically, I am not sure about usefulness of this code today. Few other architectures also don't seem to support this today. If you are using profiling and fine grained control and don't like this going away in normal case, yell at me right now. 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-01-06[PATCH] x86: missing printk newline in apic boot option parserDave Jones1-1/+1
Missing newline in printk. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] i386: LVT entries remaining unmasked on rebootZwane Mwaikambo1-2/+8
Excerpt from bugzilla entry http://bugzilla.kernel.org/show_bug.cgi?id=5518 "i386 version of Reboot-through-BIOS is unsafe: it forgets to mask APIC LVT interrupts before jumping to a BIOS entry point. As a result, BIOS ends up bombarded with interrupts early on boot. The BIOS does not expect it since following a "normal" hardware cpu reset, all APIC LVT registers have the Mask bit (16) set and can't generate interrupts. For example, the version of Phoenix BIOS used by VMware enables interrupts for the first time before masking/clearing APIC LVT. The APIC Timer LVT register is still set up for a timer interrupt delivery with a high vector from the previous Linux incarnation (0xef in our case). The BIOS has not fully initialized its IDT at this point and the real mode gate for 0xef remains all zeros. Vector 0xef dispatches BIOS to address 0:0, BIOS takes a #GP and eventually hangs. machine_shutdown() does attempt to shut down APIC before jumping to BIOS, but it is ineffective" Signed-off-by: Zwane Mwaikambo <zwane@arm.linux.org.uk> Cc: "Seth, Rohit" <rohit.seth@intel.com> Cc: Zachary Amsden <zach@vmware.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-31Revert "i386: move apic init in init_IRQs"Linus Torvalds1-61/+16
Commit f2b36db692b7ff6972320ad9839ae656a3b0ee3e causes a bootup hang on at least one machine. Revert for now until we understand why. The old code may be ugly, but it works. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] kdump/i386: apic verification failure fixVivek Goyal1-2/+1
o Removes the unnecessary call to local_irq_disable(). o Kdump was failing while second kernel was coming up. Check for presence of boot cpu apic id was failing in (apic_id_registered), hence hitting BUG(). o This should not have failed because before calling setup_local_APIC(), it is ensured that even if BIOS has not reported boot cpu, then hard set the prence of it. Problem happens because of usage of hard_smp_processor_id() which is hardcoded to zero in case of non SMP kernel. In kdump case second kernel can boot on a cpu whose boot cpu id is not zero. o Using boot_cpu_physical_apicid instead to hard set the presence of boot cpu. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386: move apic init in init_IRQsEric W. Biederman1-17/+64
All kinds of ugliness exists because we don't initialize the apics during init_IRQs. - We calibrate jiffies in non apic mode even when we are using apics. - We have to have special code to initialize the apics when non-smp. - The legacy i8259 must exist and be setup correctly, even when we won't use it past initialization. - The kexec on panic code must restore the state of the io_apics. - init/main.c needs a special case for !smp smp_init on x86 In addition to pure code movement I needed a couple of non-obvious changes: - Move setup_boot_APIC_clock into APIC_late_time_init for simplicity. - Use cpu_khz to generate a better approximation of loops_per_jiffies so I can verify the timer interrupt is working. - Call setup_apic_nmi_watchdog again after cpu_khz is initialized on the boot cpu. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-26[PATCH] useless includes of linux/irq.h in arch/i386Al Viro1-1/+0
Most of these guys are simply not needed (pulled by other stuff via asm-i386/hardirq.h). One that is not entirely useless is hilarious - arch/i386/oprofile/nmi_timer_int.c includes linux/irq.h... as a way to get linux/errno.h Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-18[PATCH] x86: Remove obsolete get_cpu_vendor callAndi Kleen1-4/+0
Since early CPU identify is in this information is already available Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-30[PATCH] x86: i8253/i8259A lock cleanupIngo Molnar1-1/+1
Introduce proper declarations for i8253_lock and i8259A_lock. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] kexec: x86: resture apic virtual wire mode on shutdownEric W. Biederman1-1/+37
When coming out of apic mode attempt to set the appropriate apic back into virtual wire mode. This improves on previous versions of this patch by by never setting bot the local apic and the ioapic into veritual wire mode. This code looks at data from the mptable to see if an ioapic has an ExtInt input to make this decision. A future improvement is to figure out which apic or ioapic was in virtual wire mode at boot time and to remember it. That is potentially a more accurate method, of selecting which apic to place in virutal wire mode. Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] kexec: x86: local apic fixEric W. Biederman1-20/+5
From: "Maciej W. Rozycki" <macro@linux-mips.org> Fix a kexec problem whcih causes local APIC detection failure. The problem is detect_init_APIC() is called early, before the command line have been processed. Therefore "lapic" (and "nolapic") have not been seen, yet. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] init call cleanupLi Shaohua1-7/+7
Trival patch for CPU hotplug. In CPU identify part, only did cleaup for intel CPUs. Need do for other CPUs if they support S3 SMP. Signed-off-by: Li Shaohua<shaohua.li@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] i386 CPU hotplugZwane Mwaikambo1-1/+2
(The i386 CPU hotplug patch provides infrastructure for some work which Pavel is doing as well as for ACPI S3 (suspend-to-RAM) work which Li Shaohua <shaohua.li@intel.com> is doing) The following provides i386 architecture support for safely unregistering and registering processors during runtime, updated for the current -mm tree. In order to avoid dumping cpu hotplug code into kernel/irq/* i dropped the cpu_online check in do_IRQ() by modifying fixup_irqs(). The difference being that on cpu offline, fixup_irqs() is called before we clear the cpu from cpu_online_map and a long delay in order to ensure that we never have any queued external interrupts on the APICs. There are additional changes to s390 and ppc64 to account for this change. 1) Add CONFIG_HOTPLUG_CPU 2) disable local APIC timer on dead cpus. 3) Disable preempt around irq balancing to prevent CPUs going down. 4) Print irq stats for all possible cpus. 5) Debugging check for interrupts on offline cpus. 6) Hacky fixup_irqs() to redirect irqs when cpus go off/online. 7) play_dead() for offline cpus to spin inside. 8) Handle offline cpus set in flush_tlb_others(). 9) Grab lock earlier in smp_call_function() to prevent CPUs going down. 10) Implement __cpu_disable() and __cpu_die(). 11) Enable local interrupts in cpu_enable() after fixup_irqs() 12) Don't fiddle with NMI on dead cpu, but leave intact on other cpus. 13) Program IRQ affinity whilst cpu is still in cpu_online_map on offline. Signed-off-by: Zwane Mwaikambo <zwane@linuxpower.ca> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] xen: x86: Rename usermode macroVincent Hanquez1-1/+1
Rename user_mode to user_mode_vm and add a user_mode macro similar to the x86-64 one. This is useful for Xen because the linux xen kernel does not runs on the same priviledge that a vanilla linux kernel, and with this we just need to redefine user_mode(). Signed-off-by: Vincent Hanquez <vincent.hanquez@cl.cam.ac.uk> Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] check nmi watchdog is brokenJack F Vogel1-2/+0
A bug against an xSeries system showed up recently noting that the check_nmi_watchdog() test was failing. I have been investigating it and discovered in both i386 and x86_64 the recent change to the routine to use the cpu_callin_map has uncovered a problem. Prior to that change, on an SMP box, the test was trivally passing because all cpu's were found to not yet be online, but now with the callin_map they are discovered, it goes on to test the counter and they have not yet begun to increment, so it announces a CPU is stuck and bails out. On all the systems I have access to test, the announcement of failure is also bougs... by the time you can login and check /proc/interrupts, the NMI count is happily incrementing on all CPUs. Its just that the test is being done too early. I have tried moving the call to the test around a bit, and it was always too early. I finally hit on this proposed solution, it delays the routine via a late_initcall(), seems like the right solution to me. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] pm_message_t: more fixes in common and i386Pavel Machek1-1/+1
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that turned out not to be the case as Russel King pointed out. Here are fixes for Documentation and common code (mainly system devices). Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+1278
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!