With CPU_HOTPLUG=n:
WARNING: vmlinux.o(.text+0x104f8): Section mismatch: reference to .init.text:fork_idle (between
'do_fork_idle' and 'lapic_timer_broadcast')
do_fork_idle() needs to be __cpuinit. It can be static as well.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
After 17d57a9206 ("x86: fix x86-32 early
fixmap initialization.") removing lg.ko caused a printk from vunmap:
mm/memory.c:115: bad pgd 004b3027.
On the second use after module load, the kernel crashes.
This fixes the immediate problem (accessed and dirty bits not set as
expected in pmd_none_or_clear_bad). I can't see why this would cause
a crash, but I haven't been able to reproduce it once this is applied.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit fbdcf18df7.
As pointed out by Yanmin Zhang, the problem was already fixed
differently (and correctly), and rather than fix anything, it actually
causes us to create a sub-optimal sched-domains hierarchy (not setting
up the domain belonging to the core) when CONFIG_X86_HT=y.
Requested-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch adds a cpu cache info entry for the Intel Tolapai cpu.
Signed-off-by: Jason Gaston <jason.d.gaston@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Andrew "Eagle Eye" Morton noticed that we use raw_local_save_flags()
instead of raw_local_irq_save(flags) in die(). This allows the
preemption of oopsing contexts - which is highly undesirable. It also
causes CONFIG_DEBUG_PREEMPT to complain, as reported by Miles Lane.
this bug was introduced via:
commit 39743c9ef7
Author: Andi Kleen <ak@suse.de>
Date: Fri Oct 19 20:35:03 2007 +0200
x86: use raw locks during oopses
- spin_lock_irqsave(&die.lock, flags);
+ __raw_spin_lock(&die.lock);
+ raw_local_save_flags(flags);
that is not a correct open-coding of spin_lock_irqsave(): both the
ordering is wrong (irqs should be disabled _first_), and the wrong
flags-saving API was used.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
when called by setup_arch) after smp_store_cpu_info() had set it to the
correct value.
The error shows up in 'cat /proc/cpuinfo' will all cpus = 0.
Signed-off-by: Mike Travis <travis@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: Suresh B Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
this is the tale of a full day spent debugging an ancient but elusive bug.
after booting up thousands of random .config kernels, i finally happened
to generate a .config that produced the following rare bootup failure
on 32-bit x86:
| ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
| ..MP-BIOS bug: 8254 timer not connected to IO-APIC
| ...trying to set up timer (IRQ0) through the 8259A ... failed.
| ...trying to set up timer as Virtual Wire IRQ... failed.
| ...trying to set up timer as ExtINT IRQ... failed :(.
| Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug
| and send a report. Then try booting with the 'noapic' option
this bug has been reported many times during the years, but it was never
reproduced nor fixed.
the bug that i hit was extremely sensitive to .config details.
First i did a .config-bisection - suspecting some .config detail.
That led to CONFIG_X86_MCE: enabling X86_MCE magically made the bug disappear
and the system would boot up just fine.
Debugging my way through the MCE code ended up identifying two unlikely
candidates: the thing that made a real difference to the hang was that
X86_MCE did two printks:
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
Adding the same printks to a !CONFIG_X86_MCE kernel made the bug go away!
this left timing as the main suspect: i experimented with adding various
udelay()s to the arch/x86/kernel/io_apic_32.c:check_timer() function, and
the race window turned out to be narrower than 30 microseconds (!).
That made debugging especially funny, debugging without having printk
ability before the bug hits is ... interesting ;-)
eventually i started suspecting IRQ activities - those are pretty much the
only thing that happen this early during bootup and have the timescale of
a few dozen microseconds. Also, check_timer() changes the IRQ hardware
in various creative ways, so the main candidate became IRQ0 interaction.
i've added a counter to track timer irqs (on which core they arrived, at
what exact time, etc.) and found that no timer IRQ would arrive after the
bug condition hits - even if we re-enable IRQ0 and re-initialize the i8259A,
but that we'd get a small number of timer irqs right around the time when we
call the check_timer() function.
Eventually i got the following backtrace triggered from debug code in the
timer interrupt:
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ...
Pid: 1, comm: swapper Not tainted (2.6.24-rc5 #57)
EIP: 0060:[<c044d57e>] EFLAGS: 00000246 CPU: 0
EIP is at _spin_unlock_irqrestore+0x5/0x1c
EAX: c0634178 EBX: 00000000 ECX: c4947d63 EDX: 00000246
ESI: 00000002 EDI: 00010031 EBP: c04e0f2e ESP: f7c41df4
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: ffe04000 CR3: 00630000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
[<c05f5784>] setup_IO_APIC+0x9c3/0xc5c
the spin_unlock() was called from init_8259A(). Wait ... we have an IRQ0
entry while we are in the middle of setting up the local APIC, the i8259A
and the PIT??
That is certainly not how it's supposed to work! check_timer() was supposed
to be called with irqs turned off - but this eroded away sometime in the
past. This code would still work most of the time because this code runs
very quickly, but just the right timing conditions are present and IRQ0
hits in this small, ~30 usecs window, timer irqs stop and the system does
not boot up. Also, given how early this is during bootup, the hang is
very deterministic - but it would only occur on certain machines (and
certain configs).
The fix was quite simple: disable/restore interrupts properly in this
function. With that in place the test-system now boots up just fine.
(64-bit x86 io_apic_64.c had the same bug.)
Phew! One down, only 1500 other kernel bugs are left ;-)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Kprobes for x86-64 may cause a kernel crash if it inserted on "iret"
instruction. "call absolute" is invalid on x86-64, so we don't need
treat it.
- Change the processing order as same as x86-32.
- Add "iret"(0xcf) case.
- Remove next_rip local variable.
Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
jprobe for x86-64 may cause kernel page fault when the jprobe_return()
is called from incorrect function.
- Use jprobe_saved_regs instead getting it from stack.
(Especially on x86-64, it may get incorrect data, because
pt_regs can not be get by using container_of(rsp))
- Change the type of stack pointer to unsigned long *.
Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Revert commit efa4d2fb04 ("Hibernation:
Use temporary page tables for kernel text mapping on x86_64") because it
causes my t61p to reboot right at the end of resume-from-disk. For
reasons unknown at this time.
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Old debugging hack sneaked back during x86 merge, this removes it.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
fix this on i386 allnoconfig:
WARNING: vmlinux.o(.text+0x6f2e): Section mismatch: reference to .init.text:register_cpu (between 'arch_register_cpu' and 'text_poke')
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
free_cache_attributes() must be __cpuinit since it calls the
__cpuinit cache_remove_shared_cpu_map().
This patch fixes the following section mismatch reported by
Chris Clayton:
...
WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to .init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' and 'show_level')
...
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Our automated test suite looks for keywords like error, fail, warning in
the boot log. In the case when the nmi watchdog is determined to be
stuck in check_nmi_watchdog(), none of those keywords are displayed.
This patch adds a keyword, "WARNING:", so it makes it easier to notice
when the nmi watchdog isn't working correctly. Also add a proper
KERN_WARNING mark to this printout.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
pageexec@freemail.hu writes:
> i've just noticed that the chunk in i386/kernel/head.S ended up in a
> weird place, namely, it's not going to be executed as it's just after
> a 'jmp 3f' and before startup_32_smp, probably not what you intended.
> on a sidenote, the whole thing can be done in a single insn, like:
>
> movl $(swapper_pg_pmd - __PAGE_OFFSET + 0x067), (swapper_pg_dir -
> __PAGE_OFFSET+ 4092)
Thanks for the reminder I thought we had fixed this problem a while ago.
Needed to get fixed virtual address for USB debug and earlycon with mmio.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
we should also add hpet_disable() for kdump.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If HPET was enabled by pci quirks, we use i8253 as initial clockevent
because pci quirks doesn't run until pci is initialized.
The above means the kernel (or something) is assuming HPET legacy
replacement is disabled and can use i8253 at boot.
If we used kexec, it isn't true. So, this patch disables HPET legacy
replacement for kexec in machine_shutdown().
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores the
old behaviour, and makes it consistent with the non-CONFIG_PARAVIRT case.
Takashi Iwai <tiwai@suse.de> adds:
> I took at this problem (as I have an nvidia card on one of my
> workstations), and found out that the following suffer from
> EXPORT_SYMBOL_GPL changes:
>
> * local_disable_irq(), local_irq_save*(), etc.
> * MSR-related macros like rdmsr(), wrmsr(), read_cr0(), etc.
> wbinvd(), too.
> * pmd_val(), pgd_val(), etc are all involved with pv_mm_ops.
> pmd_large() and pmd_bad() is also indirectly involved.
> __flush_tlb() and friends suffer, too.
Christoph Hellwig objects to this patch on the grounds that modules
shouldn't be using these operations anyway. I don't think this is a
particularly good reason to reject the patch, for several reasons:
1. These operations are still available to modules when not using
CONFIG_PARAVIRT, since they are implicitly exported as inline
functions via the kernel headers. Exporting the same functionality as
GPL-only symbols just adds a gratuitious difference between
CONFIG_PARAVIRT and non-CONFIG_PARAVIRT configurations. If we really
think these operations are not for module use (or non-GPL module use),
then we should solve the problem in a general way.
2. It's a regression from previous kernels, which would work these
modules even with CONFIG_PARAVIRT enabled.
3. The operations in question seem pretty reasonable for modules to
use. The control registers/MSRs can be accessed directly anyway, so there's
no benefit in preventing modules from using standard interfaces. And it seems
reasonable to allow a graphics driver to create its own mappings if it wants.
Therefore, I think this patch should go in for 2.6.24. If people
really think that these operations should not be available to modules,
then we can address that separately.
Signed-off-by: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: Tobias Powalowski <t.powa@gmx.de>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
x86: fix APIC related bootup crash on Athlon XP CPUs
time: add ADJ_OFFSET_SS_READ
x86: export the symbol empty_zero_page on the 32-bit x86 architecture
x86: fix kprobes_64.c inlining borkage
pci: use pci=bfsort for HP DL385 G2, DL585 G2
x86: correctly set UTS_MACHINE for "make ARCH=x86"
lockdep: annotate do_debug() trap handler
x86: turn off iommu merge by default
x86: fix ACPI compile for LOCAL_APIC=n
x86: printk kernel version in WARN_ON and other dump_stack users
ACPI: Set max_cstate to 1 for early Opterons.
x86: fix NMI watchdog & 'stopped time' problem
warmbloodedcreature@gmail.com reported that an APIC-enabled
Asus a7v8x-x with an Athlon XP reboots early in the bootup:
http://bugzilla.kernel.org/show_bug.cgi?id=8723
after a long marathon of spontaneous-reboot debugging, it turns
out to be caused by sync_Arb_ids(). AMD CPUs never really needed
this sequence anyway, so just return early if we meet an AMD CPU.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The latest KVM driver wants to use the empty_zero_page symbol, and it's
not exported in 32-bit x86 (although it is exported by x86_64, s390, and
uml architectures).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: tglx@linutronix.de
Cc: linux-kernel@vger.kernel.com
Cc: kvm-devel@lists.sourceforge.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
fix:
arch/x86/kernel/kprobes_64.c: In function 'set_current_kprobe':
arch/x86/kernel/kprobes_64.c:152: sorry, unimplemented: inlining failed in call to 'is_IF_modifier': recursive inlining
arch/x86/kernel/kprobes_64.c:166: sorry, unimplemented: called from here
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@elte.hu
Cc: akpm@linux-foundation.org
Cc: tglx@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
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>
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=2544http://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>
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>
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>
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>
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>
92cb7612ae 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>
Fix regressions introduced with 92cb7612ae.
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>
Commit d435d862ba
("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>
Add throttling control via MSR when T-states uses
the FixHW Control Status registers.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86:
x86: enable "make ARCH=x86"
x86: do not use $(ARCH) when not needed
kconfig: use $K64BIT to set 64BIT with all*config targets
kconfig: add helper to set config symbol from environment variable
kconfig: factor out code in confdata.c
x86: move the rest of the menu's to Kconfig
x86: move all simple arch settings to Kconfig
x86: copy x86_64 specific Kconfig symbols to Kconfig.i386
x86: add X86_64 dependency to x86_64 specific symbols in Kconfig.x86_64
x86: add X86_32 dependency to i386 specific symbols in Kconfig.i386
x86: arch/x86/Kconfig.cpu unification
x86: start unification of arch/x86/Kconfig.*
x86: unification of cfufreq/Kconfig
Fix regression introduced with d435d862ba
("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>
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>
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>
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>
Thomas Gleixner