diff --git a/ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch b/ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch deleted file mode 100644 index bbfd57839..000000000 --- a/ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch +++ /dev/null @@ -1,65 +0,0 @@ -Bugzilla: 990955 -Upstream-status: Sent for 3.14, CC'd to stable - -sta_rc_update() callback must be atomic, hence we can not take mutexes -or do other operations, which can sleep in ath9k_htc_sta_rc_update(). - -I think we can just return from ath9k_htc_sta_rc_update(), if it is -called without IEEE80211_RC_SUPP_RATES_CHANGED bit. That will help -with scheduling while atomic bug for most cases (except mesh and IBSS -modes). - -For mesh and IBSS I do not see other solution like creating additional -workqueue, because sending firmware command require us to sleep, but -this can be done in additional patch. - -Patch partially fixes bug: -https://bugzilla.redhat.com/show_bug.cgi?id=990955 - -Cc: stable@vger.kernel.org -Signed-off-by: Stanislaw Gruszka ---- - drivers/net/wireless/ath/ath9k/htc_drv_main.c | 25 +++++++++++++------------ - 1 file changed, 13 insertions(+), 12 deletions(-) - -diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c -index 608d739..a57af9b 100644 ---- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c -+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c -@@ -1315,21 +1315,22 @@ static void ath9k_htc_sta_rc_update(struct ieee80211_hw *hw, - struct ath_common *common = ath9k_hw_common(priv->ah); - struct ath9k_htc_target_rate trate; - -+ if (!(changed & IEEE80211_RC_SUPP_RATES_CHANGED)) -+ return; -+ - mutex_lock(&priv->mutex); - ath9k_htc_ps_wakeup(priv); - -- if (changed & IEEE80211_RC_SUPP_RATES_CHANGED) { -- memset(&trate, 0, sizeof(struct ath9k_htc_target_rate)); -- ath9k_htc_setup_rate(priv, sta, &trate); -- if (!ath9k_htc_send_rate_cmd(priv, &trate)) -- ath_dbg(common, CONFIG, -- "Supported rates for sta: %pM updated, rate caps: 0x%X\n", -- sta->addr, be32_to_cpu(trate.capflags)); -- else -- ath_dbg(common, CONFIG, -- "Unable to update supported rates for sta: %pM\n", -- sta->addr); -- } -+ memset(&trate, 0, sizeof(struct ath9k_htc_target_rate)); -+ ath9k_htc_setup_rate(priv, sta, &trate); -+ if (!ath9k_htc_send_rate_cmd(priv, &trate)) -+ ath_dbg(common, CONFIG, -+ "Supported rates for sta: %pM updated, rate caps: 0x%X\n", -+ sta->addr, be32_to_cpu(trate.capflags)); -+ else -+ ath_dbg(common, CONFIG, -+ "Unable to update supported rates for sta: %pM\n", -+ sta->addr); - - ath9k_htc_ps_restore(priv); - mutex_unlock(&priv->mutex); --- -1.7.11.7 diff --git a/kernel.spec b/kernel.spec index 5d34a224d..fbcf2d451 100644 --- a/kernel.spec +++ b/kernel.spec @@ -74,7 +74,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 4 +%define stable_update 5 # Is it a -stable RC? %define stable_rc 0 # Set rpm version accordingly @@ -747,15 +747,9 @@ Patch25183: 0003-Input-wacom-add-reporting-of-SW_MUTE_DEVICE-events.patch #rhbz 953211 Patch25184: Input-ALPS-add-support-for-Dolphin-devices.patch -#rhbz 990955 -Patch25186: ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch - #rhbz 950630 Patch25187: xhci-fix-resume-issues-on-renesas-chips-in-samsung-laptops.patch -#rhbz 1031296 -Patch25189: tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch - #rhbz 1045755 Patch25195: cgroup-fixes.patch @@ -1466,15 +1460,9 @@ ApplyPatch 0003-Input-wacom-add-reporting-of-SW_MUTE_DEVICE-events.patch #rhbz 953211 ApplyPatch Input-ALPS-add-support-for-Dolphin-devices.patch -#rhbz 990955 -ApplyPatch ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch - #rhbz 950630 ApplyPatch xhci-fix-resume-issues-on-renesas-chips-in-samsung-laptops.patch -#rhbz 1031296 -ApplyPatch tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch - #rhbz 1045755 ApplyPatch cgroup-fixes.patch @@ -2305,6 +2293,9 @@ fi # and build. %changelog +* Mon Feb 24 2014 Justin M. Forbes +- Linux v3.13.5 + * Fri Feb 21 2014 Josh Boyer - Fix WARN from e100 from Michele Baldessari (rhbz 994438) diff --git a/sources b/sources index 866078c24..a6d6949ac 100644 --- a/sources +++ b/sources @@ -1,2 +1,2 @@ 0ecbaf65c00374eb4a826c2f9f37606f linux-3.13.tar.xz -77ca721ea0e8373f58f596fe0d9b1b47 patch-3.13.4.xz +114c391a592131f1c12544e063173a45 patch-3.13.5.xz diff --git a/tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch b/tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch deleted file mode 100644 index a0d58cf4d..000000000 --- a/tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch +++ /dev/null @@ -1,88 +0,0 @@ -On Mon, 10 Feb 2014, Thomas Gleixner wrote: -> On Mon, 10 Feb 2014, poma wrote: -> -> > [ 83.558551] [] amd_e400_idle+0x87/0x130 -> -> So this seems to happen only on AMD machines which use that e400 idle -> mode. I have no idea at the moment whats wrong there. I'll find one of -> those machines and try to reproduce. - -Found it. Patch below. - -Thanks, - - tglx ----- -Subject: tick: Clear broadcast pending bit when switching to oneshot -From: Thomas Gleixner -Date: Tue, 11 Feb 2014 14:35:40 +0100 - -AMD systems which use the C1E workaround in the amd_e400_idle routine -trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU. - -The reason is that the idle routine of those AMD systems switches the -cpu into forced broadcast mode early on before the newly brought up -CPU can switch over to high resolution / NOHZ mode. The timer related -CPU1 bringup looks like this: - - clockevent_register_device(local_apic); - tick_setup(local_apic); - ... - idle() - tick_broadcast_on_off(FORCE); - tick_broadcast_oneshot_control(ENTER) - cpumask_set(cpu, broadcast_oneshot_mask); - halt(); - -Now the broadcast interrupt on CPU0 sets CPU1 in the -broadcast_pending_mask and wakes CPU1. So CPU1 continues: - - local_apic_timer_interrupt() - tick_handle_periodic(); - softirq() - tick_init_highres(); - cpumask_clr(cpu, broadcast_oneshot_mask); - - tick_broadcast_oneshot_control(ENTER) - WARN_ON(cpumask_test(cpu, broadcast_pending_mask); - -So while we remove CPU1 from the broadcast_oneshot_mask when we switch -over to highres mode, we do not clear the pending bit, which then -triggers the warning when we go back to idle. - -The reason why this is only visible on C1E affected AMD systems is -that the other machines enter the deep sleep states via -acpi_idle/intel_idle and exit the broadcast mode before executing the -remote triggered local_apic_timer_interrupt. So the pending bit is -already cleared when the switch over to highres mode is clearing the -oneshot mask. - -The solution is simple: Clear the pending bit together with the mask -bit when we switch over to highres mode. - -Reported-by: poma -Cc: stable@vger.kernel.org # 3.10+ -Signed-off-by: Thomas Gleixner ---- - kernel/time/tick-broadcast.c | 1 + - 1 file changed, 1 insertion(+) - -Index: linux-2.6/kernel/time/tick-broadcast.c -=================================================================== ---- linux-2.6.orig/kernel/time/tick-broadcast.c -+++ linux-2.6/kernel/time/tick-broadcast.c -@@ -756,6 +756,7 @@ out: - static void tick_broadcast_clear_oneshot(int cpu) - { - cpumask_clear_cpu(cpu, tick_broadcast_oneshot_mask); -+ cpumask_clear_cpu(cpu, tick_broadcast_pending_mask); - } - - static void tick_broadcast_init_next_event(struct cpumask *mask, - - --- -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html -Please read the FAQ at http://www.tux.org/lkml/ \ No newline at end of file