aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2006-03-22[PATCH] hugepage: is_aligned_hugepage_range() cleanupDavid Gibson1-12/+0
Quite a long time back, prepare_hugepage_range() replaced is_aligned_hugepage_range() as the callback from mm/mmap.c to arch code to verify if an address range is suitable for a hugepage mapping. is_aligned_hugepage_range() stuck around, but only to implement prepare_hugepage_range() on archs which didn't implement their own. Most archs (everything except ia64 and powerpc) used the same implementation of is_aligned_hugepage_range(). On powerpc, which implements its own prepare_hugepage_range(), the custom version was never used. In addition, "is_aligned_hugepage_range()" was a bad name, because it suggests it returns true iff the given range is a good hugepage range, whereas in fact it returns 0-or-error (so the sense is reversed). This patch cleans up by abolishing is_aligned_hugepage_range(). Instead prepare_hugepage_range() is defined directly. Most archs use the default version, which simply checks the given region is aligned to the size of a hugepage. ia64 and powerpc define custom versions. The ia64 one simply checks that the range is in the correct address space region in addition to being suitably aligned. The powerpc version (just as previously) checks for suitable addresses, and if necessary performs low-level MMU frobbing to set up new areas for use by hugepages. No libhugetlbfs testsuite regressions on ppc64 (POWER5 LPAR). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] Uninline sys_mmap common code (reduce binary size)Michael Buesch1-16/+9
Remove the inlining of the new vs old mmap system call common code. This reduces the size of the resulting vmlinux for defconfig as follows: mb@pc1:~/develop/git/linux-2.6$ size vmlinux.mmap* text data bss dec hex filename 3303749 521524 186564 4011837 3d373d vmlinux.mmapinline 3303557 521524 186564 4011645 3d367d vmlinux.mmapnoinline The new sys_mmap2() has also one function call overhead removed, now. (probably it was already optimized to a jmp before, but anyway...) Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] remove set_page_count() outside mm/Nick Piggin1-3/+3
set_page_count usage outside mm/ is limited to setting the refcount to 1. Remove set_page_count from outside mm/, and replace those users with init_page_count() and set_page_refcounted(). This allows more debug checking, and tighter control on how code is allowed to play around with page->_count. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] i386: pageattr remove __put_pageNick Piggin1-7/+13
Stop using __put_page and page_count in i386 pageattr.c Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] on_each_cpu(): disable local interruptsAndrew Morton1-16/+12
When on_each_cpu() runs the callback on other CPUs, it runs with local interrupts disabled. So we should run the function with local interrupts disabled on this CPU, too. And do the same for UP, so the callback is run in the same environment on both UP and SMP. (strictly it should do preempt_disable() too, but I think local_irq_disable is sufficiently equivalent). Also uninlines on_each_cpu(). softirq.c was the most appropriate file I could find, but it doesn't seem to justify creating a new file. Oh, and fix up that comment over (under?) x86's smp_call_function(). It drives me nuts. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] x86: mark cyc2ns_scale readmostlyRavikiran G Thirumalai2-2/+2
This variable is rarely written to. Mark the variable accordingly. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by: Shai Fultheim <shai@scalex86.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-22[PATCH] efi_call_phys_epilog() warning fixAndrew Morton1-1/+1
arch/i386/kernel/efi.c: In function `efi_call_phys_epilog': arch/i386/kernel/efi.c:118: warning: assignment makes integer from pointer without a cast Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com> Cc: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-20update the i386 defconfigAdrian Bunk1-431/+741
The i386 defconfig wasn't updated for ages. Instead of running "make oldconfig" on the old defconfig and trying to give reasonable answers at all new options, this patch replaces it with the one I'm using in 2.6.16-rc1. This way, it's a .config that is confirmed to work on at least one computer in the world. ;-) Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-17[PATCH] x86: check for online cpus before bringing them upSrivatsa Vaddagiri1-0/+10
Bryce reported a bug wherein offlining CPU0 (on x86 box) and then subsequently onlining it resulted in a lockup. On x86, CPU0 is never offlined. The subsequent attempt to online CPU0 doesn't take that into account. It actually tries to bootup the already booted CPU. Following patch fixes the problem (as acknowledged by Bryce). Please consider for inclusion in 2.6.16. Check if cpu is already online. Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.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-03-08[PATCH] i386: port ATI timer fix from x86_64 to i386 IIAndi Kleen6-6/+32
ATI chipsets tend to generate double timer interrupts for the local APIC timer when both the 8254 and the IO-APIC timer pins are enabled. This is because they route it to both and the result is anded together and the CPU ends up processing it twice. This patch changes check_timer to disable the 8254 routing for interrupt 0. I think it would be safe on all chipsets actually (i tested it on a couple and it worked everywhere) and Windows seems to do it in a similar way, but to be conservative this patch only enables this mode on ATI (and adds options to enable/disable too) Ported over from a similar x86-64 change. I reused the ACPI earlyquirk infrastructure for the ATI bridge check, but tweaked it a bit to work even without ACPI. Inspired by a patch from Chuck Ebbert, but redone. Cc: Chuck Ebbert <76306.1226@compuserve.com> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-08[PATCH] fix kexec asmMichael Matz1-7/+7
While testing kexec and kdump we hit problems where the new kernel would freeze or instantly reboot. The easiest way to trigger it was to kexec a kernel compiled for CONFIG_M586 on an athlon cpu. Compiling for CONFIG_MK7 instead would work fine. The patch fixes a few problems with the kexec inline asm. Signed-off-by: Chris Mason <mason@suse.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-08[PATCH] x86: cpu model calculation for family 6 cpuShaohua Li1-2/+2
The x86_model calculation also applies for family 6. early_cpu_detect does the right thing, but generic_identify misses. Signed-off-by: Shaohua Li<shaohua.li@intel.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: "Seth, Rohit" <rohit.seth@intel.com> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-08[PATCH] x86: Fix i386 nmi_watchdog that does not trigger die_nmiGOTO Masanori1-2/+2
Fix i386 nmi_watchdog that does not meet watchdog timeout condition. It does not hit die_nmi when it should be triggered, because the current nmi_watchdog_tick in arch/i386/kernel/nmi.c never count up alert_counter like this: void nmi_watchdog_tick (struct pt_regs * regs) { if (last_irq_sums[cpu] == sum) { alert_counter[cpu]++; <- count up alert_counter, but if (alert_counter[cpu] == 5*nmi_hz) die_nmi(regs, "NMI Watchdog detected LOCKUP"); alert_counter[cpu] = 0; <- reset alert_counter This patch changes it back to the previous and working version. This was found and originally written by Kohta NAKASHIMA. (akpm: also uninline write_watchdog_counter(), saving 184 byets) Signed-off-by: GOTO Masanori <gotom@sanori.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-06[PATCH] EFI: Fix gdt loadEdgar Hucek1-6/+8
This patch makes the kernel bootable again on ia32 EFI systems. Signed-off-by: Edgar Hucek <hostmaster@ed-soft.at> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-06[PATCH] x86: fix potential jiffies overflow in timer_resume()Atsushi Nemoto1-2/+2
i386 timer_resume is updating jiffies, not jiffies_64. It looks there is a potential overflow problem. And jiffies_64 and wall_jiffies should be protected by xtime_lock. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-28[PATCH] x86 microcode driver vs hotplug CPUs.Dave Jones1-6/+9
This driver loops over 'num_online_cpus', but it doesn't account for holes in the online map created by offlined cpus, and assumes that the cpu numbers stay linear. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-27Revert "[PATCH] x86_64: Only do the clustered systems have unsynchronized TSC assumption on IBM systems"Linus Torvalds1-0/+3
This reverts commit 13a229abc25640813f1480c0478dfc6bdbc1c19e. Quoth Andi: "After some consideration and feedback from various people it turns out this wasn't that good an idea. It has some problems and needs more work. Since it was only an optimization anyways it's best to just back it out again for now." Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-26Make Kprobes depend on modulesLinus Torvalds1-0/+1
Commit 9ec4b1f356b3bad928ae8e2aa9caebfa737d52df made kprobes not compile without module support, so just make that clear in the Kconfig file. Also, since it's marked EXPERIMENTAL, make that dependency explicit too. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-26[PATCH] fix voyager after topology.c moveJames Bottomley2-15/+1
Commit 9c869edac591977314323a4eaad5f7633fca684f broke voyager again rather subtly because it already had its own topology exporting functions, so now each CPU gets registered twice. I think we can actually use the generic ones, so I don't propose reverting it. The attached should eliminate the voyager topology functions in favour of the generic ones. I also added a define to ensure voyager is never hotplug CPU (we don't have the support in the SMP harness). Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-26[PATCH] i386: Handle non existing APICs without panicingAndreas Deresch2-4/+12
[description from AK] This fixes booting in APIC mode on some ACER laptops. x86-64 did a similar change some time ago. See http://bugzilla.kernel.org/show_bug.cgi?id=4700 for details Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-26[PATCH] x86_64: Only do the clustered systems have unsynchronized TSC assumption on IBM systemsAndi Kleen1-3/+0
Big Unisys systems have multiple clusters too, but they have an synchronized TSC. I'm using the SMBIOS to check for vendor == IBM. Cc: Chris McDermott <lcm@us.ibm.com> Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-24[PATCH] Fix topology.c locationZachary Amsden3-5/+5
When compiling a non-default subarch, topology.c is missing from the kernel build. This causes builds with CONFIG_HOTPLUG_CPU to fail. In addition, on Intel processors with cpuid level > 4, it causes intel_cacheinfo.c to reference uninitialized data that should have been set up by the initcall in topology.c which calls register_cpu. This causes a kernel panic on boot on newer Intel processors. Moving topology.c to arch/i386/kernel fixes both of these problems. Thanks to Dan Hecht for finding and fixing this problem. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Dan Hecht <dhect@vmware.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-24[PATCH] x86: fix broken SMP boot sequenceJames Bottomley5-19/+35
Recent GDT changes broke the SMP boot sequence if the booting CPU is numbered anything other than zero. There's also a subtle source of error in that the boot time CPU now uses cpu_gdt_table (which is actually the GDT for booting CPUs in head.S). This patch fixes both problems by making GDT descriptors themselves allocated from a per_cpu area and switching to them in cpu_init(), which now means that cpu_gdt_table is exclusively used for booting CPUs again. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Cc: Zachary Amsden <zach@vmware.com> Cc: Matt Tolentino <metolent@snoqualmie.dp.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-24[PATCH] voyager: fix the cpu_possible_map to make voyager boot againJames Bottomley1-0/+1
Right at the moment (thanks to a patch from Andrew), cpu_possible_map on voyager is CPU_MASK_NONE, which means the machine always thinks it has no CPUs. Fix that by doing an early initialisation of the cpu_possible_map from the cpu_phys_present_map. (akpm: we aim to please) Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-24[PATCH] voyager: fix boot panic by adding topology exportJames Bottomley1-0/+15
It looks like I can't get away without exporting topology functions from voyager any longer, so add them to the voyager subarchitecture. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-24[PATCH] Kprobes causes NX protection fault on i686 SMPPrasanna S Panchamukhi1-2/+14
Fix a problem seen on i686 machine with NX support where the instruction could not be single stepped because of NX bit set on the memory pages allocated by kprobes module. This patch provides allocation of instruction solt so that the processor can execute the instruction from that location similar to x86_64 architecture. Thanks to Bibo and Masami for testing this patch. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-20[PATCH] i386: need to pass virtual address to smp_read_mpc()Daniel Yeisley1-1/+1
I'm seeing a kernel panic on an ES7000-600 when booting in virtual wire mode. The panic happens because smp_read_mpc() is passed a physical address, and it should be virtual. I tested the attached patch on the ES7000-600 and on a 2 cpu Dell box, and saw no problems on either. Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-17[PATCH] x86_64: Add boot option to disable randomized mappings and cleanupAndi Kleen1-0/+1
AMD SimNow!'s JIT doesn't like them at all in the guest. For distribution installation it's easiest if it's a boot time option. Also I moved the variable to a more appropiate place and make it independent from sysctl And marked __read_mostly which it is. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-14[PATCH] x86: gitignore some autogenerated files for i386Thomas Meyer3-0/+5
Add some more gitignore files for i386 architecture. This files are created during the build process of a i386 kernel. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-14[PATCH] x86: document sysenter pathAlbert D. Cahalan1-0/+15
This path isn't obvious. It looks as if the kernel will be taking three args from the user stack, but it only takes one from there. Signed-off-by: Albert Cahalan <acahalan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-14[PATCH] x86: fix oprofile kernel callgraph regressionGerald Britton1-3/+16
Fix x86 oprofile regression introduced by: commit c34d1b4d165c67b966bca4aba026443d7ff161eb [PATCH] mm: kill check_user_page_readable That commit reorganized tests for the userspace stack walking moving all those tests into dump_backtrace(), however, dump_backtrace() was used for both userspace and kernel stalk walking. The result is typically no recorded callgraph information for kernel samples. Revive the original function as dump_kernel_backtrace() and rename the other to dump_user_backtrace() to avoid future confusion. Signed-off-by: Gerald Britton <gbritton@alum.mit.edu> Apology-from: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-13Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds1-0/+5
2006-02-11[PATCH] x86: print out early faults via early_printk()Ingo Molnar1-0/+4
Lost a few hours debugging an early-bootup fault within printk itself, which manifested itself as a hard to debug early hang. This patch makes it much easier by printing out early faults via early_printk(), which function is a lot simpler than a full printk, and hence more likely to succeed in emergencies. (We do not recover from early faults anyway, so there's no loss from not having these messages in the normal printk buffer.) Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-11[PATCH] fstatat64 supportUlrich Drepper1-1/+1
The *at patches introduced fstatat and, due to inusfficient research, I used the newfstat functions generally as the guideline. The result is that on 32-bit platforms we don't have all the information needed to implement fstatat64. This patch modifies the code to pass up 64-bit information if __ARCH_WANT_STAT64 is defined. I renamed the syscall entry point to make this clear. Other archs will continue to use the existing code. On x86-64 the compat code is implemented using a new sys32_ function. this is what is done for the other stat syscalls as well. This patch might break some other archs (those which define __ARCH_WANT_STAT64 and which already wired up the syscall). Yet others might need changes to accomodate the compatibility mode. I really don't want to do that work because all this stat handling is a mess (more so in glibc, but the kernel is also affected). It should be done by the arch maintainers. I'll provide some stand-alone test shortly. Those who are eager could compile glibc and run 'make check' (no installation needed). The patch below has been tested on x86 and x86-64. Signed-off-by: Ulrich Drepper <drepper@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-10[PATCH] x86: don't initialise cpu_possible_map to all onesAndrew Morton2-5/+1
Initialising cpu_possible_map to all-ones with CONFIG_HOTPLUG_CPU means that a) All for_each_cpu() loops will iterate across all NR_CPUS CPUs, rather than over possible ones. That can be quite expensive. b) Soon we'll be allocating per-cpu areas only for possible CPUs. So with CPU_MASK_ALL, we'll be wasting memory. I also switched voyager over to not use CPU_MASK_ALL in the non-CPU-hotplug case. Should be OK.. I note that parisc is also using CPU_MASK_ALL. Suggest that it stop doing that. Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Paul Jackson <pj@sgi.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Zwane Mwaikambo <zwane@linuxpower.ca> Cc: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-07[PATCH] unshare system call -v5: system call registration for i386JANAK DESAI1-0/+1
Registers system call for the i386 architecture. Signed-off-by: Janak Desai <janak@us.ibm.com> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Michael Kerrisk <mtk-manpages@gmx.net> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> 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-05[PATCH] i386: HIGHMEM64G must depend on X86_CMPXCHG64Adrian Bunk1-0/+1
Due to the usage of set_64bit in include/asm-i386/pgtable-3level.h, HIGHMEM64G must depend on X86_CMPXCHG64. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-05[PATCH] i386: print kernel version in register dumpsChuck Ebbert2-4/+8
Show first field of kernel version in register dumps like x86_64 does. Changes output from e.g.: (2.6.16-rc1) to: (2.6.16-rc1 #12) Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-05[PATCH] i386 cpu hotplug: don't access freed memoryChuck Ebbert9-3/+77
i386 CPU init code accesses freed init memory when booting a newly-started processor after CPU hotplug. The cpu_devs array is searched to find the vendor and it contains pointers to freed data. Fix that by: 1. Zeroing entries for freed vendor data after bootup. 2. Changing Transmeta, NSC and UMC to all __init[data]. 3. Printing a warning (once only) and setting this_cpu to a safe default when the vendor is not found. This does not change behavior for AMD systems. They were broken already but no error was reported. Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-05[PATCH] x86: fix stack trace facility levelHugh Dickins1-1/+2
dump_stack() on page allocation failure presently has an irritating habit of shouting just "====" at everyone: please stop it. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-05[PATCH] percpu data: only iterate over possible CPUsEric Dumazet1-1/+1
percpu_data blindly allocates bootmem memory to store NR_CPUS instances of cpudata, instead of allocating memory only for possible cpus. As a preparation for changing that, we need to convert various 0 -> NR_CPUS loops to use for_each_cpu(). (The above only applies to users of asm-generic/percpu.h. powerpc has gone it alone and is presently only allocating memory for present CPUs, so it's currently corrupting memory). Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@suse.de> Cc: Anton Blanchard <anton@samba.org> Acked-by: William Irwin <wli@holomorphy.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> 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-02-04[PATCH] x86_64: Dont record local apic ids when they are disabled in MADTAshok Raj1-3/+10
Some broken BIOS's had processors disabled, but same apic id as a valid processor. This causes acpi_processor_start() to think this disabled cpu is ok, and croak. So we dont record bad apicid's anymore. http://bugzilla.kernel.org/show_bug.cgi?id=5930 Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-03[PATCH] OProfile: fixed x86_64 incorrect kernel call graphsTong Li1-2/+17
Fix the problem in kernel 2.6.15.1 (and early versions) that OProfile on x86_64 does not correctly collect the stack traces for kernel functions. The original code in valid_kernel_stack() in arch/i386/oprofile/backtrace.c assumes that the frame pointer (headaddr) should be greater than stack (i.e., regs). This assumption is wrong for x86_64 because NMIs in x86_64 use a seperate stack different from the kernel stack. Therefore, the variable stack now points to some location on the NMI stack, which turns out to be at a higher address than the frame pointer (headaddr) on the kernel stack. The correct comparison here should be between headaddr and regs->rsp for x86_64. Signed-off-by: Tong Li <tong.n.li@intel.com> Cc: John Levon <levon@movementarian.org> Cc: Philippe Elie <phil.el@wanadoo.fr> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-02[CPUFREQ] Check for not initialized freq on cpufreq changesThomas Renninger1-0/+5
Test for old_freq equals 0 to insure not to divide by 0: ______________________________________________ Check for not initialized freq on cpufreq changes Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
2006-02-01Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6Linus Torvalds7-149/+83
2006-02-01[PATCH] VMSPLIT config optionsMark Lord1-0/+37
Enable selection of different user/kernel VM splits for i386, including an optimized mode for 1GB physical RAM, which gives the kernel a direct (non HIGHMEM) mapping to the entire 1GB rather than just the first 896MB. There is a similarly a similarly optimized mode for machines with exactly 2GB of physical RAM. This can speed up the kernel by avoiding having to create/destroy temporary HIGHMEM mappings, and by not having to include HIGHMEM support at all on such machines. The flip side is that there's less virtual addressing left for userspace in these alternatives, and some binary-only kernel modules may misbehave unless rebuilt with the same VMSPLIT option as the main kernel image. Original idea/patch from Jens Axboe, modified based on suggestions from Linus et al. Signed-off-by: Mark Lord <mlord@pobox.com> Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-01[PATCH] disable lost tick compensation before TSCs are syncedjohn stultz1-2/+12
Avoid lost tick compensation early in boot before the TSCs are synchronized. Currently timekeeping is enabled before the TSCs are synchronized, thus when the TSCs are synched (reset to zero), it appears that a number of lost ticks have occurred. This can cause premature expiry of timers and in extreme cases can cause the soft lockup detection to fire. This resolves issues reported by Andy Whitcroft as well as bug #5366 reported by Tim Mann. Signed-off-by: John Stultz <johnstul@us.ibm.com> Acked-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>