- 01 Apr, 2013 4 commits
-
-
Stone Piao authored
Limit the channel number in scan request, or the driver scan config structure memory will be overflowed. Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by:
Stone Piao <piaoyun@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixesJohn W. Linville authored
Samuel Ortiz <sameo@linux.intel.com> says: "This is the 2nd batch of NFC fixes for 3.9. This time we have: - A crash fix for when a DGRAM LLCP socket is listening while the NFC adapter is physically removed. - A potential double skb free when the LLCP socket receive queue is full. - A fix for properly handling multiple and consecutive LLCP connections, and not trash the socket ack log. - A build failure for the MEI microread physical layer, now that the MEI bus APIs have been merged into char-misc-next." Signed-off-by: -
-
-
- 31 Mar, 2013 1 commit
-
-
Samuel Ortiz authored
uuid device_id field is removed and mei_device is renamed mei_cl_device. Signed-off-by:Samuel Ortiz <sameo@linux.intel.com>
-
- 28 Mar, 2013 1 commit
-
-
Johannes Berg authored
Alex Romosan reported that since the mac80211 changes in "mac80211: start auth/assoc timeout on frame status" and the subsequent fixes in "mac80211: fix auth/assoc timeout handling" (commits 1672c0e3 and 89afe614) there's sometimes an issue connecting to a 5 GHz network with the iwlwifi DVM driver. The reason appears to be that since these commits any bad TX status makes mac80211 immediately try again, causing all of the authentication attempts to be quickly rejected by the firmware as it hasn't heard a beacon yet. Before, it would wait for the timeout regardless of status. To fix this, invoke the passive-no-RX workaround when not associated yet as well. This will cause the first frame to get lost, but then the driver will stop the queues and the second attempt will only be transmitted after hearing a beacon, thus delaying it appropriately to not make the firmware reject it again. Reported-by:
Alex Romosan <romosan@sycorax.lbl.gov> Tested-by:
Johannes Berg <johannes.berg@intel.com>
-
- 27 Mar, 2013 8 commits
-
-
Rafał Miłecki authored
When calculating "offset" for final RSSI calibration we're using numbers bigger than s8 can hold. We have for example: offset[j] = 232 - poll_results[j]; formula. If poll_results[j] is small enough (it usually is) we treat number's bit as a sign bit. For example 232 - 1 becomes: 0xE8 - 0x1 = 0xE7, which is not 231 but -25. This code was introduced in e0c9a021 and caused stability regression on some cards, for ex. BCM4322. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Dan Williams authored
Would be better maintained by somebody who actualy has time for it. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Colin Ian King authored
il4965_rs_initialize_lq checks to see if sta is null, however, before that check il4965_rs_use_green dereferences sta when intializing use_green. Avoid a potential null pointer dereference error by only calling il4965_rs_use_green after we are sure sta is not null. Smatch analysis: drivers/net/wireless/iwlegacy/4965-rs.c:2160 il4965_rs_initialize_lq() warn: variable dereferenced before check 'sta' (see line 2155) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Luis R. Rodriguez authored
The following issue was reported. WARNING: at net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40 [mac80211]() Hardware name: iMac12,1 queueing ieee80211 work while going to suspend Pid: 0, comm: swapper/0 Tainted: PF O 3.8.2-206.fc18.x86_64 #1 Call Trace: Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642992] <IRQ> [<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0 [<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k] <ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50 [<ffffffffa045b542>] ieee80211_can_queue_work.isra.7+0x32/0x40 Fix this by avoiding to queue the work if our device has already been marked as suspended or stopped. Reported-by:
Parag Warudkar <parag.lkml@gmail.com> Tested-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
-
Iestyn C. Elfick authored
Intermittently, b43 will report "Out of order TX status report on DMA ring". When this happens, the driver must be reset before communication can resume. The cause of the problem is believed to be an error in the closed-source firmware; however, all versions of the firmware are affected. This change uses the observation that the expected status is always 2 less than the observed value, and supplies a fake status report to skip one header/data pair. Not all devices suffer from this problem, but it can occur several times per second under heavy load. As each occurence kills the unmodified driver, this patch makes if possible for the affected devices to function. The patch logs only the first instance of the reset operation to prevent spamming the logs. Tested-by:
Chris Vine <chris@cvine.freeserve.co.uk> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Rafał Miłecki authored
We're using "mind" variable to find the VCM that got the best polling results. For each VCM we calculte "currd" which is compared to the "mind". For PHY rev3+ "currd" gets values around 14k-40k. Looking for a value smaller than 40 makes no sense, so increase the initial value. This fixes a regression introduced in 3.4 by commit: e0c9a021 (my BCM4322 performance dropped from 18,4Mb/s to 9,26Mb/s) Signed-off-by:
-
-
John W. Linville authored
This reverts commit b6fc28a1. This commit is reported to cause a regression in the support for some revisions of 4313 ePA devices. http://marc.info/?l=linux-wireless&m=136360340200943&w=2 Conflicts: drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c Reported-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
- 26 Mar, 2013 1 commit
-
-
Samuel Ortiz authored
And avoid decreasing the ack log twice when dequeueing connected LLCP sockets. Signed-off-by:
-
- 25 Mar, 2013 4 commits
-
-
Avinash Patil authored
This patch is a bug fix for an issue wherein power save was not working for PCIe. This happens because for processing power save sleep confirm command we pull skb so that skb->data points ahead of interface header. We use same skb to get other cmda responses as well. So if we don't push skb after processing cmd response, it results into reduction in skb->len and finally skb->len reaches zero. This causes failure in processing sleep command response. Fix this by pushing skb by INTF_HEADER_LEN at the end of command response processing. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
-
Johannes Berg authored
Corey Richardson reported that my idle handling cleanup (commit fd0f979a, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by:
Corey Richardson <corey@octayn.net> Signed-off-by:
-
Johannes Berg authored
If a ROC item is canceled just as it expires, the work struct may be scheduled while it is running (and waiting for the mutex). This results in it being run after being freed, which obviously crashes. To fix this don't free it when aborting is requested but instead mark it as "to be freed", which makes the work a no-op and allows freeing it outside. Cc: stable@vger.kernel.org [3.6+] Reported-by:
Jouni Malinen <j@w1.fi> Tested-by:
-
- 24 Mar, 2013 2 commits
-
-
Ben Greear authored
I found another crash when deleting lots of virtual stations in a congested environment. I think the problem is that the ieee80211_mlme_notify_scan_completed could call ieee80211_restart_sta_timer for a stopped interface that was about to be deleted. With the following patch I am unable to reproduce the crash. Signed-off-by:
Ben Greear <greearb@candelatech.com> [move check, also make the same change in mesh] Signed-off-by:
-
Johannes Berg authored
If a P2P device wdev is removed while it has a scan, then the scan completion might crash later as it is already freed by that time. To avoid the crash always check the scan completion when the P2P device is being removed for some reason. If the driver already canceled it, don't want and free it, otherwise warn and leak it to avoid later crashes. In order to do this, locking needs to be changed away from the rdev mutex (which can't always be guaranteed). For now, use the sched_scan_mtx instead, I'll rename it to just scan_mtx in a later patch. Signed-off-by:
-
- 20 Mar, 2013 7 commits
-
-
Johannes Berg authored
The virtual monitor interface has a locking issue, it calls into the channel context code with the iflist mutex held which isn't allowed since it is usually acquired the other way around. The mutex is still required for the interface iteration, but need not be held across the channel calls. Signed-off-by: -
Johannes Berg authored
Arend reported a crash in tracing if the driver returns an ERR_PTR() value from the add_virtual_intf() callback. This is due to the tracing then still attempting to dereference the "pointer", fix this by using IS_ERR_OR_NULL(). Reported-by:
Arend van Spriel <arend@broadcom.com> Tested-by:
-
Thierry Escande authored
kfree_skb was called twice when the socket receive queue is full Signed-off-by:
Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
There is a race between the restart flow and the workers. The workers are cancelled after the fw is already killed and might send HCMD when there is fw to handle them. Simply check that there is a fw to which the HCMD can be sent before actually sending it. Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
We didn't update the internal of the PCIe transport when we read the RFkill state directly. Fix that. Signed-off-by:
-
Emmanuel Grumbach authored
As reported by Ben Hutchings, there was a harmless issue in the checks being done on the lengths of the TBs while building the TFD for a multi-TB host command. Cc: stable@vger@kernel.org Signed-off-by:
-
Samuel Ortiz authored
Calling sock_orphan when e.g. the NFC adapter is removed can lead to kernel crashes when e.g. a connection less client is sleeping on the Rx workqueue, waiting for data to show up. Signed-off-by:
-
- 18 Mar, 2013 9 commits
-
-
Jussi Kivilinna authored
Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@iki.fi> Acked-by:
-
Bing Zhao authored
curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Cc: <stable@vger.kernel.org> # 3.8 Tested-by:
Marco Cesarano <marco@marvell.com> Signed-off-by:
-
Bing Zhao authored
During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is sent to firmware. Firmware expcets only FUNC_INIT once WLAN function is shut down. Any command pending in the command queue should be ignored and freed. Cc: <stable@vger.kernel.org> # 3.8 Tested-by:
Daniel Drake <dsd@laptop.org> Tested-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
Running the following script repeatedly on XO-4 with SD8787 produces command timeout and system lockup. insmod mwifiex_sdio.ko sleep 1 ifconfig eth0 up iwlist eth0 scan & sleep 0.5 rmmod mwifiex_sdio mwifiex_send_cmd_async() is called for sync as well as async commands. (mwifiex_send_cmd_sync() internally calls it for sync command.) "adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async() routine for both types of commands. But it is used only for sync commands in mwifiex_wait_queue_complete(). This could lead to a race when two threads try to queue a sync command with another sync/async command simultaneously. Get rid of global variable and pass command node as a parameter to mwifiex_wait_queue_complete() to fix the problem. Cc: <stable@vger.kernel.org> # 3.8 Reported-by:
-
Felix Fietkau authored
The beacon and multicast-buffer queues are managed by the beacon tasklet, and the generic tx path hang check does not help in any way here. Running it on those queues anyway can introduce some race conditions leading to unnecessary chip resets. Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
The commit 'ath9k_hw: fix calibration issues on chainmask that don't include chain 0' changed the hardware chainmask to the chip chainmask for the duration of the calibration, but the revert to user configuration in the reset path runs too early. That causes some issues with limiting the number of antennas (including spurious failure in hardware-generated packets). Fix this by reverting the chainmask after the essential parts of the calibration that need the workaround, and before NF calibration is run. Signed-off-by:
Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by:
-
Stanislaw Gruszka authored
commit bdb084b2 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Wed Feb 13 15:49:08 2013 +0100 iwlegacy: more checks for dma mapping errors broke il3945_tx_skb() dma buffer length settings, what results on firmware errors like showed below and make 3945 device non usable. iwl3945 0000:02:00.0: Microcode SW error detected. Restarting 0x82000008. iwl3945 0000:02:00.0: Loaded firmware version: 15.32.2.9 iwl3945 0000:02:00.0: Start IWL Error Log Dump: iwl3945 0000:02:00.0: Status: 0x000202E4, count: 1 iwl3945 0000:02:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line iwl3945 0000:02:00.0: SYSASSERT (0x5) 0000208934 0x008B6 0x0035E 0x00320 0x00000 267 iwl3945 0000:02:00.0: Error Reply type 0x00000001 cmd Reported-by:
Zdenek Kabelac <zkabelac@redhat.com> Reported-by:
Krzysztof Kolasa <kkolasa@winsoft.pl> Reported-by:
Pedro Francisco <pedrogfrancisco@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
-
Ming Lei authored
Add support for the AR9462 chip T: Bus=03 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=817a Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Cc: <stable@vger.kernel.org> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 15 Mar, 2013 1 commit
-
-
Ming Lei authored
Add support for the AR9462 chip T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=0036 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Cc: <stable@vger.kernel.org> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
- 14 Mar, 2013 1 commit
-
-
Vinicius Costa Gomes authored
With deferred setup for SCO, it is possible that userspace closes the socket when it is in the BT_CONNECT2 state, after the Connect Request is received but before the Accept Synchonous Connection is sent. If this happens the following crash was observed, when the connection is terminated: [ +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10 [ +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16 [ +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110 [ +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199 [ +0.000906] IP: [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0 [ +0.000000] Oops: 0002 [#1] SMP [ +0.000000] Modules linked in: rfcomm bnep btusb bluetooth [ +0.000000] CPU 0 [ +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd1 #1 Bochs Bochs [ +0.000000] RIP: 0010:[<ffffffff810620dd>] [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] RSP: 0018:ffff88003c3c19d8 EFLAGS: 00010002 [ +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000 [ +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868 [ +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000 [ +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002 [ +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850 [ +0.000000] FS: 0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 [ +0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000) [ +0.000000] Stack: [ +0.000000] ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868 [ +0.000000] ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd [ +0.000000] 0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a [ +0.000000] Call Trace: [ +0.000000] [<ffffffff8101efbd>] ? kvm_clock_read+0x34/0x3b [ +0.000000] [<ffffffff81007c7a>] ? paravirt_sched_clock+0x9/0xd [ +0.000000] [<ffffffff81007fd4>] ? sched_clock+0x9/0xb [ +0.000000] [<ffffffff8104fd7a>] ? sched_clock_local+0x12/0x75 [ +0.000000] [<ffffffff810632d1>] lock_acquire+0x93/0xb1 [ +0.000000] [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffff8105f3d8>] ? lock_release_holdtime.part.22+0x4e/0x55 [ +0.000000] [<ffffffff814f6038>] _raw_spin_lock+0x40/0x74 [ +0.000000] [<ffffffffa0022339>] ? spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffff814f6936>] ? _raw_spin_unlock+0x23/0x36 [ +0.000000] [<ffffffffa0022339>] spin_lock+0x9/0xb [bluetooth] [ +0.000000] [<ffffffffa00230cc>] sco_conn_del+0x76/0xbb [bluetooth] [ +0.000000] [<ffffffffa002391d>] sco_connect_cfm+0x2da/0x2e9 [bluetooth] [ +0.000000] [<ffffffffa000862a>] hci_proto_connect_cfm+0x38/0x65 [bluetooth] [ +0.000000] [<ffffffffa0008d30>] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth] [ +0.000000] [<ffffffffa000cd96>] hci_event_packet+0x153b/0x239d [bluetooth] [ +0.000000] [<ffffffff814f68ff>] ? _raw_spin_unlock_irqrestore+0x48/0x5c [ +0.000000] [<ffffffffa00025f6>] hci_rx_work+0xf3/0x2e3 [bluetooth] [ +0.000000] [<ffffffff8103efed>] process_one_work+0x1dc/0x30b [ +0.000000] [<ffffffff8103ef83>] ? process_one_work+0x172/0x30b [ +0.000000] [<ffffffff8103e07f>] ? spin_lock_irq+0x9/0xb [ +0.000000] [<ffffffff8103fc8d>] worker_thread+0x123/0x1d2 [ +0.000000] [<ffffffff8103fb6a>] ? manage_workers+0x240/0x240 [ +0.000000] [<ffffffff81044211>] kthread+0x9d/0xa5 [ +0.000000] [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60 [ +0.000000] [<ffffffff814f75bc>] ret_from_fork+0x7c/0xb0 [ +0.000000] [<ffffffff81044174>] ? __kthread_parkme+0x60/0x60 [ +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 <f0> ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00 [ +0.000000] RIP [<ffffffff810620dd>] __lock_acquire+0xed/0xe82 [ +0.000000] RSP <ffff88003c3c19d8> [ +0.000000] CR2: 0000000000000199 [ +0.000000] ---[ end trace e73cd3b52352dd34 ]--- Cc: stable@vger.kernel.org [3.8] Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Tested-by:
Frederic Dalleau <frederic.dalleau@intel.com> Signed-off-by:
-
- 13 Mar, 2013 1 commit
-
-
Larry Finger authored
The driver was failing to clear the BSSID when a disconnect happened. That prevented a reconnection. This problem is reported at https://bugzilla.redhat.com/show_bug.cgi?id=789605, https://bugzilla.redhat.com/show_bug.cgi?id=866786, https://bugzilla.redhat.com/show_bug.cgi?id=906734, and https://bugzilla.kernel.org/show_bug.cgi?id=46171. Thanks to Jussi Kivilinna for making the critical observation that led to the solution. Reported-by:
Alessandro Lannocca <alessandro.lannocca@gmail.com> Signed-off-by:
-
