rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v3.13.5

This commit is contained in:
Justin M. Forbes 2014-02-24 09:59:18 -06:00
parent 87ff8590f6
commit f7f0adff73
4 changed files with 5 additions and 167 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
ath9k_htc-make-sta_rc_update-atomic-for-most-calls.patch
View File

@ -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 <sgruszka@redhat.com>
---
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

17
kernel.spec
View File

@ -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
@ -741,15 +741,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
@ -1464,15 +1458,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
@ -2302,6 +2290,9 @@ fi
# ||----w |
# || ||
%changelog
* Mon Feb 24 2014 Justin M. Forbes <jforbes@fedoraproject.org>
- Linux v3.13.5
* Fri Feb 21 2014 Josh Boyer <jwboyer@fedoraproject.org>
- Fix WARN from e100 from Michele Baldessari (rhbz 994438)

2
sources
View File

@ -1,2 +1,2 @@
0ecbaf65c00374eb4a826c2f9f37606f linux-3.13.tar.xz
77ca721ea0e8373f58f596fe0d9b1b47 patch-3.13.4.xz
114c391a592131f1c12544e063173a45 patch-3.13.5.xz

88
tick-Clear-broadcast-pending-bit-when-switching-to-oneshot.patch
View File

@ -1,88 +0,0 @@
On Mon, 10 Feb 2014, Thomas Gleixner wrote:
> On Mon, 10 Feb 2014, poma wrote:
>
> > [ 83.558551] [<ffffffff81025b17>] 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 <tglx@linutronix.de>
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 <pomidorabelisima@gmail.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
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/