- 26 Apr, 2008 15 commits
-
-
Akinobu Mita authored
memset and NULL check after alloc_bootmem() are unnecessary. Because it returns zeroed memory and it never return NULL. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Akinobu Mita authored
Use bitmap library for pin_programmed rather than reinvent bitmaps. Signed-off-by:
-
Akinobu Mita authored
Remove duplicate code by using MP_intsrc_info() in mpparse.c Signed-off-by:
-
Akinobu Mita authored
Use BUILD_BUG_ON() instead of compile-time error technique with extern non-exsistent function. Signed-off-by:
-
Roland McGrath authored
Now that there are no more special cases in sys32_ptrace, we can convert to using the generic compat_sys_ptrace entry point. The sys32_ptrace function gets simpler and becomes compat_arch_ptrace. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Roland McGrath authored
This removes the special-case handling for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO from x86_64's sys32_ptrace. The generic compat_ptrace_request code handles these. Signed-off-by:
-
Roland McGrath authored
This lifts the set_fs(USER_DS) call for signal handler setup out of the three places copying the same code into the one place that calls them all. There is no change in what it does. Signed-off-by:
-
Roland McGrath authored
This lifts the code diddling the TF and DF bits for signal handler setup out of the several places copying the same code into the one place that calls them all. There is no change in what it does. I also separated the recently-added DF bit clearing from the TF diddling. The compiler turns them back into one instruction anyway. The tossing in of DF to the same line of code with no new comments was a bit more arcane than seems wise. Signed-off-by:
-
Dmitri Vorobiev authored
It is claimed that NexGen CPUs were never shipped: http://lkml.org/lkml/2008/4/20/179 Also, the kernel support for these chips has been broken for a long time, the code intended to support NexGen thereby being essentially dead. As an outcome of the discussion that can be found using the URL above, this patch removes the NexGen support altogether. The changes in this patch survived a defconfig build for i386, a couple of successful randconfig builds, as well as a runtime test, which consisted in booting a 32-bit x86 box up to the shell prompt. Signed-off-by:
Dmitri Vorobiev <dmitri.vorobiev@gmail.com> Signed-off-by:
-
Dmitri Vorobiev authored
In arch/x86/kernel/setup_64.c, the standard_io_resources array is needlessly defined as global. This patch makes this variable static. This patch was successfully build-tested using the defconfig for x86_64. Runtime test was performed by booting a 64-bit x86 box up to the shell prompt. Signed-off-by:
-
Dmitri Vorobiev authored
There are no users for the function amd_init_cpu() defined in arch/x86/kernel/cpu/amd.c. This patch removes this routine. This patch was build-tested using defconfigs for i386 and x86_64, and a few randconfig instances. Runtime tests were performed by booting 32- and 64-bit x86 boxen up to the shell prompt. Signed-off-by:
-
Jan Beulich authored
At least on my Barcelona, I see MCE log entries after cold boot caused by BIOS not properly clearing the respective registers. Therefore, this patch extends the workaround to families 0x10 and 0x11 (the latter just for completeness, I have nothing to verify this against). At the same time, provide a way to make these entries visible via the 'mce=bootlog' command line option even on these machines. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Jan Beulich authored
.. since it uses ILL_BADSTK (which is meaningless in the context of SIGSEGV). Signed-off-by:
-
Jan Beulich authored
There apparently was an unnoticed conflict between an earlier patch to this file and mine (d1e08474 ), which I noticed only now. I suppose a change like the one below (untested) is needed; I didn't get any response on a confirmation request for this from the submitter of the first patch. The issue is the writing of the 'checkbit' member at the end of setup_intel_arch_watchdog(), which my patch made go to intel_arch_wd_ops rather than wd_ops. Signed-off-by:
-
Jan Beulich authored
Two prior changes resulted in the "ecx" clobber being lost. Signed-off-by:
-
- 25 Apr, 2008 8 commits
-
-
Matthew Wilcox authored
Add some autogenerated files to various .gitignore files Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Ingo Molnar authored
Signed-off-by: -
Mathieu Desnoyers authored
Clean up the codepath, remove alignment restrictions and do sanity checking of the end result, to make sure we patched the right site. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by:
-
Jiri Slaby authored
kernel_text_address returns true even for modules which is not wanted in text_poke. Use core_kernel_text instead. This is a regression introduced in e587cadd which caused occasionaly crashes after suspend/resume. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> CC: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Andi Kleen <andi@firstfloor.org> CC: pageexec@freemail.hu CC: H. Peter Anvin <hpa@zytor.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Ingo Molnar authored
set_fixmap()+clear_fixmap() is safe. Signed-off-by: -
Ingo Molnar authored
Signed-off-by: -
David S. Miller authored
Otherwise all sorts of bad things can happen, including spurious softlockup reports. Other platforms have this same bug, in one form or another, just don't see the issue because they don't sleep as long as sparc64 can in NOHZ. Thanks to some brilliant debugging by Peter Zijlstra. Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Second and third arguments were swapped for whatever reason. Reported by Tom Callaway. Signed-off-by:
-
- 24 Apr, 2008 17 commits
-
-
Kumar Gala authored
Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Jeremy Fitzhardinge authored
There's no real reason we can't support sparsemem/discontigmem, so do so. This is mostly useful to support hotplug memory. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Jeremy Fitzhardinge authored
xen_sysexit and xen_iret were doing essentially the same thing. Rather than having a separate implementation for xen_sysexit, we can just strip the stack back to an iret frame and jump into xen_iret. This removes a lot of code and complexity - specifically, another critical region. Signed-off-by:
-
Jeremy Fitzhardinge authored
The usual pagetable locking protocol doesn't seem to apply to updates to init_mm, so don't rely on preemption being disabled in xen_set_pte_at on init_mm. Signed-off-by:
-
Jeremy Fitzhardinge authored
Various places in the kernel flush the tlb even though preemption doens't guarantee the tlb flush is happening on any particular CPU. In many cases this doesn't seem to matter, so don't make a fuss about it. Signed-off-by:
-
Isaku Yamahata authored
split out x86 specific part from grant-table.c and allow ia64/xen specific initialization. ia64/xen grant table is based on pseudo physical address (guest physical address) unlike x86/xen. On ia64 init_mm doesn't map identity straight mapped area. ia64/xen specific grant table initialization is necessary. Signed-off-by:
Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by:
-
Isaku Yamahata authored
move arch/x86/xen/events.c undedr drivers/xen to share codes with x86 and ia64. And minor adjustment to compile. ia64/xen also uses events.c Signed-off-by:
Yaozu (Eddie) Dong <eddie.dong@intel.com> Signed-off-by:
-
Isaku Yamahata authored
ia64/xen also uses it too. Move it into common place so that ia64/xen can share the code. Signed-off-by:
-
Jeremy Fitzhardinge authored
Use jmp rather than call for the iret fixup, so its consistent with the sysexit fixup, and it simplifies the stack (which is already complex). Signed-off-by:
-
Jeremy Fitzhardinge authored
Mask MCE/MCA out of cpu caps. Its harmless to leave them there, but it does prevent the kernel from starting an unnecessary thread. Signed-off-by:
-
Jeremy Fitzhardinge authored
If an event comes in while events are currently being processed, then just increment the counter and have the outer event loop reprocess the pending events. This prevents unbounded recursion on heavy event loads (of course massive event storms will cause infinite loops). Signed-off-by:
-
Jeremy Fitzhardinge authored
retrigger_dynirq() was incomplete, and didn't properly set the event to be pending again. It doesn't seem to actually get used. Signed-off-by:
-
Jeremy Fitzhardinge authored
Xen supports the notion of a debug interrupt which can be triggered from the console. For now this is implemented to show pending events, masks and each CPU's pending event set. Signed-off-by:
-
Jeremy Fitzhardinge authored
64-bit Xen supports sysenter for 32-bit guests, so support its use. (sysenter is faster than int $0x80 in 32-on-64.) sysexit is still not supported, so we fake it up using iret. Signed-off-by:
-
Jeremy Fitzhardinge authored
All pagetables need fundamentally the same setup and destruction, so just use the same code for everything. Signed-off-by:
-
Jeremy Fitzhardinge authored
Make KERNEL_PGD_PTRS common, as previously it was only being defined for 32-bit. There are a couple of follow-on changes from this: - KERNEL_PGD_PTRS was being defined in terms of USER_PGD_PTRS. The definition of USER_PGD_PTRS doesn't really make much sense on x86-64, since it can have two different user address-space configurations. I renamed USER_PGD_PTRS to KERNEL_PGD_BOUNDARY, which is meaningful for all of 32/32, 32/64 and 64/64 process configurations. - USER_PTRS_PER_PGD was also defined and was being used for similar purposes. Converting its users to KERNEL_PGD_BOUNDARY left it completely unused, and so I removed it. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
