- 08 Dec, 2011 1 commit
-
-
Hauke Mehrtens authored
This fixes a Data bus error on some SoCs. The first fix for this problem did not solve it on all devices. commit 6ae8ec27 Author: Rafał Miłecki <zajec5@gmail.com> Date: Tue Jul 5 17:25:32 2011 +0200 ssb: fix init regression of hostmode PCI core In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is accessed, but the sprom only exists when the ssb bus is connected over a PCI bus to the rest of the system and not when the SSB Bus is the main system bus. SoCs sometimes have a PCI host controller and there this code will not be executed, but there are some old SoCs with an PCI controller in client mode around and ssb_pcicore_fix_sprom_core_index() should not be called on these devices too. The PCI controller on these devices are unused, but without this fix it results in an Data bus error when it gets initialized. Cc: Michael Buesch <m@bues.ch> Cc: Rafał Miłecki <zajec5@gmail.com> Signed-off-by:Hauke Mehrtens <hauke@hauke-m.de> Cc: stable@vger.kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 07 Dec, 2011 2 commits
-
-
Philipp Dreimann authored
In drivers rtl8192ce, rtl8192cu, rtl8192se, and rtl8192de, break statements would allow ppsc->rfpwr_state to be changed to ERFSLEEP even though the device is actually in ERFOFF. Signed-off-by:
Philipp Dreimann <philipp@dreimann.net> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Cc: Chaoming Li <chaoming_li@realsil.com.cn> Signed-off-by:
-
Johannes Berg authored
Emmanuel noticed that when mac80211 stops the queues for aggregation that can leave a packet pending. This packet will be given to the driver after the AMPDU callback, but as a non-aggregated packet which messes up the sequence number etc. I also noticed by looking at the code that if packets are being processed while we clear the WANT_START bit, they might see it cleared already and queue up on tid_tx->pending. If the driver then rejects the new aggregation session we leak the packet. Fix both of these issues by changing this code to not stop the queues at all. Instead, let packets queue up on the tid_tx->pending queue instead of letting them get to the driver, and add code to recover properly in case the driver rejects the session. (The patch looks large because it has to move two functions to before their new use.) Cc: stable@vger.kernel.org Reported-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- 06 Dec, 2011 2 commits
-
-
Felix Fietkau authored
fixes a regression on single-stream chips introduced in commit 43c35284 "ath9k: implement .get_antenna and .set_antenna" Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Marek Lindner <lindner_marek@yahoo.de> Signed-off-by:
-
-
- 02 Dec, 2011 5 commits
-
-
Andrei Emeltchenko authored
Check for hci_ver instead of lmp_ver Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi>
-
Cong Wang authored
This patch fixes the following memory leak reported by kmemleak: unreferenced object 0xffff880060a53840 (size 192): comm "softirq", pid 0, jiffies 4320571771 (age 1406.569s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81138a1c>] create_object+0x187/0x28b [<ffffffff814be12e>] kmemleak_alloc+0x73/0x98 [<ffffffff811289d3>] __kmalloc+0xfc/0x123 [<ffffffff81386546>] usb_alloc_urb+0x1e/0x48 [<ffffffffa0130274>] btusb_send_frame+0x86/0x385 [btusb] [<ffffffffa02d8230>] hci_send_frame+0xa0/0xa5 [bluetooth] [<ffffffffa02d8a4e>] hci_cmd_task+0xa0/0xfb [bluetooth] [<ffffffff81058548>] tasklet_action+0x8f/0xef [<ffffffff81058a4c>] __do_softirq+0xf4/0x1db [<ffffffff81058bb7>] run_ksoftirqd+0x84/0x129 [<ffffffff8106f1c4>] kthread+0xa0/0xa8 [<ffffffff814dd144>] kernel_thread_helper+0x4/0x10 [<ffffffffffffffff>] 0xffffffffffffffff The problem is that when inc_tx() returns non-zero, we forgot to call usb_free_urb(). Cc: Marcel Holtmann <marcel@holtmann.org> Cc: "Gustavo F. Padovan" <padovan@profusion.mobi> Signed-off-by:WANG Cong <amwang@redhat.com> Acked-by:
-
Wey-Yi Guy authored
The current default watchdog timer is enabled, but we are seeing issues on legacy devices. So change the default setting of watchdog timer to per device based. But user still can use the "wd_disable" module parameter to overwrite the system setting Cc: stable@vger.kernel.org #3.0+ Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
The ht40 setting should not change after association unless channel switch This fix a problem we are seeing which cause uCode assert because driver sending invalid information and make uCode confuse Here is the firmware assert message: kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000. kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump: kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version kernel: iwlagn 0000:03:00.0: 0x00480303 | board version kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd kernel: iwlagn 0000:03:00.0: CSR values: kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG) kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010 kernel: iwlagn 0000:03:00.0: FH register values: kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries kernel: ------------[ cut here ]------------ WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407() kernel: Hardware name: 4290W4H kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2 kernel: Call Trace: kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb Cc: <stable@kernel.org> 3.1+ Reported-by:
Udo Steinberg <udo@hypervisor.org> Signed-off-by:
-
Johannes Berg authored
Group keys in IBSS or AP mode are not programmed into the device since we give the key to it with every TX packet. However, we do need mac80211 to create the MMIC & PN in all cases. Move the code around to set the key flags all the time. We set them even when the key is removed again but that is obviously harmless. Cc: stable@vger.kernel.org Reported-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
- 01 Dec, 2011 1 commit
-
-
John W. Linville authored
This reverts commit f785d83a. This was provoking WARNINGs from the iwlegacy drivers. Signed-off-by:
-
- 30 Nov, 2011 3 commits
-
-
Simon Wunderlich authored
The rates bitmap for internal scan requests shoud be filled, otherwise there will be probe requests with zero rates supported. Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by:
Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Luis R. Rodriguez authored
Johannes' patch for "cfg80211: fix regulatory NULL dereference" broke user regulaotry hints and it did not address the fact that last_request was left populated even if the previous regulatory hint was stale due to the wiphy disappearing. Fix user reguluatory hints by only bailing out if for those regulatory hints where a request_wiphy is expected. The stale last_request considerations are addressed through the previous fixes on last_request where we reset the last_request to a static world regdom request upon reset_regdomains(). In this case though we further enhance the effect by simply restoring reguluatory settings completely. Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Luis R. Rodriguez authored
There is a theoretical race that if hit will trigger a crash. The race is between when we issue the first regulatory hint, regulatory_hint_core(), gets processed by the workqueue and between when the first device gets registered to the wireless core. This is not easy to reproduce but it was easy to do so through the regulatory simulator I have been working on. This is a port of the fix I implemented there [1]. [1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8 Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- 28 Nov, 2011 6 commits
-
-
Emmanuel Grumbach authored
When a packet is supposed to sent be as an a-MPDU, mac80211 sets IEEE80211_TX_CTL_AMPDU to let the driver know. On the other hand, mac80211 configures the driver for aggregration with the ampdu_action callback. There is race between these two mechanisms since the following scenario can occur when the BA agreement is torn down: Tx softIRQ drv configuration ========== ================= check OPERATIONAL bit Set the TX_CTL_AMPDU bit in the packet clear OPERATIONAL bit stop Tx AGG Pass Tx packet to the driver. In that case the driver would get a packet with TX_CTL_AMPDU set although it has already been notified that the BA session has been torn down. To fix this, we need to synchronize all the Qdisc activity after we cleared the OPERATIONAL bit. After that step, all the following packets will be buffered until the driver reports it is ready to get new packets for this RA / TID. This buffering allows not to run into another race that would send packets with TX_CTL_AMPDU unset while the driver hasn't been requested to tear down the BA session yet. This race occurs in practice and iwlwifi complains with a WARN_ON when it happens. Cc: stable@kernel.org Signed-off-by:
-
Nikolay Martynov authored
If addBA responses comes in just after addba_resp_timer has expired mac80211 will still accept it and try to open the aggregation session. This causes drivers to be confused and in some cases even crash. This patch fixes the race condition and makes sure that if addba_resp_timer has expired addBA response is not longer accepted and we do not try to open half-closed session. Cc: stable@vger.kernel.org Signed-off-by:
Nikolay Martynov <mar.kolya@gmail.com> [some adjustments] Signed-off-by:
-
Rafael J. Wysocki authored
Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by commit 2577c6e8 (ath9k_hw: Add support for AR946/8x chipsets) that caused a nasty regression to appear on my Acer Ferrari One (the box locks up entirely at random times after the wireless has been started without any way to get debug information out of it). Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Stanislaw Gruszka authored
rtl_lps_leave can be called from interrupt context, so we have to disable interrupts when taking lps_lock. Below is full lockdep info about deadlock: [ 93.815269] ================================= [ 93.815390] [ INFO: inconsistent lock state ] [ 93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1 [ 93.815556] --------------------------------- [ 93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 93.815832] (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.815947] {SOFTIRQ-ON-W} state was registered at: [ 93.815947] [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c [ 93.815947] [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e [ 93.815947] [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79 [ 93.815947] [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi] [ 93.815947] [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi] [ 93.815947] [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211] [ 93.815947] [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211] [ 93.815947] [<ffffffff81075aa5>] process_one_work+0x205/0x3e7 [ 93.815947] [<ffffffff81076753>] worker_thread+0xda/0x15d [ 93.815947] [<ffffffff8107a119>] kthread+0xa8/0xb0 [ 93.815947] [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10 [ 93.815947] irq event stamp: 547822 [ 93.815947] hardirqs last enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61 [ 93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e [ 93.815947] softirqs last enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15 [ 93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30 [ 93.815947] [ 93.815947] other info that might help us debug this: [ 93.815947] Possible unsafe locking scenario: [ 93.815947] [ 93.815947] CPU0 [ 93.815947] ---- [ 93.815947] lock(&(&rtlpriv->locks.lps_lock)->rlock); [ 93.815947] <Interrupt> [ 93.815947] lock(&(&rtlpriv->locks.lps_lock)->rlock); [ 93.815947] [ 93.815947] *** DEADLOCK *** [ 93.815947] [ 93.815947] no locks held by swapper/0. [ 93.815947] [ 93.815947] stack backtrace: [ 93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1 [ 93.815947] Call Trace: [ 93.815947] <IRQ> [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8 [ 93.815947] [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49 [ 93.815947] [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0 [ 93.815947] [<ffffffff8108dc8a>] mark_lock+0x106/0x220 [ 93.815947] [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c [ 93.815947] [<ffffffff810152af>] ? native_sched_clock+0x34/0x36 [ 93.830125] [<ffffffff810152ba>] ? sched_clock+0x9/0xd [ 93.830125] [<ffffffff81080181>] ? sched_clock_local+0x12/0x75 [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79 [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d [ 93.830125] [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi] [ 93.830125] [<ffffffff8106281f>] tasklet_action+0x8d/0xee [ 93.830125] [<ffffffff810629ce>] __do_softirq+0x112/0x25a [ 93.830125] [<ffffffff814f327c>] call_softirq+0x1c/0x30 [ 93.830125] [<ffffffff81010bf6>] do_softirq+0x4b/0xa1 [ 93.830125] [<ffffffff81062d7d>] irq_exit+0x5d/0xcf [ 93.830125] [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5 [ 93.830125] [<ffffffff814ea533>] common_interrupt+0x73/0x73 [ 93.830125] <EOI> [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf [ 93.830125] [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c [ 93.830125] [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c [ 93.830125] [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe [ 93.830125] [<ffffffff8100e2ef>] cpu_idle+0xab/0x101 [ 93.830125] [<ffffffff814c6373>] rest_init+0xd7/0xde [ 93.830125] [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c [ 93.830125] [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea [ 93.830125] [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3 [ 93.830125] [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140 [ 93.830125] [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=755154 Reported-by: vjain02@students.poly.edu Reported-and-tested-by:Oliver Paukstadt <pstadt@sourcentral.org> Cc: stable@vger.kernel.org Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Johannes Berg authored
Nikolay noticed (by code review) that mac80211 can attempt to stop an aggregation session while it is already being stopped. So to fix it, check whether stop is already being done and bail out if so. Also move setting the STOPPING state into the lock so things are properly atomic. Cc: stable@vger.kernel.org Reported-by:
-
Eliad Peller authored
MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Cc: stable@vger.kernel.org Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
-
- 22 Nov, 2011 2 commits
-
-
John W. Linville authored
This reverts commit 4ba7d999. The original patch was a misguided attempt to improve performance on some hardware that is apparently prone to spurious interrupt generation. Signed-off-by:
-
John W. Linville authored
This reverts commit 23085d57. The original patch was a misguided attempt to improve performance on some hardware that is apparently prone to spurious interrupt generation. Signed-off-by:
-
- 21 Nov, 2011 7 commits
-
-
Dan Carpenter authored
"dwrq->length" is the capped version of "essid->length". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Johannes Berg authored
By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com> Signed-off-by:
-
Helmut Schaa authored
I intoduced this bug in commit a2fe8166 "mac80211: Build TX radiotap header dynamically" Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
-
Ben Greear authored
It was flipped. See section 7.3.2.56 of the 802.11n spec for details. Signed-off-by:
Ben Greear <greearb@candelatech.com> Acked-by:
-
David Herrmann authored
We cannot call module_put(THIS_MODULE) if this is our last reference. Otherwise, this call may cleanup our module before it returns. Gladly, the kthread API provides a simple wrapper for us. So lets use module_put_and_exit() to avoid a race condition with the module cleanup code. Signed-off-by:
David Herrmann <dh.herrmann@googlemail.com> Acked-by:
-
David Herrmann authored
We cannot call module_put(THIS_MODULE) if this is our last reference. Otherwise, this call may cleanup our module before it returns. Gladly, the kthread API provides a simple wrapper for us. So lets use module_put_and_exit() to avoid a race condition with the module cleanup code. Signed-off-by:
-
Bing Zhao authored
The SD8797 firmware image is shared with mwifiex driver. Whoever gets loaded first will be responsible for firmware downloading. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Frank Huang <frankh@marvell.com> Signed-off-by:
-
- 17 Nov, 2011 5 commits
-
-
Michael Büsch authored
priv->work must not be synced while priv->mutex is locked, because the mutex is taken in the work handler. Move cancel_work_sync down to after the device shutdown code. This is safe, because the work handler checks fw_state and bails out early in case of a race. Signed-off-by:
Michael Buesch <m@bues.ch> Cc: <stable@vger.kernel.org> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Michael Büsch authored
The tx_lock is not initialized properly. Add spin_lock_init(). Signed-off-by:
-
Gertjan van Wingerde authored
Fix __le32 to __le16 conversion of the first word of an 8-word block of EEPROM read via the efuse method. Reported-and-tested-by:
Ingvar Hagelund <ingvar@redpill-linpro.com> Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> CC: <stable@vger.kernel.org> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
We have documented case of very bad performance issue on rt2800pci device, because it generate spurious interrupt, what cause irq line is disabled: https://bugzilla.redhat.com/show_bug.cgi?id=658451 We already address that problem in separate patch by returning IRQ_HANDLED from interrupt handler. We think similar fix is needed for other rt2x00 PCI devices, because users report performance problems on these devices too. Cc: stable@vger.kernel.org Signed-off-by:
-
Stanislaw Gruszka authored
Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work: [ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option) [ 2052.114339] Pid: 0, comm: swapper Tainted: P 2.6.35.6-48.fc14.x86_64 #1 [ 2052.114341] Call Trace: [ 2052.114342] <IRQ> [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b [ 2052.114349] [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f [ 2052.114352] [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce [ 2052.114355] [<ffffffff8100c2ea>] handle_irq+0x88/0x90 [ 2052.114357] [<ffffffff8146f034>] do_IRQ+0x5c/0xb4 [ 2052.114360] [<ffffffff81469593>] ret_from_intr+0x0/0x11 [ 2052.114361] <EOI> [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd [ 2052.114366] [<ffffffff81010f03>] ? need_resched+0x23/0x2d [ 2052.114367] [<ffffffff8101102a>] default_idle+0x34/0x4f [ 2052.114370] [<ffffffff81008325>] cpu_idle+0xaa/0xcc [ 2052.114373] [<ffffffff81461f2a>] start_secondary+0x24d/0x28e [ 2052.114374] handlers: [ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c) [ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci]) [ 2052.114384] Disabling IRQ #17 Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=658451Reported-and-tested-by:
Amir Hedayaty <hedayaty@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 15 Nov, 2011 3 commits
-
-
Jesper Juhl authored
If we hit the default case in the switch in if_spi_host_to_card() we'll leak the memory we allocated for 'packet'. This patch resolves the leak by freeing the allocated memory in that case. Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Acked-by:
Dan Williams <dcbw@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Gertjan van Wingerde authored
The generic powersaving code that determines after reception of a frame whether the device should go back to sleep or whether is could stay awake was calling rt2x00lib_config directly from RX tasklet context. On a number of the devices this call can actually sleep, due to having to confirm that the sleeping commands have been executed successfully. Fix this by moving the call to rt2x00lib_config to a workqueue call. This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672Tested-by:
Tomas Trnka <tomastrnka@gmx.com> Signed-off-by:
-
Gertjan van Wingerde authored
This is reported to be an RT3070 based device. Reported-by:
Teika Kazura <teika@lavabit.com> Signed-off-by:
-
- 11 Nov, 2011 2 commits
-
-
Amitkumar Karwar authored
Firmware expects 'max_ssid_length' field in 'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for performing SSID specific scan. Currently driver updates it with an actual SSID length. Hence UUT is not able to find the AP configured in hidden SSID mode in scan results and association fails. max_ssid_length is filled with '0' to fix the issue. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Emmanuel Grumbach authored
When HW RF kill switch is set to kill the radio, our NIC issues an interrupt after we stop the APM module. When we unload the module, the driver disables and cleans the interrupts before stopping the APM. So we have a real interrupt (inta not zero) pending. When this interrupts pops up the tasklet has already been killed and we crash. Here is a logical description of the flow: disable and clean interrupts synchronize interrupts kill the tasklet stop the APM <<== creates an RF kill interrupt free_irq <<== somehow our ISR is called here and we crash Here is the panic message: [ 201.313636] BUG: unable to handle kernel paging request at ffff8800911b7150 [ 201.314541] IP: [<ffffffff8106d652>] tasklet_action+0x62/0x130 [ 201.315149] PGD 1c06063 PUD db37f067 PMD db408067 PTE 80000000911b7160 [ 201.316456] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 201.317324] CPU 1 [ 201.317495] Modules linked in: arc4 iwlwifi(-) mac80211 cfg80211 netconsole configfs binfmt_misc i915 drm_kms_helper drm uvcvideo i2c_algo_bit videodev dell_laptop dcdbas intel_agp dell_wmi intel_ips psmouse intel_gtt v4l2_compat_ioctl32 asix usbnet mii serio_raw video sparse_keymap firewire_ohci sdhci_pci sdhci firewire_core e1000e crc_itu_t [last unloaded: configfs] [ 201.323839] [ 201.324015] Pid: 2061, comm: modprobe Not tainted 3.1.0-rc9-wl #4 Dell Inc. Latitude E6410/0667CC [ 201.324736] RIP: 0010:[<ffffffff8106d652>] [<ffffffff8106d652>] tasklet_action+0x62/0x130 [ 201.325128] RSP: 0018:ffff88011bc43ea0 EFLAGS: 00010286 [ 201.325338] RAX: ffff88008ae70000 RBX: ffff8800911b7150 RCX: ffff88008ae70028 [ 201.325555] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88008ae70000 [ 201.325775] RBP: ffff88011bc43ec0 R08: 0000000000000000 R09: 0000000000000000 [ 201.325994] R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000001 [ 201.326212] R13: 0000000000000006 R14: 0000000000000100 R15: ffff88008e259fd8 [ 201.326431] FS: 00007f4b90ea9700(0000) GS:ffff88011bc40000(0000) knlGS:0000000000000000 [ 201.326657] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 201.326864] CR2: ffff8800911b7150 CR3: 000000008fd6d000 CR4: 00000000000006e0 [ 201.327083] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 201.327302] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 201.327521] Process modprobe (pid: 2061, threadinfo ffff88008e258000, task ffff88008ae70000) [ 201.327747] Stack: [ 201.330494] 0000000000000046 0000000000000030 0000000000000001 0000000000000006 [ 201.333870] ffff88011bc43f30 ffffffff8106cd8a ffffffff811e1016 ffff88011bc43f08 [ 201.337186] 0000000100000046 ffff88008e259fd8 0000000a10be2160 0000000000000006 [ 201.340458] Call Trace: [ 201.342994] <IRQ> [ 201.345656] [<ffffffff8106cd8a>] __do_softirq+0xca/0x250 [ 201.348185] [<ffffffff811e1016>] ? pde_put+0x76/0x90 [ 201.350730] [<ffffffff8131aeae>] ? do_raw_spin_unlock+0x5e/0xb0 [ 201.353261] [<ffffffff811e1016>] ? pde_put+0x76/0x90 [ 201.355776] [<ffffffff8163ccfc>] call_softirq+0x1c/0x30 [ 201.358287] [<ffffffff8101531d>] do_softirq+0x9d/0xd0 [ 201.360823] [<ffffffff8106cb05>] irq_exit+0xd5/0xf0 [ 201.363330] [<ffffffff8163d5d6>] do_IRQ+0x66/0xe0 [ 201.365819] [<ffffffff81632673>] common_interrupt+0x73/0x73 [ 201.368257] <EOI> Cc: <stable@kernel.org> 3.1+ Signed-off-by:
-
- 09 Nov, 2011 1 commit
-
-
Johannes Berg authored
When the connection monitor timer fires right before suspend, the following will happen: timer fires -> monitor_work gets queued suspend calls ieee80211_sta_quiesce ieee80211_sta_quiesce: - deletes timer - cancels monitor_work synchronously, running it [note wrong order of these steps] monitor_work runs, re-arming the timer later, timer fires while system should be quiesced This causes a warning: WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x35/0x40 [mac80211]() but is otherwise harmless. I'm not completely sure this is the scenario Thomas stumbled across, but it is the only way I can right now see the warning in a scenario like the one he reported. Reported-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
-
