- Nov 27, 2007
-
-
Andreas Herrmann authored
x86: correctly set UTS_MACHINE for "make ARCH=x86" For a kernel built with "make ARCH=x86" the following system information is displayed when running the new kernel $ uname -m x86 On some i386 systems (e.g. K7) we even have the following information $ uname -m x66 This is weird. The usual information for "uname -m" should be "x86_64" on 64-bit and "i386" or "i686" on 32-bit. This patch fixes the issue by setting UTS_MACHINE to "i386" for 32-bit kernel builds and to "x86_64" for 64-bit kernel builds. I.e., "x86" won't be used for UTS_MACHINE anymore. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Andreas Herrmann <aherrman@arcor.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@redhat.com>
-
Peter Zijlstra authored
Ensure the hardirq state is consistent before using locks. Use the rare trace_hardirqs_fixup() because the trap can happen in any context. resolves this rare lockdep warning: WARNING: at kernel/lockdep.c:2658 check_flags() [<c013571e>] check_flags+0x90/0x140 [<c0138a69>] lock_release+0x4b/0x1d0 [<c0507fea>] notifier_call_chain+0x2a/0x47 [<c050806b>] __atomic_notifier_call_chain+0x64/0x6d [<c0508007>] __atomic_notifier_call_chain+0x0/0x6d [<c050808b>] atomic_notifier_call_chain+0x17/0x1a [<c0131802>] notify_die+0x30/0x34 [<c0506b09>] do_debug+0x3e/0xd4 [<c050658f>] debug_stack_correct+0x27/0x2c [<c04be389>] tcp_rcv_established+0x1/0x620 [<c04c38c2>] tcp_v4_do_rcv+0x2b/0x313 [<c04c56b6>] tcp_v4_rcv+0x467/0x85d [<c0505ff2>] _spin_lock_nested+0x27/0x32 [<c04c5a4d>] tcp_v4_rcv+0x7fe/0x85d [<c04c560e>] tcp_v4_rcv+0x3bf/0x85d [<c04adbb5>] ip_local_deliver_finish+0x11b/0x1b0 [<c04adac8>] ip_local_deliver_finish+0x2e/0x1b0 [<c04ada7b>] ip_rcv_finish+0x27b/0x29a [<c04961e5>] netif_receive_skb+0xfb/0x2a6 [<c04add0f>] ip_rcv+0x0/0x1fb [<c0496354>] netif_receive_skb+0x26a/0x2a6 [<c04961e5>] netif_receive_skb+0xfb/0x2a6 [<c049872e>] process_backlog+0x7f/0xc6 [<c04983ba>] net_rx_action+0xb9/0x1ac [<c0498348>] net_rx_action+0x47/0x1ac [<c01376cb>] trace_hardirqs_on+0x118/0x16b [<c01225e2>] __do_softirq+0x49/0xa2 [<c010595f>] do_softirq+0x60/0xdd [<c0506300>] _spin_unlock_irq+0x20/0x2c [<c0103e4f>] restore_nocheck+0x12/0x15 [<c01440e1>] handle_fasteoi_irq+0x0/0x9b [<c0105a70>] do_IRQ+0x94/0xaa [<c0506300>] _spin_unlock_irq+0x20/0x2c [<c0104832>] common_interrupt+0x2e/0x34 [<c0114703>] native_safe_halt+0x2/0x3 [<c0102c01>] default_idle+0x44/0x65 [<c010257f>] cpu_idle+0x42/0x50 [<c076ea09>] start_kernel+0x26b/0x270 [<c076e317>] unknown_bootoption+0x0/0x196 ======================= irq event stamp: 559190 hardirqs last enabled at (559190): [<c0507316>] kprobe_exceptions_notify+0x299/0x305 hardirqs last disabled at (559189): [<c05067bf>] do_int3+0x1d/0x95 softirqs last enabled at (559172): [<c010595f>] do_softirq+0x60/0xdd softirqs last disabled at (559181): [<c010595f>] do_softirq+0x60/0xdd Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Ingo Molnar authored
revert this commit for now: commit 94806268 Author: Andi Kleen <ak@suse.de> Date: Fri Oct 19 20:35:03 2007 +0200 x86: enable iommu_merge by default it's causing regressions: http://bugzilla.kernel.org/show_bug.cgi?id=9412 Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Arjan van de Ven authored
today, all oopses contain a version number of the kernel, which is nice because the people who actually do bother to read the oops get this vital bit of information always without having to ask the reporter in another round trip. However, WARN_ON() and many other dump_stack() users right now lack this information; the patch below adds this. This information is essential for getting people to use their time effectively when looking at these things; in addition, it's essential for tools that try to collect statistics about defects. Please consider, since its so simple and important for long term kernel quality processes. The code is identical between 32/64 bit; a lot of this code should be unified over time, the patch keeps the identical-ness intact. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Maciej W. Rozycki authored
More than 3 years ago Niclas Gustafsson reported a 'stopped time' problem: > Watching the /proc/interrupts with 10s apart after the "stop". > > [root@s151 root]# more /proc/interrupts > CPU0 > 0: 66413955 local-APIC-edge timer [...] > LOC: 67355837 > ERR: 0 > MIS: 0 > [root@s151 root]# more /proc/interrupts > CPU0 > 0: 66413955 local-APIC-edge timer [...] > LOC: 67379568 > ERR: 0 > MIS: 0 This may be because buggy SMM firmware messes with the 8259A (configured for a transparent mode -- yes that rare "local-APIC-edge" mode is tricky ;-) ) insanely. this should resolve: http://bugzilla.kernel.org/show_bug.cgi?id=2544 http://bugzilla.kernel.org/show_bug.cgi?id=6296 Patch-dusted-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Nov 18, 2007
-
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: - 0f855aa6 ("kconfig: add helper to set config symbol from environment variable") - 2a113281 ("kconfig: use $K64BIT to set 64BIT with all*config targets") Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: 0f855aa6 -> kconfig: add helper to set config symbol from environment variable 2a113281 -> kconfig: use $K64BIT to set 64BIT with all*config targets Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
- Nov 17, 2007
-
-
Denys authored
Needed to make the wireless board, WRAP2C reboot. Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Yinghai Lu authored
need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so info->bus->resource[info->res_num] = res will not beyond of bus resource array when acpi returns too many resource entries. Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Gary Hade <gary.hade@us.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
Some BIOSes advertise HPET at 0x0. We really do no want to allocate a resource there. Check for it and leave early. Other BIOSes tell us the HPET is at 0xfed0000000000000 instead of 0xfed00000. Add a check and fix it up with a warning on user request. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
David P. Reed authored
Correct potentially unstable PC RTC time register reading in time_64.c Stop the use of an incorrect technique for reading the standard PC RTC timer, which is documented to "disconnect" time registers from the bus while updates are in progress. The use of UIP flag while interrupts are disabled to protect a 244 microsecond window is one of the Motorola spec sheet's documented ways to read the RTC time registers reliably. tglx: removed locking changes from original patch, as they gain nothing (read_persistent_clock is only called during boot, suspend, resume - so no hot path affected) and conflict with the paravirt locking scheme (see 32bit code), which we do not want to complicate for no benefit. Signed-off-by:
David P. Reed <dpreed@reed.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
David P. Reed authored
Fix hard freeze on x86_64 when the ntpd service calls update_persistent_clock() A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion dv9000z laptop. This freeze is due to the use of spin_lock(&rtc_lock) under the assumption (per a bad comment) that set_rtc_mmss is called only with interrupts disabled. The call from ntp.c to update_persistent_clock is made with interrupts enabled. Signed-off-by:
David P. Reed <dpreed@reed.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
92cb7612 sets cpu_info->cpu_index to zero for no reason. Referencing cpu_info->cpu_index now points always to CPU#0, which is apparently not what we want. Remove it. Spotted-by:
Zou Nan hai <nanhai.zou@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andreas Herrmann authored
Fix regressions introduced with 92cb7612 . It can happen that cpuinfo is displayed for CPUs that are not online or even worse for CPUs not present at all. As an example, following was shown for a "second" CPU of a single core K8 variant: processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : unknown stepping : 0 cache size : 0 KB fpu : yes fpu_exception : yes cpuid level : 0 wp : yes flags : bogomips : 0.00 clflush size : 0 cache_alignment : 0 address sizes : 0 bits physical, 0 bits virtual power management: Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andreas Herrmann authored
Commit d435d862 ("cpu hotplug: mce: fix cpu hotplug error handling") changed the error handling in mce_cpu_callback. In cases where not all CPUs are brought up during boot (e.g. using maxcpus and additional_cpus parameters) mce_cpu_callback now returns NOTFIY_BAD because for such CPUs cpu_data is not completely filled when the notifier is called. Thus mce_create_device fails right at its beginning: if (!mce_available(&cpu_data[cpu])) return -EIO; As a quick fix I suggest to check boot_cpu_data for MCE. To reproduce this regression: (1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system (2) # echo 1 >/sys/devices/system/cpu/cpu2/online -bash: echo: write error: Invalid argument dmesg shows: _cpu_up: attempt to bring up CPU 2 failed Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Ingo Molnar authored
dont use the vgetcpu tcache - it's causing problems with tasks migrating, they'll see the old cache up to a jiffy after the migration, further increasing the costs of the migration. In the worst case they see a complete bogus information from the tcache, when a sys_getcpu() call "invalidated" the cache info by incrementing the jiffies _and_ the cpuid info in the cache and the following vdso_getcpu() call happens after vdso_jiffies have been incremented. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Randy Dunlap authored
Fix Voyager section mismatch due to using __devinit instead of __cpuinit. WARNING: vmlinux.o(.text+0xd943): Section mismatch: reference to .init.text:init_gdt (between 'voyager_smp_prepare_boot_cpu' and 'smp_vic_cmn_interrupt') Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Randy Dunlap authored
Fix Voyager section mismatches: voyager_cat_init() should be __init. WARNING: vmlinux.o(.text+0xee83): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeea6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeac): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeb2): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef4c): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef56): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf10f): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf13b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf14b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf159): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1b1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1bb): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c7): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1e6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- Nov 15, 2007
-
-
Andreas Herrmann authored
Fix regression introduced with d435d862 ("cpu hotplug: mce: fix cpu hotplug error handling"). A CPU which was not brought up during boot (using maxcpus and additional_cpus parameters) couldn't be onlined anymore. For such a CPU it seemed that MCE was not supported during CPU_UP_PREPARE-time which caused mce_cpu_callback to return NOTIFY_BAD to notifier_call_chain. To fix this we: - call mce_create_device for CPU_ONLINE event (instead of CPU_UP_PREPARE), - avoid mce_remove_device() for the CPU that is not correctly initialized by mce_create_device() failure, - make mce_cpu_callback always return NOTIFY_OK for CPU_ONLINE event. Because CPU_ONLINE callback return value is always ignored. [akinobu.mita@gmail.com: avoid mce_remove_device() for not initialized device] [akinobu.mita@gmail.com: make mce_cpu_callback always return NOTIFY_OK] Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Andrew Morton authored
Marin Mitov points out that delay_tsc() can misbehave if it is preempted and rescheduled on a different CPU which has a skewed TSC. Fix it by disabling preemption. (I assume that the worst-case behaviour here is a stall of 2^32 cycles) Cc: Andi Kleen <ak@suse.de> Cc: Marin Mitov <mitov@issp.bas.bg> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 13, 2007
-
-
Sam Ravnborg authored
After unification of the Kconfig files and introducing K64BIT support in kconfig it required only trivial changes to enable "make ARCH=x86". With this patch you can build for x86_64 in several ways: 1) make ARCH=x86_64 2) make ARCH=x86 K64BIT=y 3) make ARCH=x86 menuconfig => select 64-bit Likewise for i386 with the addition that i386 is default is you say ARCH=x86. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
For x86 ARCH may say i386 or x86_64 and soon x86. Rely on CONFIG_X64_32 to select between 32/64 or just hardcode the value as appropriate. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
With this patch we have all the Kconfig file shared between i386 and x86_64. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
Most of the arch settings were equal so combine them in the first part of Kconfig. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
No functional changes. A prepatory step towards full unification. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
To ease unification of Kconfig.i386 and Kconfig.x86_64 add X86_64 dependencies to all x86_64 specific symbols. This patch introduce no functional changes but is one step towards unification. This smaller step is used to ease review of the patch set. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
To ease unification of Kconfig.i386 and Kconfig.x86_64 add X86_32 dependencies to all i386 specific symbols. This patch introduce no functional changes but is one step towards unification. This smaller step is used to ease review of the patch set. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
Move all CPU definitions to Kconfig.cpu Always define X86_MINIMUM_CPU_FAMILY and do the obvious code cleanup in boot/cpucheck.c Comments from: Adrian Bunk <bunk@kernel.org> incorporated. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@kernel.org> Cc: Brian Gerst <bgerst@didntduck.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
This step introduces the file arch/x86/Kconfig which contains all the menu's from "Power Management" and below. The main part of the new Kconfig file is shared and the remaining i386/x86_64 specific symbols are covered by dependencies. A x86_64 allmodconfig build did not show any differences. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
-
Sam Ravnborg authored
Merge the two Kconfig files to a single file. Checked using make allmodconfig for x86_64. No changes in build. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk>
-
Siddha, Suresh B authored
restore sigcontext is taking a DNA exception while restoring FP context from the user stack, during the sigreturn. Appended patch fixes it by doing clts() if the app doesn't touch FP during the signal handler execution. This will stop generating a DNA, during the fxrstor in the sigreturn. This improves 64-bit lat_sig numbers by ~30% on my core2 platform. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 10, 2007
-
-
Chuck Ebbert authored
[ jdike - Pushing Chuck's patch - see http://lkml.org/lkml/2005/9/16/261 for some history and a test program. UML is also broken without this patch - its processes get SIGBUS from the corrupt 6th argument to mmap being interpretted as a file offset ] When the 32-bit vDSO is used to make a system call, the %ebp register for the 6th syscall arg has to be loaded from the user stack (where it's pushed by the vDSO user code). The native i386 kernel always does this before stopping for syscall tracing, so %ebp can be seen and modified via ptrace to access the 6th syscall argument. The x86-64 kernel fails to do this, presenting the stack address to ptrace instead. This makes the %rbp value seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a 32-bit caller of ptrace, both differ from the native i386 behavior. This patch fixes the problem by putting the word loaded from the user stack into %rbp before calling syscall_trace_enter, and reloading the 6th syscall argument from there afterwards (so ptrace can change it). This makes the behavior match that of i386 kernels. Original-Patch-By:
Roland McGrath <roland@redhat.com> Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Roland McGrath authored
The addr argument to PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA is not a magic constant. It's derived from the segment register values being used, which are computed originally from the index used with set_thread_area. The value does not need to match what a native i386 kernel would accept. It needs to match the segment selectors that can actually be in use in this 32-bit process. The 64-bit ptrace support for PTRACE_GET_THREAD_AREA (normally used only on 32-bit processes) is correct, but the 32-bit emulation of ptrace is broken. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Ingo Molnar authored
nmi_cpu_busy() must be available on !SMP too. this is in preparation to a smp_call_function_mask() fix. Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
prepare for up_smp_call_function() to ensure that the 'func' pointer is unused. (which is related to a KVM build fix) Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- Nov 05, 2007
-
-
Rusty Russell authored
After Adrian Bunk's "make async_hcall static" moved things around, update comments to match (aka "make Guest"). Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
Adrian Bunk authored
async_hcall() can become static. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
H. Peter Anvin authored
In accordance with the newly formalized 32-bit boot protocol, set %ebx == %ebp == %edi == 0 in order to support future extensions to the protocol. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
H. Peter Anvin authored
The 386 and 486 needs a jump immediately after setting %cr0 in order to serialize the pipeline. Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
- Oct 30, 2007
-
-
Andi Kleen authored
No reason I can think of of making them default y Most people don't have the hardware and with default y they just pollute lots of configs during make oldconfig. Signed-off-by:
Andi Kleen <ak@suse.de> Acked-by:
Jeff Garzik <jeff@garzik.org> Acked-by:
"Nelson, Shannon" <shannon.nelson@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-