aboutsummaryrefslogtreecommitdiff
path: root/include/asm-i386/mach-default
AgeCommit message (Collapse)Author
2006-01-11[PATCH] x86_64/i386: Remove preempt disable calls in lowlevel IPIZwane Mwaikambo
I noticed that some lowlevel send_IPI_mask helpers had a hotplug/preempt race whereupon the cpu_online_map was read before disabling preemption; ... cpumask_t mask = cpu_online_map; int cpu = get_cpu(); cpu_clear(cpu, mask); ... But then i realised that there is no need for these lowlevel functions to be going through all this trouble when all the callers are already made hotplug/preempt safe. Signed-off-by: Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-14[PATCH] x86_64: Reduce number of retries for reset through keyboard controllerAndi Kleen
Old code could retry for 10 seconds worst time. Only try it for one second now. Suggested by Yinghai Lu Cc: Yinghai.Lu@amd.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09[PATCH] fix reboot via keyboard controller resetTruxton Fulton
I have a system (Biostar IDEQ210M mini-pc with a VIA chipset) which will not reboot unless a keyboard is plugged in to it. I have tried all combinations of the kernel "reboot=x,y" flags to no avail. Rebooting by any method will leave the system in a wedged state (at the "Restarting system" message). I finally tracked the problem down to the machine's refusal to fully reboot unless the keyboard controller status register had bit 2 set. This is the "System flag" which when set, indicates successful completion of the keyboard controller self-test (Basic Assurance Test, BAT). I suppose that something is trying to protect against sporadic reboots unless the keyboard controller is in a good state (a keyboard is present), but I need this machine to be headless. I found that setting the system flag (via the command byte) before giving the "pulse reset line" command will allow the reboot to proceed. The patch is simple, and I think it should be fine for everybody whether they have this type of machine or not. This affects the "hard" reboot (as done when the kernel boot flags "reboot=c,h" are used). 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 Molnar
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] i386: Dont use IPI broadcast when using cpu hotplug.Ashok Raj
This patch introduces a startup parameter no_broadcast. When we enable CONFIG_HOTPLUG_CPU, we dont want to use broadcast shortcut as it has ill effects on a offline cpu. If we issue broadcast, the IPI is also delivered to offline cpus, or partially up cpu causing stale IPI's to be handled, which is a problem and can cause undesirable effects. Introduces a new startup cmdline option no_ipi_broadcast, that can be switched at cmdline if necessary. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Acked-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] Do not enforce unique IO_APIC_ID check for xAPIC systems (i386)Natalie Protasevich
This patch is per Andi's request to remove NO_IOAPIC_CHECK from genapic and use heuristics to prevent unique I/O APIC ID check for systems that don't need it. The patch disables unique I/O APIC ID check for Xeon-based and other platforms that don't use serial APIC bus for interrupt delivery. Andi stated that AMD systems don't need unique IO_APIC_IDs either. Signed-off-by: Natalie Protasevich <Natalie.Protasevich@unisys.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!