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

x86_64: CPA, fix cache attribute inconsistency bug

2008-02-26T00:14:08+00:00

no upstream git id as the code has been rewritten.

fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
(when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
the secondary alias address by -14 MB (depending on the configured
offset).

The default 64-bit kernels of Fedora and Ubuntu are affected:

   $ grep RELOCA /boot/config-2.6.23.9-85.fc8
     CONFIG_RELOCATABLE=y

   $ grep RELOC /boot/config-2.6.22-14-generic
     CONFIG_RELOCATABLE=y

and probably on many other distros as well.

the bug affects all pages in the first 40 MB of physical RAM that
are allocated by some subsystem that does ioremap_nocache() on them:

       if (__pa(address) < KERNEL_TEXT_SIZE) {

Hence we might leave page table entries with inconsistent cache
attributes around (pages mapped at both UnCacheable and Write-Back),
and we can also set the wrong kernel text pages to UnCacheable.

the effects of this bug can be random slowdowns and other misbehavior.
If for example AGP allocates its aperture pages into the first 40 MB
of physical RAM, then the -14 MB bug might mark random kernel texto
pages as uncacheable, slowing down a random portion of the 64-bit
kernel until the AGP driver is unloaded.

Signed-off-by: Ingo Molnar 
Acked-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Disable G5 NAP mode during SMU commands on U3

2008-02-26T00:14:08+00:00

patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.

It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail.  It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate properly when the said bridge is
in napping along with the CPU.  That is on U3 at least, U4 doesn't
seem to be affected.

This didn't show before NO_HZ as the timer wakeup was enough to make
it work it seems, but that is no longer the case.

This fixes it by disabling NAP mode on those machines while
an SMU command is in flight.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

ia64: Fix unaligned handler for floating point instructions with base update

2008-02-08T20:01:46+00:00

commit 1a499150e4ec1299232e24389f648d059ce5617a in mainline.

[IA64] Fix unaligned handler for floating point instructions with base update

The compiler team did the hard work for this distilling a problem in
large fortran application which showed up when applied to a 290MB input
data set down to this instruction:

	ldfd f34=[r17],-8

Which they noticed incremented r17 by 0x10 rather than decrementing it
by 8 when the value in r17 caused an unaligned data fault.  I tracked
it down to some bad instruction decoding in unaligned.c. The code
assumes that the 'x' bit can determine whether the instruction is
an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on
page 3:302 of the SDM).  But for opcode=7 the 'x' bit is irrelevent,
all variants are "ldf" instructions (see table 4-36 on page 3:306).

Note also that interpreting the instruction as "ldfp" means that the
"paired" floating point register (f35 in the example here) will also
be corrupted.

Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

PM: ACPI and APM must not be enabled at the same time

2008-02-08T20:01:32+00:00

patch 9f9adecd2d0e4f88fa0e8cb06c6ec207748df70a in mainline.

ACPI and APM used "pm_active" to guarantee that
they would not be simultaneously active.

But pm_active was recently moved under CONFIG_PM_LEGACY,
so that without CONFIG_PM_LEGACY, pm_active became a NOP --
allowing ACPI and APM to both be simultaneously enabled.
This caused unpredictable results, including boot hangs.

Further, the code under CONFIG_PM_LEGACY is scheduled
for removal.

So replace pm_active with pm_flags.
pm_flags depends only on CONFIG_PM,
which is present for both CONFIG_APM and CONFIG_ACPI.

http://bugzilla.kernel.org/show_bug.cgi?id=9194

Signed-off-by: Len Brown 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

SPARC64: Implement pci_resource_to_user()

2008-02-08T20:01:28+00:00

[SPARC64]: Implement pci_resource_to_user()

[ Upstream commit: bcea1db16ba1c45ccebb3bfb8441642d1342c4d5 ]

This makes libpciaccess able to mmap() resources of the
device properly.

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

SPARC64: Fix two kernel linear mapping setup bugs.

2008-02-08T20:01:13+00:00

[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

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

2008-02-08T20:01:11+00:00

[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 sparc64 cpu cross call hangs.

2008-02-08T20:01:05+00:00

[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

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