summaryrefslogtreecommitdiffstats
path: root/arch/i386
AgeCommit message (Collapse)Author
2005-05-31[CPUFREQ] Typos.Dave Jones
cpfureq developers cant spel. Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] longhaul - adjust transition latency.Dave Jones
From patch by: Ken Staton <ken_staton@agilent.com> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] Longhaul: Magic timer frobbing.Dave Jones
As mandated by the spec, disable timer around transitions. From code by : Ken Staton <ken_staton@agilent.com Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] longhaul - disable PCI mastering around transition.Dave Jones
The spec states that we have to do this, which is *horrid*. Based on code from: Ken Staton <ken_staton@agilent.com> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] dual-core powernow-k8Dave Jones
With the release of the dual-core AMD Opterons last week, it's high time that cpufreq supported them. The attached patch applies cleanly to 2.6.12-rc3 and updates powernow-k8 to support the latest Athlon 64 and Opteron processors. Update the driver to version 1.40.0 and provide support for dual-core processors. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] Recalibrate cpu_khz [2/2]Dave Jones
Some cpufreq drivers (at that time, only powernow-k7) need to recalibrate the cpu_khz at runtime. Signed-off-by: Bruno Ducrot <ducrot@poupinou.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] Recalibrate cpu_khz [1/2]Dave Jones
We have to recalibrate cpu_khz in order to use the current FID instead the max FID since some BIOS do not put the processor at maximum frequency at POST. Also, some BIOS will change the processor frequency at our back after cpu_khz was calibrate. Finally, this will fix a long standing bug when we do something like this: # rmmod powernow-k7 # modprobe powernow-k7 Signed-off-by: Bruno Ducrot <ducrot@poupinou.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] AMD Elan SC520 cpufreq driver.Dave Jones
From: Sean Young <sean@mess.org> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] speedstep-smi: it works on at least one P4MDave Jones
The speedstep-smi driver actually works on >=1 notebook with a Pentium 4-M CPU where all other cpufreq drivers fail. Therefore, allow speedstep-smi on P4Ms again, but warn users of likely failure Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] speedstep-centrino: Pentium 4 - M (HT) supportDave Jones
The Pentium 4 - Ms (HT) with CPUID 0xF34 and 0xF41 seem to support centrino-like enhanced speedstep; however, no "table" support is possible. Therefore, put NULL entries into speedstep-centrino.c Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] powernow-k7: don't print khz element of FSB.Dave Jones
Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[PATCH] acpi build fix: x86 setup.cAlexander Nyberg
This is a neverending story linux/acpi.h contains empty declarations for acpi_boot_init() & acpi_boot_table_init() but they are nested inside #ifdef CONFIG_ACPI. So we'll have to #ifdef in arch/i386/kernel/setup.c: setup_arch() Signed-off-by: Alexander Nyberg <alexn@telia.com> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28[PATCH] x86: fix smp_num_siblings on buggy BIOSesSiddha, Suresh B
This fixes 'smp_num_siblings' value on the systems with a buggy bios, which sets number of siblings to '2' even when HT is disabled. (more details are at http://bugzilla.kernel.org/show_bug.cgi?id=4359) I am planning to do more cleanup in this area (like moving smp_num_siblings to per cpuinfo) shortly. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28[PATCH] arch/i386/kernel/cpu/intel_cacheinfo.c: section fixAdrian Bunk
num_cache_leaves is used in __devexit cache_remove_dev() and can therefore not be __devinit. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-27[PATCH] Note on ACPI build fixAlexander Nyberg
Even after the previous fix you can still set CONFIG_ACPI_BOOT indirectly even without CONFIG_ACPI by choosing CONFIG_PCI and CONFIG_PCI_MMCONFIG. That doesn't build very well either. This makes PCI_MMCONFIG depend on ACPI, fixing that hole. [ I guess in theory Kconfig could follow the whole chain of dependencies for things that get selected, but that sounds insanely complicated, so we'll just fix up these things by hand. --Linus ] Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-27[PATCH] VIA IRQ quirkLen Brown
Delete quirk_via_bridge(), restore quirk_via_irqpic() -- but now improved to be invoked upon device ENABLE, and now only for VIA devices -- not all devices behind VIA bridges. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-24[PATCH] voyager_smp.c static inline fixDominik Hackl
This patch fixes a compile bug by moving a static inline function to the right place. The body of a static inline function has to be declared before the use of this function. Signed-off-by: Dominik Hackl <dominik@hackl.dhs.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-20[PATCH] x86_64: i386/x86-64: Export cpu_core_mapAndi Kleen
Needed for the powernow k8 driver for dual core support. Signed-off-by: Andi Kleen <ak@suse.de> Cc: <mark.langsdorf@amd.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-20[PATCH] i386: Fix race in iounmapAndi Kleen
We need to hold the vmlist_lock while doing change_page_attr, otherwise we could reset someone else's mapping. Requires previous patch to add __remove_vm_area 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-05-20[PATCH] x86_64: 386/x86-64 Further AMD dual core fixesAndi Kleen
- Remove duplicated ifdef - Make core_id match what Intel uses - Initialize phys_proc_id correctly for non DC case - Handle non power of two core numbers. Fixes for both i386 and x86-64 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-05-17[PATCH] fix memory scribble in arch/i386/pci/fixup.cChristoph Lameter
The GET_INDEX() macro should use just the low three bits of the devfn, otherwise we have a memory scribble in pcie_rootport_aspm_quirk that overwrites ptype_all Fix it to be more careful about its arguments while at it. Acked by Dely Sy <dely.l.sy@intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-17[PATCH] x86_64/i386: fix defaults for physical/core id in /proc/cpuinfoAndi Kleen
Last round hopefully of cpu_core_id changes hopefully fow now: - Always initialize cpu_core_id for all CPUs, even when no dual core setup is detected. This prevents funny /proc/cpuinfo output - Do the same with phys_proc_id[] even when no HyperThreading - dito. - Use the CPU APIC-ID from CPUID 1 instead of the linux virtual CPU number to identify the core for AMD dual core setups. Patch for i386/x86-64. 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-05-06Fix acpi_find_rsdp() - acpi_scan_rsdp takes length, not endLinus Torvalds
Noticed by Jakub Jermar <jermar@itbs.cz>
2005-05-05[PATCH] x86: geode support fixesKianusch Sayah Karadji
- Changed Name/defines from "Geode GX" to "Geode GX1" for clarification - Dropped "-march=i586" in favor of "-march=i486" - Dopped X86_OOSTORE support for Geode GX1 Signed-off-by: Kianusch Sayah Karadji <kianusch@sk-tech.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] CodingStyle: trivial whitespace fixupsDomen Puncer
When I do a "diff -Nur arch/i386 arch/x86_64" to see what is different between these two architectures, I see some differences due to whitespace issues only. The attached patch removes some of the noise by fixing up the following files: - arch/i386/boot/bootsect.S - arch/i386/boot/video.S - arch/x86_64/boot/bootsect.S Signed-off-by: Daniel Dickman <didickman@yahoo.com> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] cyrix: eliminate bad section referencesmaximilian attems
Fix cyrix section references: convert __initdata to __devinitdata. Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000379 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000399 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b3 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b9 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003bf R_386_32 .init.data Signed-of-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] Kprobes: Incorrect handling of probes on ret/lret instructionPrasanna S Panchamukhi
Kprobes could not handle the insertion of a probe on the ret/lret instruction and used to oops after single stepping since kprobes was modifying eip/rip incorrectly. Adjustment of eip/rip is not required after single stepping in case of ret/lret instruction, because eip/rip points to the correct location after execution of the ret/lret instruction. This patch fixes the above problem. 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>
2005-05-05[PATCH] x86_64: make string func definition work as intendedPaolo 'Blaisorblade' Giarrusso
In include/asm-x86_64/string.h there are such comments: /* Use C out of line version for memcmp */ #define memcmp __builtin_memcmp int memcmp(const void * cs,const void * ct,size_t count); This would mean that if the compiler does not decide to use __builtin_memcmp, it emits a call to memcmp to be satisfied by the C out-of-line version in lib/string.c. What happens is that after preprocessing, in lib/string.i you may find the definition of "__builtin_strcmp". Actually, by accident, in the object you will find the definition of strcmp and such (maybe a trick intended to redirect calls to __builtin_memcmp to the default memcmp when the definition is not expanded); however, this particular case is not a documented feature as far as I can see. Also, the EXPORT_SYMBOL does not work, so it's duplicated in the arch. I simply added some #undef to lib/string.c and removed the (now duplicated) exports in x86-64 and UML/x86_64 subarchs (the second ones are introduced by another patch I just posted for -mm). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> CC: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] x86 stack initialisation fixAlexander Nyberg
The recent change fix-crash-in-entrys-restore_all.patch childregs->esp = esp; p->thread.esp = (unsigned long) childregs; - p->thread.esp0 = (unsigned long) (childregs+1); + p->thread.esp0 = (unsigned long) (childregs+1) - 8; p->thread.eip = (unsigned long) ret_from_fork; introduces an inconsistency between esp and esp0 before the task is run the first time. esp0 is no longer the actual start of the stack, but 8 bytes off. This shows itself clearly in a scenario when a ptracer that is set to also ptrace eventual children traces program1 which then clones thread1. Now the ptracer wants to modify the registers of thread1. The x86 ptrace implementation bases it's knowledge about saved user-space registers upon p->thread.esp0. But this will be a few bytes off causing certain writes to the kernel stack to overwrite a saved kernel function address making the kernel when actually running thread1 jump out into user-space. Very spectacular. The testcase I've used is: /* start with strace -f ./a.out */ #include <pthread.h> #include <stdio.h> void *do_thread(void *p) { for (;;); } int main() { pthread_t one; pthread_create(&one, NULL, &do_thread, NULL); for (;;); return 0; } So, my solution is to instead of just adjusting esp0 that creates an inconsitent state I adjust where the user-space registers are saved with -8 bytes. This gives us the wanted extra bytes on the start of the stack and esp0 is now correct. This solves the issues I saw from the original testcase from Mateusz Berezecki and has survived testing here. I think this should go into -mm a round or two first however as there might be some cruft around depending on pt_regs lying on the start of the stack. That however would have broken with the first change too! It's actually a 2-line diff but I had to move the comment of why the -8 bytes are there a few lines up. Thanks to Zwane for helping me with this. Signed-off-by: Alexander Nyberg <alexn@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.gitDavid Woodhouse
2005-05-04[PATCH] ISA DMA Kconfig fixes - part 1Al Viro
A bunch of drivers use ISA DMA helpers or their equivalents for platforms that have ISA with different DMA controller (a lot of ARM boxen). Currently there is no way to put such dependency in Kconfig - CONFIG_ISA is not it (e.g. it is not set on platforms that have no ISA slots, but have on-board devices that pretend to be ISA ones). New symbol added - ISA_DMA_API. Set when we have functional enable_dma()/set_dma_mode()/etc. set of helpers. Next patches in the series will add missing dependencies for drivers that need them. I'm very carefully staying the hell out of the recurring flamefest on what exactly CONFIG_ISA would mean in ideal world - added symbol has a well-defined meaning and for now I really want to treat it as completely independent from the mess around CONFIG_ISA. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-03Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.gitDavid Woodhouse
2005-05-01[PATCH] make lots of things staticAdrian Bunk
Another large rollup of various patches from Adrian which make things static where they were needlessly exported. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] fbdev: edid.h cleanupsAdrian Bunk
This patch removes some completely unused code. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] convert that currently tests _NSIG directly to use valid_signal()Jesper Juhl
Convert most of the current code that uses _NSIG directly to instead use valid_signal(). This avoids gcc -W warnings and off-by-one errors. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] misc verify_area cleanupsJesper Juhl
There were still a few comments left refering to verify_area, and two functions, verify_area_skas & verify_area_tt that just wrap corresponding access_ok_skas & access_ok_tt functions, just like verify_area does for access_ok - deprecate those. There was also a few places that still used verify_area in commented-out code, fix those up to use access_ok. After applying this one there should not be anything left but finally removing verify_area completely, which will happen after a kernel release or two. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] Change synchronize_kernel to _rcu and _schedPaul E. McKenney
This patch changes calls to synchronize_kernel(), deprecated in the earlier "Deprecate synchronize_kernel, GPL replacement" patch to instead call the new synchronize_rcu() and synchronize_sched() APIs. Signed-off-by: Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] clean up kernel messagesMatt Mackall
Arrange for all kernel printks to be no-ops. Only available if CONFIG_EMBEDDED. This patch saves about 375k on my laptop config and nearly 100k on minimal configs. Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] uml: fix syscall table by including $(SUBARCH)'s one, for i386Paolo 'Blaisorblade' Giarrusso
Split the i386 entry.S files into entry.S and syscall_table.S which is included in the previous one (so actually there is no difference between them) and use the syscall_table.S in the UML build, instead of tracking by hand the syscall table changes (which is inherently error-prone). We must only insert the right #defines to inject the changes we need from the i386 syscall table (for instance some different function names); also, we don't implement some i386 syscalls, as ioperm(), nor some TLS-related ones (yet to provide). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] Linux 2.6.x VM86 interrupt emulation fixesPavel Pisa
Patch solves VM86 interrupt emulation deadlock on SMP systems. The VM86 interrupt emulation has been heavily tested and works well on UP systems after last update, but it seems to deadlock when we have used it on SMP/HT boxes now. It seems, that disable_irq() cannot be called from interrupts, because it waits until disabled interrupt handler finishes (/kernel/irq/manage.c:synchronize_irq():while(IRQ_INPROGRESS);). This blocks one CPU after another. Solved by use disable_irq_nosync. There is the second problem. If IRQ source is fast, it is possible, that interrupt is sometimes processed and re-enabled by the second CPU, before it is disabled by the first one, but negative IRQ disable depths are not allowed. The spinlocking and disabling IRQs over call to disable_irq_nosync/enable_irq is the only solution found reliable till now. Signed-off-by: Michal Sojka <sojkam1@control.felk.cvut.cz> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] Increase number of e820 entries hard limit from 32 to 128Venkatesh Pallipadi
The specifications that talk about E820 map doesn't have an upper limit on the number of e820 entries. But, today's kernel has a hard limit of 32. With increase in memory size, we are seeing the number of E820 entries reaching close to 32. Patch below bumps the number upto 128. The patch changes the location of EDDBUF in zero-page (as it comes after E820). As, EDDBUF is not used by boot loaders, this patch should not have any effect on bootloader-setup code interface. Patch covers both i386 and x86-64. Tested on: * grub booting bzImage * lilo booting bzImage with EDID info enabled * pxeboot of bzImage Side-effect: bss increases by ~ 2K and init.data increases by ~7.5K on all systems, due to increase in size of static arrays. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] cpuid x87 bit on AMD falsely marked as PNIZwane Mwaikambo
http://bugme.osdl.org/show_bug.cgi?id=4426 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP stepping : 0 cpu MHz : 2204.807 <snipped> cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow bogomips : 4358.14 We're marking bit 0 of extended function 0x80000001 cpuid as PNI support on AMD processors, when it actually denotes x87 FPU present. Patch for i386 and x86_64 below. Signed-off-by: Zwane Mwaikambo <zwane@arm.linux.org.uk> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] irq and pci_ids for Intel ICH7DH & ICH7-M DHJason Gaston
This patch adds the Intel ICH7DH and ICH7-M DH DID's to the irq.c and pci_ids.h files. Signed-off-by:  Jason Gaston <Jason.d.gaston@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] i386: fix hpet for systems that don't support legacy replacementjohn stultz
Currently the i386 HPET code assumes the entire HPET implementation from the spec is present. This breaks on boxes that do not implement the optional legacy timer replacement functionality portion of the spec. This patch, which is very similar to my x86-64 patch for the same issue, fixes the problem allowing i386 systems that cannot use the HPET for the timer interrupt and RTC to still use the HPET as a time source. I've tested this patch on a system systems without HPET, with HPET but without legacy timer replacement, as well as HPET with legacy timer replacement. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] Enable write combining for server works LE rev > 6Lee Revell
Enable write combining for server works LE rev > 6 per http://www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html Signed-Off-By: Lee Revell <rlrevell@joe-job.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] x86: entry.S trap return fixesStas Sergeev
do_debug() and do_int3() return void. This patch fixes the CONFIG_KPROBES variant of do_int3() to return void too and adjusts entry.S accordingly. Signed-off-by: Stas Sergeev <stsp@aknet.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] x86 reboot: Add reboot fixup for gx1/cs5530aJaya Kumar
This patch by Jaya Kumar introduces a generic infrastructure to deal with x86 chipsets with nonstandard reset sequences, and adds support for the Geode gx1/cs5530a chipset. Signed-off-by: Jaya Kumar <jayalk@intworks.biz> Signed-off-by: H. Peter Anvin <hpa@zytor.com> 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 Vogel
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-05-01[PATCH] i386/x86_64 segment register access updateH. J. Lu
The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. I am enclosing patches for 2.4 and 2.6 kernels here. The resulting kernel binaries should be unchanged as before, with old and new assemblers, if gcc never generates memory access for unsigned gsindex; asm volatile("movl %%gs,%0" : "=g" (gsindex)); If gcc does generate memory access for the code above, the upper bits in gsindex are undefined and the new assembler doesn't allow it. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-30[PATCH] kbuild/i386: re-introduce dependency on vmlinux for install target, ↵Sam Ravnborg
and add kernel_install Removing the dependency on vmlinux for the install target raised a few complaints, so instead a new target i added: kernel_install. kernel_install will install the kernel just like the ordinary install target. The only difference is that install has a dependency on vmlinux, kernel_install does not. Therefore kernel_install is the best choice when accessing the kernel over a NFS mount or as another user. kernel_install is similar to modules_install in the fact that neither does a full kernel compile before performing the install. In this way they are good for root use. Also added back the dependency on vmlinux for the install target so peoples scripts are no longer broken. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>