- 23 Oct, 2007 40 commits
-
-
Carlos Corbacho authored
Add support to force_hpet for all known MCP55 (nForce 5) chipset LPC bridges. These are the untested nForce 5 chips (taken from Mikko's original patch, and checked against pci.ids). Signed-off-by:
Carlos Corbacho <cathectic@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu> arch/x86/kernel/quirks.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
-
Carlos Corbacho authored
This patch adds a quirk from LinuxBIOS to force enable HPET on the nVidia CK804 (nForce 4) chipset. This quirk can very likely support more than just nForce 4 (LinuxBIOS use the same code for nForce 5), and possibly nForce 3, but I don't have those chipsets, so cannot add and test them. Tested on an Abit KN9 (CK804). Signed-off-by:
-
H. Peter Anvin authored
Make <asm/setup.h> usable by the boot code. Clean up vestiges of the old command-line protocol from setup.h and head_32.S (it is still supported from the boot loader point of view, since it is converted to the new command-line protocol by the boot code.) Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Rafael J. Wysocki authored
During hibernation and suspend on x86_64 save CPU registers in the saved_context structure rather than in a handful of separate variables. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Brian Gerst authored
Signed-off-by:Brian Gerst <bgerst@didntduck.org>
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
The x86_64 arch/x86/kernel/Makefile uses references into arch/x86/kernel/cpu/... to use code from there. Unifiy it with the nicely structured i386 way and reuse the existing subdirectory make rules. Also move the machine check related source into ...kernel/cpu/mcheck, where the other machine check related code is. No code change. Signed-off-by:
-
Thomas Gleixner authored
Move mce.c to mce_32.c to allow the later move of the x86_64 mce.c from arch/x86/kernel/ to ...kernel/cpu/mcheck No code change. Signed-off-by:
-
Thomas Gleixner authored
Prepare the makefiles in x86/kernel/cpu and x86/kernel/cpu/mcheck to be used by the x86_64 build as well. No code change. Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Preperatory patch to simplify the sharing of Makefiles in arch/x86. Linus came up with this during a discussion about the ugliness of ifeq($CONFIG_X86_32),y) and obj-$(CONFIG_X86_32) in the shared Makefiles. Signed-off-by:
-
Chris Snook authored
Unify x86 div64.h headers. Signed-off-by:
Chris Snook <csnook@redhat.com> Signed-off-by:
-
Chris Snook authored
Unify x86 a.out_32.h and a.out_64.h [ tglx: Kbuild fixup ] Signed-off-by:
-
Hiroshi Shimamoto authored
Most of contents in crash are same. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
-
Hiroshi Shimamoto authored
Preperatory patch to allow crash_32/64.c merging Signed-off-by:
-
Hiroshi Shimamoto authored
Preperatory patch to allow crash_32/64.c merging Signed-off-by:
-
Chris Snook authored
Merge mmu_32.h and mmu_64.h into mmu.h. Signed-off-by:
-
Alejandro Martinez Ruiz authored
Signed-off-by:
Alejandro Martinez Ruiz <alex@flawedcode.org> Signed-off-by:
-
Dave Johnson authored
The previous patch wasn't correctly handling the 'count' variable. If a CPU gave bad results on the 1st or 2nd run but good results on the 3rd, it wouldn't do the correct thing. No idea if any such CPU exists, but the patch below handles that case by discarding the bad runs. If a bad result (too quick, or too slow) occurs on any of the 3 runs it will be discarded. Also updated some comments to explain what's going on. Signed-off-by:
Dave Johnson <djohnson@sw.starentnetworks.com> Signed-off-by:
-
Dave Johnson authored
I ran into this problem on a system that was unable to obtain NTP sync because the clock was running very slow (over 10000ppm slow). ntpd had declared all of its peers 'reject' with 'peer_dist' reason. On investigation, the tsc_khz variable was significantly incorrect causing xtime to run slow. After a reboot tsc_khz was correct so I did a reboot test to see how often the problem occurred: Test was done on a 2000 Mhz Xeon system. Of 689 reboots, 8 of them had unacceptable tsc_khz values (>500ppm): range of tsc_khz # of boots % of boots ---------------- ---------- ---------- < 1999750 0 0.000% 1999750 - 1999800 21 3.048% 1999800 - 1999850 166 24.128% 1999850 - 1999900 241 35.029% 1999900 - 1999950 211 30.669% 1999950 - 2000000 42 6.105% 2000000 - 2000000 0 0.000% 2000050 - 2000100 0 0.000% [...] 2000100 - 2015000 1 0.145% << BAD 2015000 - 2030000 6 0.872% << BAD 2030000 - 2045000 1 0.145% << BAD 2045000 < 0 0.000% The worst boot was 2032.577 Mhz, over 1.5% off! It appears that on rare occasions, mach_countup() is taking longer to complete than necessary. I suspect that this is caused by the CPU taking a periodic SMI interrupt right at the end of the 30ms calibration loop. This would cause the loop to delay while the SMI BIOS hander runs. The resulting TSC value is beyond what it actually should be resulting in a higher tsc_khz. The below patch makes native_calculate_cpu_khz() take the best (shortest duration, lowest khz) run of it's 3 calibration loops. If a SMI goes off causing a bad result (long duration, higher khz) it will be discarded. With the patch applied, 300 boots of the same system produce good results: range of tsc_khz # of boots % of boots ---------------- ---------- ---------- < 1999750 0 0.000% 1999750 - 1999800 30 10.000% 1999800 - 1999850 166 55.333% 1999850 - 1999900 89 29.667% 1999900 - 1999950 15 5.000% 1999950 < 0 0.000% Problem was found and tested against 2.6.18. Patch is against 2.6.22. Signed-off-by: -
Nick Piggin authored
I missed an obvious one! x86 CPUs are defined not to reorder stores past earlier loads, so there is no hardware memory barrier required to implement a release-consistent store (all stores are, by definition). So ditch the generic lock bitops, and implement optimised versions for x86, which removes the mfence from __clear_bit_unlock (which is already a useful primitive for SLUB). Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Adrian Bunk authored
It seems commit 09cadedb was incomplete due to a clash with the x86 architecture merge. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fsLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs: 9p: v9fs_vfs_rename incorrect clunk order 9p: fix memleak in fs/9p/v9fs.c 9p: add virtio transport
-
Ralf Baechle authored
Commits 58b053e4 ("Update arch/ to use sg helpers") 45711f1a ("[SG] Update drivers to use sg helpers") fa05f128 ("Update net/ to use sg helpers") converted many files to use the scatter gather helpers without ensuring that the necessary headerfile <linux/scatterlist> is included. This happened to work for ia64, powerpc, sparc64 and x86 because they happened to drag in that file via their <asm/dma-mapping.h>. On most of the others this probably broke. Instead of increasing the header file spider web I choose to include <linux/scatterlist.h> directly into the affectes files. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Latchesar Ionkov authored
In v9fs_vfs_rename function labels don't match the fids that are clunked. The correct clunk order is clunking newdirfid first and then olddirfid next. Signed-off-by:
Latchesar Ionkov <lucho@ionkov.net> Signed-off-by:
Eric Van Hensbergen <ericvh@gmail.com>
-
Adrian Bunk authored
This patch fixes a memory leak introduced by commit ba17674f. Spotted by the Coverity checker. Signed-off-by:
-
Eric Van Hensbergen authored
This adds a transport to 9p for communicating between guests and a host using a virtio based transport. Signed-off-by:
-
