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

[PATCH] x86_64/i386: Compute correct MTRR mask on early Noconas

2005-11-24T22:10:11+00:00

Force correct address space size for MTRR on some 64bit Intel Xeons

They report 40bit, but only have 36bits of physical address space.
This caused problems with setting up the correct masks for MTRR,
resulting in incorrect MTRRs.

CPUID workaround for steppings 0F33h(supporting x86) and 0F34h(supporting x86
and EM64T). Detail info can be found at:
http://download.intel.com/design/Xeon/specupdt/30240216.pdf
http://download.intel.com/design/Pentium4/specupdt/30235221.pdf

Signed-off-by: Shaohua Li
Signed-off-by: Andi Kleen 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] ppc64 memory model depends on NUMA

2005-11-24T22:10:06+00:00

Signed-off-by: Andy Whitcroft 
Signed-off-by: Joel Schopp 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] CVE-2005-2709 sysctl unregistration oops

2005-11-08T19:14:00+00:00

You could open the /proc/sys/net/ipv4/conf// file, then
wait for interface to go away, try to grab as much memory as possible in
hope to hit the (kfreed) ctl_table.  Then fill it with pointers to your
function. Then do read from file you've opened and if you are lucky,
you'll get it called as ->proc_handler() in kernel mode.

So this is at least an Oops and possibly more.  It does depend on an
interface going away though, so less of a security risk than it would
otherwise be.

Signed-off-by: Greg Kroah-Hartman

Merge master.kernel.org:/home/rmk/linux-2.6-arm

2005-10-26T21:01:57+00:00

[PATCH] ppc64: Fix wrong register mapping in mpic driver

2005-10-26T17:39:43+00:00

The mpic interrupt controller driver (used on G5 and early pSeries among
others) has a bug where it doesn't get the right virtual address for the
timer registers.  It causes the driver to poke at the MMIO space of
whatever has been mapped just next to it (ouch !) when initializing and
causes boot failures on some IBM machines.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[ARM] fix sharp zaurus c-3000 compile failure without CONFIG_FB_PXA

2005-10-24T21:30:10+00:00

This fixes compile problem when CONFIG_FB_PXA is not set.

  LD      .tmp_vmlinux1
arch/arm/mach-pxa/built-in.o(.text+0x1d74): In function
`spitz_get_hsync_len':
: undefined reference to `pxafb_get_hsync_time'
make: *** [.tmp_vmlinux1] Error 1
3.46user 0.46system 5.10 (0m5.106s) elapsed 77.01%CPU

Signed-off-by: Pavel Machek 
Signed-off-by: Richard Purdie 
Signed-off-by: Russell King

[PATCH] uml: fix compile failure for TT mode

2005-10-24T15:59:25+00:00

Without this patch, uml compile fails with:

  LD      .tmp_vmlinux1
arch/um/kernel/built-in.o: In function `config_gdb_cb':
arch/um/kernel/tt/gdb.c:129: undefined reference to `TASK_EXTERN_PID'

Tested on i386, but fix needed on x86_64 too AFAICS.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Linus Torvalds

[PATCH] typo fix in last cpufreq powernow patch

2005-10-22T00:08:30+00:00

Not sure how it slipped by, but here's a trivial typo fix for powernow.

Signed-off-by: Chris Wright 
[ It's "nurter" backwards.. Maybe we have a hillbilly The Shining fan? ]
Signed-off-by: Linus Torvalds

[PATCH] cpufreq: fix pending powernow timer stuck condition

2005-10-21T21:28:58+00:00

AMD recently discovered that on some hardware, there is a race condition
possible when a C-state change request goes onto the bus at the same
time as a P-state change request.

Both requests happen, but the southbridge hardware only acknowledges the
C-state change.  The PowerNow! driver is then stuck in a loop, waiting
for the P-state change acknowledgement.  The driver eventually times
out, but can no longer perform P-state changes.

It turns out the solution is to resend the P-state change, which the
southbridge will acknowledge normally.

Thanks to Johannes Winkelmann for reporting this and testing the fix.

Signed-off-by: Mark Langsdorf 
Signed-off-by: Dave Jones 
Signed-off-by: Linus Torvalds

[PATCH] ppc64: Fix typo bug in iSeries hash code

2005-10-21T19:24:41+00:00

This fixes a stupid typo bug in the iSeries hash table code.

When we place a hash PTE in the secondary bucket, instead of setting the
SECONDARY flag bit, as we should, we (redundantly) set the VALID flag.

This was introduced with the patch abolishing bitfields from the hash
table code.  Mea culpa, oops.  It hasn't been noticed until now because
in practice we don't hit the secondary bucket terribly often.

Signed-off-by: David Gibson 
Signed-off-by: Linus Torvalds