- 26 9月, 2006 40 次提交
-
-
由 Andi Kleen 提交于
This is useful on systems with broken PCI bus. Affects various scans in x86-64 and i386's early ACPI quirk scan. Cc: gregkh@suse.de Cc: len.brown@intel.com Cc: Trammell Hudson <hudson@osresearch.net> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
SYSENTER can cause a NT to be set which might cause crashes on the IRET in the next task. Following similar i386 patch from Linus. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Jan Beulich 提交于
Current gcc generates calls not jumps to noreturn functions. When that happens the return address can point to the next function, which confuses the unwinder. This patch works around it by marking asynchronous exception frames in contrast normal call frames in the unwind information. Then teach the unwinder to decode this. For normal call frames the unwinder now subtracts one from the address which avoids this problem. The standard libgcc unwinder uses the same trick. It doesn't include adjustment of the printed address (i.e. for the original example, it'd still be kernel_math_error+0 that gets displayed, but the unwinder wouldn't get confused anymore. This only works with binutils 2.6.17+ and some versions of H.J.Lu's 2.6.16 unfortunately because earlier binutils don't support .cfi_signal_frame [AK: added automatic detection of the new binutils and wrote description] Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
No functional changes Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
In case the user space was compiled with -mregparm=3 Following i386. Pointed out by Albert Cahalan Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
This was old code that was needed for iBCS and x86-64 never supported that. Pointed out by Albert Cahalan Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
We do some additional CPU synchronization in gettimeofday et.al. to make sure the time stamps are always monotonic over multiple CPUs. But on single core systems that is not needed. So don't do it. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Cc: gregkh@suse.de Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
It is faster than using a unrolled loop for the use cases the kernel cares about (cached, sizes typically < 4K) Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Matthew Garrett 提交于
Got it. i8259A_resume calls init_8259A(0) unconditionally, even if auto_eoi has been set. Keep track of the current status and restore that on resume. This fixes it for AMD64 and i386. Signed-off-by: NMatthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Dave Jones 提交于
Sometimes, bug reports come in where we've had an oops, and the only record we have is what the reporter saw on screen shortly before the system locked up completely. Unfortunatly, syslog only prints lines beginning with KERN_EMERG to the console, so some lines get lost. An example of this can be seen at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203723 Some of this information isn't vital to diagnosis, but some parts are useful, such as the tainted flag. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Jeremy Fitzhardinge 提交于
Fix pack_descriptor: 1. flags are bits 20-23 in the high word 2. limit's 4 msb are bits 16-19 in the high word These haven't mattered so far, because all users have had small limits and a flags setting of 0. Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: NAndi Kleen <ak@suse.de> ===================================================================
-
由 Andi Kleen 提交于
Following earlier x86-64 patch Cc: gregkh@suse.de Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Aaron Durbin 提交于
On Sat, Sep 09, 2006 at 04:14:29PM +0200, Andi Kleen wrote: > [patch] Looks reasonable, but probably not for 2.6.18 because this stuff > is already too fragile and it is probably too risky to do any big changes now > since not enough testing time is left. Can you please resubmit > it with proper description and signed-off-by line? I can queue it for .19 then > > -Andi Patch inserts PCI memory mapped config region(s) into the resource map. This will allow for the MMCCONFIG regions to be marked as busy in the iomem address space as well as the regions(s) showing up in /proc/iomem. Signed-off-by: NAaron Durbin <adurbin@google.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Aaron Durbin 提交于
Patch inserts the GART region into the iomem resource map. The GART will then be visible within /proc/iomem. It will also allow for other users utilizing the GART to subreserve the region (agp or IOMMU). Signed-off-by: NAaron Durbin <adurbin@google.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Needs earlier patch to split type 1 probing from use. This patch should fix the x86 macs where type 1 PCI config space access doesn't work, but MCFG does. They also don't have a usable e820 table so the e820 sanity check failed. Instead assume now that if type 1 doesn't work then MCFG must work and don't do the e820 check. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
First probe if type1/2 accesses work, but then only initialize them at the end. This is useful for a later patch that needs this information inbetween. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Previously exit_idle would be called more often than enter_idle Now instead of using complicated tests just keep track of it using the per CPU variable as a flip flop. I moved the idle state into the PDA to make the access more efficient. Original bug report and an initial patch from Stephane Eranian, but redone by AK. Cc: Stephane Eranian <eranian@hpl.hp.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Eric W. Biederman 提交于
kexec has been marked experimental for a year now and all of the serious problems have been worked through. So it is time (if not past time) to remove the experimental mark. Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Eric W. Biederman 提交于
kexec has been marked experimental for a year now and all of the serious problems have been worked through. So it is time (if not past time) to remove the experimental mark. Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Before 2.6.16 this was changed to work around code that accessed CPUs not in the possible map. But that code should be all fixed now, so mark it __initdata again. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
This quietens so warnings about uninitialized use of the return value of the pda read operations. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Reindent the macros in x86-64 pda.h, making them much more readable. Follows Jeremy's i386 version of this. No functional changes Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
- Replace some broken white space. - Replace __ keywords with standard names No functional changes. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Quietens some new warnings Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Fix linux/fs/compat.c: In function compat_sys_pselect7 linux/fs/compat.c:1869: warning: ignoring return value of copy_to_user, declared with attribute warn_unused_result To make it easier to handle I changed to semantics to not try to write out a timespec if an error occurred. I hope that's ok. Cc: dwmw2@infradead.org Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Following i386. And also fix the two occurrences that caused warnings in arch/x86_64/* Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
- Don't zero for __copy_from_user_inatomic following i386. This will prevent spurious zeros for parallel file system writers when one does a exception - The string instruction version didn't zero the output on exception. Oops. Also I cleaned up the code a bit while I was at it and added a minor optimization to the string instruction path. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 adurbin@google.com 提交于
Add HPET(s) into resource map. This will allow for the HPET(s) to be visibile within /proc/iomem. Signed-off-by: NAaron Durbin <adurbin@google.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 adurbin@google.com 提交于
This patch places the IOAPIC(s) and the Local APIC specified by ACPI tables into the resource map. The APICs will then be visible within /proc/iomem Signed-off-by: NAaron Durbin <adurbin@google.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Chuck Ebbert 提交于
Add early i386 fault handlers with debug information for common faults. Handles: divide error invalid opcode protection fault page fault Also adds code to detect early recursive/multiple faults and halt the system when they happen (taken from x86_64.) Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NAndrew Morton <akpm@osdl.org>
-
由 Rusty Russell 提交于
We allow for the fact that the guest kernel may not run in ring 0. This requires some abstraction in a few places when setting %cs or checking privilege level (user vs kernel). This is Chris' [RFC PATCH 15/33] move segment checks to subarch, except rather than using #define USER_MODE_MASK which depends on a config option, we use Zach's more flexible approach of assuming ring 3 == userspace. I also used "get_kernel_rpl()" over "get_kernel_cs()" because I think it reads better in the code... 1) Remove the hardcoded 3 and introduce #define SEGMENT_RPL_MASK 3 2) Add a get_kernel_rpl() macro, and don't assume it's zero. And: Clean up of patch for letting kernel run other than ring 0: a. Add some comments about the SEGMENT_IS_*_CODE() macros. b. Add a USER_RPL macro. (Code was comparing a value to a mask in some places and to the magic number 3 in other places.) c. Add macros for table indicator field and use them. d. Change the entry.S tests for LDT stack segment to use the macros Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NZachary Amsden <zach@vmware.com> Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Rusty Russell 提交于
Abstract sensitive instructions in assembler code, replacing them with macros (which currently are #defined to the native versions). We use long names: assembler is case-insensitive, so if something goes wrong and macros do not expand, it would assemble anyway. Resulting object files are exactly the same as before. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Fix linux/arch/x86_64/kernel/process.c: In function __switch_to: linux/arch/x86_64/kernel/process.c:626: warning: assignment makes integer from pointer without a cast Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Jeremy Fitzhardinge 提交于
I just added type checking for assignments the PDA in the i386 PDA code. Here's the x86-64 equivalent. (Obviously this doesn't contain the latest x86-64 PDA change.) Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Apparently that is the more official way to get numbers without $ in inline assembly Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Arjan van de Ven 提交于
Add a feature check that checks that the gcc compiler has stack-protector support and has the bugfix for PR28281 to make this work in kernel mode. The easiest solution I could find was to have a shell script in scripts/ to do the detection; if needed we can make this fancier in the future without making the makefile too complex. Signed-off-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NAndi Kleen <ak@suse.de> CC: Andi Kleen <ak@suse.de> CC: Sam Ravnborg <sam@ravnborg.org>
-
由 Arjan van de Ven 提交于
GCC emits a call to a __stack_chk_fail() function when the stack canary is not matching the expected value. Since this is a bad security issue; lets panic the kernel rather than limping along; the kernel really can't be trusted anymore when this happens. Signed-off-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NAndi Kleen <ak@suse.de> CC: Andi Kleen <ak@suse.de>
-