Skip to content

L
linux
Switch branch/tag
  1. 10 May, 2011 4 commits
    • Paul Fox's avatar
      libertas: fix cmdpendingq locking · 2ae1b8b3
      Paul Fox authored 
      We occasionally see list corruption using libertas.

While we haven't been able to diagnose this precisely, we have spotted
a possible cause: cmdpendingq is generally modified with driver_lock
held. However, there are a couple of points where this is not the case.

Fix up those operations to execute under the lock, it seems like
the correct thing to do and will hopefully improve the situation.
Signed-off-by: default avatarPaul Fox <pgf@laptop.org>
Signed-off-by: default avatarDaniel Drake <dsd@laptop.org>
Acked-by: default avatarDan Williams <dcbw@redhat.com>
Cc: stable@kernel.org
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2ae1b8b3
    • Stanislaw Gruszka's avatar
      iwlegacy: fix IBSS mode crashes · eb85de3f
      Stanislaw Gruszka authored 
      We should not switch to non-IBSS channels when working in IBSS mode,
otherwise there are microcode errors, and after some time system
crashes.

This bug is only observable when software scan is used in IBSS mode,
so should be considered as regression after:

commit 0263aa45
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Mar 29 11:24:21 2011 +0200

    iwl3945: disable hw scan by default

However IBSS mode check, which this patch add again, was removed by

commit b2f30e8b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 21 07:32:20 2010 -0800

    iwlwifi: remove IBSS channel sanity check

That commit claim that mac80211 will not use non-IBSS channel in IBSS
mode, what definitely is not true. Bug probably should be fixed in
mac80211, but that will require more work, so better to apply that patch
temporally, and provide proper mac80211 fix latter.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=34452Reported-and-tested-by: default avatarMikko Rapeli <mikko.rapeli@iki.fi>
Cc: stable@kernel.org # 2.6.38.5+
Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eb85de3f
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix a warning due to a queued work during S3 state · 99aa55b6
      Mohammed Shafi Shajakhan authored 
      during suspend/S3 state drv_flush is called from mac80211 irrespective of
interface count. In ath9k we queue a work in ath9k_flush which we expect
to be cancelled in the drv_stop call back. during suspend process mac80211
calls drv_stop only when the interface count(local->count) is non-zero.
unfortunately when the network manager is enabled, drv_flush is called
while drv_stop is not called as local->count reaches '0'.
	So fix this by simply checking for the device presence in the
drv_flush call back in the driver before queueing work or anything else.
this patch fixes the following WARNING

	Call Trace:
	[<c014c6e2>] warn_slowpath_common+0x72/0xa0
	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<c014c75b>] warn_slowpath_fmt+0x2b/0x30
	[<fc133f99>] ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<fc134ed1>] ieee80211_queue_delayed_work+0x21/0x50 [mac80211]
	[<fc1e5b22>] ath_tx_complete_poll_work+0xb2/0x100 [ath9k]
	[<c016399e>] run_workqueue+0x8e/0x150
	[<fc1e5a70>] ? ath_tx_complete_poll_work+0x0/0x100 [ath9k]
	[<c0163ae4>] worker_thread+0x84/0xe0
	[<c0167a60>] ? autoremove_wake_function+0x0/0x50
	[<c0163a60>] ? worker_thread+0x0/0xe0
	[<c01677d4>] kthread+0x74/0x80
	[<c0167760>] ? kthread+0x0/0x80
	[<c0104087>] kernel_thread_helper+0x7/0x10
---[ end trace 2aff81010df9215b ]---
Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: default avatarMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      99aa55b6
    • Luciano Coelho's avatar
      mac80211: don't start the dynamic ps timer if not associated · 5db1c07c
      Luciano Coelho authored 
      When we are disconnecting, we set PS off, but this happens before we
send the deauth/disassoc request.  When the deauth/disassoc frames are
sent, we trigger the dynamic ps timer, which then times out and turns
PS back on.  Thus, PS remains on after disconnecting, causing problems
when associating again.

This can be fixed by preventing the timer to start when we're not
associated anymore.
Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5db1c07c
  3. 29 Apr, 2011 2 commits
  5. 28 Apr, 2011 3 commits
  7. 20 Apr, 2011 4 commits
  9. 19 Apr, 2011 1 commit
  11. 18 Apr, 2011 5 commits
  13. 13 Apr, 2011 1 commit
  15. 12 Apr, 2011 2 commits
    • Sujith Manoharan's avatar
      ath9k_htc: Fix ethtool reporting · 50f68712
      Sujith Manoharan authored 
      Pass the correct module name and device interface so that
ethtool can display the proper values.

The firmware version will be fixed later on when the FW
can actually report a version. :)
Reported-by: default avatarRichard Farina <sidhayn@gmail.com>
Signed-off-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
Tested-by: default avatarRichard Farina <sidhayn@gmail.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50f68712
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored 
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.

This typically shows up in the kernel log with messages like these:

ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<8023f0e8>] dump_stack+0x8/0x34
[<80075050>] warn_slowpath_common+0x78/0xa4
[<80075094>] warn_slowpath_null+0x18/0x24
[<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]

When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.

This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  17. 11 Apr, 2011 1 commit
  19. 08 Apr, 2011 2 commits
  21. 07 Apr, 2011 3 commits
  23. 04 Apr, 2011 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7