- 03 Jan, 2012 4 commits
-
-
Amitkumar Karwar authored
If 'iw connect' command is fired when driver is already busy in serving 'iw scan' command, ssid specific scan operation for connect is skipped. In this case cmd wait queue handler gets called with no command in queue (i.e. adapter->cmd_queued = NULL). This patch adds a NULL check in mwifiex_wait_queue_complete() routine to fix crash observed during simultaneous scan and assoc operations. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Guennadi Liakhovetski authored
This patch fixes the regression, introduced by commit 17030f48 From: Rafał Miłecki <zajec5@gmail.com> Date: Thu, 11 Aug 2011 17:16:27 +0200 Subject: [PATCH] b43: support new RX header, noticed to be used in 598.314+ fw in PIO case. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
don't do aggregation related stuff for 'AP mode client power save handling' if aggregation is not enabled in the driver, otherwise it will lead to panic because those data structures won't be never intialized in 'ath_tx_node_init' if aggregation is disabled EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k] EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000 ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860 task.ti=f40dc000) Stack: 0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac f40e1cb0 f8186741 f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001 c0b4ba43 00000000 0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac f2a30000 00010020 Call Trace: [<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k] [<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k] [<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350 [mac80211] [<c018dc75>] ? __module_address+0x95/0xb0 [<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211] [<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0 [mac80211] [<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211] [<c018440b>] ? trace_hardirqs_on+0xb/0x10 [<c056936e>] ? skb_queue_tail+0x3e/0x50 [<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750 [mac80211] [<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211] [<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211] [<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k] [<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k] [<c0151b7e>] tasklet_action+0xbe/0x180 Cc: stable@kernel.org Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Reported-by:
Ashwin Mendonca <ashwinloyal@gmail.com> Tested-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
-
- 23 Dec, 2011 1 commit
-
-
Gustavo F. Padovan authored
This reverts commit e1b6eb3c. This was causing a delay of 10 seconds in the resume process of a Thinkpad laptop. I'm afraid this could affect more devices once 3.2 is released. Reported-by:
Tomáš Janoušek <tomi@nomi.cz> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi>
-
- 19 Dec, 2011 5 commits
-
-
Emmanuel Grumbach authored
Since we configure all the queues as CHAINABLE, we need to update the byte count for all the queues, not only the AGGREGATABLE ones. Not doing so can confuse the SCD and make the fw assert. Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
-
Gustavo F. Padovan authored
This reverts commit 4dff523a. It was reported that this patch cause issues when trying to connect to legacy devices so reverting it. Reported-by:
David Fries <david@fries.net> Signed-off-by:
-
Mat Martineau authored
When the last RFCOMM data channel is closed, a timer is normally set up to disconnect the control channel at a later time. If the control channel disconnect command is sent with the timer pending, the timer needs to be cancelled. If the timer is not cancelled in this situation, the reference counting logic for the RFCOMM session does not work correctly when the remote device closes the L2CAP connection. The session is freed at the wrong time, leading to a kernel panic. Signed-off-by:
Mat Martineau <mathewm@codeaurora.org> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Mat Martineau authored
When configuring an ERTM or streaming mode connection, remote devices are expected to send an RFC option in a successful config response. A misbehaving remote device might not send an RFC option, and the L2CAP code should not access uninitialized data in this case. Signed-off-by:
-
- 14 Dec, 2011 3 commits
-
-
Wey-Yi Guy authored
My previous patch 34a5b4b6 iwlwifi: do not re-configure HT40 after associated Fix the case of HT40 after association on specified AP, but it break the association for some APs and cause not able to establish connection. We need to address HT40 before and after addociation. CC: stable@vger.kernel.org #3.0+ Reported-by:
Andrej Gelenberg <andrej.gelenberg@udo.edu> Signed-off-by:
-
Johannes Berg authored
Ted reported that he couldn't connect to some APs and bisected it to the tx_sync implementation. Disable it for the BSS context to fix this issue. Reported-by:
Ted Ts'o <tytso@mit.edu> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Yogesh Ashok Powar authored
Command cancel path cancels the current command and moves it to free command queue. While doing that it deletes the command entry from the pending list. This is not correct as the entry has been already deleted from the pending list at 'mwifiex_exec_next_cmd'. Fixing it. Also making sure the stale command pointer is cleaned and unaccessible for later use. Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
-
- 12 Dec, 2011 3 commits
-
-
Rajkumar Manoharan authored
The stations always chooses 1Mbps for all trasmitting frames, whenever the AP is configured to lock the supported rates. As the max phy rate is always set with the 4th from highest phy rate, this assumption might be wrong if we have less than that. Fix that. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Reported-by:
Ajay Gummalla <agummalla@google.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
Dan Carpenter authored
wait_for_completion_interruptible_timeout() returns -ERESTARTSYS if interrupted so completion_rc needs to be signed. The current code probably returns -ETIMEDOUT if we hit this situation, but after this patch is applied it will return -ERESTARTSYS. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Wey-Yi Guy authored
Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill make the firmware to increment the sequence number which is incorrect and cause unknown behavior. CC: stable@vger.kernel.org #3.0+ Signed-off-by:
-
- 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:
-
- 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:
-
- 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:
-
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 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 2 commits
-
-
Dan Carpenter authored
"dwrq->length" is the capped version of "essid->length". 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:
-
