- 07 Jun, 2010 1 commit
-
-
Grazvydas Ignotas authored
wl1251_sdio_probe() error path is missing wl1251_free_hw, add it. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Acked-by:
Kalle Valo <kvalo@adurom.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 06 Jun, 2010 4 commits
-
-
Emmanuel Grumbach authored
Move the sysfs_create_group to iwl_ucode_callback after we have safely got the firmware. The motivation to do this comes from a warning from lockdep which detected that we request priv->mutex while holding s_active during a sysfs request (show_statistics in the example copy pasted). The reverse order exists upon request_firmware: request_firmware which is a sysfs operation that requires s_active is run under priv->mutex. This ensures that we don't get sysfs request before we finish to request the firmware, avoiding this deadlock. ======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- cat/2595 is trying to acquire lock: (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn] but task is already holding lock: (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (s_active){++++.+}: [<c0489b74>] __lock_acquire+0xc44/0x1230 [<c048a1ed>] lock_acquire+0x8d/0x110 [<c0581499>] sysfs_addrm_finish+0xe9/0x180 [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80 [<c05829d4>] sysfs_remove_group+0x44/0xd0 [<c0714b75>] dpm_sysfs_remove+0x15/0x20 [<c070dac8>] device_del+0x38/0x170 [<c070dc1e>] device_unregister+0x1e/0x60 [<c071838d>] _request_firmware+0x29d/0x550 [<c07186c7>] request_firmware+0x17/0x20 [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn] [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211] [<c0808cd2>] dev_open+0x92/0xf0 [<c0808b2b>] dev_change_flags+0x7b/0x190 [<c08148e8>] do_setlink+0x178/0x3b0 [<c0815169>] rtnl_setlink+0xf9/0x130 [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0 [<c0827ce6>] netlink_rcv_skb+0x86/0xa0 [<c081436c>] rtnetlink_rcv+0x1c/0x30 [<c08279c3>] netlink_unicast+0x263/0x290 [<c0828768>] netlink_sendmsg+0x1c8/0x2a0 [<c07f85fd>] sock_sendmsg+0xcd/0x100 [<c07f964d>] sys_sendmsg+0x15d/0x290 [<c07f9e6b>] sys_socketcall+0xeb/0x2a0 [<c040ad9f>] sysenter_do_call+0x12/0x38 -> #0 (&priv->mutex){+.+.+.}: [<c0489f84>] __lock_acquire+0x1054/0x1230 [<c048a1ed>] lock_acquire+0x8d/0x110 [<c08bb358>] __mutex_lock_common+0x58/0x470 [<c08bb84a>] mutex_lock_nested+0x3a/0x50 [<facfa598>] show_statistics+0x48/0x100 [iwlagn] [<c070d219>] dev_attr_show+0x29/0x50 [<c057fecd>] sysfs_read_file+0xdd/0x190 [<c052880f>] vfs_read+0x9f/0x190 [<c0528d22>] sys_read+0x42/0x70 [<c040ad9f>] sysenter_do_call+0x12/0x38 other info that might help us debug this: 3 locks held by cat/2595: #0: (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190 #1: (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50 #2: (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50 stack backtrace: Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2 Call Trace: [<c08b99ab>] ? printk+0x1d/0x22 [<c0487752>] print_circular_bug+0xc2/0xd0 [<c0489f84>] __lock_acquire+0x1054/0x1230 [<c0478d81>] ? sched_clock_cpu+0x121/0x180 [<c048a1ed>] lock_acquire+0x8d/0x110 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn] [<c08bb358>] __mutex_lock_common+0x58/0x470 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn] [<c08bb84a>] mutex_lock_nested+0x3a/0x50 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn] [<facfa598>] show_statistics+0x48/0x100 [iwlagn] [<c0580cf9>] ? sysfs_get_active+0x69/0xb0 [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn] [<c070d219>] dev_attr_show+0x29/0x50 [<c057fecd>] sysfs_read_file+0xdd/0x190 [<c05ff314>] ? security_file_permission+0x14/0x20 [<c0528242>] ? rw_verify_area+0x62/0xd0 [<c052880f>] vfs_read+0x9f/0x190 [<c047745b>] ? up_read+0x1b/0x30 [<c057fdf0>] ? sysfs_read_file+0x0/0x190 [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220 [<c0528d22>] sys_read+0x42/0x70 [<c040ad9f>] sysenter_do_call+0x12/0x38 Signed-off-by:Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com>
-
Wey-Yi Guy authored
Add "Wey-Yi Guy" to maintainers list for iwlwifi. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Abhijeet Kolekar authored
Port of internal scan to iwl3945 missed introduction of iwl3945_get_single_channel_for_scan. Fix the following bug by introducing the iwl3945_get_single_channel_for_scan http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208Signed-off-by:
Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by:
-
Reinette Chatre authored
We learn from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and https://bugzilla.redhat.com/show_bug.cgi?id=589777 that 3945 can also suffer from a stuck command queue. Enable stuck queue detection for iwl3945 to enable recovery in this case. Signed-off-by:
-
- 04 Jun, 2010 4 commits
-
-
Bob Copeland authored
Commit 56d1de0a, "ath5k: clean up filter flags setting" introduced a regression in monitor mode such that the promisc filter flag would get lost. Although we set the promisc flag when it changed, we did not preserve it across subsequent calls to configure_filter. This patch restores the original functionality. Cc: stable@kernel.org Bisected-by: weedy2887@gmail.com Tested-by: weedy2887@gmail.com Tested-by:
Rick Farina <sidhayn@gmail.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Tobias Doerffel authored
When building a kernel with CONFIG_PM=y but neither suspend nor hibernate support, the compiler complains about the static functions ath5k_pci_suspend() and ath5k_pci_resume() not being used: drivers/net/wireless/ath/ath5k/base.c:713:12: warning: ‘ath5k_pci_suspend’ defined but not used drivers/net/wireless/ath/ath5k/base.c:722:12: warning: ‘ath5k_pci_resume’ defined but not used Depending on CONFIG_PM_SLEEP rather than CONFIG_PM fixes the issue. Signed-off-by:
Tobias Doerffel <tobias.doerffel@gmail.com> Signed-off-by:
-
Johannes Berg authored
Processing an association response could take a bit of time while we set up the hardware etc. During that time, the AP might already send a blockack request. If this happens very quickly on a fairly slow machine, we can end up processing the blockack request before the association processing has finished. Since the blockack processing cannot sleep right now, we also cannot make it wait in the driver. As a result, sometimes on slow machines the iwlagn driver gets totally confused, and no traffic can pass when the aggregation setup was done before the assoc setup completed. I'm working on a proper fix for this, which involves queuing all blockack category action frames from a work struct, and also allowing the ampdu_action driver callback to sleep, which will generally clean up the code and make things easier. However, this is a very involved and complex change. To fix the problem at hand in a way that can also be backported to stable, I've come up with this patch. Here, I simply process all aggregation action frames from the managed interface skb queue, which means their processing will be serialized with processing the association response, thereby fixing the problem. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Cc: stable@kernel.org Signed-off-by:
-
John W. Linville authored
This reverts commit 15920d8a. This patch was discovered to cause some hostap devices to fail to initialized. https://bugzilla.kernel.org/show_bug.cgi?id=16111Signed-off-by:
-
- 01 Jun, 2010 3 commits
-
-
Johannes Berg authored
The dialog token allocator has apparently been broken since b83f4e15 ("mac80211: fix deadlock in sta->lock") because it got moved out under the spinlock. Fix it. Signed-off-by:
-
Johannes Berg authored
Daniel reported that the paged RX changes had broken blockack request frame processing due to using data that wasn't really part of the skb data. Fix this using skb_copy_bits() for the needed data. As a side effect, this adds a check on processing too short frames, which previously this code could do. Reported-by:
Daniel Halperin <dhalperi@cs.washington.edu> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
-
Bruno Randolf authored
We can wake all queues after a chip reset since everything should be set up and we are ready to transmit. If we don't do that we might end up starting up with stopped queues, not beeing able to transmit. (This started to happen after "ath5k: clean up queue manipulation" but since periodic calibration also stopped and started the queues this effect was hidden most of the time). This way we can also get rid of the superfluous ath5k_reset_wake() function. Signed-off-by:
Bruno Randolf <br1@einfach.org> Acked-by:
Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
-
- 28 May, 2010 5 commits
-
-
Christoph Fritz authored
Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb9 and ea2db495 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30 Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
-
Johannes Berg authored
sparse correctly complains that __ieee80211_get_channel_mode is not static. Signed-off-by:
-
Prarit Bhargava authored
Fixes: drivers/net/wireless/libertas/rx.c: In function process_rxed_802_11_packet: drivers/net/wireless/libertas/rx.c:354: error: radiotap_hdr.flags may be used uninitialized in this function Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
This bug was introduced by the following commit Author: Vasanthakumar Thiagarajan <vasanth@atheros.com> Date: Thu Apr 15 17:38:46 2010 -0400 ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose Wrong buffer is checked for bf_tx_aborted field in ath_tx_num_badfrms(), this may result in a rate scaling with wrong feedback (number of unacked frames in this case). It is the last one in the chain of buffers for an aggregate frame that should be checked. Also it misses the initialization of this field in the buffer, this may lead to a situation where we stop the sw retransmission of failed subframes associated to this buffer. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Justin P. Mattock authored
ath_print in xmit.c should say "Reseting hardware" instead of Resetting HAL!(since HAL is being fazed out). dmesg shows: [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL! Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
-
- 26 May, 2010 2 commits
-
-
Christian Lamparter authored
Commit "ar9170: wait for asynchronous firmware loading" introduced a bug, which is triggered by fatal errors while the driver is initializing the device. BUG: unable to handle kernel paging request at 6b6b6bf7 IP: [<c117b567>] kobject_put+0x7/0x70 *pde = 00000000 Oops: 0000 [#1] PREEMPT last sysfs file: /sys/devices/platform/hdaps/position Modules linked in: ar9170usb [...] Pid: 6246, comm: firmware/ar9170 Not tainted 2.6.34-wl #54 EIP: 0060:[<c117b567>] EFLAGS: 00010206 CPU: 0 EIP is at kobject_put+0x7/0x70 EAX: 6b6b6bd7 EBX: f4d3d0e0 ECX: f5ba9124 EDX: f6af2a7c ESI: 00000000 EDI: f4d3d0e0 EBP: 00000000 ESP: f5e98f9c DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process firmware/ar9170 (pid: 6246) Stack: c12532ed 00000246 f5bfaa70 f8487353 f4d3d0e0 Call Trace: [<c12532ed>] ? device_release_driver+0x1d/0x30 [<f8487353>] ? ar9170_usb_firmware_failed+0x43/0x70 [ar9170usb] [<c125983c>] ? request_firmware_work_func+0x2c/0x70 [<c1259810>] ? request_firmware_work_func+0x0/0x70 [<c10413f4>] ? kthread+0x74/0x80 [<c1041380>] ? kthread+0x0/0x80 [<c1003136>] ? kernel_thread_helper+0x6/0x10 Code: 40 d3 f2 ff 85 c0 89 c3 74 0a ba 44 86 4c c1 e8 [...] EIP: [<c117b567>] kobject_put+0x7/0x70 SS:ESP 0068:f5e98f9c CR2: 000000006b6b6bf7 ---[ end trace e81abb992434b410 ]--- Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
John W. Linville authored
This reverts commit 663cb47c. This patch was merged out of the proper order, so instead of fixing a problem with a prior (unmerged) patch, it creates one. Ooops! Signed-off-by:
-
- 25 May, 2010 2 commits
-
-
Felix Fietkau authored
With VEOL, Beacon transmission in ad-hoc does not currently work. I believe for larger ad-hoc networks, VEOL is too unreliable, as it can get beacon transmissions stuck during synchronization. Use SWBA based beacon trasmission similar to AP mode instead. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Acked-by:
Benoit Papillault <benoit.papillault@free.fr> Signed-off-by:
-
Felix Fietkau authored
This fixes IBSS beacon transmissions without VEOL enabled Signed-off-by:
-
- 24 May, 2010 12 commits
-
-
Vasanthakumar Thiagarajan authored
The functionality to keep the device awake until it is done with the rx of any mcast/bcast frames which are pending on AP should also be added to the hardwares which support auto sleep feature. This patch fixes frequent failures in ARP resolution when it is initiated by the other end. Currently auto sleep is enabled only for ar9003 in ath9k. Signed-off-by:
-
Randy Dunlap authored
Fix sta_info.h kernel-doc warnings: Warning(net/mac80211/sta_info.h:164): No description found for parameter 'tid_active_rx[STA_TID_NUM]' Warning(net/mac80211/sta_info.h:164): Excess struct/union/enum/typedef member 'tid_state_rx' description in 'sta_ampdu_mlme' Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
-
Randy Dunlap authored
Fix kernel-doc warnings in mac80211.h: Warning(include/net/mac80211.h:838): No description found for parameter 'ap_addr' Warning(include/net/mac80211.h:1726): No description found for parameter 'get_survey' Signed-off-by:
-
Dan Carpenter authored
The intent here is to test that "sta_id_r" is a valid pointer. We do this same test later on in the function. Btw iwl_add_bssid_station() is called from two places and "sta_id_r" is a valid pointer from both callers. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Dan Carpenter authored
This is obviously a small picky thing. The original error handling code doesn't free the most recent allocations which haven't been added to the hif_dev->tx.tx_buf list yet. Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Dan Carpenter authored
After c11d8f89: "ath9k_htc: Simplify TX URB management" we no longer assume that tx_buf is a non-null pointer. Signed-off-by:
-
Gertjan van Wingerde authored
The recent changes to skb handling introduced a bug in the rt2800usb TX descriptor writing whereby the length of the USB packet wasn't calculated correctly. Found via code inspection, as the devices themselves didn't seem to mind. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Gertjan van Wingerde authored
(Based on a patch created by Ondrej Zary) In some circumstances the Ralink devices do not properly go to sleep or wake up, with timeouts occurring. Fix this by retrying telling the device that it has to wake up or sleep. Signed-off-by:
-
John W. Linville authored
This reverts commit 03ceedea. This patch was reported to cause a regression in which connectivity is lost and cannot be reestablished after a suspend/resume cycle. Signed-off-by:
-
Tejun Heo authored
Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Helmut Schaa authored
Don't use to_pci_dev in rt2x00pci_uninitialize to get the allocated irq as it won't work for platform devices (SoC). Instead, use the irq field that's already used everywhere else. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
-
Bruno Randolf authored
We should use the same buffer size we set up for DMA also in the hardware descriptor. Previously we used common->rx_bufsize for setting up the DMA mapping, but used skb_tailroom(skb) for the size we tell to the hardware in the descriptor itself. The problem is that skb_tailroom(skb) can give us a larger value than the size we set up for DMA before. This allows the hardware to write into memory locations not set up for DMA. In practice this should rarely happen because all packets should be smaller than the maximum 802.11 packet size. On the tested platform rx_bufsize is 2528, and we allocated an skb of 2559 bytes length (including padding for cache alignment) but sbk_tailroom() was 2592. Just consistently use rx_bufsize for all RX DMA memory sizes. Also use the return value of the descriptor setup function. Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
- 21 May, 2010 7 commits
-
-
Johannes Berg authored
Specifying a valid channel type will get goto out rather than continuing, due to missing braces. This affects both remain on channel and action frame TX commands. Signed-off-by:
-
Jussi Kivilinna authored
Remove (hopefully) last use of WEXT in rndis_wlan. Replace wireless_send_event with missing cfg80211_disconnected in rndis_wlan_do_link_down_work. Reported-by:
"Rogério Brito" <rbrito@ime.usp.br> Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Luis R. Rodriguez authored
We tried to squeeze as much AR9003 support into this kernel release cycle but there are a few features which are still being tested and developed. Some of these features are critical to the stable operation of AR9003 so for now disable AR9003 support all together. This will get re-enabled once all necessary features are in place but very likely will not happen for 2.6.35. Reviewed-by:
Don Breslin <don.breslin@atheros.com> Signed-off-by:
-
Felix Fietkau authored
Since wdev can be NULL, check it before dereferencing it Signed-off-by:
-
Juuso Oikarinen authored
The current frame length used by the driver for RX frames is the SPI bus transfer length. This length has padding bytes, which do not belong to the WLAN frame. As there is no other length information in the WLAN frame except the skb length this problem caused for instance extra ESSID's to be listed at the end of scan results (IE id 0) with zero length. Fix the frame length by removing padding. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by:
Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by:
-
Reinette Chatre authored
It is possible for internal scan to race against itself if the device is not returning the scan results from first requests. What happens in this case is the cleanup done during the abort of the first internal scan also cleans up part of the new scan, causing it to access memory it shouldn't. Here are details: * First internal scan is triggered and scan command sent to device. * After seven seconds there is no scan results so the watchdog timer triggers a scan abort. * The scan abort succeeds and a SCAN_COMPLETE_NOTIFICATION is received for failed scan. * During processing of SCAN_COMPLETE_NOTIFICATION we clear STATUS_SCANNING and queue the "scan_completed" work. ** At this time, since the problem that caused the internal scan in first place is still present, a new internal scan is triggered. The behavior at this point is a bit different between 2.6.34 and 2.6.35 since 2.6.35 has a lot of this synchronized. The rest of the race description will thus be generalized. ** As part of preparing for the scan "is_internal_short_scan" is set to true. * At this point the completion work for fist scan is run. As part of this there is some locking missing around the "is_internal_short_scan" variable and it is set to "false". ** Now the second scan runs and it considers itself a real (not internal0 scan and thus causes problems with wrong memory being accessed. The fix is twofold. * Since "is_internal_short_scan" should be protected by mutex, fix this in scan completion work so that changes to it can be serialized. * Do not queue a new internal scan if one is in progress. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=15824Signed-off-by:
-
Sujith authored
signal_type is enum cfg80211_signal_type. This fixes the gcc warning: scan.c: In function `cfg80211_inform_bss': scan.c:518:6: warning: comparison between `enum cfg80211_signal_type' and `enum nl80211_bss' scan.c: In function `cfg80211_inform_bss_frame': scan.c:574:6: warning: comparison between `enum cfg80211_signal_type' and `enum nl80211_bss' Signed-off-by:
-
