.39 patches

12 files changed, 614 insertions, 0 deletions

diff --git a/queue-2.6.39/cpufreq-remove-cpufreq_stats-sysfs-entries-on-module-unload.patch b/queue-2.6.39/cpufreq-remove-cpufreq_stats-sysfs-entries-on-module-unload.patch
new file mode 100644
index 0000000000..9ec1548d5e
--- /dev/null
+++ b/queue-2.6.39/cpufreq-remove-cpufreq_stats-sysfs-entries-on-module-unload.patch
@@ -0,0 +1,30 @@
+From 13f067537f34456443f61c950cd6dc37d1d5f3ee Mon Sep 17 00:00:00 2001
+From: Dave Jones <davej@redhat.com>
+Date: Sun, 12 Jun 2011 16:35:28 -0400
+Subject: CPUFREQ: Remove cpufreq_stats sysfs entries on module unload.
+
+From: Dave Jones <davej@redhat.com>
+
+commit 13f067537f34456443f61c950cd6dc37d1d5f3ee upstream.
+
+cpufreq_stats leaves behind its sysfs entries, which causes a panic
+when something stumbled across them.
+(Discovered by unloading cpufreq_stats while powertop was loaded).
+
+Signed-off-by: Dave Jones <davej@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/cpufreq/cpufreq_stats.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/cpufreq/cpufreq_stats.c
++++ b/drivers/cpufreq/cpufreq_stats.c
+@@ -388,6 +388,7 @@ static void __exit cpufreq_stats_exit(vo
+ 	unregister_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
+ 	for_each_online_cpu(cpu) {
+ 		cpufreq_stats_free_table(cpu);
++		cpufreq_stats_free_sysfs(cpu);
+ 	}
+ }
+ 
diff --git a/queue-2.6.39/igb-fix-i350-sr-iov-failture.patch b/queue-2.6.39/igb-fix-i350-sr-iov-failture.patch
new file mode 100644
index 0000000000..4db0ba9ce1
--- /dev/null
+++ b/queue-2.6.39/igb-fix-i350-sr-iov-failture.patch
@@ -0,0 +1,40 @@
+From 665c8c8ee405738375b679246b49342ce38ba056 Mon Sep 17 00:00:00 2001
+From: "Williams, Mitch A" <mitch.a.williams@intel.com>
+Date: Tue, 7 Jun 2011 14:22:57 -0700
+Subject: igb: fix i350 SR-IOV failture
+
+From: "Williams, Mitch A" <mitch.a.williams@intel.com>
+
+commit 665c8c8ee405738375b679246b49342ce38ba056 upstream.
+
+When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to
+the driver attempting to enable RSS on the PF device, which is not
+supported by the i350.
+
+When max_vfs is specified on an i350 adapter, set the number of RSS queues
+to 1.
+
+This issue affects 2.6.39 as well.
+
+Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
+Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/igb/igb_main.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/igb/igb_main.c
++++ b/drivers/net/igb/igb_main.c
+@@ -2372,6 +2372,9 @@ static int __devinit igb_sw_init(struct
+ 	}
+ #endif /* CONFIG_PCI_IOV */
+ 	adapter->rss_queues = min_t(u32, IGB_MAX_RX_QUEUES, num_online_cpus());
++	/* i350 cannot do RSS and SR-IOV at the same time */
++	if (hw->mac.type == e1000_i350 && adapter->vfs_allocated_count)
++		adapter->rss_queues = 1;
+ 
+ 	/*
+ 	 * if rss_queues > 4 or vfs are going to be allocated with rss_queues
diff --git a/queue-2.6.39/iwl4965-set-tx-power-after-rxon_assoc.patch b/queue-2.6.39/iwl4965-set-tx-power-after-rxon_assoc.patch
new file mode 100644
index 0000000000..cbbe1d6a83
--- /dev/null
+++ b/queue-2.6.39/iwl4965-set-tx-power-after-rxon_assoc.patch
@@ -0,0 +1,45 @@
+From 51892dbbd511911c0f965a36b431fc3e8f1e4f8a Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Mon, 6 Jun 2011 15:11:30 +0200
+Subject: iwl4965: set tx power after rxon_assoc
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 51892dbbd511911c0f965a36b431fc3e8f1e4f8a upstream.
+
+Setting tx power can be deferred during scan or changing channel.
+If after that correct tx power settings will not be sent to device,
+we can observe transmission problems and timeouts. Force to send
+tx power settings also after partial rxon change, to assure device
+always be configured with up-to-date settings.
+
+Resolves:
+https://bugzilla.kernel.org/show_bug.cgi?id=36492
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/iwlegacy/iwl-4965.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/iwlegacy/iwl-4965.c
++++ b/drivers/net/wireless/iwlegacy/iwl-4965.c
+@@ -1237,7 +1237,7 @@ static int iwl4965_commit_rxon(struct iw
+ 
+ 		memcpy(active_rxon, &ctx->staging, sizeof(*active_rxon));
+ 		iwl_legacy_print_rx_config_cmd(priv, ctx);
+-		return 0;
++		goto set_tx_power;
+ 	}
+ 
+ 	/* If we are currently associated and the new config requires
+@@ -1317,6 +1317,7 @@ static int iwl4965_commit_rxon(struct iw
+ 
+ 	iwl4965_init_sensitivity(priv);
+ 
++set_tx_power:
+ 	/* If we issue a new RXON command which required a tune then we must
+ 	 * send a new TXPOWER command or we won't be able to Tx any frames */
+ 	ret = iwl_legacy_set_tx_power(priv, priv->tx_power_next, true);
diff --git a/queue-2.6.39/iwlagn-use-cts-to-self-protection-on-5000-adapters-series.patch b/queue-2.6.39/iwlagn-use-cts-to-self-protection-on-5000-adapters-series.patch
new file mode 100644
index 0000000000..9e4a33516c
--- /dev/null
+++ b/queue-2.6.39/iwlagn-use-cts-to-self-protection-on-5000-adapters-series.patch
@@ -0,0 +1,100 @@
+From 42b70a5f6d18165a075d189d1bee82fad7cdbf29 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Thu, 26 May 2011 17:14:22 +0200
+Subject: iwlagn: use cts-to-self protection on 5000 adapters series
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 42b70a5f6d18165a075d189d1bee82fad7cdbf29 upstream.
+
+This patch fixes 802.11n stability and performance regression we have
+since 2.6.35. It boost performance on my 5GHz N-only network from about
+5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.
+
+These are test results of 5x downloading of approximately 700MB iso
+image:
+
+vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
+patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946
+
+This was achieved with NetworkManager configured to do not perform
+periodical scans, by configuring constant BSSID. With periodical scans,
+after some time, performance downgrade to unpatched driver level, like
+in example below:
+
+patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683
+
+However patch still make better here, since similar test on unpatched
+driver make link disconnects with below messages after some time:
+
+wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
+wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
+wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
+wlan1: authentication with 00:23:69:35:d1:3f timed out
+
+On 2.6.35 kernel patch helps against connection hangs with messages:
+
+iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
+iwlagn 0000:20:00.0: On demand firmware reload
+iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/iwlwifi/iwl-5000.c     |    1 -
+ drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c |   12 ++----------
+ drivers/net/wireless/iwlwifi/iwl-agn-rxon.c |    8 ++++++++
+ 3 files changed, 10 insertions(+), 11 deletions(-)
+
+--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
++++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
+@@ -513,7 +513,6 @@ static struct iwl_base_params iwl5000_ba
+ };
+ static struct iwl_ht_params iwl5000_ht_params = {
+ 	.ht_greenfield_support = true,
+-	.use_rts_for_aggregation = true, /* use rts/cts protection */
+ };
+ 
+ #define IWL_DEVICE_5000						\
+--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
++++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+@@ -217,17 +217,9 @@ static void iwlagn_tx_cmd_protection(str
+ 				     __le16 fc, __le32 *tx_flags)
+ {
+ 	if (info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS ||
+-	    info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT) {
++	    info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT ||
++	    info->flags & IEEE80211_TX_CTL_AMPDU)
+ 		*tx_flags |= TX_CMD_FLG_PROT_REQUIRE_MSK;
+-		return;
+-	}
+-
+-	if (priv->cfg->ht_params &&
+-	    priv->cfg->ht_params->use_rts_for_aggregation &&
+-	    info->flags & IEEE80211_TX_CTL_AMPDU) {
+-		*tx_flags |= TX_CMD_FLG_PROT_REQUIRE_MSK;
+-		return;
+-	}
+ }
+ 
+ /* Calc max signal level (dBm) among 3 possible receivers */
+--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
++++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+@@ -173,6 +173,14 @@ int iwlagn_commit_rxon(struct iwl_priv *
+ 			return 0;
+ 	}
+ 
++	/*
++	 * force CTS-to-self frames protection if RTS-CTS is not preferred
++	 * one aggregation protection method
++	 */
++	if (!(priv->cfg->ht_params &&
++	      priv->cfg->ht_params->use_rts_for_aggregation))
++		ctx->staging.flags |= RXON_FLG_SELF_CTS_EN;
++
+ 	if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) ||
+ 	    !(ctx->staging.flags & RXON_FLG_BAND_24G_MSK))
+ 		ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK;
diff --git a/queue-2.6.39/mac80211-fix-ibss-teardown-race.patch b/queue-2.6.39/mac80211-fix-ibss-teardown-race.patch
new file mode 100644
index 0000000000..c39a9ef200
--- /dev/null
+++ b/queue-2.6.39/mac80211-fix-ibss-teardown-race.patch
@@ -0,0 +1,53 @@
+From f3209bea110cade12e2b133da8b8499689cb0e2e Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 8 Jun 2011 13:27:29 +0200
+Subject: mac80211: fix IBSS teardown race
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit f3209bea110cade12e2b133da8b8499689cb0e2e upstream.
+
+Ignacy reports that sometimes after leaving an IBSS
+joining a new one didn't work because there still
+were stations on the list. He fixed it by flushing
+stations when attempting to join a new IBSS, but
+this shouldn't be happening in the first case. When
+I looked into it I saw a race condition in teardown
+that could cause stations to be added after flush,
+and thus cause this situation. Ignacy confirms that
+after applying my patch he hasn't seen this happen
+again.
+
+Reported-by: Ignacy Gawedzki <i@lri.fr>
+Debugged-by: Ignacy Gawedzki <i@lri.fr>
+Tested-by: Ignacy Gawedzki <i@lri.fr>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/ibss.c |    6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/mac80211/ibss.c
++++ b/net/mac80211/ibss.c
+@@ -967,6 +967,10 @@ int ieee80211_ibss_leave(struct ieee8021
+ 
+ 	mutex_lock(&sdata->u.ibss.mtx);
+ 
++	sdata->u.ibss.state = IEEE80211_IBSS_MLME_SEARCH;
++	memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
++	sdata->u.ibss.ssid_len = 0;
++
+ 	active_ibss = ieee80211_sta_active_ibss(sdata);
+ 
+ 	if (!active_ibss && !is_zero_ether_addr(ifibss->bssid)) {
+@@ -1000,8 +1004,6 @@ int ieee80211_ibss_leave(struct ieee8021
+ 	kfree_skb(skb);
+ 
+ 	skb_queue_purge(&sdata->skb_queue);
+-	memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
+-	sdata->u.ibss.ssid_len = 0;
+ 
+ 	del_timer_sync(&sdata->u.ibss.timer);
+ 
diff --git a/queue-2.6.39/md-check-hot_remove_disk-when-removing-disk.patch b/queue-2.6.39/md-check-hot_remove_disk-when-removing-disk.patch
new file mode 100644
index 0000000000..0c175f7c8f
--- /dev/null
+++ b/queue-2.6.39/md-check-hot_remove_disk-when-removing-disk.patch
@@ -0,0 +1,74 @@
+From 01393f3d5836b7d62e925e6f4658a7eb22b83a11 Mon Sep 17 00:00:00 2001
+From: Namhyung Kim <namhyung@gmail.com>
+Date: Thu, 9 Jun 2011 11:42:54 +1000
+Subject: md: check ->hot_remove_disk when removing disk
+
+From: Namhyung Kim <namhyung@gmail.com>
+
+commit 01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream.
+
+Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store()
+during disk removal. The linear personality only has ->hot_add_disk and
+no ->hot_remove_disk, so that removing disk in the array resulted to
+following kernel bug:
+
+$ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3]
+$ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot
+ BUG: unable to handle kernel NULL pointer dereference at           (null)
+ IP: [<          (null)>]           (null)
+ PGD c9f5d067 PUD 8575a067 PMD 0
+ Oops: 0010 [#1] SMP
+ CPU 2
+ Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg
+
+ Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO
+ RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
+ RSP: 0018:ffff880085757df0  EFLAGS: 00010282
+ RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e
+ RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000
+ RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a
+ R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff
+ R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000
+ FS:  00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
+ CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
+ CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+ Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000)
+ Stack:
+  ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000
+  ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90
+  ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98
+ Call Trace:
+  [<ffffffff8138496a>] ? slot_store+0xaa/0x265
+  [<ffffffff81384bae>] rdev_attr_store+0x89/0xa8
+  [<ffffffff8115a96a>] sysfs_write_file+0x108/0x144
+  [<ffffffff81106b87>] vfs_write+0xb1/0x10d
+  [<ffffffff8106e6c0>] ? trace_hardirqs_on_caller+0x111/0x135
+  [<ffffffff81106cac>] sys_write+0x4d/0x77
+  [<ffffffff814fe702>] system_call_fastpath+0x16/0x1b
+ Code:  Bad RIP value.
+ RIP  [<          (null)>]           (null)
+  RSP <ffff880085757df0>
+ CR2: 0000000000000000
+ ---[ end trace ba5fc64319a826fb ]---
+
+Signed-off-by: Namhyung Kim <namhyung@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/md.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -2462,7 +2462,7 @@ slot_store(mdk_rdev_t *rdev, const char
+ 		if (rdev->raid_disk == -1)
+ 			return -EEXIST;
+ 		/* personality does all needed checks */
+-		if (rdev->mddev->pers->hot_add_disk == NULL)
++		if (rdev->mddev->pers->hot_remove_disk == NULL)
+ 			return -EINVAL;
+ 		err = rdev->mddev->pers->
+ 			hot_remove_disk(rdev->mddev, rdev->raid_disk);
diff --git a/queue-2.6.39/md-raid5-fix-fua-request-handling-in-ops_run_io.patch b/queue-2.6.39/md-raid5-fix-fua-request-handling-in-ops_run_io.patch
new file mode 100644
index 0000000000..2fd827eab1
--- /dev/null
+++ b/queue-2.6.39/md-raid5-fix-fua-request-handling-in-ops_run_io.patch
@@ -0,0 +1,55 @@
+From b062962edb086011e94ec4d9eb3f6a6d814f2a8f Mon Sep 17 00:00:00 2001
+From: Namhyung Kim <namhyung@gmail.com>
+Date: Tue, 14 Jun 2011 14:20:19 +1000
+Subject: md/raid5: fix FUA request handling in ops_run_io()
+
+From: Namhyung Kim <namhyung@gmail.com>
+
+commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream.
+
+Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support")
+introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
+However remaining code still checks whether rw is exactly same
+as WRITE or not, so FUAed-write ends up with being treated as
+READ. Fix it.
+
+This bug has been present since 2.6.37 and the fix is suitable for any
+-stable kernel since then.  It is not clear why this has not caused
+more problems.
+
+Cc: Tejun Heo <tj@kernel.org>
+Signed-off-by: Namhyung Kim <namhyung@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/raid5.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -514,7 +514,7 @@ static void ops_run_io(struct stripe_hea
+ 		bi = &sh->dev[i].req;
+ 
+ 		bi->bi_rw = rw;
+-		if (rw == WRITE)
++		if (rw & WRITE)
+ 			bi->bi_end_io = raid5_end_write_request;
+ 		else
+ 			bi->bi_end_io = raid5_end_read_request;
+@@ -548,13 +548,13 @@ static void ops_run_io(struct stripe_hea
+ 			bi->bi_io_vec[0].bv_offset = 0;
+ 			bi->bi_size = STRIPE_SIZE;
+ 			bi->bi_next = NULL;
+-			if (rw == WRITE &&
++			if ((rw & WRITE) &&
+ 			    test_bit(R5_ReWrite, &sh->dev[i].flags))
+ 				atomic_add(STRIPE_SECTORS,
+ 					&rdev->corrected_errors);
+ 			generic_make_request(bi);
+ 		} else {
+-			if (rw == WRITE)
++			if (rw & WRITE)
+ 				set_bit(STRIPE_DEGRADED, &sh->state);
+ 			pr_debug("skip op %ld on disc %d for sector %llu\n",
+ 				bi->bi_rw, i, (unsigned long long)sh->sector);
diff --git a/queue-2.6.39/md-raid5-fix-raid5_set_bi_hw_segments.patch b/queue-2.6.39/md-raid5-fix-raid5_set_bi_hw_segments.patch
new file mode 100644
index 0000000000..b830782cd7
--- /dev/null
+++ b/queue-2.6.39/md-raid5-fix-raid5_set_bi_hw_segments.patch
@@ -0,0 +1,36 @@
+From 9b2dc8b665932a8e681a7ab3237f60475e75e161 Mon Sep 17 00:00:00 2001
+From: Namhyung Kim <namhyung@gmail.com>
+Date: Mon, 13 Jun 2011 14:48:22 +0900
+Subject: md/raid5: fix raid5_set_bi_hw_segments
+
+From: Namhyung Kim <namhyung@gmail.com>
+
+commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream.
+
+The @bio->bi_phys_segments consists of active stripes count in the
+lower 16 bits and processed stripes count in the upper 16 bits. So
+logical-OR operator should be bitwise one.
+
+This bug has been present since 2.6.27 and the fix is suitable for any
+-stable kernel since then.  Fortunately the bad code is only used on
+error paths and is relatively unlikely to be hit.
+
+Signed-off-by: Namhyung Kim <namhyung@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/raid5.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -129,7 +129,7 @@ static inline int raid5_dec_bi_hw_segmen
+ 
+ static inline void raid5_set_bi_hw_segments(struct bio *bio, unsigned int cnt)
+ {
+-	bio->bi_phys_segments = raid5_bi_phys_segments(bio) || (cnt << 16);
++	bio->bi_phys_segments = raid5_bi_phys_segments(bio) | (cnt << 16);
+ }
+ 
+ /* Find first data disk in a raid6 stripe */
diff --git a/queue-2.6.39/series b/queue-2.6.39/series
index 6954bfe5c4..c4c596c749 100644
--- a/queue-2.6.39/series
+++ b/queue-2.6.39/series
@@ -73,3 +73,14 @@ oprofile-free-potentially-owned-tasks-in-case-of-errors.patch
 oprofile-fix-locking-dependency-in-sync_start.patch
 oprofile-dcookies-fix-possible-circular-locking-dependency.patch
 drm-radeon-kms-do-bounds-checking-for-3d_load_vbpntr-and.patch
+iwlagn-use-cts-to-self-protection-on-5000-adapters-series.patch
+iwl4965-set-tx-power-after-rxon_assoc.patch
+igb-fix-i350-sr-iov-failture.patch
+mac80211-fix-ibss-teardown-race.patch
+x86-devicetree-add-missing-early_init_dt_setup_initrd_arch.patch
+x86-cpu-hotplug-prevent-softirq-wakeup-on-wrong-cpu.patch
+cpufreq-remove-cpufreq_stats-sysfs-entries-on-module-unload.patch
+tomoyo-fix-oops-in-tomoyo_mount_acl.patch
+md-check-hot_remove_disk-when-removing-disk.patch
+md-raid5-fix-raid5_set_bi_hw_segments.patch
+md-raid5-fix-fua-request-handling-in-ops_run_io.patch
diff --git a/queue-2.6.39/tomoyo-fix-oops-in-tomoyo_mount_acl.patch b/queue-2.6.39/tomoyo-fix-oops-in-tomoyo_mount_acl.patch
new file mode 100644
index 0000000000..ff79d9c8b4
--- /dev/null
+++ b/queue-2.6.39/tomoyo-fix-oops-in-tomoyo_mount_acl.patch
@@ -0,0 +1,33 @@
+From 4e78c724d47e2342aa8fde61f6b8536f662f795f Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Mon, 13 Jun 2011 13:49:11 +0900
+Subject: TOMOYO: Fix oops in tomoyo_mount_acl().
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 4e78c724d47e2342aa8fde61f6b8536f662f795f upstream.
+
+In tomoyo_mount_acl() since 2.6.36, kern_path() was called without checking
+dev_name != NULL. As a result, an unprivileged user can trigger oops by issuing
+mount(NULL, "/", "ext3", 0, NULL) request.
+Fix this by checking dev_name != NULL before calling kern_path(dev_name).
+
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Signed-off-by: James Morris <jmorris@namei.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ security/tomoyo/mount.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/tomoyo/mount.c
++++ b/security/tomoyo/mount.c
+@@ -138,7 +138,7 @@ static int tomoyo_mount_acl(struct tomoy
+ 	}
+ 	if (need_dev) {
+ 		/* Get mount point or device file. */
+-		if (kern_path(dev_name, LOOKUP_FOLLOW, &path)) {
++		if (!dev_name || kern_path(dev_name, LOOKUP_FOLLOW, &path)) {
+ 			error = -ENOENT;
+ 			goto out;
+ 		}
diff --git a/queue-2.6.39/x86-cpu-hotplug-prevent-softirq-wakeup-on-wrong-cpu.patch b/queue-2.6.39/x86-cpu-hotplug-prevent-softirq-wakeup-on-wrong-cpu.patch
new file mode 100644
index 0000000000..f1971fc3b2
--- /dev/null
+++ b/queue-2.6.39/x86-cpu-hotplug-prevent-softirq-wakeup-on-wrong-cpu.patch
@@ -0,0 +1,78 @@
+From fd8a7de177b6f56a0fc59ad211c197a7df06b1ad Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 20 Jul 2010 14:34:50 +0200
+Subject: x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit fd8a7de177b6f56a0fc59ad211c197a7df06b1ad upstream.
+
+After a newly plugged CPU sets the cpu_online bit it enables
+interrupts and goes idle. The cpu which brought up the new cpu waits
+for the cpu_online bit and when it observes it, it sets the cpu_active
+bit for this cpu. The cpu_active bit is the relevant one for the
+scheduler to consider the cpu as a viable target.
+
+With forced threaded interrupt handlers which imply forced threaded
+softirqs we observed the following race:
+
+cpu 0                         cpu 1
+
+bringup(cpu1);
+                              set_cpu_online(smp_processor_id(), true);
+		              local_irq_enable();
+while (!cpu_online(cpu1));
+                              timer_interrupt()
+                                -> wake_up(softirq_thread_cpu1);
+                                     -> enqueue_on(softirq_thread_cpu1, cpu0);
+
+                                                                        ^^^^
+
+cpu_notify(CPU_ONLINE, cpu1);
+  -> sched_cpu_active(cpu1)
+     -> set_cpu_active((cpu1, true);
+
+When an interrupt happens before the cpu_active bit is set by the cpu
+which brought up the newly onlined cpu, then the scheduler refuses to
+enqueue the woken thread which is bound to that newly onlined cpu on
+that newly onlined cpu due to the not yet set cpu_active bit and
+selects a fallback runqueue. Not really an expected and desirable
+behaviour.
+
+So far this has only been observed with forced hard/softirq threading,
+but in theory this could happen without forced threaded hard/softirqs
+as well. It's probably unobservable as it would take a massive
+interrupt storm on the newly onlined cpu which causes the softirq loop
+to wake up the softirq thread and an even longer delay of the cpu
+which waits for the cpu_online bit.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/smpboot.c |   13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/arch/x86/kernel/smpboot.c
++++ b/arch/x86/kernel/smpboot.c
+@@ -285,6 +285,19 @@ notrace static void __cpuinit start_seco
+ 	per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
+ 	x86_platform.nmi_init();
+ 
++	/*
++	 * Wait until the cpu which brought this one up marked it
++	 * online before enabling interrupts. If we don't do that then
++	 * we can end up waking up the softirq thread before this cpu
++	 * reached the active state, which makes the scheduler unhappy
++	 * and schedule the softirq thread on the wrong cpu. This is
++	 * only observable with forced threaded interrupts, but in
++	 * theory it could also happen w/o them. It's just way harder
++	 * to achieve.
++	 */
++	while (!cpumask_test_cpu(smp_processor_id(), cpu_active_mask))
++		cpu_relax();
++
+ 	/* enable local interrupts */
+ 	local_irq_enable();
+ 
diff --git a/queue-2.6.39/x86-devicetree-add-missing-early_init_dt_setup_initrd_arch.patch b/queue-2.6.39/x86-devicetree-add-missing-early_init_dt_setup_initrd_arch.patch
new file mode 100644
index 0000000000..65462921d3
--- /dev/null
+++ b/queue-2.6.39/x86-devicetree-add-missing-early_init_dt_setup_initrd_arch.patch
@@ -0,0 +1,59 @@
+From 977cb76d52e7aa040e18a84b29fe6fd80d79319b Mon Sep 17 00:00:00 2001
+From: Florian Fainelli <ffainelli@freebox.fr>
+Date: Mon, 6 Jun 2011 10:15:49 +0200
+Subject: x86: devicetree: Add missing early_init_dt_setup_initrd_arch
+ stub
+
+From: Florian Fainelli <ffainelli@freebox.fr>
+
+commit 977cb76d52e7aa040e18a84b29fe6fd80d79319b upstream.
+
+This patch fixes the following build failure:
+
+drivers/built-in.o: In function `early_init_dt_check_for_initrd':
+/home/florian/dev/kernel/x86/linux-2.6-x86/drivers/of/fdt.c:571:
+undefined reference to `early_init_dt_setup_initrd_arch'
+make: *** [.tmp_vmlinux1] Error 1
+
+which happens as soon as we enable initrd support on a x86 devicetree
+platform such as Intel CE4100.
+
+Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
+Acked-by: Grant Likely <grant.likely@secretlab.ca>
+Cc: Maxime Bizon <mbizon@freebox.fr>
+Acked-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
+Link: http://lkml.kernel.org/r/201106061015.50039.ffainelli@freebox.fr
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/devicetree.c |   11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/x86/kernel/devicetree.c
++++ b/arch/x86/kernel/devicetree.c
+@@ -13,6 +13,7 @@
+ #include <linux/slab.h>
+ #include <linux/pci.h>
+ #include <linux/of_pci.h>
++#include <linux/initrd.h>
+ 
+ #include <asm/hpet.h>
+ #include <asm/irq_controller.h>
+@@ -98,6 +99,16 @@ void * __init early_init_dt_alloc_memory
+ 	return __alloc_bootmem(size, align, __pa(MAX_DMA_ADDRESS));
+ }
+ 
++#ifdef CONFIG_BLK_DEV_INITRD
++void __init early_init_dt_setup_initrd_arch(unsigned long start,
++					    unsigned long end)
++{
++	initrd_start = (unsigned long)__va(start);
++	initrd_end = (unsigned long)__va(end);
++	initrd_below_start_ok = 1;
++}
++#endif
++
+ void __init add_dtb(u64 data)
+ {
+ 	initial_dtb = data + offsetof(struct setup_data, data);