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

x86 setup: add a near jump to serialize %cr0 on 386/486

2007-12-14T17:50:58+00:00

patch 7ed192906a2144ebc8ca2925a85d27b9c5355668 in mainline.

The 386 and 486 needs a jump immediately after setting %cr0 in order
to serialize the pipeline.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: fix freeze in x86_64 RTC update code in time_64.c

2007-11-26T17:42:32+00:00

patch c399da0d97e06803e51085ec076b63a3168aad1b in mainline.

x86: fix freeze in x86_64 RTC update code in time_64.c

Fix hard freeze on x86_64 when the ntpd service calls
update_persistent_clock()

A repeatable but randomly timed freeze has been happening in Fedora 6
and 7 for the last year, whenever I run the ntpd service on my AMD64x2
HP Pavilion dv9000z laptop.  This freeze is due to the use of
spin_lock(&rtc_lock) under the assumption (per a bad comment) that
set_rtc_mmss is called only with interrupts disabled.  The call from
ntp.c to update_persistent_clock is made with interrupts enabled.

[ tglx@linutronix.de: ported to 2.6.23.stable ]

Signed-off-by: David P. Reed 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: return correct error code from child_rip in x86_64 entry.S

2007-11-26T17:42:31+00:00

patch 1c5b5cfd290b6cb7c67020ef420e275f746a7236 in mainline.

x86: return correct error code from child_rip in x86_64 entry.S

Right now register edi is just cleared before calling do_exit.
That is wrong because correct return value will be ignored.
Value from rax should be copied to rdi instead of clearing edi.

AK: changed to 32bit move because it's strictly an int

[ tglx: arch/x86 adaptation ]

Signed-off-by: Andrey Mirkin 
Signed-off-by: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86: NX bit handling in change_page_attr()

2007-11-26T17:42:31+00:00

patch 84e0fdb1754d066dd0a8b257de7299f392d1e727 in mainline.

x86: NX bit handling in change_page_attr()

This patch fixes a bug of change_page_attr/change_page_attr_addr on
Intel x86_64 CPUs.  After changing page attribute to be executable with
these functions, the page remains un-executable on Intel x86_64 CPU.
Because on Intel x86_64 CPU, only if the "NX" bits of all four level
page tables are cleared, the corresponding page is executable (refer to
section 4.13.2 of Intel 64 and IA-32 Architectures Software Developer's
Manual).  So, the bug is fixed through clearing the "NX" bit of PMD when
splitting the huge PMD.

Signed-off-by: Huang Ying 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86: fix off-by-one in find_next_zero_string

2007-11-26T17:42:31+00:00

patch 801916c1b369b637ce799e6c71a94963ff63df79 in mainline.

x86: fix off-by-one in find_next_zero_string

Fix an off-by-one error in find_next_zero_string which prevents
allocating the last bit.

[ tglx: arch/x86 adaptation ]

Signed-off-by: Andrew Hastings 
Signed-off-by: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

i386: avoid temporarily inconsistent pte-s

2007-11-26T17:42:31+00:00

patch aa506dc7b12d03fbf8fd11aab752aed1aadd9c07 in mainline.

i386: avoid temporarily inconsistent pte-s

One more of these issues (which were considered fixed a few releases
back): other than on x86-64, i386 allows set_fixmap() to replace
already present mappings. Consequently, on PAE, care must be taken to
not update the high half of a pte while the low half is still holding
the old value.

 [tglx: arch/x86 adaptation]

Signed-off-by: Jan Beulich 
Signed-off-by: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86: disable preemption in delay_tsc()

2007-11-26T17:42:29+00:00

patch 35d5d08a085c56f153458c3f5d8ce24123617faf in mainline.

Marin Mitov points out that delay_tsc() can misbehave if it is preempted and
rescheduled on a different CPU which has a skewed TSC.  Fix it by disabling
preemption.

(I assume that the worst-case behaviour here is a stall of 2^32 cycles)

Cc: Andi Kleen 
Cc: Marin Mitov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-16T16:22:59+00:00

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:58+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

x86 setup: sizeof() is unsigned, unbreak comparisons

2007-11-16T16:22:58+00:00

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