Linux v3.13.5
This commit is contained in:
parent
ebd6e20919
commit
a294ed94df
|
@ -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
17
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 <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
2
sources
|
@ -1,2 +1,2 @@
|
|||
0ecbaf65c00374eb4a826c2f9f37606f linux-3.13.tar.xz
|
||||
77ca721ea0e8373f58f596fe0d9b1b47 patch-3.13.4.xz
|
||||
114c391a592131f1c12544e063173a45 patch-3.13.5.xz
|
||||
|
|
|
@ -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/
|
Loading…
Reference in New Issue