- 20 Jul, 2010 1 commit
-
-
John W. Linville authored
These synthetic frames are all triggered from userland requests in process context. https://bugzilla.kernel.org/show_bug.cgi?id=16412Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 16 Jul, 2010 1 commit
-
-
Stephen Boyd authored
The rt2x00dev->intf_work workqueue is never initialized when a driver is probed for a non-existent device (in this case rt2500usb). On such a path we call rt2x00lib_remove_dev() to free any resources initialized during the probe before we use INIT_WORK to initialize the workqueue. This causes lockdep to get confused since the lock used in the workqueue hasn't been initialized yet but is now being acquired during cancel_work_sync() called by rt2x00lib_remove_dev(). Fix this by initializing the workqueue first before we attempt to probe the device. This should make lockdep happy and avoid breaking any assumptions about how the library cleans up after a probe fails. phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60 Call Trace: [<ffffffff8105fe59>] register_lock_class+0x152/0x31f [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111 [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4 [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf [<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41 [<ffffffff810628d5>] lock_acquire+0xd1/0xf7 [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e [<ffffffff8104f136>] cancel_work_sync+0xb/0xd [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib] [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib] [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52 [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb] [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb] [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136 [<ffffffff812ea167>] __driver_attach+0x4a/0x66 [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66 [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89 [<ffffffff812e9efd>] driver_attach+0x19/0x1b [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204 [<ffffffff812ea41b>] driver_register+0x98/0x109 [<ffffffff813465dd>] usb_register_driver+0xb2/0x173 [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb] [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb] [<ffffffff81000203>] do_one_initcall+0x6d/0x17a [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0 [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b Signed-off-by:
Stephen Boyd <bebarino@gmail.com> Signed-off-by:
-
- 14 Jul, 2010 1 commit
-
-
John W. Linville authored
"hostap: Protect against initialization interrupt" (which reinstated "wireless: hostap, fix oops due to early probing interrupt") reintroduced Bug 16111. This is because hostap_pci wasn't setting dev->base_addr, which is now checked in prism2_interrupt. As a result, initialization was failing for PCI-based hostap devices. This corrects that oversight. Signed-off-by:
-
- 07 Jul, 2010 1 commit
-
-
Rajkumar Manoharan authored
Failure cases within ath9k_hif_usb_alloc_urbs are failed to release allocated memory. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
- 02 Jul, 2010 1 commit
-
-
Reinette Chatre authored
When there is a firmware error or the firmware is reloaded for some other reason we currently clear all station information, including keys associated with them. A problem is that we do not clear some other information regarding keys that are not stored in the station structs. The consequence of this is that when the device is reconfigured after the firmware reload we can, among other things, run out of key indices. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16232 http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2221Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com>
-
- 25 Jun, 2010 2 commits
-
-
Wey-Yi Guy authored
When building tx command, always set TX_CMD_FLAG_PROT_REQUIRE_MSK for 5000 series and up. Without setting this bit the firmware will not examine the RTS/CTS setting and thus not send traffic with the appropriate protection. RTS/CTS is is required for HT traffic in a noisy environment where, without this setting, connections will stall on some hardware as documented in the patch that initially attempted to address this: commit 1152dcc2 Author: Wey-Yi Guy <wey-yi.w.guy@intel.com> Date: Fri Jan 15 13:42:58 2010 -0800 iwlwifi: Fix throughput stall issue in HT mode for 5000 Similar to 6000 and 1000 series, RTS/CTS is the recommended protection mechanism for 5000 series in HT mode based on the HW design. Using RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment, it also prevent uCode encounter TX FIFO underrun and other HT mode related performance issues. For 3945 and 4965, different flags are used for RTS/CTS or CTS-to-Self protection. Signed-off-by:Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 3474ad63 Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Apr 29 04:43:05 2010 -0700 iwlwifi: apply filter flags directly broke multicast. The reason, it turns out, is that the code previously checked if ALLMULTI _changed_, which the new code no longer did, and normally it _never_ changes. Had somebody changed it manually, the code prior to my patch there would have been broken already. The reason is that we always, unconditionally, ask the device to pass up all multicast frames, but the new code made it depend on ALLMULTI which broke it since now we'd pass up multicast frames depending on the default filter in the device, which isn't necessarily what we want (since we don't program it right now). Fix this by simply not checking allmulti as we have allmulti behaviour enabled already anyway. Reported-by:
Maxim Levitsky <maximlevitsky@gmail.com> Tested-by:
-
- 23 Jun, 2010 1 commit
-
-
Vasanthakumar Thiagarajan authored
There are few places where ANI is started without checking if it is right to start. This might lead to a case where ani timer would be left undeleted and cause improper memory acccess during module unload. This bug is clearly exposed with paprd support where the driver detects tx hang and does a chip reset. During this reset ani is (re)started without checking if it needs to be started. This would leave a timer scheduled even after all the resources are freed and cause a panic. This patch introduces a bit in sc_flags to indicate if ani needs to be started in sw_scan_start() and ath_reset(). This would fix the following panic. This issue is easily seen with ar9003 + paprd. BUG: unable to handle kernel paging request at 0000000000003f38 [<ffffffff81075391>] ? __queue_work+0x41/0x50 [<ffffffff8106afaa>] run_timer_softirq+0x17a/0x370 [<ffffffff81088be8>] ? tick_dev_program_event+0x48/0x110 [<ffffffff81061f69>] __do_softirq+0xb9/0x1f0 [<ffffffff810ba060>] ? handle_IRQ_event+0x50/0x160 [<ffffffff8100af5c>] call_softirq+0x1c/0x30 [<ffffffff8100c9f5>] do_softirq+0x65/0xa0 [<ffffffff81061e25>] irq_exit+0x85/0x90 [<ffffffff8155e095>] do_IRQ+0x75/0xf0 [<ffffffff815570d3>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff812fd67b>] ? acpi_idle_enter_simple+0xe4/0x119 [<ffffffff812fd674>] ? acpi_idle_enter_simple+0xdd/0x119 [<ffffffff81441c87>] cpuidle_idle_call+0xa7/0x140 [<ffffffff81008da3>] cpu_idle+0xb3/0x110 [<ffffffff81550722>] start_secondary+0x1ee/0x1f5 Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
- 18 Jun, 2010 1 commit
-
-
Bob Copeland authored
ath5k assumes ah_current_channel is always a valid pointer in several places, but a newly created interface may not have a channel. To avoid null pointer dereferences, set it up to point to the first available channel until later reconfigured. This fixes the following oops: $ rmmod ath5k $ insmod ath5k $ iw phy0 set distance 11000 BUG: unable to handle kernel NULL pointer dereference at 00000006 IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] *pde = 00000000 Oops: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90 scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc Pid: 1597, comm: iw Not tainted (2.6.32.14 #8) EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0 EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080 ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000) Stack: d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0 <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7 <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000 Call Trace: [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k] [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211] [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211] [<c10f5db9>] ? nla_parse+0x59/0xc0 [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0 [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0 [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90 [<c11c9649>] ? genl_rcv+0x19/0x30 [<c11c7c03>] ? netlink_unicast+0x1b3/0x220 [<c11c893e>] ? netlink_sendmsg+0x26e/0x290 [<c11a409e>] ? sock_sendmsg+0xbe/0xf0 [<c1032780>] ? autoremove_wake_function+0x0/0x50 [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530 [<c1074933>] ? do_lookup+0x53/0x1b0 [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0 [<c11acab0>] ? verify_iovec+0x50/0x90 [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270 [<c1048e50>] ? find_get_page+0x10/0x50 [<c104a96f>] ? filemap_fault+0x5f/0x370 [<c1059159>] ? __do_fault+0x319/0x370 [<c11a55b4>] ? sys_socketcall+0x244/0x290 [<c101962c>] ? do_page_fault+0x1ec/0x270 [<c1019440>] ? do_page_fault+0x0/0x270 [<c1002ae5>] ? syscall_call+0x7/0xb Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24 0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2 EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 0068:cfa09bf4 CR2: 0000000000000006 ---[ end trace 54f73d6b10ceb87b ]--- Cc: stable@kernel.org Reported-by:
Steve Brown <sbrown@cortland.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
- 16 Jun, 2010 1 commit
-
-
Christoph Fritz authored
regression introduced by b8d92c9c In function ‘ieee80211_work_rx_queued_mgmt’: warning: ‘rma’ may be used uninitialized in this function this re-adds default value WORK_ACT_NONE back to rma Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
-
- 15 Jun, 2010 2 commits
-
-
Tim Gardner authored
Use an irq spinlock to hold off the IRQ handler until enough early card init is complete such that the handler can run without faulting. Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Cc: stable@kernel.org Signed-off-by:
-
John W. Linville authored
Avoids this: WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1 [mac80211]() Hardware name: Latitude E5400 Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Pid: 979, comm: iwlagn Tainted: G W 2.6.33.3-85.fc13.x86_64 #1 Call Trace: [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11 [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211] [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore] [<ffffffff81060d3d>] worker_thread+0x1a4/0x232 [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore] [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34 [<ffffffff81060b99>] ? worker_thread+0x0/0x232 [<ffffffff810643c7>] kthread+0x7a/0x82 [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10 [<ffffffff8106434d>] ? kthread+0x0/0x82 [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10 Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=590436Signed-off-by:
Mihai Harpau <mishu@piatafinanciara.ro> Cc: stable@kernel.org Acked-by:
-
- 14 Jun, 2010 5 commits
-
-
Zhu Yi authored
Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
Joerg Albert authored
Cc: stable@kernel.org Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Prarit Bhargava authored
Fixes linux-2.6 warning: drivers/net/wireless/libertas_tf/main.c: In function 'lbtf_rx': drivers/net/wireless/libertas_tf/main.c:578: warning: 'stats.antenna' is used uninitialized in this function drivers/net/wireless/libertas_tf/main.c:578: warning: 'stats.mactime' is used uninitialized in this function stats struct needs to be set to 0 before use. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Shanyu Zhao authored
The flow id (scd_flow) in a compressed BA packet should match the txq_id of the queue from which the aggregated packets were sent. However, in some hardware like the 1000 series, sometimes the flow id is 0 for the txq_id (10 to 19). This can cause the annoying message: [ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected [ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0), index 5, is out of range [0-256] 7 7. And even worse, if agg->wait_for_ba is true when the bad BA is arriving, this can cause system hang due to NULL pointer dereference because the code is operating in a wrong tx queue! Signed-off-by:
Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by:
Pradeep Kulkarni <pradeepx.kulkarni@intel.com> Signed-off-by:
-
Reinette Chatre authored
We are seeing some race conditions between incoming station management requests (station add/remove) and the internal unassoc RXON command that modifies station table. Modify these flows to require the mutex to be held and thus serializing them. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2207Signed-off-by:
-
- 08 Jun, 2010 2 commits
-
-
Johannes Berg authored
When we receive a deauthentication frame before having successfully associated, we neither print a message nor abort assocation. The former makes it hard to debug, while the latter later causes a warning in cfg80211 when, as will typically be the case, association timed out. This warning was reported by many, e.g. in https://bugzilla.kernel.org/show_bug.cgi?id=15981, but I couldn't initially pinpoint it. I verified the fix by hacking hostapd to send a deauth frame instead of an association response. Cc: stable@kernel.org Signed-off-by:
Miles Lane <miles.lane@gmail.com> Signed-off-by:
-
Johannes Berg authored
Using ieee80211_find_sta() needs to be under RCU read lock, which iwlwifi currently misses, so fix it. Cc: stable@kernel.org Reported-by:
-
- 07 Jun, 2010 5 commits
-
-
Holger Schurig authored
This makes "iw wlan0 dump survey" work again with mac80211-based drivers that support it, e.g. ath5k. Signed-off-by:
Holger Schurig <holgerschurig@gmail.com> Signed-off-by:
-
Zhu Yi authored
Remove my name from the MAINTAINERS file. Signed-off-by:
-
Bruno Randolf authored
If the channel is not set yet and we configure the antennas just store the setting. It will be activated during the next reset, when the channel is set. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
-
Jason Dravet authored
Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the USB Ids in p54usb. Signed-off-by:
Jason Dravet <dravet@hotmail.com> Tested-by:
Richard Gregory Tillmore <rtillmore@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
-
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:
-
- 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:
-
Wey-Yi Guy authored
Add "Wey-Yi Guy" to maintainers list for iwlwifi. 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:
-
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:
-
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:
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:
-
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:
-
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:
-
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:
-
