talos-op-linux/arch, branch v2.6.36-rc8

Don't dump task struct in a.out core-dumps

2010-10-14T17:57:40+00:00

akiphie points out that a.out core-dumps have that odd task struct dumping that was never used and was never really a good idea (it goes back into the mists of history, probably the original core-dumping code). Just remove it. Also do the access_ok() check on dump_write(). It probably doesn't matter (since normal filesystems all seem to do it anyway), but he points out that it's normally done by the VFS layer, so ... [ I suspect that we should possibly do "vfs_write()" instead of calling ->write directly. That also does the whole fsnotify and write statistics thing, which may or may not be a good idea. ] And just to be anal, do this all for the x86-64 32-bit a.out emulation code too, even though it's not enabled (and won't currently even compile) Reported-by: akiphie Signed-off-by: Linus Torvalds

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

2010-10-13T23:35:33+00:00

* master.kernel.org:/home/rmk/linux-2.6-arm: ARM: relax ioremap prohibition (309caa9) for -final and -stable ARM: 6440/1: ep93xx: DMA: fix channel_disable cpuimx27: fix i2c bus selection cpuimx27: fix compile when ULPI is selected ARM: 6435/1: Fix HWCAP_TLS flag for ARM11MPCore/Cortex-A9 ARM: 6436/1: AT91: Fix power-saving in idle-mode on 926T processors ARM: fix section mismatch warnings in Versatile Express ARM: 6412/1: kprobes-decode: add support for MOVW instruction ARM: 6419/1: mmu: Fix MT_MEMORY and MT_MEMORY_NONCACHED pte flags ARM: 6416/1: errata: faulty hazard checking in the Store Buffer may lead to data corruption

Merge branch 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

2010-10-13T23:35:05+00:00

* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: omap: iommu-load cam register before flushing the entry

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2010-10-13T23:34:23+00:00

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, numa: For each node, register the memory blocks actually used x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order x86, mce, therm_throt.c: Fix missing curly braces in error handling logic

ARM: relax ioremap prohibition (309caa9) for -final and -stable

2010-10-12T23:19:03+00:00

... but produce a big warning about the problem as encouragement for people to fix their drivers. Signed-off-by: Russell King

Merge branch 'for-rmk' of git://git.pengutronix.de/git/imx/linux-2.6

2010-10-12T21:43:36+00:00

ARM: 6440/1: ep93xx: DMA: fix channel_disable

2010-10-12T21:43:19+00:00

When channel_disable() is called, it disables per channel interrupts and waits until channels state becomes STATE_STALL, and then disables the channel. Now, if the DMA transfer is disabled while the channel is in STATE_NEXT we will not wait anything and disable the channel immediately. This seems to cause weird data corruption for example in audio transfers. Fix is to wait while we are in STATE_NEXT or STATE_ON and only then disable the channel. Signed-off-by: Mika Westerberg Acked-by: Ryan Mallon Signed-off-by: Russell King

x86, numa: For each node, register the memory blocks actually used

2010-10-11T22:26:15+00:00

Russ reported SGI UV is broken recently. He said: | The SRAT table shows that memory range is spread over two nodes. | | SRAT: Node 0 PXM 0 100000000-800000000 | SRAT: Node 1 PXM 1 800000000-1000000000 | SRAT: Node 0 PXM 0 1000000000-1080000000 | |Previously, the kernel early_node_map[] would show three entries |with the proper node. | |[ 0.000000] 0: 0x00100000 -> 0x00800000 |[ 0.000000] 1: 0x00800000 -> 0x01000000 |[ 0.000000] 0: 0x01000000 -> 0x01080000 | |The problem is recent community kernel early_node_map[] shows |only two entries with the node 0 entry overlapping the node 1 |entry. | | 0: 0x00100000 -> 0x01080000 | 1: 0x00800000 -> 0x01000000 After looking at the changelog, Found out that it has been broken for a while by following commit |commit 8716273caef7f55f39fe4fc6c69c5f9f197f41f1 |Author: David Rientjes |Date: Fri Sep 25 15:20:04 2009 -0700 | | x86: Export srat physical topology Before that commit, register_active_regions() is called for every SRAT memory entry right away. Use nodememblk_range[] instead of nodes[] in order to make sure we capture the actual memory blocks registered with each node. nodes[] contains an extended range which spans all memory regions associated with a node, but that does not mean that all the memory in between are included. Reported-by: Russ Anderson Tested-by: Russ Anderson Signed-off-by: Yinghai Lu LKML-Reference: <4CB27BDF.5000800@kernel.org> Acked-by: David Rientjes Cc: 2.6.33 .34 .35 .36 Signed-off-by: H. Peter Anvin

KVM: x86: Move TSC reset out of vmcb_init

2010-10-11T10:36:07+00:00

The VMCB is reset whenever we receive a startup IPI, so Linux is setting TSC back to zero happens very late in the boot process and destabilizing the TSC. Instead, just set TSC to zero once at VCPU creation time. Why the separate patch? So git-bisect is your friend. Signed-off-by: Zachary Amsden Signed-off-by: Marcelo Tosatti

KVM: x86: Fix SVM VMCB reset

2010-10-11T10:36:07+00:00

On reset, VMCB TSC should be set to zero. Instead, code was setting tsc_offset to zero, which passes through the underlying TSC. Signed-off-by: Zachary Amsden Signed-off-by: Marcelo Tosatti