user/sven/linux.git, branch v2.6.23.3

Linux 2.6.23.3

2007-11-16T16:24:58Z

revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-16T16:22:59Z

Reverted upstream by commit 6a22c57b8d2a62dea7280a6b2ac807a539ef0716 Revert this commit: commit 2e1c49db4c640b35df13889b86b9d62215ade4b6 Author: Zou Nan hai Date: Fri Jun 1 00:46:28 2007 -0700 x86_64: allocate sparsemem memmap above 4G This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6. First off, testing in Fedora has shown it to cause boot failures, bisected down by Martin Ebourne, and reported by Dave Jobes. So the commit will likely be reverted in the 2.6.23 stable kernels. Secondly, in the 2.6.24 model, x86-64 has now grown support for SPARSEMEM_VMEMMAP, which disables the relevant code anyway, so while the bug is not visible any more, it's become invisible due to the code just being irrelevant and no longer enabled on the only architecture that this ever affected. Reported-by: Dave Jones Tested-by: Martin Ebourne Cc: Zou Nan hai Cc: Suresh Siddha Cc: Andrew Morton Acked-by: Andy Whitcroft Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

x86: fix TSC clock source calibration error

2007-11-16T16:22:58Z

patch edaf420fdc122e7a42326fe39274c8b8c9b19d41 in mainline. 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: Dave Johnson Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86 setup: sizeof() is unsigned, unbreak comparisons

2007-11-16T16:22:58Z

patch e6e1ace9904b72478f0c5a5aa7bd174cb6f62561 in mainline. We use signed values for limit checking since the values can go negative under certain circumstances. However, sizeof() is unsigned and forces the comparison to be unsigned, so move the comparison into the heap_free() macros so we can ensure it is a signed comparison. Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86 setup: handle boot loaders which set up the stack incorrectly

2007-11-16T16:22:58Z

patch 6b6815c6d5d1dc209701d1661a7a0e09a295db2f in mainline. Apparently some specific versions of LILO enter the kernel with a stack pointer that doesn't match the rest of the segments. Make our best attempt at untangling the resulting mess. Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86: fix global_flush_tlb() bug

2007-11-16T16:22:58Z

patch 9a24d04a3c26c223f22493492c5c9085b8773d4a upstream While we were reviewing pageattr_32/64.c for unification, Thomas Gleixner noticed the following serious SMP bug in global_flush_tlb(): down_read(&init_mm.mmap_sem); list_replace_init(&deferred_pages, &l); up_read(&init_mm.mmap_sem); this is SMP-unsafe because list_replace_init() done on two CPUs in parallel can corrupt the list. This bug has been introduced about a year ago in the 64-bit tree: commit ea7322decb974a4a3e804f96a0201e893ff88ce3 Author: Andi Kleen Date: Thu Dec 7 02:14:05 2006 +0100 [PATCH] x86-64: Speed and clean up cache flushing in change_page_attr down_read(&init_mm.mmap_sem); - dpage = xchg(&deferred_pages, NULL); + list_replace_init(&deferred_pages, &l); up_read(&init_mm.mmap_sem); the xchg() based version was SMP-safe, but list_replace_init() is not. So this "cleanup" introduced a nasty bug. why this bug never become prominent is a mystery - it can probably be explained with the (still) relative obscurity of the x86_64 architecture. the safe fix for now is to write-lock init_mm.mmap_sem. Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andi Kleen Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman

xfs: eagerly remove vmap mappings to avoid upsetting Xen

2007-11-16T16:22:58Z

patch ace2e92e193126711cb3a83a3752b2c5b8396950 in mainline. XFS leaves stray mappings around when it vmaps memory to make it virtually contigious. This upsets Xen if one of those pages is being recycled into a pagetable, since it finds an extra writable mapping of the page. This patch solves the problem in a brute force way, by making XFS always eagerly unmap its mappings. [ Stable: This works around a bug in 2.6.23. We may come up with a better solution for mainline, but this seems like a low-impact fix for the stable kernel. ] Signed-off-by: Jeremy Fitzhardinge Cc: XFS masters Cc: Morten =?utf-8?q?B=C3=B8geskov?= Cc: Mark Williamson Signed-off-by: Greg Kroah-Hartman

xen: fix incorrect vcpu_register_vcpu_info hypercall argument

2007-11-16T16:22:58Z

patch e3d2697669abbe26c08dc9b95e2a71c634d096ed in mainline. The kernel's copy of struct vcpu_register_vcpu_info was out of date, at best causing the hypercall to fail and the guest kernel to fall back to the old mechanism, or worse, causing random memory corruption. Signed-off-by: Jeremy Fitzhardinge Cc: Stable Kernel Cc: Morten =?utf-8?q?B=C3=B8geskov?= Cc: Mark Williamson Signed-off-by: Greg Kroah-Hartman

xen: deal with stale cr3 values when unpinning pagetables

2007-11-16T16:22:57Z

patch 9f79991d4186089e228274196413572cc000143b in mainline. When a pagetable is no longer in use, it must be unpinned so that its pages can be freed. However, this is only possible if there are no stray uses of the pagetable. The code currently deals with all the usual cases, but there's a rare case where a vcpu is changing cr3, but is doing so lazily, and the change hasn't actually happened by the time the pagetable is unpinned, even though it appears to have been completed. This change adds a second per-cpu cr3 variable - xen_current_cr3 - which tracks the actual state of the vcpu cr3. It is only updated once the actual hypercall to set cr3 has been completed. Other processors wishing to unpin a pagetable can check other vcpu's xen_current_cr3 values to see if any cross-cpu IPIs are needed to clean things up. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman

xen: add batch completion callbacks

2007-11-16T16:22:57Z

patch 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1 in mainline. This adds a mechanism to register a callback function to be called once a batch of hypercalls has been issued. This is typically used to unlock things which must remain locked until the hypercall has taken place. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman