linux-toradex.git/arch, branch v2.6.22.15

x86: fix TSC clock source calibration error

2007-11-21T17:25:53+00:00

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:08+00:00

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:07+00:00

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:06+00:00

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:15+00:00

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:10+00:00

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

i386: Use global flag to disable broken local apic timer on AMD CPUs.

2007-10-10T17:50:17+00:00

commit d3f7eae182b04997be19343a23f7009170f4f7a5 upstream

The Averatec 2370 and some other Turion laptop BIOS seems to program the
ENABLE_C1E MSR inconsistently between cores. This confuses the lapic
use heuristics because when C1E is enabled anywhere it seems to affect
the complete chip.

Use a global flag instead of a per cpu flag to handle this.
If any CPU has C1E enabled disabled lapic use.

Thanks to Cal Peake for debugging.

Cc: tglx@linutronix.de
Cc: Chuck Ebbert 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Fix sparc64 v100 platform booting.

2007-09-26T17:54:44+00:00

commit 2cc7345ff71b27b5ac99e49ad7de39360042f601 in mainline

Subject: [PATCH] [SPARC64]: Fix booting on V100 systems.

On the root PCI bus, the OBP device tree lists device 3 twice.
Once as 'pm' and once as 'lomp'.

Everything goes downhill from there.

Ignore the second instance to workaround this.

Thanks to Kövedi_Krisztián for the bug report and
testing the fix.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

POWERPC: Flush registers to proper task context

2007-09-26T17:54:38+00:00

commit 0ee6c15e7ba7b36a217cdadb292eeaf32a057a59 in mainline.

When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
we need to respect the task_struct that the caller has passed to us.

Most cases we are called with current, however sometimes (ptrace) we may
be passed a different task_struct.

This showed up when using gdbserver debugging a simple program that used
floating point. When gdb tried to show the FP regs they all showed up as
0, because the child's FP registers were never properly flushed to memory.

Signed-off-by: Kumar Gala 
Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: Zero extend all registers after ptrace in 32bit entry path.

2007-09-21T22:38:11+00:00

Strictly it's only needed for eax.

It actually does a little more than strictly needed -- the other registers
are already zero extended.

Also remove the now unnecessary and non functional compat task check
in ptrace.

This is CVE-2007-4573

Found by Wojciech Purczynski

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright