- 28 Sep, 2010 1 commit
-
-
Florian Mickler authored
iwl3945's scan_completed calls into the mac80211 stack which triggers a warn on if there is no scan outstanding. This can be avoided by not calling scan_completed but abort_scan in iwl3945_request_scan in the done: branch of the function which is used as an error out. The done: branch seems to be an error-out branch, as, for example, if iwl_is_ready(priv) returns false the done: branch is executed. NOTE: I'm not familiar with the driver at all. I just quickly scanned as a reaction to https://bugzilla.kernel.org/show_bug.cgi?id=17722 the users of scan_completed in the iwl3945 driver and noted the odd discrepancy between the comment above this instance and the comment in mac80211 scan_completed function. Signed-off-by:
Florian Mickler <florian@mickler.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 24 Sep, 2010 1 commit
-
-
Johannes Berg authored
commit 8c0c709e Author: Johannes Berg <johannes@sipsolutions.net> Date: Wed Nov 25 17:46:15 2009 +0100 mac80211: move cmntr flag out of rx flags moved the CMTR flag into the skb's status, and in doing so introduced a use-after-free -- when the skb has been handed to cooked monitors the status setting will touch now invalid memory. Additionally, moving it there has effectively discarded the optimisation -- since the bit is only ever set on freed SKBs, and those were a copy, it could never be checked. For the current release, fixing this properly is a bit too involved, so let's just remove the problematic code and leave userspace with one copy of each frame for each virtual interface. Cc: stable@kernel.org [2.6.33+] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- 20 Sep, 2010 1 commit
-
-
Johannes Berg authored
When a driver doesn't fill the entire buffer, old heap contents may remain, and if it also doesn't update the length properly, this old heap content will be copied back to userspace. It is very unlikely that this happens in any of the drivers using private ioctls since it would show up as junk being reported by iwpriv, but it seems better to be safe here, so use kzalloc. Reported-by:
Jeff Mahoney <jeffm@suse.com> Cc: stable@kernel.org Signed-off-by:
-
- 17 Sep, 2010 1 commit
-
-
Wey-Yi Guy authored
When uCode error condition detected, driver try to perform either rf reset or firmware reload in order bring device back to working condition. If rf reset is required and scan is in process, there is no need to issue rf reset since scan already reset the rf. If firmware reload is required and scan is in process, skip the reload request. There is a possibility firmware reload during scan cause problem. [ 485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62() [ 485.804049] Hardware name: Latitude E6400 [ 485.804052] ieee80211_restart_hw called with hardware scan in progress [ 485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore] [ 485.804069] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74 [ 485.804072] Call Trace: [ 485.804079] [<c103019a>] warn_slowpath_common+0x60/0x75 [ 485.804084] [<c1030213>] warn_slowpath_fmt+0x26/0x2a [ 485.804089] [<c145da67>] ieee80211_restart_hw+0x28/0x62 [ 485.804102] [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn] [ 485.804108] [<c10415d5>] process_one_work+0x181/0x25c [ 485.804119] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn] [ 485.804124] [<c104190a>] worker_thread+0xf9/0x1f2 [ 485.804128] [<c1041811>] ? worker_thread+0x0/0x1f2 [ 485.804133] [<c10451b0>] kthread+0x64/0x69 [ 485.804137] [<c104514c>] ? kthread+0x0/0x69 [ 485.804141] [<c1002df6>] kernel_thread_helper+0x6/0x10 [ 485.804145] ---[ end trace 3d4ebdc02d524bbb ]--- [ 485.804148] WG> 1 [ 485.804153] Pid: 812, comm: kworker/u:3 Tainted: G W 2.6.36-rc3-wl+ #74 [ 485.804156] Call Trace: [ 485.804161] [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62 [ 485.804172] [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn] [ 485.804177] [<c10415d5>] process_one_work+0x181/0x25c [ 485.804188] [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn] [ 485.804192] [<c104190a>] worker_thread+0xf9/0x1f2 [ 485.804197] [<c1041811>] ? worker_thread+0x0/0x1f2 [ 485.804201] [<c10451b0>] kthread+0x64/0x69 [ 485.804205] [<c104514c>] ? kthread+0x0/0x69 [ 485.804209] [<c1002df6>] kernel_thread_helper+0x6/0x10 Signed-off-by:Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 31 Aug, 2010 3 commits
-
-
Luis R. Rodriguez authored
The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Cc: stable@kernel.org [2.6.27+] Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
The EEPROM is compressed on AR9003, upon decompression the wrong upper limit was being used for the block which prevented the 5 GHz CTL indexes from being used, which are stored towards the end of the EEPROM block. This fix allows the actual intended regulatory limits to be used on AR9003 hardware. Cc: stable@kernel.org [2.6.36+] Signed-off-by:
-
John W. Linville authored
Otherwise lockdep complains... https://bugzilla.kernel.org/show_bug.cgi?id=17311 [ INFO: possible circular locking dependency detected ] 2.6.36-rc2-git4 #12 ------------------------------------------------------- kworker/0:3/3630 is trying to acquire lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14 but task is already holding lock: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>] rfkill_switch_all+0x24/0x49 [rfkill] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (rfkill_global_mutex){+.+.+.}: [<ffffffff81079ad7>] lock_acquire+0x120/0x15b [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39 [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill] [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211] [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211] [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn] [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f [<ffffffff81065d15>] kthread+0x8c/0x94 [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10 -> #1 (cfg80211_mutex){+.+.+.}: [<ffffffff81079ad7>] lock_acquire+0x120/0x15b [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39 [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211] [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211] [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272 [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7 [<ffffffff8139a687>] T.723+0xbd/0x12c [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509 [<ffffffff81102b5d>] sys_ioctl+0x51/0x74 [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b -> #0 (rtnl_mutex){+.+.+.}: [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a [<ffffffff81079ad7>] lock_acquire+0x120/0x15b [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39 [<ffffffff813396c7>] rtnl_lock+0x12/0x14 [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211] [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill] [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill] [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill] [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill] [<ffffffff81060708>] process_one_work+0x248/0x403 [<ffffffff81062620>] worker_thread+0x139/0x214 [<ffffffff81065d15>] kthread+0x8c/0x94 [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10 Signed-off-by:
Johannes Berg <johannes@sipsolutions.net>
-
- 30 Aug, 2010 5 commits
-
-
Johannes Berg authored
Wireless extensions have an unfortunate, undocumented requirement which requires drivers to always fill iwp->length when returning a successful status. When a driver doesn't do this, it leads to a kernel heap content leak when userspace offers a larger buffer than would have been necessary. Arguably, this is a driver bug, as it should, if it returns 0, fill iwp->length, even if it separately indicated that the buffer contents was not valid. However, we can also at least avoid the memory content leak if the driver doesn't do this by setting the iwp length to max_tokens, which then reflects how big the buffer is that the driver may fill, regardless of how big the userspace buffer is. To illustrate the point, this patch also fixes a corresponding cfg80211 bug (since this requirement isn't documented nor was ever pointed out by anyone during code review, I don't trust all drivers nor all cfg80211 handlers to implement it correctly). Cc: stable@kernel.org [all the way back] Signed-off-by:
-
John W. Linville authored
Reported-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Johannes Berg authored
The new workqueue changes helped me find this bug that's been lingering since the changes to the work processing in mac80211 -- the work timer is never deleted properly. Do that to avoid having it fire after all data structures have been freed. It can't be re-armed because all it will do, if running, is schedule the work, but that gets flushed later and won't have anything to do since all work items are gone by now (by way of interface removal). Cc: stable@kernel.org [2.6.34+] Signed-off-by:
-
Christian Lamparter authored
Michael reported that p54* never really entered power save mode, even tough it was enabled. It turned out that upon a power save mode change the firmware will set a special flag onto the last outgoing frame tx status (which in this case is almost always the designated PSM nullfunc frame). This flag confused the driver; It erroneously reported transmission failures to the stack, which then generated the next nullfunc. and so on... Cc: <stable@kernel.org> Reported-by:
Michael Buesch <mb@bu3sch.de> Tested-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
John W. Linville authored
This avoids a NULL pointer dereference as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=625889 When the WARN condition is hit in ieee80211_get_tx_rate, it will return NULL. So, we need to check the return value and avoid dereferencing it in that case. Signed-off-by:
Bob Copeland <me@bobcopeland.com>
-
- 27 Aug, 2010 1 commit
-
-
Mike Rapoport authored
The commit 886275ce (param: lock if_sdio's lbs_helper_name and lbs_fw_name against sysfs changes) introduced new fields into the if_sdio_card structure. It caused missalignment of the if_sdio_card.buffer field and failure at driver load time: ~# modprobe libertas_sdio [ 62.315124] libertas_sdio: Libertas SDIO driver [ 62.319976] libertas_sdio: Copyright Pierre Ossman [ 63.020629] DMA misaligned error with device 48 [ 63.025207] mmci-omap-hs mmci-omap-hs.1: unexpected dma status 800 [ 66.005035] libertas: command 0x0003 timed out [ 66.009826] libertas: Timeout submitting command 0x0003 [ 66.016296] libertas: PREP_CMD: command 0x0003 failed: -110 Adding explicit alignment attribute for the if_sdio_card.buffer field fixes this problem. Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Acked-by:
Marek Vasut <marek.vasut@gmail.com> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
- 18 Aug, 2010 2 commits
-
-
Wey-Yi Guy authored
For 5000 series of devices, use long monitor timer to check stuck tx queues. This modification apply to all the 5000 series including 5300 and others. Cc: stable@kernel.org [2.6.35] Reported-by:
drago01 <drago01@gmail.com> Signed-off-by:
-
Joe Perches authored
Commit c96c31e4 "(drivers/net/wireless: Use wiphy_<level>)" inadvertently changed some upper case words to lower case. Restore the original case. Signed-off-by:
-
- 17 Aug, 2010 2 commits
-
-
Johannes Berg authored
Applying the filter flags directly as done since commit 3474ad63 Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Apr 29 04:43:05 2010 -0700 iwlwifi: apply filter flags directly broke 3945 under some unknown circumstances, as reported by Alex. Since I want to keep the direct application of filter flags on iwlagn, duplicate the code into both 3945 and agn and remove committing the RXON that broke things from the 3945 version. Cc: stable@kernel.org [2.6.35] Reported-by:
Alex Romosan <romosan@sycorax.lbl.gov> Signed-off-by:
-
John W. Linville authored
These are allocated with pci_alloc_consistent, so calling pci_dma_sync_single_for_cpu is incorrect usage of the API. Remove this misuse and consequently avoid the following backtrace: WARNING: at lib/dma-debug.c:902 check_sync+0xce/0x43a() Hardware name: 2373HU6 ipw2100 0000:02:02.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000034e88008] [size=8 bytes] Modules linked in: microcode ipw2100(+) snd_seq_device ppdev libipw nsc_ircc snd_pcm lib80211 video output irda parport_pc cfg80211 parport thinkpad_acpi e1000 iTCO_wdt crc_ccitt snd_timer iTCO_vendor_support snd i2c_i801 pcspkr rfkill soundcore joydev snd_page_alloc yenta_socket radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Tainted: G W 2.6.35-wl+ #8 Call Trace: [<c043aa42>] warn_slowpath_common+0x6a/0x7f [<c05d252a>] ? check_sync+0xce/0x43a [<c043aaca>] warn_slowpath_fmt+0x2b/0x2f [<c05d252a>] check_sync+0xce/0x43a [<c046189a>] ? print_lock_contention_bug+0x11/0xb2 [<c05d2b6f>] debug_dma_sync_single_for_cpu+0x47/0x49 [<c06cbd3c>] ? ehci_irq+0x31/0x331 [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100] [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100] [<f82a221d>] pci_dma_sync_single_for_cpu.clone.1+0x42/0x4b [ipw2100] [<f82a23a2>] ipw2100_irq_tasklet+0x17c/0x5e9 [ipw2100] [<c043fd87>] tasklet_action+0x78/0xcb [<c0440293>] __do_softirq+0xc4/0x183 [<c044038d>] do_softirq+0x3b/0x5f [<c04404d0>] irq_exit+0x3a/0x6d [<c0404423>] do_IRQ+0x8b/0x9f [<c04038b5>] common_interrupt+0x35/0x3c [<c062ecfa>] ? acpi_idle_enter_simple+0xfe/0x13c [<c045007b>] ? exit_itimers+0x2d/0x73 [<c062ecfc>] ? acpi_idle_enter_simple+0x100/0x13c [<c070bf10>] cpuidle_idle_call+0x78/0xdc [<c040251c>] cpu_idle+0x9b/0xb7 [<c07b1dd2>] rest_init+0xa6/0xab [<c0a4b96d>] start_kernel+0x389/0x38e [<c0a4b0c9>] i386_start_kernel+0xc9/0xd0 Signed-off-by:
-
- 14 Aug, 2010 2 commits
-
-
Wey-Yi Guy authored
For 5000 and 6000g2b series of devices, use long monitor timer to check stuck tx queues. .6000g2b series device, it is WiFi/BT combo device, there are some cases, tx queues are not move for a period of time because the WiFi/BT coex. .5000 series device, it is being reported firmware got reload more often than necessary, so extend the timer to avoid un-necessary reload. Signed-off-by: -
Wey-Yi Guy authored
Change the name for monitor timer, also adding define for long monitor timer; long monitor timer can be used for the type of devices require longer time to determine the uCode is stuck on tx and needed reload. Signed-off-by:
-
- 13 Aug, 2010 4 commits
-
-
Maxim Levitsky authored
Atheros PCIe wireless cards handled by ath5k do require L0s disabled. For distributions shipping with CONFIG_PCIEASPM (this will be enabled by default in the future in 2.6.36) this will also mean both L1 and L0s will be disabled when a pre 1.1 PCIe device is detected. We do know L1 works correctly even for all ath5k pre 1.1 PCIe devices though but cannot currently undue the effect of a blacklist, for details you can read pcie_aspm_sanity_check() and see how it adjusts the device link capability. It may be possible in the future to implement some PCI API to allow drivers to override blacklists for pre 1.1 PCIe but for now it is best to accept that both L0s and L1 will be disabled completely for distributions shipping with CONFIG_PCIEASPM rather than having this issue present. Motivation for adding this new API will be to help with power consumption for some of these devices. Example of issues you'd see: - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well with ASPM enabled, the card will eventually stall on heavy traffic with often 'unsupported jumbo' warnings appearing. Disabling ASPM L0s in ath5k fixes these problems. - On the same card you would see a storm of RXORN interrupts even though medium is idle. Credit for root causing and fixing the bug goes to Jussi Kivilinna. Cc: David Quan <David.Quan@atheros.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tim Gardner <tim.gardner@canonical.com> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Cc: stable@kernel.org Signed-off-by:Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
-
Rajkumar Manoharan authored
This patch handles the firmware loading properly for device ID 7015. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Yuri Kululin authored
Use appropriate command (CMD_TRIGGER_SCAN_TO) instead of scan command (CMD_SCAN) to configure trigger scan timeout. This was broken in commit 3a98c30f. This fix address the bug reported here: https://bugzilla.kernel.org/show_bug.cgi?id=16554 Cc: stable@kernel.org Signed-off-by:
Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
Yuri Kululin <ext-yuri.kululin@nokia.com> Acked-by:
Kalle Valo <kvalo@adurom.com> Signed-off-by:
-
Vivek Natarajan authored
Some APs advertise that they may be HT40 capable in the capabilites but the current operating channel configuration may be only HT20. This causes disconnection as ath9k_htc sets WLAN_RC_40_FLAG despite the AP operating in HT20 mode. Hence set this flag only if the current channel configuration is HT40 enabled. Cc: stable@kernel.org Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
-
- 11 Aug, 2010 2 commits
-
-
Rajkumar Manoharan authored
This should fix the oops which occurs during the packet injection on monitor interface. EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc] [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211] [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc] [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211] [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211] [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211] [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211] [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210 [<c04b97c2>] ? __alloc_skb+0x52/0x130 [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170 [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0 [<c0567e1e>] ? packet_snd+0x21e/0x250 [<c05684a2>] ? packet_sendmsg+0x32/0x40 [<c04b4c63>] ? sock_aio_write+0x113/0x130 [<c0207934>] ? do_sync_write+0xc4/0x100 [<c0167740>] ? autoremove_wake_function+0x0/0x50 [<c02f4414>] ? security_file_permission+0x14/0x20 [<c0207ad4>] ? rw_verify_area+0x64/0xe0 [<c01e6458>] ? handle_mm_fault+0x338/0x390 [<c0207cd5>] ? vfs_write+0x185/0x1a0 [<c058db20>] ? do_page_fault+0x160/0x3a0 [<c0208512>] ? sys_write+0x42/0x70 [<c01033ec>] ? syscall_call+0x7/0xb Signed-off-by:
-
John W. Linville authored
It is necessary to call pm_qos_add_request prior to calling pm_qos_update_request. It was revealed that ipw2100 has been doing this wrong since "pm_qos: Get rid of the allocation in pm_qos_add_request()" (commit 82f68251) added a WARN that results in the following backtrace: WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70() pm_qos_update_request() called for unknown object Call Trace: [<c1024088>] ? warn_slowpath_common+0x78/0xb0 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<c1024153>] ? warn_slowpath_fmt+0x33/0x40 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100] [<c11961c9>] ? vsnprintf+0xc9/0x530 [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100] [<c12f542d>] ? register_netdevice+0x7d/0x3c0 [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100] [<c12f579f>] ? register_netdev+0x2f/0x40 [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100] [<c11a5ebb>] ? local_pci_probe+0xb/0x10 [<c11a6d49>] ? pci_device_probe+0x69/0x90 [<c1224704>] ? driver_probe_device+0x74/0x180 [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0 [<c1224889>] ? __driver_attach+0x79/0x80 [<c1224810>] ? __driver_attach+0x0/0x80 [<c1223fa2>] ? bus_for_each_dev+0x52/0x80 [<c1224586>] ? driver_attach+0x16/0x20 [<c1224810>] ? __driver_attach+0x0/0x80 [<c122395f>] ? bus_add_driver+0x17f/0x250 [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20 [<c11a6c80>] ? pci_device_remove+0x0/0x40 [<c1224b13>] ? driver_register+0x63/0x120 [<c11a6f96>] ? __pci_register_driver+0x36/0xa0 [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100] [<c1001122>] ? do_one_initcall+0x32/0x170 [<c1087078>] ? __vunmap+0xb8/0xf0 [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100] [<c10510c1>] ? sys_init_module+0x161/0x1000 [<c108f847>] ? sys_close+0x67/0xe0 [<c13647c1>] ? syscall_call+0x7/0xb This patch moves pm_qos_add_request prior to pci_register_driver in ipw2100 in order to avoid this problem. Reported-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
-
- 10 Aug, 2010 5 commits
-
-
-
Mat Martineau authored
The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on the default L2CAP MTU. That default MTU is calculated from the size of two DH5 packets, minus ACL and L2CAP b-frame header overhead. ERTM is used with newer basebands that typically support larger 3-DH5 packets, and i-frames and s-frames have more header overhead. With clean RF conditions, basebands will typically attempt to use 1021-byte 3-DH5 packets for maximum throughput. Adjusting for 2 bytes of ACL headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes of payload. This PDU size imposes less overhead for header bytes and gives the baseband the option to choose 3-DH5 packets, but is small enough for ERTM traffic to interleave well with other L2CAP or SCO data. 672-byte payloads do not allow the most efficient over-the-air packet choice, and cannot achieve maximum throughput over BR/EDR. Signed-off-by:
Mat Martineau <mathewm@codeaurora.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Mat Martineau authored
remote_tx_win is intended to be set on receipt of an L2CAP configuration request. The value is used to determine the size of the transmit window on the remote side of an ERTM connection, so L2CAP can stop sending frames when that remote window is full. An incorrect remote_tx_win value will cause the stack to not fully utilize the tx window (performance impact), or to overfill the remote tx window (causing dropped frames or a disconnect). This patch removes an extra setting of remote_tx_win when a configuration response is received. The transmit window has a different meaning in a response - it is an informational value less than or equal to the local tx_win. Signed-off-by:
-
Mat Martineau authored
The L2CAP specification requires that the ERTM retransmit timeout be at least 2 seconds for BR/EDR connections. Signed-off-by:
-
Mat Martineau authored
Incoming configuration values must be converted to native CPU order before use. This fixes a bug where a little-endian MPS value is compared to a native CPU value. On big-endian processors, this can cause ERTM and streaming mode segmentation to produce PDUs that are larger than the remote stack is expecting, or that would produce fragmented skbs that the current FCS code cannot handle. Signed-off-by:
-
- 09 Aug, 2010 8 commits
-
-
Johannes Berg authored
Currently the driver will try to protect all frames, which leads to a lot of odd things like sending an RTS with a zeroed RA before multicast frames, which is clearly bogus. In order to fix all of this, we need to take a step back and see what we need to achieve: * we need RTS/CTS protection if requested by the AP for the BSS, mac80211 tells us this * in that case, CTS-to-self should only be enabled when mac80211 tells us * additionally, as a hardware workaround, on some devices we have to protect aggregated frames with RTS To achieve the first two items, set up the RXON accordingly and set the protection required flag in the transmit command when mac80211 requests protection for the frame. To achieve the last item, set the rate-control RTS-requested flag for all stations that we have aggregation sessions with, and set the protection required flag when sending aggregated frames (on those devices where this is required). Since otherwise bugs can occur, do not allow the user to override the RTS-for-aggregation setting from sysfs any more. Finally, also clean up the way all these flags get set in the driver and move everything into the device-specific functions. Cc: stable@kernel.org [2.6.35] Signed-off-by:
-
Johannes Berg authored
Accesses to "wdev->current_bss" must be locked with the wdev lock, which action frame transmission is missing. Cc: stable@kernel.org [2.6.33+] Signed-off-by:
-
John W. Linville authored
CC [M] drivers/net/wireless/libertas/cfg.o /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_scan_worker’: /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: ‘TASK_NORMAL’ undeclared (first use in this function) /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: (Each undeclared identifier is reported only once /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: for each function it appears in.) /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_cfg_connect’: /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘signal_pending’ /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘schedule_timeout’ Reported-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
John W. Linville authored
This reverts commit 5f7aebd8. Apparently, that PCI ID data was incorrectly taken from the subsystem information. The actual ID matches another already known ID. Signed-off-by:
-
Jeff Kirsher authored
Adds documentation for the igbvf (igb virtual function driver). v2: - Removed trailing white space - Removed Ethtool version info Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jeff Kirsher authored
Add documentation for the igb networking driver. v2: - Removed trailing white space - Removed Ethtool version info - Removed LRO kernel version info Signed-off-by:
-
Jeff Kirsher authored
Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller <miltonm@bga.com> CC: Anton Blanchard <anton@samba.org> CC: Sonny Rao <sonnyrao@us.ibm.com> CC: stable <stable@kernel.org> Signed-off-by:
-
John Fastabend authored
Building ixgbe without DCB_CONFIG and FCOE_CONFIG will cause a build error. This resolves the build error by wrapping the fcoe.up in CONFIG_IXGBE_DCB ifdefs. Also frames were being priority VLAN tagged even without DCB enabled. This fixes this so that 8021Q priority tags are only added with DCB actually enabled. Reported-by:
divya <dipraksh@linux.vnet.ibm.com> Reported-by:
Jon Mason <jon.mason@exar.com> Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Tested-by:
Stephen Ko <stephen.s.ko@intel.com> Tested-by:
Ross Brattain <ross.b.brattain@intel.com> Signed-off-by:
-
- 08 Aug, 2010 2 commits
-
-
Amit Kumar Salecha authored
Signed-off-by:
Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by:
-
Dan Carpenter authored
I moved the kfree(cb) below the dereferences. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
