linux-toradex.git/arch, branch v2.6.31.12 Linux kernel for Apalis and Colibri modules x86/ptrace: make genregs[32]_get/set more robust 2010-01-06T22:26:44+00:00 Linus Torvalds torvalds@linux-foundation.org 2009-12-17T15:04:56+00:00 1bb36e83e350d997fb109b77e41bf4dce57ffe58 commit 04a1e62c2cec820501f93526ad1e46073b802dc4 upstream. The loop condition is fragile: we compare an unsigned value to zero, and then decrement it by something larger than one in the loop. All the callers should be passing in appropriately aligned buffer lengths, but it's better to just not rely on it, and have some appropriate defensive loop limits. Acked-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 04a1e62c2cec820501f93526ad1e46073b802dc4 upstream.

The loop condition is fragile: we compare an unsigned value to zero, and
then decrement it by something larger than one in the loop.  All the
callers should be passing in appropriately aligned buffer lengths, but
it's better to just not rely on it, and have some appropriate defensive
loop limits.

Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
x86, cpuid: Add "volatile" to asm in native_cpuid() 2010-01-06T22:26:35+00:00 Suresh Siddha suresh.b.siddha@intel.com 2009-12-17T00:25:42+00:00 43abf240b660703fbff2bae3695e41f1169795f5 commit 45a94d7cd45ed991914011919e7d40eb6d2546d1 upstream. xsave_cntxt_init() does something like: cpuid(0xd, ..); // find out what features FP/SSE/.. etc are supported xsetbv(); // enable the features known to OS cpuid(0xd, ..); // find out the size of the context for features enabled Depending on what features get enabled in xsetbv(), value of the cpuid.eax=0xd.ecx=0.ebx changes correspondingly (representing the size of the context that is enabled). As we don't have volatile keyword for native_cpuid(), gcc 4.1.2 optimizes away the second cpuid and the kernel continues to use the cpuid information obtained before xsetbv(), ultimately leading to kernel crash on processors supporting more state than the legacy FP/SSE. Add "volatile" for native_cpuid(). Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1261009542.2745.55.camel@sbs-t61.sc.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 45a94d7cd45ed991914011919e7d40eb6d2546d1 upstream.

xsave_cntxt_init() does something like:

	cpuid(0xd, ..);	// find out what features FP/SSE/.. etc are supported

	xsetbv();	// enable the features known to OS

	cpuid(0xd, ..);	// find out the size of the context for features enabled

Depending on what features get enabled in xsetbv(), value of the
cpuid.eax=0xd.ecx=0.ebx changes correspondingly (representing the
size of the context that is enabled).

As we don't have volatile keyword for native_cpuid(), gcc 4.1.2
optimizes away the second cpuid and the kernel continues to use
the cpuid information obtained before xsetbv(), ultimately leading to kernel
crash on processors supporting more state than the legacy FP/SSE.

Add "volatile" for native_cpuid().

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1261009542.2745.55.camel@sbs-t61.sc.intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f. 2009-12-18T21:44:14+00:00 Zhao Yakui yakui.zhao@intel.com 2009-12-11T07:17:20+00:00 7aea74857b397f343696a468e569486cff76ff29 commit 03a05ed1152944000151d57b71000de287a1eb02 upstream. Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 03a05ed1152944000151d57b71000de287a1eb02 upstream.

Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms.
For such platforms, reduce contention on c3_lock by skipping the fake
ARB_DISABLE.

The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box,
the box can't be booted correctly. But if we still enable ARB_DISABLE on this
box, the box can be booted correctly.

So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f.

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

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value 2009-12-18T21:44:12+00:00 Yong Wang yong.y.wang@linux.intel.com 2009-12-16T05:25:10+00:00 a845dbd1d7be1e7cc7bfa2fbaa3fc73933411700 Upstream commit a2202aa29289db64ca7988b12343158b67b27f10. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by: Yong Wang <yong.y.wang@intel.com> Reviewed-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Upstream commit a2202aa29289db64ca7988b12343158b67b27f10.

On platforms where bios handles the thermal monitor interrupt,
APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS
can't touch it.

Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all
the LVT entries except the mask bit. Essentially this results in
all LVT entries including the thermal monitoring interrupt set to masked
(clearing the bios programmed value for APIC_LVTTHMR).

And this leads to kernel take over the thermal monitoring interrupt
on AP's but not on BSP (leaving the bios programmed value only on BSP).

As a result of this, we have seen system hangs when the thermal
monitoring interrupt is generated.

Fix this by reading the initial value of thermal LVT entry on BSP
and if bios has taken over the control, then program the same value
on all AP's and leave the thermal monitoring interrupt control
on all the logical cpu's to the bios.

Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Reviewed-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Arjan van de Ven <arjan@infradead.org>
LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
x86/mce: Set up timer unconditionally 2009-12-18T21:44:10+00:00 Jan Beulich jbeulich@novell.com 2009-12-08T02:21:37+00:00 013fecfdb1d018458327634840f905249dc9b51d commit bc09effabf0c5c6c7021e5ef9af15a23579b32a8 upstream. mce_timer must be passed to setup_timer() in all cases, no matter whether it is going to be actually used. Otherwise, when the CPU gets brought down, its call to del_timer_sync() will never return, as the timer won't have a base associated, and hence lock_timer_base() will loop infinitely. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> LKML-Reference: <4B1DB831.2030801@jp.fujitsu.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit bc09effabf0c5c6c7021e5ef9af15a23579b32a8 upstream.

mce_timer must be passed to setup_timer() in all cases, no
matter whether it is going to be actually used. Otherwise, when
the CPU gets brought down, its call to del_timer_sync() will
never return, as the timer won't have a base associated, and
hence lock_timer_base() will loop infinitely.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
LKML-Reference: <4B1DB831.2030801@jp.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc: Set UTS_MACHINE correctly. 2009-12-18T21:44:10+00:00 David S. Miller davem@davemloft.net 2009-12-06T01:17:55+00:00 b77a21835581b8e2f7ee79dfe762ea5a2069ac6c [ Upstream commit 7f5620a5fcd658f219e85831d3691908f1eccbde ] "ARCH" can be just about anything, so we shouldn't end up with UTS_MACHINE of "sparc" in a 64-bit kernel build just because someone set the personality using 'sparc32' or similar. CONFIG_SPARC64 drives the compilation and therefore provides the definitive value, not "ARCH". This mirrors commit 8c6531f7a99f29ba8817ffb12cc9ecf190049bd6 (x86: correctly set UTS_MACHINE for "make ARCH=x86") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 7f5620a5fcd658f219e85831d3691908f1eccbde ]

"ARCH" can be just about anything, so we shouldn't end up
with UTS_MACHINE of "sparc" in a 64-bit kernel build just
because someone set the personality using 'sparc32' or
similar.  CONFIG_SPARC64 drives the compilation and
therefore provides the definitive value, not "ARCH".

This mirrors commit 8c6531f7a99f29ba8817ffb12cc9ecf190049bd6
(x86: correctly set UTS_MACHINE for "make ARCH=x86")

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: Fix stack debugging IRQ stack regression. 2009-12-18T21:44:09+00:00 David S. Miller davem@davemloft.net 2009-12-09T09:43:45+00:00 2b8d879954ca74e594fe17e30c2ea3a2b4ec893b [ Upstream commit 166e553a575f09485f6d0df8a1ef3c5991f7d953 ] Commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd (sparc64: Implement IRQ stacks.) has two bugs. First, the softirq range check forgets to subtract STACK_BIAS before comparing with %sp. Next, on failure the wrong label is jumped to, resulting in a bogus stack being loaded. Reported-by: Igor Kovalenko <igor.v.kovalenko@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 166e553a575f09485f6d0df8a1ef3c5991f7d953 ]

Commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd
(sparc64: Implement IRQ stacks.) has two bugs.

First, the softirq range check forgets to subtract STACK_BIAS
before comparing with %sp.  Next, on failure the wrong label
is jumped to, resulting in a bogus stack being loaded.

Reported-by: Igor Kovalenko <igor.v.kovalenko@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: Fix overly strict range type matching for PCI devices. 2009-12-18T21:44:08+00:00 David S. Miller davem@davemloft.net 2009-12-09T09:39:09+00:00 ec5e87a33f85e49acde6ee737c27d48595dd456a [ Upstream commit 4230fa3b89ea1c413766bd411a8315a3d05aa6c7 ] When we are trying to see if a range property entry applies to a given address, we are overly strict about the type. We should only allow I/O ranges for I/O addresses, and only allow CONFIG space ranges for CONFIG space address. However for MEM ranges, they come in 32-bit and 64-bit flavors. And a lack of an exact match is OK if the range is 32-bit and the address is 64-bit. We can assign a 64-bit address properly into a 32-bit parent range just fine. So allow it. Reported-by: Patrick Finnegan <pat@computer-refuge.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 4230fa3b89ea1c413766bd411a8315a3d05aa6c7 ]

When we are trying to see if a range property entry applies
to a given address, we are overly strict about the type.

We should only allow I/O ranges for I/O addresses, and only allow
CONFIG space ranges for CONFIG space address.

However for MEM ranges, they come in 32-bit and 64-bit flavors.
And a lack of an exact match is OK if the range is 32-bit and
the address is 64-bit.  We can assign a 64-bit address properly
into a 32-bit parent range just fine.

So allow it.

Reported-by: Patrick Finnegan <pat@computer-refuge.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: Don't specify IRQF_SHARED for LDC interrupts. 2009-12-18T21:44:07+00:00 David S. Miller davem@davemloft.net 2009-12-10T07:44:43+00:00 91c1e7f6a857670528d6dec7640e5c305cee14e6 [ Upstream commit 08a036d583409e3517e3d15b7478d029b25f2cf2 ] IRQF_SHARED and IRQF_DISABLED don't mix. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 08a036d583409e3517e3d15b7478d029b25f2cf2 ]

IRQF_SHARED and IRQF_DISABLED don't mix.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: Fix definition of VMEMMAP_SIZE. 2009-12-18T21:43:59+00:00 David S. Miller davem@davemloft.net 2009-11-24T00:38:56+00:00 bcb7797d596b725c2b6b11f24b9254385297261f [ Upstream commit bffbc94a4d2c1769c3826fceddd2dbb75e72c80b ] This was the cause of various boot failures on V480, V880, etc. systems. Kernel image memory was being overwritten because the vmemmap[] array was being sized to small. So if you had physical memory addresses past a certain point, the early bootup would spam all over variables in the kernel data section. The vmemmap mappings map page structs, not page struct pointers. And that was the key thinko in the macro definition. This was fixable thanks to the help, reports, and tireless patience of Hermann Lauer. Reported-by: Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit bffbc94a4d2c1769c3826fceddd2dbb75e72c80b ]

This was the cause of various boot failures on V480, V880, etc.
systems.

Kernel image memory was being overwritten because the vmemmap[]
array was being sized to small.  So if you had physical memory
addresses past a certain point, the early bootup would spam
all over variables in the kernel data section.

The vmemmap mappings map page structs, not page struct pointers.
And that was the key thinko in the macro definition.

This was fixable thanks to the help, reports, and tireless patience
of Hermann Lauer.

Reported-by: Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>