kernel/linux.git, branch v2.6.24-rc8

Linux 2.6.24-rc8

2008-01-16T04:22:48+00:00

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

2008-01-15T22:26:55+00:00

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

Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev

2008-01-15T21:49:09+00:00

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata: correct handling of TSS DVD [libata] core checkpatch fix [libata] pata_bf54x: checkpatch fixes libata fixes for sparse-found problems

libata: correct handling of TSS DVD

2008-01-15T21:35:21+00:00

Devices that misreport the validity bit for word 93 look like SATA. If they are on the blacklist then we must not test for SATA but assume 40 wire in the 40 wire case (The TSSCorp reports 80 wire on SATA it seems!) Signed-off-by: Alan Cox Cc: Tejun Heo Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

[libata] core checkpatch fix

2008-01-15T20:59:18+00:00

Cc: Alan Cox Cc: Jeff Garzik Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

[libata] pata_bf54x: checkpatch fixes

2008-01-15T20:58:59+00:00

WARNING: line over 80 characters #36: FILE: drivers/ata/pata_bf54x.c:1512: + while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) { ERROR: need spaces around that '>' (ctx:VxV) #36: FILE: drivers/ata/pata_bf54x.c:1512: + while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) { ^ total: 1 errors, 1 warnings, 19 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jeff Garzik Cc: Sonic Zhang Cc: Tejun Heo Cc: sonic zhang Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

libata fixes for sparse-found problems

2008-01-15T20:58:36+00:00

In pata_legacy and pata_winbond we've got bugs - cpu_to_le16() instead of cpu_to_le32(). Fortunately, both affected suckers are VLB, thus l-e-only, so we might get away with that unless we hit it with slop == 3 (hadn't checked if playing with badly aligned sg could trigger that). Still buggy... Moreover, pata_legacy, pata_winbond and pata_qdi forgot to initialize pad on the write side of 32bit case in their ->data_xfer(). Hopefully the hardware does't care, but still, sending uninitialized data to it... Signed-off-by: Al Viro Signed-off-by: Jeff Garzik

Fix Blackfin HARDWARE_PM support

2008-01-15T20:32:30+00:00

This patch restores the blackfin Hardware Performance Monitor Profiling support that was killed by the combining of instrumentation menus in commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9. Since there seems to be no good reason to behave differently from other architectures, it now automatically selects the hardware performance counters whenever the profiling is activated. mach-common/irqpanic.c: pm_overflow calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt that setting HARDWARE_PM as "m" will work at all, since the pm_overflow_handler should be in the core kernel image because it is called by irqpanic.c. Therefore, I change HARDWARE_PM from a tristate to a bool. The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since part of the HARDWARE_PM support files sits in this directory, it makes sense to also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on PROFILING, it is correct to only depend on OPROFILE only. Thanks to Adrian Bunk for finding this bug and providing an initial patch. Signed-off-by: Mathieu Desnoyers CC: Adrian Bunk CC: Randy Dunlap CC: bryan.wu@analog.com Acked-by: Robin Getz Signed-off-by: Linus Torvalds

Fix ARM profiling/instrumentation configuration

2008-01-15T17:23:51+00:00

Commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 ("Combine instrumentation menus in kernel/Kconfig.instrumentation") broke ARM profiling support, since ARM has some extra Kconfig options and doesn't just use the common OPROFILE/KPROBES config options. Rather than just revert the thing outright, or add ARM-specific knowledge to the generic Kconfig.instrumentation file (where the only and whole point was to be generic, not too architecture-specific), this just makes ARM not use the generic version, since it doesn't suit it. So create an arm-specific version of Kconfig.instrumentation instead, and use that. Acked-by: Ingo Molnar Acked-by: Russell King Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86

2008-01-15T16:08:40+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTC x86: asm-x86/msr.h: pull in linux/types.h x86: fix boot crash on HIGHMEM4G && SPARSEMEM