- 10 7月, 2012 4 次提交
-
-
由 Emmanuel Grumbach 提交于
When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device. This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys. Reported-by: NPaul Bolle <pebolle@tiscali.nl> Cc: stable@vger.kernel.org Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
This is iwlegacy version of: commit 342bbf3f Author: Johannes Berg <johannes.berg@intel.com> Date: Sun Mar 4 08:50:46 2012 -0800 iwlwifi: always monitor for stuck queues If we only monitor while associated, the following can happen: - we're associated, and the queue stuck check runs, setting the queue "touch" time to X - we disassociate, stopping the monitoring, which leaves the time set to X - almost 2s later, we associate, and enqueue a frame - before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device Cc: stable@vger.kernel.org Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
On rt2x00_dmastart() we increase index specified by Q_INDEX and on rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries between Q_INDEX_DONE and Q_INDEX are those we currently process in the hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can submit to the hardware. According to that fix rt2x00usb_kick_queue(), as we need to submit RX entries that are not processed by the hardware. It worked before only for empty queue, otherwise was broken. Note that for TX queues indexes ordering are ok. We need to kick entries that have filled skb, but was not submitted to the hardware, i.e. started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set. From practical standpoint this fixes RX queue stall, usually reproducible in AP mode, like for example reported here: https://bugzilla.redhat.com/show_bug.cgi?id=828824Reported-and-tested-by: NFranco Miceli <fmiceli@plan.ceibal.edu.uy> Reported-and-tested-by: NTom Horsley <horsley1953@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bing Zhao 提交于
> *. CID 709078: Resource leak (RESOURCE_LEAK) > - drivers/net/wireless/mwifiex/cfg80211.c, line: 935 > Assigning: "bss_cfg" = storage returned from "kzalloc(132UL, 208U)" > - but was not free > drivers/net/wireless/mwifiex/cfg80211.c:935 Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 7月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
This was useful for debugging the queue stop/wake issues and is pretty small so let's just put it in. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 7月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
Due to the recent change of NUM_BANDS from 2 to 3 hwsim broke. Fix the code by using the right constant but don't support bands other than 2.4 and 5 GHz. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Thomas Huehn 提交于
IEEE80211_TX_MAX_RATES can be reduced from 5 to 4 as there is no current hardware supporting a rate chain with 5 multi rate stages (mrr), so 4 mrr stages are sufficient. The memory that is freed within the ieee80211_tx_info struct will be used in the upcoming Transmission Power Control (TPC) implementation. Suggested-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de> [reword commit message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 7月, 2012 1 次提交
-
-
由 Vladimir Kondratiev 提交于
Add enumerations for both cfg80211 and nl80211. This expands wiphy.bands etc. arrays. Extend channel <-> frequency translation to cover 60g band and modify the rate check logic since there are no legacy mandatory rates (only MCS is used.) Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 29 6月, 2012 10 次提交
-
-
由 Amitkumar Karwar 提交于
As we don't provide custom regulatory rules to cfg80211, "chan->max_power" remains uninitialized (0dbm) and "chan->max_reg_power" will contain maximum power for a channel extracted from regulatory rules provided by CRDA; hence use "chan->max_reg_power" in reg_notifier handler instead of "chan->max_power" to set max_power in firmware. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
Since we don't support custom regulatory domains, WIPHY_FLAG_CUSTOM_REGULATORY should not be enabled during wiphy registration. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
"priv->max_tx_power_level" and "priv->min_tx_power_level" variables are initialized to maximum and minimum power levels supported by hardware by sending correct firmware command. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
We miss to wakeup main thread after adding command to cmd pending queue at follwing places. These commands are handled later when main thread is woken up for handling an interrupt for sleep event from firmware. This adds worst case delay of 50msec. 1) We don't wakeup main thread when asynchronous command is added to cmd pending queue. Move queue_work() call from mwifiex_wait_queue_complete() to mwifiex_send_cmd_async() to wakeup main thread for sync as well as async commands. 2) Scan operation is triggered due to following reasons a) request from user (ex. "iw scan" command) b) Scan performed by driver internally. In first case main thread is woken up when first scan command is queued in cmd pending queue (we don't need to wakeup main thread for subsequent scan commands, because they are queued in scan command response handler), but it is not done for second case. queue_work() is moved inside mwifiex_scan_networks() to handle both the cases. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
The initvals tool from https://github.com/mcgrof/qca-swiss-army-knife has been modified to detect identical initval tables and replace them with macros. This patch contains the generated changes. On MIPS this reduces the binary size by 24 KB with no runtime changes. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Generated using the initvals tool from the qca-swiss-army-knife repository from https://github.com/mcgrof/qca-swiss-army-knifeSigned-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
seems i got a message like this ath: phy0: BT_Status_Update: is_link=0, linkId=2, state=1, SEQ=-2085766476 initially. Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
ath9k_hw_mci_is_enabled wrapper also takes care of ATH9K_HW_CAP_MCI being set for the AR9462 under test. Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
ath9k_ani_reset (which is called at reset time) uses a state variable ani->update_ani to prevent the ANI noise immunity state on the operating channel from being overwritten by background scans. Unfortunately this is also being set for AP mode, since it's mixed with code that is only supposed to change the default settings after a reset. In AP mode this has the side effect of having ANI run, but being unable to change its runtime noise immunity level, making it effectively useless. Fix this by getting rid of ani->update_ani and passing a parameter to ath9k_hw_set_ofdm_nil and ath9k_hw_set_cck_nil instead. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Paul Bolle 提交于
Every now and then, after resuming from suspend, the iwlegacy driver prints iwl4965 0000:03:00.0: Queue 2 stuck for 2000 ms. iwl4965 0000:03:00.0: On demand firmware reload I have no idea what causes these errors. But the code currently uses wd_timeout in the first error. wd_timeout will generally be set at IL_DEF_WD_TIMEOUT (ie, 2000). Perhaps printing for how long the queue was actually stuck can clarify the cause of these errors. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 6月, 2012 12 次提交
-
-
由 Avinash Patil 提交于
Free ap_custom_ie before return from function. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Wrap the MCI-work canceling with CONFIG_ATH9K_BTCOEX_SUPPORT. Reported-by: NEmmanuel Benisty <benisty.e@gmail.com> Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
The commit "brcmfmac: introduce checkdied debugfs functionality" also introduced a sparse warning: ..../brcmfmac/dhd_sdio.c:3147:45: sparse: cast to restricted __le32 This patch fixes this sparse warning. Reported-by: NFengguang Wu <wfg@linux.intel.com> Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
BCM4334 is a dualband a/b/g/n WiFi chip support 20MHz/40MHz channels. This patch adds support for its SDIO interface. Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
The nvram data is preprocessed before being sent to the device and just before sending an additional allocation was done that assured word alignment of the data. This has moved to the preprocessing step to reduce allocations and subsequent copying of the nvram data. Reviewed-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
The nvram file could be parsed directly in the data buffer in the firmware structure passed by request_firmware function. This patch gets rid of the redundant memcpy. Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
txglomming alignment is a SDIO bus specific feature. It is more appropriate to place it in SDIO bus layer instead of common layer. Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
txglomming is a firmware feature for sdio bus interface. For SDIO device cores newer than revision 11, the default setting of firmware should be used instead of disabling it from the host side. Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
brcmfmac need to support data command setting for dongle's bus core. A list must be placed at brcmf_bus structure before calling brcmf_bus_start in order to be sent by brcmf_c_preinit_dcmds. Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Tom Hughes 提交于
Commit 3a2923e8 introduced a bug when a corrupt descriptor is encountered - although the following descriptor is discarded and returned to the queue for reuse the associated frame is also returned for processing. This leads to a panic: BUG: unable to handle kernel NULL pointer dereference at 000000000000003a IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k] Call Trace: <IRQ> [<ffffffff812d7fa0>] ? map_single+0x60/0x60 [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k] [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k] [<ffffffff8105e133>] tasklet_action+0x63/0xd0 [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0 [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80 [<ffffffff815f9d5c>] call_softirq+0x1c/0x30 [<ffffffff810151f5>] do_softirq+0x75/0xb0 [<ffffffff8105df95>] irq_exit+0xb5/0xc0 [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0 [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a <EOI> [<ffffffff8131840a>] ? intel_idle+0xea/0x150 [<ffffffff813183eb>] ? intel_idle+0xcb/0x150 [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20 [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240 [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120 [<ffffffff815cda8e>] rest_init+0x72/0x74 [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4 [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135 [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f Making sure bf is cleared to NULL in this case restores the old behaviour. Signed-off-by: NTom Hughes <tom@compton.nu> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Panayiotis Karabassis 提交于
https://bugzilla.kernel.org/show_bug.cgi?id=42903 Based on the work of <fynivx@gmail.com> Signed-off-by: NPanayiotis Karabassis <panayk@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
The latest Realtek driver for the RTL8188CU and RTL8192CU chips adds three new USB IDs. Reported-by: NXose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 6月, 2012 10 次提交
-
-
由 Johannes Berg 提交于
When CONFIG_PM is disabled, no device can possibly support WoWLAN since it can't go to sleep to start with. Due to this, mac80211 had even rejected the hardware registration. By making all the code and data for WoWLAN depend on CONFIG_PM we can promote this runtime error to a compile-time error. Add #ifdef around all WoWLAN code to remove it in systems that don't need it as they never suspend. Cc: Kalle Valo <kvalo@qca.qualcomm.com> Acked-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Sujith Manoharan 提交于
Remove the radio enable/disable stuff and fix the transition to FULL_SLEEP mode when the device is idle. Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Cancel the MCI work only when MCI is actually enabled. Fixes this: [96833.124051] Call Trace: [96833.124060] [<ffffffff810afaf8>] __lock_acquire+0x1518/0x1e40 [96833.124065] [<ffffffff810ad126>] ? mark_held_locks+0x86/0x110 [96833.124069] [<ffffffff810ad3ad>] ? trace_hardirqs_on+0xd/0x10 [96833.124073] [<ffffffff814464f0>] ? _raw_spin_unlock_irq+0x30/0x70 [96833.124078] [<ffffffff81072968>] ? wait_on_cpu_work+0x98/0xc0 [96833.124082] [<ffffffff810b0a11>] lock_acquire+0xa1/0x150 [96833.124085] [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0 [96833.124088] [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0 [96833.124092] [<ffffffff810729e2>] wait_on_work+0x52/0x120 [96833.124095] [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0 [96833.124099] [<ffffffff81063b3f>] ? del_timer+0x7f/0x110 [96833.124102] [<ffffffff81072c13>] __cancel_work_timer+0x83/0x130 [96833.124106] [<ffffffff81072cf0>] cancel_work_sync+0x10/0x20 [96833.124113] [<ffffffffa065b5cd>] __ath_cancel_work+0x4d/0x60 [ath9k] [96833.124119] [<ffffffffa065cf28>] ath9k_config+0x458/0x680 [ath9k] [96833.124125] [<ffffffffa065dd1e>] ? ath9k_flush+0x6e/0x1d0 [ath9k] [96833.124129] [<ffffffff8144394d>] ? __mutex_unlock_slowpath+0x10d/0x190 [96833.124146] [<ffffffffa056c7b5>] ieee80211_hw_config+0x135/0x2a0 [mac80211] [96833.124163] [<ffffffffa057ebbb>] ieee80211_do_open+0x67b/0xc50 [mac80211] [96833.124178] [<ffffffffa057f1fd>] ieee80211_open+0x6d/0x80 [mac80211] [96833.124183] [<ffffffff8137a44f>] __dev_open+0x9f/0xf0 [96833.124187] [<ffffffff8137a701>] __dev_change_flags+0xa1/0x180 [96833.124190] [<ffffffff8137a898>] dev_change_flags+0x28/0x70 [96833.124195] [<ffffffff813e1179>] devinet_ioctl+0x659/0x780 [96833.124199] [<ffffffff8137aea0>] ? dev_ioctl+0x210/0x6d0 [96833.124203] [<ffffffff813e1db5>] inet_ioctl+0x75/0x90 [96833.124208] [<ffffffff8135e0e0>] sock_do_ioctl+0x30/0x70 [96833.124211] [<ffffffff8135e3dd>] sock_ioctl+0x7d/0x2c0 [96833.124218] [<ffffffff81193c39>] do_vfs_ioctl+0x99/0x580 [96833.124222] [<ffffffff81447415>] ? sysret_check+0x22/0x5d [96833.124226] [<ffffffff811941b9>] sys_ioctl+0x99/0xa0 [96833.124230] [<ffffffff814473e9>] system_call_fastpath+0x16/0x1b Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sven Eckelmann 提交于
mac80211 adds stations in HT IBSS as soon as a frame comes by, even if the HT capabilities are not known yet (they are often received later, e.g. in beacons). So far, ampdu factor/density are only calculated when the station is initially added. This patch changes this to update ampdu factor/density settings when starting a blockack session. Using this patch, we had performance boosts from 60 to 150 MBit/s between two 2x2 Atheros devices in 5 GHz HT IBSS mode. Signed-off-by: NSven Eckelmann <sven@narfation.org> Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
The command "make includecheck" yields the following for the rtlwifi tree: /home/finger/linux-2.6/drivers/net/wireless/rtlwifi/rtl8192se/sw.c: ../pci.h is included more than once. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
The PCI-based drivers can generate the following warning: [ 9497.776350] ------------[ cut here ]------------ [ 9497.776366] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0() [ 9497.776370] Hardware name: 05794NC [ 9497.776597] Pid: 6413, comm: hostapd Not tainted 3.3.0-4.fc16.x86_64 #1 [ 9497.776601] Call Trace: [ 9497.776612] [<ffffffff81057b1f>] warn_slowpath_common+0x7f/0xc0 [ 9497.776633] [<ffffffffa034a099>] ? rtl_pci_reset_trx_ring+0x199/0x230 [rtlwifi] [ 9497.776640] [<ffffffff81057b7a>] warn_slowpath_null+0x1a/0x20 [ 9497.776646] [<ffffffff8105f06a>] local_bh_enable_ip+0x7a/0xa0 [ 9497.776654] [<ffffffff815f3ef6>] _raw_spin_unlock_bh+0x16/0x20 [ 9497.776671] [<ffffffffa03e50de>] destroy_conntrack+0x9e/0x120 [nf_conntrack] [ 9497.776681] [<ffffffff81511847>] nf_conntrack_destroy+0x17/0x20 [ 9497.776689] [<ffffffff814d9c85>] skb_release_head_state+0xe5/0x120 [ 9497.776695] [<ffffffff814d98b6>] __kfree_skb+0x16/0xa0 [ 9497.776700] [<ffffffff814d9a35>] kfree_skb+0x45/0xc0 [ 9497.776717] [<ffffffffa034a099>] rtl_pci_reset_trx_ring+0x199/0x230 [rtlwifi] [ 9497.776734] [<ffffffffa034a155>] rtl_pci_start+0x25/0x1d0 [rtlwifi] [ 9497.776750] [<ffffffffa03440b5>] rtl_op_start+0x55/0x90 [rtlwifi] [ 9497.776785] [<ffffffffa02c4956>] ieee80211_do_open+0x296/0xa10 [mac80211] [ 9497.776794] [<ffffffff815f7ddd>] ? notifier_call_chain+0x4d/0x70 [ 9497.776828] [<ffffffffa02c513d>] ieee80211_open+0x6d/0x80 [mac80211] [ 9497.776836] [<ffffffff814e8b3f>] __dev_open+0x8f/0xe0 [ 9497.776842] [<ffffffff814e8de1>] __dev_change_flags+0xa1/0x180 [ 9497.776847] [<ffffffff814e8f78>] dev_change_flags+0x28/0x70 [ 9497.776856] [<ffffffff8154e99d>] devinet_ioctl+0x61d/0x7b0 [ 9497.776863] [<ffffffff8154ef55>] inet_ioctl+0x75/0x90 [ 9497.776870] [<ffffffff814cdd50>] sock_do_ioctl+0x30/0x70 [ 9497.776876] [<ffffffff814cee09>] sock_ioctl+0x79/0x2f0 [ 9497.776885] [<ffffffff81193498>] do_vfs_ioctl+0x98/0x550 [ 9497.776891] [<ffffffff811939e1>] sys_ioctl+0x91/0xa0 [ 9497.776897] [<ffffffff815fc029>] system_call_fastpath+0x16/0x1b [ 9497.776902] ---[ end trace 22886c442489082d ]--- The cause is due to calling kfree_skb() with interrupts disabled. This bug is discussed in https://bugzilla.redhat.com/show_bug.cgi?id=797709. Reported-and-Tested by: Ivan Ivanovich <iivanich@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Eyal Shapira 提交于
As recovery queuing can now occur from multiple code paths it's convenient to know what triggered it in all cases other than an intended recovery which is part of the switch between single role to multi role. Signed-off-by: NEyal Shapira <eyal@wizery.com> Signed-off-by: NLuciano Coelho <coelho@ti.com>
-
由 Eyal Shapira 提交于
Following the addition of propagating errors from the bus ops there's a need to distinguish between bus errors (including timeout) and a legitimate timeout occuring in cmd_wait_for_event_or_timeout. In case of real bus errors we need to queue recovery even in cases where a timeout on a response from the FW to a command is acceptable. Reported-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NEyal Shapira <eyal@wizery.com> Signed-off-by: NLuciano Coelho <coelho@ti.com>
-