kernel/linux.git, branch v2.6.32.7

Linux 2.6.32.7

2010-01-28T23:06:20+00:00

x86, msr/cpuid: Pass the number of minors when unregistering MSR and CPUID drivers.

2010-01-28T23:03:02+00:00

commit da482474b8396e1a099c37ffc6541b78775aedb4 upstream. Pass the number of minors when unregistering MSR and CPUID drivers. Reported-by: Dean Nelson Signed-off-by: Dean Nelson LKML-Reference: <20100127023722.GA22305@sgi.com> Signed-off-by: Russ Anderson Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

fnctl: f_modown should call write_lock_irqsave/restore

2010-01-28T23:03:00+00:00

commit b04da8bfdfbbd79544cab2fadfdc12e87eb01600 upstream. Commit 703625118069f9f8960d356676662d3db5a9d116 exposed that f_modown() should call write_lock_irqsave instead of just write_lock_irq so that because a caller could have a spinlock held and it would not be good to renable interrupts. Cc: Eric W. Biederman Cc: Al Viro Cc: Alan Cox Cc: Tavis Ormandy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

iwlwifi: Fix throughput stall issue in HT mode for 5000

2010-01-28T23:02:56+00:00

commit 1152dcc28c66a74b5b3f1a3ede0aa6729bfd48e4 upstream Similar to 6000 and 1000 series, RTS/CTS is the recommended protection mechanism for 5000 series in HT mode based on the HW design. Using RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment, it also prevent uCode encounter TX FIFO underrun and other HT mode related performance issues. Signed-off-by: Wey-Yi Guy Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C

2010-01-28T23:02:54+00:00

upstream in 2.6.33-rc: 5d76b6f6c17572e662f5c99c2023adae92100855 Refreshed here for 2.6.32.y, applies w/ offset back to 2.6.29.y. Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec, and the ACPI spec is clear that is correct FADT-supplied C2. However, the ACPI spec explicitly states that _CST-supplied C-states have no latency limits. So move the 100usec C2 test out of the code shared by FADT and _CST code-paths, and into the FADT-specific path. This bug has not been visible until Nehalem, which advertises a CPU-C2 worst case exit latency on servers of 205usec. That (incorrect) figure is being used by BIOS writers on mobile Nehalem systems for the AC configuration. Thus, Linux ignores C2 leaving just C1, which is saves less power, and also impacts performance by preventing the use of turbo mode. http://bugzilla.kernel.org/show_bug.cgi?id=15064 Tested-by: Alex Chiang Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

x86: Reenable TSC sync check at boot, even with NONSTOP_TSC

2010-01-28T23:02:52+00:00

commit 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7 upstream. Commit 83ce4009 did the following change If the TSC is constant and non-stop, also set it reliable. But, there seems to be few systems that will end up with TSC warp across sockets, depending on how the cpus come out of reset. Skipping TSC sync test on such systems may result in time inconsistency later. So, reenable TSC sync test even on constant and non-stop TSC systems. Set, sched_clock_stable to 1 by default and reset it in mark_tsc_unstable, if TSC sync fails. This change still gives perf benefit mentioned in 83ce4009 for systems where TSC is reliable. Signed-off-by: Venkatesh Pallipadi Acked-by: Suresh Siddha LKML-Reference: <20091217202702.GA18015@linux-os.sc.intel.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

IPoIB: Clear ipoib_neigh.dgid in ipoib_neigh_alloc()

2010-01-28T23:02:51+00:00

commit 0cd4d0fd9b0a4e10c091fc6316d1bf92885dcd9c upstream. IPoIB can miss a change in destination GID under some conditions. The problem is caused when ipoib_neigh->dgid contains a stale address. The fix is to set ipoib_neigh->dgid to zero in ipoib_neigh_alloc(). This can happen when a system using bonding on its IPoIB interfaces has switched its active interface from interface A to B and back to A. The system that fails over will not correctly processes the 2nd address change, as described below. When an address has changed neighbor->ha is updated with the new address. Each neighbor has an associated ipoib_neigh. ipoib_neigh->dgid also holds a copy of the remote node's hardware address. When an address changes neighbor->ha is updated by the network layer (arp code) with the new address. IPoIB detects this change in ipoib_start_xmit() by comparing neighbor->ha with ipoib_neigh->dgid. The bug is that ipoib_neigh->dgid may already contain the new address (A) thus the change from B to A is missed by ipoib. Here is the sequence of events: ipoib_neigh->dgid = A and neighbor->ha = A The address is switched to B (the first switch) neighbor->ha = B The change is seen in ipoib_start_xmit() -- neighbor->ha != ipoib_neigh->dgid so ipoib_neigh is released, and a new one is allocated. The allocator may return the same chunk of memory that was just released, therefore ipoib_neigh->dgid still contains A at this point. ipoib_neigh->dgid should be updated in neigh_add_path(), but if the following conditions are true dgid is not updated: 1) __path_find() returns a path 2) path->ah is NULL The remote system now switches from address B to A, neighbor->ha is updated to A. Now we have again : ipoib_neigh->dgid = A and neighbor->ha = A Since the addresses are the same ipoib won't process the change in address. Fix this by zeroing out the dgid field when allocating a new struct ipoib_neigh. Signed-off-by: David Wilder Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

KVM: only clear irq_source_id if irqchip is present

2010-01-28T23:02:50+00:00

commit e50212bb51356f0df48d6cce0aae5acf41df336d upstream. Otherwise kvm might attempt to dereference a NULL pointer. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: fix lock imbalance in kvm_*_irq_source_id()

2010-01-28T23:02:49+00:00

commit 0c6ddcebd8303ada6faefa6f72ac18b6230320c4 upstream. Stanse found 2 lock imbalances in kvm_request_irq_source_id and kvm_free_irq_source_id. They omit to unlock kvm->irq_lock on fail paths. Fix that by adding unlock labels at the end of the functions and jump there from the fail paths. Signed-off-by: Jiri Slaby Cc: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: x86: Fix leak of free lapic date in kvm_arch_vcpu_init()

2010-01-28T23:02:48+00:00

commit 443c39bc9ef7d8f648408d74c97e943f3bb3f48a upstream. In function kvm_arch_vcpu_init(), if the memory malloc for vcpu->arch.mce_banks is fail, it does not free the memory of lapic date. This patch fixed it. Signed-off-by: Wei Yongjun Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman