linux/arch, branch v2.6.22.18

POWERPC: Fix invalid semicolon after if statement

2008-02-06T19:43:46Z

Patch 2b02d13996fe28478e45605de9bd8bdca25718de in mainline [POWERPC] Fix invalid semicolon after if statement A similar fix to netfilter from Eric Dumazet inspired me to look around a bit by using some grep/sed stuff as looking for this kind of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: Ilpo JÃ¤rvinen Acked-by: Benjamin Herrenschmidt Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman

Fix sparc64 cpu cross call hangs.

2008-02-06T19:43:44Z

[SPARC64]: Fix endless loop in cheetah_xcall_deliver(). [ Upsteam commit: 0de56d1ab83323d604d95ca193dcbd28388dbabb ] We need to mask out the proper bits when testing the dispatch status register else we can see unrelated NACK bits from previous cross call sends. Signed-off-by: David S. Miller

SPARC64: Fix memory controller register access when non-SMP.

2008-02-06T19:43:41Z

[SPARC64]: Fix memory controller register access when non-SMP. [ Upstream commit: b332b8bc9c67165eabdfc7d10b4a2e4cc9f937d0 ] get_cpu() always returns zero on non-SMP builds, but we really want the physical cpu number in this code in order to do the right thing. Based upon a non-SMP kernel boot failure report from Bernd Zeimetz. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

SPARC64: Fix two kernel linear mapping setup bugs.

2008-02-06T19:43:41Z

[SPARC64]: Fix two kernel linear mapping setup bugs. [ Upstream commit: 8f361453d8e9a67c85b2cf9b93c642c2d8fe0462 ] This was caught and identified by Greg Onufer. Since we setup the 256M/4M bitmap table after taking over the trap table, it's possible for some 4M mapping to get loaded in the TLB beforhand which later will be 256M mappings. This can cause illegal TLB multiple-match conditions. Fix this by setting up the bitmap before we take over the trap table. Next, __flush_tlb_all() was not doing anything on hypervisor platforms. Fix by adding sun4v_mmu_demap_all() and calling it. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

x86: fix TSC clock source calibration error

2007-11-21T17:25:53Z

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

Revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-05T17:56:08Z

patch 6a22c57b8d2a62dea7280a6b2ac807a539ef0716 in mainline. 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. backported to 2.6.22 by Chuck Ebbert 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 global_flush_tlb() bug

2007-11-05T17:56:07Z

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

genirq: mark io_apic level interrupts to avoid resend

2007-11-05T17:56:06Z

patch cc75b92d11384ba14f93828a2a0040344ae872e7 in mainline. Level type interrupts do not need to be resent. It was also found that some chipsets get confused in case of the resend. Mark the ioapic level type interrupts as such to avoid the resend functionality in the generic irq code. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

POWERPC: Fix handling of stfiwx math emulation

2007-11-02T15:44:15Z

patch ba02946a903015840ef672ccc9dc8620a7e83de6 in mainline Its legal for the stfiwx instruction to have RA = 0 as part of its effective address calculation. This is illegal for all other XE form instructions. Add code to compute the proper effective address for stfiwx if RA = 0 rather than treating it as illegal. Signed-off-by: Kumar Gala Signed-off-by: Greg Kroah-Hartman

Fix sys_ipc() SEMCTL on sparc64.

2007-11-02T15:44:10Z

changeset 6536a6b331d3225921c398eb7c6e4ecedb9b05e0 from mainline Thanks to Tom Callaway for the excellent bug report and test case. sys_ipc() has several problems, most to due with semaphore call handling: 1) 'err' return should be a 'long' 2) "union semun" is passed in a register on 64-bit compared to 32-bit which provides it on the stack and therefore by reference 3) Second and third arguments to SEMCTL are swapped compared to 32-bit. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman