* Re: iwlagn fails to assoc with nexus one in ad-hoc mode
From: reinette chatre @ 2010-06-09 19:10 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100609.103326.189711649.davem@davemloft.net>
Hi David,
On Wed, 2010-06-09 at 10:33 -0700, David Miller wrote:
> From: reinette chatre <reinette.chatre@intel.com>
> > Which hardware are you using? This information is needed to decode the
> > firmware assert you are posting.
>
> 5300
The firmware assert you are encountering is something that we have fixed
before. This may be a new instance of it or you may not be running with
the fix. What repo/kernel version are you using for your testing?
Also, to confirm things, could you ensure driver is compiled with
CONFIG_IWLWIFI_DEBUG and load module with "modprobe iwlagn
debug=0x43fff" to get us some more data? It may help to compile mac80211
with verbose debugging (CONFIG_MAC80211_VERBOSE_DEBUG) also.
Thank you
Reinette
^ permalink raw reply
* Re: iwlagn fails to assoc with nexus one in ad-hoc mode
From: David Miller @ 2010-06-09 19:12 UTC (permalink / raw)
To: reinette.chatre; +Cc: linux-wireless
In-Reply-To: <1276110641.1835.14891.camel@rchatre-DESK>
From: reinette chatre <reinette.chatre@intel.com>
Date: Wed, 09 Jun 2010 12:10:41 -0700
> Hi David,
>
> On Wed, 2010-06-09 at 10:33 -0700, David Miller wrote:
>> From: reinette chatre <reinette.chatre@intel.com>
>> > Which hardware are you using? This information is needed to decode the
>> > firmware assert you are posting.
>>
>> 5300
>
> The firmware assert you are encountering is something that we have fixed
> before. This may be a new instance of it or you may not be running with
> the fix. What repo/kernel version are you using for your testing?
Upstream 2.6.34 vanilla.
> Also, to confirm things, could you ensure driver is compiled with
> CONFIG_IWLWIFI_DEBUG and load module with "modprobe iwlagn
> debug=0x43fff" to get us some more data? It may help to compile mac80211
> with verbose debugging (CONFIG_MAC80211_VERBOSE_DEBUG) also.
I'll try to find time to do this.
^ permalink raw reply
* Re: iwlagn fails to assoc with nexus one in ad-hoc mode
From: reinette chatre @ 2010-06-09 19:17 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100609.121207.193693646.davem@davemloft.net>
On Wed, 2010-06-09 at 12:12 -0700, David Miller wrote:
> Upstream 2.6.34 vanilla.
ok - the firmware assert you are encountering is in the station
management code which received significant rework in 2.6.35. Could you
please try latest linux-2.6 (since there are some issues with
2.6.35-rc2)?
Reinette
^ permalink raw reply
* pull request: wireless-next-2.6 2010-06-09
From: John W. Linville @ 2010-06-09 21:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is the usual, frightening, monstrous post-window pull request...
Along with the usual batch of driver updates, there are also some DMA
state API conversions from FUJITA Tomonori, some cleanups from Julia
Lawall and Joe Perches, some SSB changes from Larry Finger and Rafał
Miłecki, and a number of mac80211 changes from Johannes Berg. All of it
has had at least one cycle through linux-next and most of it has been
there for several days. This also includes the same wireless-2.6 pull I
sent you previously so as to resolve some merge conflicts.
Please let me know if there are problems!
John
---
The following changes since commit bb69ae049fcc986fcd742eb90ca0d44a7a49c9f1:
Eric Dumazet (1):
anycast: Some RCU conversions
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Abhijeet Kolekar (1):
iwl3945: fix internal scan
Amitkumar Karwar (1):
libertas: Added callback functions to support SDIO suspend/resume.
Bob Copeland (1):
ath5k: retain promiscuous setting
Bruno Randolf (15):
ath5k: initialize calibration timers
ath5k: move noise floor calibration into tasklet
ath5k: Stop queues only for NF calibration
ath5k: run NF calibration only every 60 seconds
ath5k: remove ATH_TRACE macro
ath5k: clarify logic when to enable spur mitigation filter
ath5k: use ath5k_softc as driver data
ath5k: add sysfs files for ANI parameters
ath5k: always calculate ANI listen time
ath5k: print error message if ANI levels are out of range
ath5k: fix NULL pointer in antenna configuration
ath5k: update AR5K_PHY_RESTART_DIV_GC values to match masks
ath5k: new function for setting the antenna switch table
ath5k: no need to save/restore the default antenna
ath5k: add debugfs file for queue debugging
Dan Carpenter (3):
ath9k/debug: improve the snprintf() handling
ath9k/debug: fixup the return codes
ath9k: cleanup: remove unneeded null check
Daniel Halperin (2):
iwlwifi: parse block ack responses correctly
iwlwifi: fix wrapping when handling aggregated batches
Emmanuel Grumbach (1):
iwlwifi: move sysfs_create_group to post request firmware
FUJITA Tomonori (7):
mwl8k: use the dma state API instead of the pci equivalents
iwlwifi: use the DMA state API instead of the pci equivalents
ssb: add dma_dev to ssb_device structure
b43legacy: replace the ssb_dma API with the generic DMA API
b43: replace the ssb_dma API with the generic DMA API
b44: replace the ssb_dma API with the generic DMA API
ssb: remove the ssb DMA API
Felix Fietkau (6):
mac80211: add the minstrel_ht rate control algorithm
ath9k_hw: add multicast key search support
ath9k_common: use allocated key cache entries for multi BSS crypto support
ath9k: use the key handling code from ath9k_common instead of duplicating it
ath9k: fix queue stop/start based on the number of pending frames
mac80211: reduce debugfs code size
Gertjan van Wingerde (14):
rt2x00: Move rt2x00debug_dump_frame declaration to rt2x00.h.
rt2x00: Push beacon TX descriptor writing to drivers.
rt2x00: Reverse calling order of bus write_tx_desc and driver write_tx_desc.
rt2x00: Properly reserve room for descriptors in skbs.
rt2x00: Fix rt2800usb TX descriptor writing.
rt2x00: Clean up USB vendor request buffer functions.
rt2x00: Centralize rt2800 beacon writing.
rt2x00: Remove RT2870 chipset identification.
rt2x00: Move all register definitions for rt2800 to rt2800.h.
rt2x00: Introduce separate interface type for PCI-express.
rt2x00: Simplify check for external LNA in rt2800_init_rfcsr.
rt2x00: Move PCI/USB specific register initializations to rt2800{pci,usb}.
rt2x00: Sync rt2800 MCU boot signal with Ralink driver.
rt2x00: Fix HT40 operation in rt2800.
Grazvydas Ignotas (2):
wl1251: fix a memory leak in probe
wl1251: fix ELP_CTRL register reads
Helmut Schaa (5):
cfg80211: don't refuse HT20 channels on devices that don't support HT40
rt2x00: rt2800: disable TX STBC for 1 stream devices
rt2x00: Update TX_SW_CFG initvals for 305x SoC
rt2x00: fix use of mcs rates
rt2x00: Remove suspicious register write
Holger Schurig (1):
mac80211: fix function pointer check
Ivo van Doorn (1):
rt2x00: Use IEEE80211_TX_CTL_STBC flag
Jason Dravet (1):
p54usb: Add device ID for Dell WLA3310 USB
Joe Perches (1):
drivers/net/wireless/ipw2x00/ipw2100.c: Remove unnecessary kmalloc casts
Johannes Berg (33):
iwlwifi: introduce iwl_sta_id_or_broadcast
iwlwifi: don't crash on firmware file missing info
iwl3945: remove sequence number assignment
iwlwifi: move iwl_free_tfds_in_queue to iwlagn
iwlwifi: improve station debugfs
iwlwifi: remove IWL_MULTICAST_ID
iwlagn: use firmware event/error log information
iwlwifi: split debug and debugfs options
iwlwifi: use proper short slot/preamble settings
cfg80211: make action channel type optional
mac80211: remove bogus mod_timer() call
mac80211: remove tx status ampdu_ack_map
mac80211: clean up ieee80211_stop_tx_ba_session
mac80211: move WEP weak IV check
mac80211: remove useless work starting
mac80211: drop control frames after processing
mac80211: move plink state
mac80211: simplify key locking
mac80211: process station blockack action frames from work
iwlwifi: remove useless node_addr assignments
iwlwifi: remove unused wlap_bssid_addr assignment
iwlwifi: remove mac_addr assignment
iwlwifi: set MAC address in RXON from interface
iwlwifi: use virtual interface address for scan
iwlwifi: remove debug frame dumping
iwlwifi: remove priv->mac_addr
iwl3945: fix bugs in txq freeing
iwlagn: fix bug in txq freeing
iwlwifi: kzalloc txb array
iwlwifi: reduce memory allocation
iwlwifi: generic scan TX antenna forcing
iwlwifi: queue user-initiated scan when doing internal scan
wireless: fix kernel-doc
John W. Linville (8):
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
ath9k_htc: fix build error when ATH9K_HTC_DEBUGFS not enabled
Revert "iwlwifi: move _agn statistics related structure"
mac80211: make ARP filtering depend on CONFIG_INET
Revert "wireless: hostap, fix oops due to early probing interrupt"
iwlwifi: fix-up botched revert
mac80211: fix lock leak w/ ARP filtering and w/o CONFIG_INET
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Julia Lawall (11):
drivers/net/wireless/orinoco: Use kzalloc
drivers/net/wireless/libertas: Use kmemdup
drivers/net/wireless/wl12xx: Use kmemdup
drivers/net/wireless/libertas_tf: Use kmemdup
drivers/net/wireless/iwmc3200wifi: Use kmemdup
drivers/net/wireless/ath/ath9k: Use kmemdup
drivers/net/wireless/b43: Use kmemdup
drivers/net/wireless/ipw2x00: Use kmemdup
drivers/net/wireless/p54: Use kmemdup
drivers/net/wireless/orinoco: Use kmemdup
drivers/net/wireless/prism54: Use memdup_user
Jussi Kivilinna (1):
rndis_wlan: increase assocbuf size and validate association info offsets from driver
Juuso Oikarinen (9):
wl1271: Update handling of the NVS file / INI parameters
wl1271: Add support for NVS files with 5GHz band parameters
wl1271: Prevent dropping of TX frames in joins
wl1271: Idle handling into own function
wl1271: Flush TX buffers to air before going to idle
wl1271: Use proper rates for PSM entry/exit null-funcs for 5GHz
wl1271: Fix scan parameter handling for 5GHz
mac80211: Add support for hardware ARP query filtering
mac80211: Add netif state checking to ieee80211_ifa_changed
Larry Finger (1):
ssb: Handle alternate SSPROM location
Luciano Coelho (1):
wl1271: the core wl1271 module shouldn't depend on SPI_MASTER
Luis R. Rodriguez (5):
ath9k_hw: add support for the AR9003 2.2
ath9k_hw: rename the ar9003_initvals.h to ar9003_2p0_initvals.h
ath9k_hw: add support for the AR9003 baseband watchdog
ath9k: enable the baseband watchdog events for AR9003
ath9k_hw: Enable TX IQ calibration on AR9003
Luke-Jr (1):
p54spi: replace internal "cx3110x" name with "p54spi"
Ming Lei (2):
ath9k: fix dma direction for map/unmap in ath_rx_tasklet
ath9k: fix dma sync in rx path
Ohad Ben-Cohen (1):
wl1271: remove sdio ARM dependency
Prarit Bhargava (1):
ath: Fix uninitialized variable warnings
Rafał Miłecki (2):
ssb: update PMU init to match specs
ssb: fast powerup delay calculation for PMU capable devices
Reinette Chatre (2):
iwlwifi: fix and add missing sta_lock usage
iwl3945: enable stuck queue detection on 3945
Sascha Silbe (1):
libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
Shanyu Zhao (3):
iwlwifi: enable remaining 6000 Gen2 devices
iwlwifi: add new PCI IDs for 6000g2 devices
iwlwifi: do not clear data after chain noise calib
Sujith (34):
ath9k_htc: Add queue statistics to xmit debugfs file
ath9k_htc: Initialize beacon/CAB queues
ath9k_htc: Remove HW queue translation
ath9k_htc: Increase credit size
ath9k_htc: Initvals update for AR9271
ath9k_htc: Cleanup rate initialization
ath9k_htc: Update HT configuration properly
ath9k_htc: Enable SGI in HT20 for AR9271
ath9k_htc: Enable RX STBC for AR9271
ath9k: Move ath9k specific RX code to driver
ath9k: Move driver specific structures
ath9k_hw: Cleanup eeprom_9287.c
ath9k_hw: Optimize ath9k_hw_ar9287_set_board_values
ath9k_hw: Cleanup TX power calculation for AR9287
ath9k_hw: Update the PCI WAR register
ath9k_hw: Fix async fifo for AR9287
ath9k_htc: Revamp CONF_IDLE handling
ath9k_htc: Add PS wrappers
ath9k_htc: Fix bug in handling CONF_IDLE
ath9k_htc: Remove useless cancel_work_sync
ath9k_htc: Fix locking for ps_idle
ath9k_htc: Handle monitor interface removal
ath9k_htc: Handle host RX disable
ath9k_htc: Fix fair beacon distribution
ath9k_htc: Use proper station add/remove callbacks
mac80211: Remove deprecated sta_notify commands
ath9k: Determine Firmware on probe
ath9k_hw: Configure byte swap for non AR9271 chips
ath9k_htc: Add support for AR7010
ath9k_common: Move count_streams to common module
ath9k_htc: Setup HT capabilites for 2-stream devices
ath9k_htc: Configure dual stream rates
ath9k_htc: Setup 5GHz channels
ath9k_htc: Configure credit size for AR7010
Tobias Doerffel (1):
ath5k: depend on CONFIG_PM_SLEEP for suspend/resume functions
Tobias Klauser (1):
drivers/net/wireless: Storage class should be before const qualifier
Vasanthakumar Thiagarajan (8):
ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips
ath9k: Make sure null func frame is acked before going into PS for ar9003
ath9k: Fix power save with auto sleeping
ath9k_hw: Enable auto sleep for ar9003
ath9k: Clean up few function parameters in recv.c
ath9k: Fix bug in accessing skb->data of rx frame for edma
ath9k: Fix bug in validating received data length for edma
ath9k: Fix bug in rate table
Walter Goldens (1):
wireless: fix several minor description typos
Wey-Yi Guy (13):
iwlwifi: move _agn statistics related structure
iwlwifi: separate statistics flag function for agn & 3945
iwlwifi: code cleanup for _agn devices
iwlwifi: modify out-dated comments
iwlwifi: move ucode related function to iwl-agn-ucode.c
iwlwifi: add name to Maintainers list
iwlwifi: remove unused parameter in iwl_priv
iwlwifi: beacon format related helper function
iwlwifi: support channel switch offload in driver
iwlwifi: beacon internal time unit
iwlwifi: remove inaccurate comment
iwlwifi: do not use huge command buffer for channel switch
iwlwifi: remove unused parameter
Zhu Yi (1):
wireless: remove my name from the maintainer list
MAINTAINERS | 5 +-
drivers/net/b44.c | 144 ++--
drivers/net/wireless/ath/ath5k/Makefile | 1 +
drivers/net/wireless/ath/ath5k/ani.c | 20 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 7 +
drivers/net/wireless/ath/ath5k/attach.c | 2 -
drivers/net/wireless/ath/ath5k/base.c | 50 +-
drivers/net/wireless/ath/ath5k/caps.c | 7 -
drivers/net/wireless/ath/ath5k/debug.c | 74 ++-
drivers/net/wireless/ath/ath5k/debug.h | 9 +-
drivers/net/wireless/ath/ath5k/desc.c | 7 -
drivers/net/wireless/ath/ath5k/dma.c | 13 -
drivers/net/wireless/ath/ath5k/eeprom.c | 3 +-
drivers/net/wireless/ath/ath5k/gpio.c | 7 -
drivers/net/wireless/ath/ath5k/pcu.c | 24 -
drivers/net/wireless/ath/ath5k/phy.c | 89 ++-
drivers/net/wireless/ath/ath5k/qcu.c | 9 -
drivers/net/wireless/ath/ath5k/reset.c | 64 +--
drivers/net/wireless/ath/ath5k/sysfs.c | 116 +++
drivers/net/wireless/ath/ath9k/ani.c | 1 +
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 11 -
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 109 ++-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 6 +-
.../{ar9003_initvals.h => ar9003_2p0_initvals.h} | 6 +-
.../{ar9003_initvals.h => ar9003_2p2_initvals.h} | 185 +++---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 163 ++++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 1 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 119 +++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 66 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 68 ++-
drivers/net/wireless/ath/ath9k/common.c | 314 +-------
drivers/net/wireless/ath/ath9k/common.h | 77 +--
drivers/net/wireless/ath/ath9k/debug.c | 56 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom.c | 29 +
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 618 ++++++++--------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 1 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/htc.h | 12 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 23 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 127 +++-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 397 ++++++----
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 47 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 3 +-
drivers/net/wireless/ath/ath9k/hw.c | 41 +-
drivers/net/wireless/ath/ath9k/hw.h | 14 +-
drivers/net/wireless/ath/ath9k/init.c | 19 +-
drivers/net/wireless/ath/ath9k/main.c | 255 +------
drivers/net/wireless/ath/ath9k/rc.c | 177 +++--
drivers/net/wireless/ath/ath9k/recv.c | 278 +++++++-
drivers/net/wireless/ath/ath9k/reg.h | 62 +-
drivers/net/wireless/ath/ath9k/wmi.c | 3 -
drivers/net/wireless/ath/ath9k/xmit.c | 60 +-
drivers/net/wireless/b43/dma.c | 69 +-
drivers/net/wireless/b43legacy/dma.c | 49 +-
drivers/net/wireless/hostap/hostap_hw.c | 9 -
drivers/net/wireless/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 3 +-
drivers/net/wireless/iwlwifi/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 202 +-----
drivers/net/wireless/iwlwifi/iwl-4965.c | 83 ++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 58 ++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 345 ++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 252 ++----
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 77 ++-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 123 +++
drivers/net/wireless/iwlwifi/iwl-agn.c | 609 ++++++++++-----
drivers/net/wireless/iwlwifi/iwl-agn.h | 34 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 305 ++++----
drivers/net/wireless/iwlwifi/iwl-core.h | 25 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 81 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 76 +-
drivers/net/wireless/iwlwifi/iwl-helpers.h | 27 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 40 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 72 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 29 +
drivers/net/wireless/iwlwifi/iwl-tx.c | 33 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 183 ++---
drivers/net/wireless/iwmc3200wifi/hal.c | 2 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 4 +-
drivers/net/wireless/libertas/cmd.c | 37 +-
drivers/net/wireless/libertas/cmdresp.c | 30 +-
drivers/net/wireless/libertas/decl.h | 2 +-
drivers/net/wireless/libertas/dev.h | 6 +
drivers/net/wireless/libertas/ethtool.c | 24 +-
drivers/net/wireless/libertas/if_sdio.c | 58 ++
drivers/net/wireless/libertas/if_usb.c | 12 +-
drivers/net/wireless/libertas/main.c | 79 ++-
drivers/net/wireless/libertas/scan.c | 2 +-
drivers/net/wireless/libertas_tf/if_usb.c | 5 +-
drivers/net/wireless/mwl8k.c | 12 +-
drivers/net/wireless/orinoco/hermes_dld.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 4 +-
drivers/net/wireless/orinoco/wext.c | 4 +-
drivers/net/wireless/p54/eeprom.c | 4 +-
drivers/net/wireless/p54/p54spi.c | 5 +-
drivers/net/wireless/p54/p54usb.c | 4 +-
drivers/net/wireless/prism54/isl_ioctl.c | 11 +-
drivers/net/wireless/rndis_wlan.c | 36 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 31 +-
drivers/net/wireless/rt2x00/rt2800.h | 49 ++-
drivers/net/wireless/rt2x00/rt2800lib.c | 154 ++--
drivers/net/wireless/rt2x00/rt2800lib.h | 13 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 103 +--
drivers/net/wireless/rt2x00/rt2800pci.h | 19 -
drivers/net/wireless/rt2x00/rt2800usb.c | 104 ++--
drivers/net/wireless/rt2x00/rt2800usb.h | 37 -
drivers/net/wireless/rt2x00/rt2x00.h | 42 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 12 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 7 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 47 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 51 ++-
drivers/net/wireless/rt2x00/rt2x00pci.h | 8 +
drivers/net/wireless/rt2x00/rt2x00queue.c | 34 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 33 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 19 -
drivers/net/wireless/rt2x00/rt61pci.c | 14 +-
drivers/net/wireless/rt2x00/rt73usb.c | 48 +-
drivers/net/wireless/wl12xx/Kconfig | 4 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c | 41 +-
drivers/net/wireless/wl12xx/wl1271.h | 31 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 41 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 28 +-
drivers/net/wireless/wl12xx/wl1271_event.c | 10 +-
drivers/net/wireless/wl12xx/wl1271_ini.h | 123 +++
drivers/net/wireless/wl12xx/wl1271_main.c | 95 ++-
drivers/net/wireless/wl12xx/wl1271_sdio.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_testmode.c | 11 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 36 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 1 +
drivers/net/wireless/zd1211rw/zd_mac.c | 2 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
drivers/ssb/driver_chipcommon.c | 25 +
drivers/ssb/driver_chipcommon_pmu.c | 17 +-
drivers/ssb/main.c | 76 +--
drivers/ssb/pci.c | 15 +-
include/linux/nl80211.h | 2 +-
include/linux/ssb/ssb.h | 159 +----
include/net/cfg80211.h | 120 +++-
include/net/mac80211.h | 35 +-
net/mac80211/Kconfig | 7 +
net/mac80211/Makefile | 4 +
net/mac80211/agg-tx.c | 7 +-
net/mac80211/cfg.c | 22 +-
net/mac80211/debugfs.c | 154 ++---
net/mac80211/debugfs_sta.c | 48 +-
net/mac80211/driver-ops.h | 25 +-
net/mac80211/driver-trace.h | 35 +-
net/mac80211/ibss.c | 14 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/iface.c | 14 +-
net/mac80211/key.c | 288 ++------
net/mac80211/key.h | 22 +-
net/mac80211/main.c | 81 ++-
net/mac80211/mlme.c | 75 ++-
net/mac80211/rate.h | 13 +
net/mac80211/rc80211_minstrel_ht.c | 824 ++++++++++++++++++++
net/mac80211/rc80211_minstrel_ht.h | 128 +++
net/mac80211/rc80211_minstrel_ht_debugfs.c | 120 +++
net/mac80211/rx.c | 41 +-
net/mac80211/sta_info.c | 8 -
net/mac80211/sta_info.h | 44 +-
net/mac80211/status.c | 2 +-
net/mac80211/work.c | 2 +-
net/wireless/chan.c | 5 +-
net/wireless/core.h | 1 +
net/wireless/mlme.c | 3 +-
net/wireless/nl80211.c | 3 +
186 files changed, 6755 insertions(+), 4340 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/sysfs.c
copy drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p0_initvals.h} (99%)
rename drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p2_initvals.h} (91%)
create mode 100644 drivers/net/wireless/wl12xx/wl1271_ini.h
create mode 100644 net/mac80211/rc80211_minstrel_ht.c
create mode 100644 net/mac80211/rc80211_minstrel_ht.h
create mode 100644 net/mac80211/rc80211_minstrel_ht_debugfs.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-06-09.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCHv4] mac80211: Fix circular locking dependency in ARP filter handling
From: reinette chatre @ 2010-06-09 23:27 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276080206-29562-1-git-send-email-juuso.oikarinen@nokia.com>
Hi Juuso,
On Wed, 2010-06-09 at 03:43 -0700, Juuso Oikarinen wrote:
> There is a circular locking dependency when configuring the
> hardware ARP filters on association, occurring when flushing the mac80211
> workqueue.
I am currently running with latest wireless-testing (HEAD
5e3283c821c3a7750b1f7bd982b10ebdbab0e155) with your patch "mac80211: Add
netif state checking to ieee80211_ifa_changed" also applied.
This hunk below does not seem to match with what is currently in
wireless-testing.
> @@ -2116,19 +2129,9 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
> cfg80211_send_assoc_timeout(wk->sdata->dev,
> wk->filter_ta);
> return WORK_DONE_DESTROY;
> -#ifdef CONFIG_INET
> - } else {
> - mutex_unlock(&wk->sdata->u.mgd.mtx);
> -
> - /*
> - * configure ARP filter IP addresses to the driver,
> - * intentionally outside the mgd mutex.
> - */
> - rtnl_lock();
> - ieee80211_set_arp_filter(wk->sdata);
> - rtnl_unlock();
> -#endif
> }
> +
> + mutex_unlock(&wk->sdata->u.mgd.mtx);
> }
>
> cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
> --
I made some modifications to get the patch to apply to wireless-testing,
not sure what should be done here since the difference seems
significant.
Even so, I tested your new patch and for some reason the BUG returned
(even though I am now running with "mac80211: Add netif state checking
to ieee80211_ifa_changed"
Here is what I get:
[ 390.153170] ------------[ cut here ]------------
[ 390.156016] kernel BUG at /home/wifi/iwlwifi-2.6/net/mac80211/main.c:437!
[ 390.156016] invalid opcode: 0000 [#1] SMP
[ 390.156016] last sysfs file: /sys/devices/virtual/misc/rfkill/dev
[ 390.156016] CPU 0
[ 390.156016] Modules linked in: iwl3945(+) iwlcore mac80211 cfg80211 rfkill binfmt_misc sbs
sbshc ipv6 evdev psmouse serio_raw pcspkr pegasus mii battery container processor video ac b
utton output intel_agp ext3 jbd mbcache sg sd_mod sr_mod cdrom ahci libahci libata ehci_hcd u
hci_hcd scsi_mod usbcore thermal fan thermal_sys
[ 390.156016]
[ 390.156016] Pid: 5171, comm: modprobe Not tainted 2.6.35-rc2-wl-64031-g07c6e79 #211 To be
filled by O.E.M./Montevina platform
[ 390.156016] RIP: 0010:[<ffffffffa026faf2>] [<ffffffffa026faf2>] ieee80211_alloc_hw+0x502/
0x520 [mac80211]
[ 390.156016] RSP: 0018:ffff880025a9fc78 EFLAGS: 00010246
[ 390.156016] RAX: ffff8800241319c0 RBX: ffff8800241302e0 RCX: 0000000000000001
[ 390.156016] RDX: ffffffffa02647a0 RSI: ffffffffa02647a8 RDI: ffffffffa0264a34
[ 390.156016] RBP: ffff880025a9fc98 R08: 0000000000000008 R09: ffffffff8154a5f8
[ 390.156016] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800241305a0
[ 390.156016] R13: ffffffffa032dfc0 R14: ffff88003b6b6000 R15: ffff880025fa2180
[ 390.156016] FS: 00007f634f2cd6f0(0000) GS:ffff880002000000(0000) knlGS:0000000000000000
[ 390.156016] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 390.156016] CR2: 00007fffc7cf9040 CR3: 000000002552a000 CR4: 00000000000006f0
[ 390.156016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 390.156016] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 390.156016] Process modprobe (pid: 5171, threadinfo ffff880025a9e000, task ffff880002442df
0)
[ 390.156016] Stack:
[ 390.156016] ffffffffa032e460 ffffffffa032e460 ffff88003b6b6000 ffff88003b6b6000
[ 390.156016] <0> ffff880025a9fcb8 ffffffffa02d553e ffffffffa032e460 ffff88003b6b6088
[ 390.156016] <0> ffff880025a9fd38 ffffffffa03131a7 0000000000000246 ffffffffa032df48
[ 390.156016] Call Trace:
[ 390.156016] [<ffffffffa02d553e>] iwl_alloc_all+0x1e/0x50 [iwlcore]
[ 390.156016] [<ffffffffa03131a7>] iwl3945_pci_probe+0x27/0x1640 [iwl3945]
[ 390.156016] [<ffffffff81348a56>] ? _raw_spin_unlock+0x26/0x30
[ 390.156016] [<ffffffff811d4ca0>] ? pci_match_device+0x20/0xd0
[ 390.156016] [<ffffffff811d4b52>] local_pci_probe+0x12/0x20
[ 390.156016] [<ffffffff811d5c60>] pci_device_probe+0x80/0xa0
[ 390.156016] [<ffffffff8124fe7b>] ? driver_sysfs_add+0x6b/0x90
[ 390.156016] [<ffffffff8124ffb5>] driver_probe_device+0x95/0x1d0
[ 390.156016] [<ffffffff8125018b>] __driver_attach+0x9b/0xb0
[ 390.156016] [<ffffffff812500f0>] ? __driver_attach+0x0/0xb0
[ 390.156016] [<ffffffff8124f65b>] bus_for_each_dev+0x6b/0xa0
[ 390.156016] [<ffffffff8124fe0c>] driver_attach+0x1c/0x20
[ 390.156016] [<ffffffff8124edb5>] bus_add_driver+0x1b5/0x300
[ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[ 390.156016] [<ffffffff8125049c>] driver_register+0x7c/0x170
[ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[ 390.156016] [<ffffffff811d5f1a>] __pci_register_driver+0x6a/0xf0
[ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[ 390.156016] [<ffffffffa009104a>] iwl3945_init+0x4a/0x80 [iwl3945]
[ 390.156016] [<ffffffff810001d8>] do_one_initcall+0x38/0x190
[ 390.156016] [<ffffffff8107ffbe>] sys_init_module+0xbe/0x220
[ 390.156016] [<ffffffff81002c6b>] system_call_fastpath+0x16/0x1b
[ 390.156016] Code: c7 c6 52 fa 2a a0 49 89 84 24 a0 03 00 00 49 89 84 24 a8 03 00 00 e8 2e
64 f5 e0 4c 89 e0 5b 41 5c 41 5d 41 5e c9 c3 0f 0b eb fe <0f> 0b eb fe 0f 0b eb fe 0f 0b eb f
e 0f 0b eb fe 0f 0b eb fe 0f
[ 390.156016] RIP [<ffffffffa026faf2>] ieee80211_alloc_hw+0x502/0x520 [mac80211]
[ 390.156016] RSP <ffff880025a9fc78>
[ 390.515754] ---[ end trace ac1678fc227a51d2 ]---
Reinette
^ permalink raw reply
* Re: iwlagn fails to assoc with nexus one in ad-hoc mode
From: David Miller @ 2010-06-10 1:20 UTC (permalink / raw)
To: reinette.chatre; +Cc: linux-wireless
In-Reply-To: <1276111062.1835.14914.camel@rchatre-DESK>
From: reinette chatre <reinette.chatre@intel.com>
Date: Wed, 09 Jun 2010 12:17:42 -0700
> On Wed, 2010-06-09 at 12:12 -0700, David Miller wrote:
>> Upstream 2.6.34 vanilla.
>
> ok - the firmware assert you are encountering is in the station
> management code which received significant rework in 2.6.35. Could you
> please try latest linux-2.6 (since there are some issues with
> 2.6.35-rc2)?
I did a quick test, and with the current tree the connection works
and I can associate with the nexus one, however I still get a few
of those beacon TIM error logs in my dmesg.
^ permalink raw reply
* [PATCH] wireless: orphan ipw2x00 drivers
From: Zhu Yi @ 2010-06-10 1:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
Please let us know if someone is interested in maintaining these drivers.
MAINTAINERS | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d119c9..bef7c1a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2978,20 +2978,14 @@ F: drivers/net/ixgb/
F: drivers/net/ixgbe/
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
-M: Reinette Chatre <reinette.chatre@intel.com>
-M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-W: http://ipw2100.sourceforge.net
-S: Odd Fixes
+S: Orphan
F: Documentation/networking/README.ipw2100
F: drivers/net/wireless/ipw2x00/ipw2100.*
INTEL PRO/WIRELESS 2915ABG NETWORK CONNECTION SUPPORT
-M: Reinette Chatre <reinette.chatre@intel.com>
-M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-W: http://ipw2200.sourceforge.net
-S: Odd Fixes
+S: Orphan
F: Documentation/networking/README.ipw2200
F: drivers/net/wireless/ipw2x00/ipw2200.*
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: John W. Linville @ 2010-06-10 1:45 UTC (permalink / raw)
To: Zhu Yi; +Cc: linux-wireless
In-Reply-To: <1276134269-2273-1-git-send-email-yi.zhu@intel.com>
On Thu, Jun 10, 2010 at 09:44:29AM +0800, Zhu Yi wrote:
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> Please let us know if someone is interested in maintaining these drivers.
Any chance of getting some hardware/firmware documentation?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [RFC v2 06/22] mac80211: pull mgmt frame rx into rx handler
From: Sujith @ 2010-06-10 4:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100609150454.085469240@sipsolutions.net>
Johannes Berg wrote:
> -ieee80211_rx_result
> -ieee80211_mesh_rx_mgmt(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
> -{
> - struct ieee80211_local *local = sdata->local;
> - struct ieee80211_mgmt *mgmt;
> - u16 fc;
> -
> - if (skb->len < 24)
> - return RX_DROP_MONITOR;
> -
> - mgmt = (struct ieee80211_mgmt *) skb->data;
> - fc = le16_to_cpu(mgmt->frame_control);
> -
> - switch (fc & IEEE80211_FCTL_STYPE) {
> - case IEEE80211_STYPE_ACTION:
> - case IEEE80211_STYPE_PROBE_RESP:
> - case IEEE80211_STYPE_BEACON:
> - skb_queue_tail(&sdata->skb_queue, skb);
> - ieee80211_queue_work(&local->hw, &sdata->work);
> - return RX_QUEUED;
> - }
> -
> - return RX_CONTINUE;
Am not familiar with mesh code, but this changes the semantics, no ?
> - if (ieee80211_vif_is_mesh(&sdata->vif))
> - return ieee80211_mesh_rx_mgmt(sdata, rx->skb);
> + stype = mgmt->frame_control & cpu_to_le16(IEEE80211_FCTL_STYPE);
> +
> + if (!ieee80211_vif_is_mesh(&sdata->vif) &&
> + sdata->vif.type != NL80211_IFTYPE_ADHOC &&
> + sdata->vif.type != NL80211_IFTYPE_STATION)
> + return RX_DROP_MONITOR;
>
> - if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
> - return ieee80211_ibss_rx_mgmt(sdata, rx->skb);
> + switch (stype) {
> + case cpu_to_le16(IEEE80211_STYPE_BEACON):
> + case cpu_to_le16(IEEE80211_STYPE_PROBE_RESP):
> + /* process for all: mesh, mlme, ibss */
> + break;
> + case cpu_to_le16(IEEE80211_STYPE_DEAUTH):
> + case cpu_to_le16(IEEE80211_STYPE_DISASSOC):
> + /* process only for station */
> + if (sdata->vif.type != NL80211_IFTYPE_STATION)
> + return RX_DROP_MONITOR;
> + break;
> + case cpu_to_le16(IEEE80211_STYPE_PROBE_REQ):
> + case cpu_to_le16(IEEE80211_STYPE_AUTH):
> + /* process only for ibss */
> + if (sdata->vif.type != NL80211_IFTYPE_ADHOC)
> + return RX_DROP_MONITOR;
> + break;
> + default:
> + return RX_DROP_MONITOR;
> + }
>
> - if (sdata->vif.type == NL80211_IFTYPE_STATION)
> - return ieee80211_sta_rx_mgmt(sdata, rx->skb);
> + /* queue up frame and kick off work to process it */
> + skb_queue_tail(&sdata->skb_queue, rx->skb);
> + ieee80211_queue_work(&rx->local->hw, &sdata->work);
>
> - return RX_DROP_MONITOR;
> + return RX_QUEUED;
> }
RX_QUEUED is the default return status for IBSS/Managed but mesh originally used RX_CONTINUE.
Wouldn't this change mesh mode's existing behavior ?
Sujith
^ permalink raw reply
* [RFC v2 07/22] mac80211: always process blockack action from workqueue
From: Sujith @ 2010-06-10 4:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100609150454.273811480@sipsolutions.net>
Johannes Berg wrote:
> switch (mgmt->u.action.u.addba_req.action_code) {
> case WLAN_ACTION_ADDBA_REQ:
> if (len < (IEEE80211_MIN_ACTION_SIZE +
> sizeof(mgmt->u.action.u.addba_req)))
> - return RX_DROP_MONITOR;
> - ieee80211_process_addba_request(local, rx->sta, mgmt, len);
> - goto handled;
> + goto invalid;
> + break;
> case WLAN_ACTION_ADDBA_RESP:
> if (len < (IEEE80211_MIN_ACTION_SIZE +
> sizeof(mgmt->u.action.u.addba_resp)))
> - break;
> - ieee80211_process_addba_resp(local, rx->sta, mgmt, len);
> - goto handled;
> + goto invalid;
> + break;
> case WLAN_ACTION_DELBA:
> if (len < (IEEE80211_MIN_ACTION_SIZE +
> sizeof(mgmt->u.action.u.delba)))
> - break;
> - ieee80211_process_delba(sdata, rx->sta, mgmt, len);
> - goto handled;
> + goto invalid;
> + break;
> + default:
> + goto invalid;
> }
rx->sta->rx_packets is no longer incremented for valid action frames,
since we return immediately after queuing to sdata.
Sujith
^ permalink raw reply
* issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Yatharth @ 2010-06-10 5:17 UTC (permalink / raw)
To: linux-wireless
I am trying to install driver for the TP-LINK : TL-WN721N (Wi-Fi USB
Device). If this is not the sort of issues this mailing list is for,
please let me know.
This device should use the ath9k_htc driver
./lsusb
Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc.
I have followed the instruction from
http://linuxwireless.org/en/users/Download
<http://linuxwireless.org/en/users/Download> But they do not seem to
work for me
When I modprobe ath9k_htc
Ubu-VM:/lib/modules/2.6.32-22-generic/build$ sudo modprobe ath9k_htc
FATAL: Error inserting ath9k_htc
(/lib/modules/2.6.32-22-generic/updates/drivers/net/wireless/ath/ath9k/ath9k_htc.ko):
Unknown symbol in module, or unknown parameter (see dmesg)
Here is the output of dmesg
Ubu-VM:/lib/modules/2.6.32-22-generic/build$ dmesg | grep ath9k
[ 1926.917944] ath9k_htc: disagrees about version of symbol
ath9k_hw_set_txpowerlimit
[ 1926.917947] ath9k_htc: Unknown symbol ath9k_hw_set_txpowerlimit
[ 1926.918248] ath9k_htc: disagrees about version of symbol
ath9k_hw_reset_calvalid
[ 1926.918250] ath9k_htc: Unknown symbol ath9k_hw_reset_calvalid
[ 1926.918377] ath9k_htc: disagrees about version of symbol
ath9k_hw_setcapability
[ 1926.918379] ath9k_htc: Unknown symbol ath9k_hw_setcapability
[ 1926.918603] ath9k_htc: disagrees about version of symbol
ieee80211_free_hw
[ 1926.918605] ath9k_htc: Unknown symbol ieee80211_free_hw
[ 1926.918680] ath9k_htc: disagrees about version of symbol ath9k_hw_reset
[ 1926.918682] ath9k_htc: Unknown symbol ath9k_hw_reset
[ 1926.919176] ath9k_htc: disagrees about version of symbol
ath9k_hw_setuptxqueue
[ 1926.919179] ath9k_htc: Unknown symbol ath9k_hw_setuptxqueue
[ 1926.919256] ath9k_htc: disagrees about version of symbol
ath9k_hw_startpcureceive
[ 1926.919257] ath9k_htc: Unknown symbol ath9k_hw_startpcureceive
[ 1926.919352] ath9k_htc: Unknown symbol ath9k_cmn_key_delete
[ 1926.919477] ath9k_htc: Unknown symbol ath9k_cmn_key_config
[ 1926.919559] ath9k_htc: disagrees about version of symbol
ath9k_hw_keyreset
^ permalink raw reply
* Re: [PATCHv4] mac80211: Fix circular locking dependency in ARP filter handling
From: Juuso Oikarinen @ 2010-06-10 5:20 UTC (permalink / raw)
To: ext reinette chatre
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276126067.1835.15473.camel@rchatre-DESK>
Hi,
On Thu, 2010-06-10 at 01:27 +0200, ext reinette chatre wrote:
> Hi Juuso,
>
> On Wed, 2010-06-09 at 03:43 -0700, Juuso Oikarinen wrote:
> > There is a circular locking dependency when configuring the
> > hardware ARP filters on association, occurring when flushing the mac80211
> > workqueue.
>
> I am currently running with latest wireless-testing (HEAD
> 5e3283c821c3a7750b1f7bd982b10ebdbab0e155) with your patch "mac80211: Add
> netif state checking to ieee80211_ifa_changed" also applied.
>
> This hunk below does not seem to match with what is currently in
> wireless-testing.
>
> > @@ -2116,19 +2129,9 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
> > cfg80211_send_assoc_timeout(wk->sdata->dev,
> > wk->filter_ta);
> > return WORK_DONE_DESTROY;
> > -#ifdef CONFIG_INET
> > - } else {
> > - mutex_unlock(&wk->sdata->u.mgd.mtx);
> > -
> > - /*
> > - * configure ARP filter IP addresses to the driver,
> > - * intentionally outside the mgd mutex.
> > - */
> > - rtnl_lock();
> > - ieee80211_set_arp_filter(wk->sdata);
> > - rtnl_unlock();
> > -#endif
> > }
> > +
> > + mutex_unlock(&wk->sdata->u.mgd.mtx);
> > }
> >
> > cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
> > --
>
> I made some modifications to get the patch to apply to wireless-testing,
> not sure what should be done here since the difference seems
> significant.
There was a small bug in regard of the mutex_unlock after Linville added
those CONFIG_INET thingies. Apparently he had fixed that in parallel,
hence the conflict.
> Even so, I tested your new patch and for some reason the BUG returned
> (even though I am now running with "mac80211: Add netif state checking
> to ieee80211_ifa_changed"
This is curious. In your source (mine does not seem to fully match what
you are using) what is the BUG that is getting triggered, main.c:437 ?
-Juuso
> Here is what I get:
>
> [ 390.153170] ------------[ cut here ]------------
> [ 390.156016] kernel BUG at /home/wifi/iwlwifi-2.6/net/mac80211/main.c:437!
> [ 390.156016] invalid opcode: 0000 [#1] SMP
> [ 390.156016] last sysfs file: /sys/devices/virtual/misc/rfkill/dev
> [ 390.156016] CPU 0
> [ 390.156016] Modules linked in: iwl3945(+) iwlcore mac80211 cfg80211 rfkill binfmt_misc sbs
> sbshc ipv6 evdev psmouse serio_raw pcspkr pegasus mii battery container processor video ac b
> utton output intel_agp ext3 jbd mbcache sg sd_mod sr_mod cdrom ahci libahci libata ehci_hcd u
> hci_hcd scsi_mod usbcore thermal fan thermal_sys
> [ 390.156016]
> [ 390.156016] Pid: 5171, comm: modprobe Not tainted 2.6.35-rc2-wl-64031-g07c6e79 #211 To be
> filled by O.E.M./Montevina platform
> [ 390.156016] RIP: 0010:[<ffffffffa026faf2>] [<ffffffffa026faf2>] ieee80211_alloc_hw+0x502/
> 0x520 [mac80211]
> [ 390.156016] RSP: 0018:ffff880025a9fc78 EFLAGS: 00010246
> [ 390.156016] RAX: ffff8800241319c0 RBX: ffff8800241302e0 RCX: 0000000000000001
> [ 390.156016] RDX: ffffffffa02647a0 RSI: ffffffffa02647a8 RDI: ffffffffa0264a34
> [ 390.156016] RBP: ffff880025a9fc98 R08: 0000000000000008 R09: ffffffff8154a5f8
> [ 390.156016] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800241305a0
> [ 390.156016] R13: ffffffffa032dfc0 R14: ffff88003b6b6000 R15: ffff880025fa2180
> [ 390.156016] FS: 00007f634f2cd6f0(0000) GS:ffff880002000000(0000) knlGS:0000000000000000
> [ 390.156016] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 390.156016] CR2: 00007fffc7cf9040 CR3: 000000002552a000 CR4: 00000000000006f0
> [ 390.156016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 390.156016] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 390.156016] Process modprobe (pid: 5171, threadinfo ffff880025a9e000, task ffff880002442df
> 0)
> [ 390.156016] Stack:
> [ 390.156016] ffffffffa032e460 ffffffffa032e460 ffff88003b6b6000 ffff88003b6b6000
> [ 390.156016] <0> ffff880025a9fcb8 ffffffffa02d553e ffffffffa032e460 ffff88003b6b6088
> [ 390.156016] <0> ffff880025a9fd38 ffffffffa03131a7 0000000000000246 ffffffffa032df48
> [ 390.156016] Call Trace:
> [ 390.156016] [<ffffffffa02d553e>] iwl_alloc_all+0x1e/0x50 [iwlcore]
> [ 390.156016] [<ffffffffa03131a7>] iwl3945_pci_probe+0x27/0x1640 [iwl3945]
> [ 390.156016] [<ffffffff81348a56>] ? _raw_spin_unlock+0x26/0x30
> [ 390.156016] [<ffffffff811d4ca0>] ? pci_match_device+0x20/0xd0
> [ 390.156016] [<ffffffff811d4b52>] local_pci_probe+0x12/0x20
> [ 390.156016] [<ffffffff811d5c60>] pci_device_probe+0x80/0xa0
> [ 390.156016] [<ffffffff8124fe7b>] ? driver_sysfs_add+0x6b/0x90
> [ 390.156016] [<ffffffff8124ffb5>] driver_probe_device+0x95/0x1d0
> [ 390.156016] [<ffffffff8125018b>] __driver_attach+0x9b/0xb0
> [ 390.156016] [<ffffffff812500f0>] ? __driver_attach+0x0/0xb0
> [ 390.156016] [<ffffffff8124f65b>] bus_for_each_dev+0x6b/0xa0
> [ 390.156016] [<ffffffff8124fe0c>] driver_attach+0x1c/0x20
> [ 390.156016] [<ffffffff8124edb5>] bus_add_driver+0x1b5/0x300
> [ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
> [ 390.156016] [<ffffffff8125049c>] driver_register+0x7c/0x170
> [ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
> [ 390.156016] [<ffffffff811d5f1a>] __pci_register_driver+0x6a/0xf0
> [ 390.156016] [<ffffffffa0091000>] ? iwl3945_init+0x0/0x80 [iwl3945]
> [ 390.156016] [<ffffffffa009104a>] iwl3945_init+0x4a/0x80 [iwl3945]
> [ 390.156016] [<ffffffff810001d8>] do_one_initcall+0x38/0x190
> [ 390.156016] [<ffffffff8107ffbe>] sys_init_module+0xbe/0x220
> [ 390.156016] [<ffffffff81002c6b>] system_call_fastpath+0x16/0x1b
> [ 390.156016] Code: c7 c6 52 fa 2a a0 49 89 84 24 a0 03 00 00 49 89 84 24 a8 03 00 00 e8 2e
> 64 f5 e0 4c 89 e0 5b 41 5c 41 5d 41 5e c9 c3 0f 0b eb fe <0f> 0b eb fe 0f 0b eb fe 0f 0b eb f
> e 0f 0b eb fe 0f 0b eb fe 0f
> [ 390.156016] RIP [<ffffffffa026faf2>] ieee80211_alloc_hw+0x502/0x520 [mac80211]
> [ 390.156016] RSP <ffff880025a9fc78>
> [ 390.515754] ---[ end trace ac1678fc227a51d2 ]---
>
> Reinette
>
>
^ permalink raw reply
* issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Sujith @ 2010-06-10 5:27 UTC (permalink / raw)
To: Yatharth; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4C107563.3010709@yatharthgupta.com>
Yatharth wrote:
> I am trying to install driver for the TP-LINK : TL-WN721N (Wi-Fi USB
> Device). If this is not the sort of issues this mailing list is for,
> please let me know.
>
> This device should use the ath9k_htc driver
>
> ./lsusb
> Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc.
>
> I have followed the instruction from
> http://linuxwireless.org/en/users/Download
> <http://linuxwireless.org/en/users/Download> But they do not seem to
> work for me
>
> When I modprobe ath9k_htc
>
> Ubu-VM:/lib/modules/2.6.32-22-generic/build$ sudo modprobe ath9k_htc
>
> FATAL: Error inserting ath9k_htc
> (/lib/modules/2.6.32-22-generic/updates/drivers/net/wireless/ath/ath9k/ath9k_htc.ko):
> Unknown symbol in module, or unknown parameter (see dmesg)
>
> Here is the output of dmesg
>
>
> Ubu-VM:/lib/modules/2.6.32-22-generic/build$ dmesg | grep ath9k
>
> [ 1926.917944] ath9k_htc: disagrees about version of symbol
> ath9k_hw_set_txpowerlimit
> [ 1926.917947] ath9k_htc: Unknown symbol ath9k_hw_set_txpowerlimit
> [ 1926.918248] ath9k_htc: disagrees about version of symbol
> ath9k_hw_reset_calvalid
> [ 1926.918250] ath9k_htc: Unknown symbol ath9k_hw_reset_calvalid
> [ 1926.918377] ath9k_htc: disagrees about version of symbol
> ath9k_hw_setcapability
> [ 1926.918379] ath9k_htc: Unknown symbol ath9k_hw_setcapability
> [ 1926.918603] ath9k_htc: disagrees about version of symbol
> ieee80211_free_hw
> [ 1926.918605] ath9k_htc: Unknown symbol ieee80211_free_hw
> [ 1926.918680] ath9k_htc: disagrees about version of symbol ath9k_hw_reset
> [ 1926.918682] ath9k_htc: Unknown symbol ath9k_hw_reset
> [ 1926.919176] ath9k_htc: disagrees about version of symbol
> ath9k_hw_setuptxqueue
> [ 1926.919179] ath9k_htc: Unknown symbol ath9k_hw_setuptxqueue
> [ 1926.919256] ath9k_htc: disagrees about version of symbol
> ath9k_hw_startpcureceive
> [ 1926.919257] ath9k_htc: Unknown symbol ath9k_hw_startpcureceive
> [ 1926.919352] ath9k_htc: Unknown symbol ath9k_cmn_key_delete
> [ 1926.919477] ath9k_htc: Unknown symbol ath9k_cmn_key_config
> [ 1926.919559] ath9k_htc: disagrees about version of symbol
> ath9k_hw_keyreset
You haven't unloaded the existing ath9k_hw module.
Do a 'sudo make install' in your compat directory, and
then 'sudo make unload'.
Check 'lsmod | grep ath'. If anything is still present, unload all of them,
along with mac80211, cfg80211. Then modprobe ath9k_htc.
Of course, you can just reboot after 'sudo make install' and things should work.
Sujith
^ permalink raw reply
* Re: [PATCHv4] mac80211: Fix circular locking dependency in ARP filter handling
From: Juuso Oikarinen @ 2010-06-10 5:30 UTC (permalink / raw)
To: ext reinette chatre
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1276147255.5277.34285.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-06-10 at 07:21 +0200, Juuso Oikarinen wrote:
> Hi,
>
> On Thu, 2010-06-10 at 01:27 +0200, ext reinette chatre wrote:
> > Hi Juuso,
> >
> > Even so, I tested your new patch and for some reason the BUG returned
> > (even though I am now running with "mac80211: Add netif state checking
> > to ieee80211_ifa_changed"
>
> This is curious. In your source (mine does not seem to fully match what
> you are using) what is the BUG that is getting triggered, main.c:437 ?
Oh, and did you remember to apply the fix patch for the bug too, as it
seems not yet be integrated to wireless-testing:
"mac80211: Add netif state checking to ieee80211_ifa_changed"
-Juuso
> -Juuso
>
> > Here is what I get:
> >
> > [ 390.153170] ------------[ cut here ]------------
> > [ 390.156016] kernel BUG at /home/wifi/iwlwifi-2.6/net/mac80211/main.c:437!
> > [ 390.156016] invalid opcode: 0000 [#1] SMP
> > [ 390.156016] last sysfs file: /sys/devices/virtual/misc/rfkill/dev
> > [ 390.156016] CPU 0
> > [ 390.156016] Modules linked in: iwl3945(+) iwlcore mac80211 cfg80211 rfkill binfmt_misc sbs
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Yatharth @ 2010-06-10 5:32 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <19472.30680.855993.112084@gargle.gargle.HOWL>
On 06/09/2010 10:27 PM, Sujith wrote:
> Yatharth wrote:
>
>> I am trying to install driver for the TP-LINK : TL-WN721N (Wi-Fi USB
>> Device). If this is not the sort of issues this mailing list is for,
>> please let me know.
>>
>> This device should use the ath9k_htc driver
>>
>> ./lsusb
>> Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc.
>>
>> I have followed the instruction from
>> http://linuxwireless.org/en/users/Download
>> <http://linuxwireless.org/en/users/Download> But they do not seem to
>> work for me
>>
>> When I modprobe ath9k_htc
>>
>> Ubu-VM:/lib/modules/2.6.32-22-generic/build$ sudo modprobe ath9k_htc
>>
>> FATAL: Error inserting ath9k_htc
>> (/lib/modules/2.6.32-22-generic/updates/drivers/net/wireless/ath/ath9k/ath9k_htc.ko):
>> Unknown symbol in module, or unknown parameter (see dmesg)
>>
>> Here is the output of dmesg
>>
>>
>> Ubu-VM:/lib/modules/2.6.32-22-generic/build$ dmesg | grep ath9k
>>
>> [ 1926.917944] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_set_txpowerlimit
>> [ 1926.917947] ath9k_htc: Unknown symbol ath9k_hw_set_txpowerlimit
>> [ 1926.918248] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_reset_calvalid
>> [ 1926.918250] ath9k_htc: Unknown symbol ath9k_hw_reset_calvalid
>> [ 1926.918377] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_setcapability
>> [ 1926.918379] ath9k_htc: Unknown symbol ath9k_hw_setcapability
>> [ 1926.918603] ath9k_htc: disagrees about version of symbol
>> ieee80211_free_hw
>> [ 1926.918605] ath9k_htc: Unknown symbol ieee80211_free_hw
>> [ 1926.918680] ath9k_htc: disagrees about version of symbol ath9k_hw_reset
>> [ 1926.918682] ath9k_htc: Unknown symbol ath9k_hw_reset
>> [ 1926.919176] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_setuptxqueue
>> [ 1926.919179] ath9k_htc: Unknown symbol ath9k_hw_setuptxqueue
>> [ 1926.919256] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_startpcureceive
>> [ 1926.919257] ath9k_htc: Unknown symbol ath9k_hw_startpcureceive
>> [ 1926.919352] ath9k_htc: Unknown symbol ath9k_cmn_key_delete
>> [ 1926.919477] ath9k_htc: Unknown symbol ath9k_cmn_key_config
>> [ 1926.919559] ath9k_htc: disagrees about version of symbol
>> ath9k_hw_keyreset
>>
> You haven't unloaded the existing ath9k_hw module.
>
> Do a 'sudo make install' in your compat directory, and
> then 'sudo make unload'.
>
> Check 'lsmod | grep ath'. If anything is still present, unload all of them,
> along with mac80211, cfg80211. Then modprobe ath9k_htc.
>
> Of course, you can just reboot after 'sudo make install' and things should work.
>
> Sujith
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I had checked earlier to ensure that everything was unloaded.
But I've done it again to make sure.
Step 1 : 'sudo make unload'
Step 2 : 'lsmod | grep ath' [Returns Nothing, thus indicating none of
these modules are loaded]
If I do 'modprobe ath9k_htc' after this, I still get the same error
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Sujith @ 2010-06-10 5:35 UTC (permalink / raw)
To: Yatharth; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4C1078D4.3070604@yatharthgupta.com>
Yatharth wrote:
> I had checked earlier to ensure that everything was unloaded.
>
> But I've done it again to make sure.
> Step 1 : 'sudo make unload'
> Step 2 : 'lsmod | grep ath' [Returns Nothing, thus indicating none of
> these modules are loaded]
>
> If I do 'modprobe ath9k_htc' after this, I still get the same error
What does 'modinfo ath9k_hw' show ?
Sujith
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Yatharth @ 2010-06-10 5:36 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <19472.31157.569068.781531@gargle.gargle.HOWL>
On 06/09/2010 10:35 PM, Sujith wrote:
> Yatharth wrote:
>
>> I had checked earlier to ensure that everything was unloaded.
>>
>> But I've done it again to make sure.
>> Step 1 : 'sudo make unload'
>> Step 2 : 'lsmod | grep ath' [Returns Nothing, thus indicating none of
>> these modules are loaded]
>>
>> If I do 'modprobe ath9k_htc' after this, I still get the same error
>>
> What does 'modinfo ath9k_hw' show ?
>
> Sujith
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Here is the output of 'modinfo ath9k_hw'
Ubu-VM:~/tmp/compat-wireless-2010-06-05$ modinfo ath9k_hw
filename: /lib/modules/2.6.32-22-generic/updates/cw/ath9k_hw.ko
license: Dual BSD/GPL
description: Support for Atheros 802.11n wireless LAN cards.
author: Atheros Communications
srcversion: 0946B41CE1566D09C4B08F1
depends: ath
vermagic: 2.6.32-22-generic SMP mod_unload modversions 586
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Sujith @ 2010-06-10 5:51 UTC (permalink / raw)
To: Yatharth; +Cc: Sujith Manoharan, linux-wireless@vger.kernel.org
In-Reply-To: <4C1079E0.6090605@yatharthgupta.com>
Yatharth wrote:
> Here is the output of 'modinfo ath9k_hw'
>
> Ubu-VM:~/tmp/compat-wireless-2010-06-05$ modinfo ath9k_hw
> filename: /lib/modules/2.6.32-22-generic/updates/cw/ath9k_hw.ko
What is the 'cw' directory ?
On my machine, modinfo -n ath9k_hw shows:
/lib/modules/2.6.32-22-generic/updates/drivers/net/wireless/ath/ath9k/ath9k_hw.ko
You have some stray modules in your system, clean them up
and reload the driver.
Sujith
^ permalink raw reply
* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: David Miller @ 2010-06-10 5:52 UTC (permalink / raw)
To: linville; +Cc: yi.zhu, linux-wireless
In-Reply-To: <20100610014547.GA2318@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Jun 2010 21:45:47 -0400
> On Thu, Jun 10, 2010 at 09:44:29AM +0800, Zhu Yi wrote:
>> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
>> ---
>> Please let us know if someone is interested in maintaining these drivers.
>
> Any chance of getting some hardware/firmware documentation?
Indeed.
I'm extremely disappointed that the only organization currently even
capable of fixing low level bugs in these drivers no longer is willing
to do so.
If documentation can't be provided so that others can maintain this
driver (not just few specific people, because some day those folks
might tire of maintaining this too) that would be a serious crime.
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Luis R. Rodriguez @ 2010-06-10 5:53 UTC (permalink / raw)
To: Sujith; +Cc: Yatharth, linux-wireless@vger.kernel.org
In-Reply-To: <19472.32107.793016.762850@gargle.gargle.HOWL>
On Wed, Jun 9, 2010 at 10:51 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Yatharth wrote:
>> Here is the output of 'modinfo ath9k_hw'
>>
>> Ubu-VM:~/tmp/compat-wireless-2010-06-05$ modinfo ath9k_hw
>> filename: /lib/modules/2.6.32-22-generic/updates/cw/ath9k_hw.ko
>
> What is the 'cw' directory ?
Its ubuntu's compat-wireless package, linux-backport-modules. Try to
uninstall that or rm -rf it.
Luis
^ permalink raw reply
* RE: Possible leak in the ampdu aggregation code?
From: Nishant Sarmukadam @ 2010-06-10 5:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez
In-Reply-To: <1276083568.14580.13.camel@jlt3.sipsolutions.net>
> I think that commit should just be reverted.
Ok, I will send a patch to revert commit 416fbdff2137e8d8cc8f23f517bee3a26b11526f.
Nishant
-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net]
Sent: Wednesday, June 09, 2010 5:09 PM
To: Nishant Sarmukadam
Cc: linux-wireless@vger.kernel.org; Luis R. Rodriguez
Subject: Re: Possible leak in the ampdu aggregation code?
On Wed, 2010-06-09 at 01:35 -0700, Nishant Sarmukadam wrote:
> I wanted to get some views on a possible issue while using mac80211
> ampdu support.
> skb's from pending queue for a TID are spliced onto the local pending
> queue when tearing down a block ack session.
Right.
> If aggregation is stopped before the ampdu state becomes
> HT_AGG_STATE_OPERATIONAL say on addba timer expiry or if the addba
> request is declined, the state is changed to
> HT_AGG_STATE_REQ_STOP_BA_MSK |(initiator <<
> HT_AGG_STATE_INITIATOR_SHIFT) in ___ieee80211_stop_tx_ba_session.
Right.
> After commit 416fbdff2137e8d8cc8f23f517bee3a26b11526f, the ampdu state
> needs to have HT_ADDBA_REQUESTED_MSK set, else the skb's are not
> spliced.
Bleh. That commit is bogus. I didn't even know it existed. It looks like
that commit was trying to fix the issue fixed by
827d42c9ac91ddd728e4f4a31fefb906ef2ceff7 but ended up just hiding it
enough that we didn't really find the cause of issue for a long time
still... we shouldn't even have been stopping the aggregation session
when it was never started!!
I think that commit should just be reverted.
johannes
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: Yatharth @ 2010-06-10 6:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Sujith, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimVqheuVKI3tCpSGoDHRaEcexDFwm77wj_9_QJU@mail.gmail.com>
On 06/09/2010 10:53 PM, Luis R. Rodriguez wrote:
> On Wed, Jun 9, 2010 at 10:51 PM, Sujith<Sujith.Manoharan@atheros.com> wrote:
>
>> Yatharth wrote:
>>
>>> Here is the output of 'modinfo ath9k_hw'
>>>
>>> Ubu-VM:~/tmp/compat-wireless-2010-06-05$ modinfo ath9k_hw
>>> filename: /lib/modules/2.6.32-22-generic/updates/cw/ath9k_hw.ko
>>>
>> What is the 'cw' directory ?
>>
> Its ubuntu's compat-wireless package, linux-backport-modules. Try to
> uninstall that or rm -rf it.
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks Sujith & Luis that fixed it. I can now see the device and use it
correctly.
I remove the 'cw' directory and then
'sudo make install'
'sudo make unload'
'sudo modprobe ath9k_htc'
I did install the compat-wireless package, I believe I did it while
self-debugging the issue without knowing the implications.
^ permalink raw reply
* Re: [RFC v2 07/22] mac80211: always process blockack action from workqueue
From: Johannes Berg @ 2010-06-10 6:25 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <19472.26264.654635.201393@gargle.gargle.HOWL>
On Thu, 2010-06-10 at 09:44 +0530, Sujith wrote:
> Johannes Berg wrote:
> > switch (mgmt->u.action.u.addba_req.action_code) {
> > case WLAN_ACTION_ADDBA_REQ:
> > if (len < (IEEE80211_MIN_ACTION_SIZE +
> > sizeof(mgmt->u.action.u.addba_req)))
> > - return RX_DROP_MONITOR;
> > - ieee80211_process_addba_request(local, rx->sta, mgmt, len);
> > - goto handled;
> > + goto invalid;
> > + break;
> > case WLAN_ACTION_ADDBA_RESP:
> > if (len < (IEEE80211_MIN_ACTION_SIZE +
> > sizeof(mgmt->u.action.u.addba_resp)))
> > - break;
> > - ieee80211_process_addba_resp(local, rx->sta, mgmt, len);
> > - goto handled;
> > + goto invalid;
> > + break;
> > case WLAN_ACTION_DELBA:
> > if (len < (IEEE80211_MIN_ACTION_SIZE +
> > sizeof(mgmt->u.action.u.delba)))
> > - break;
> > - ieee80211_process_delba(sdata, rx->sta, mgmt, len);
> > - goto handled;
> > + goto invalid;
> > + break;
> > + default:
> > + goto invalid;
> > }
>
> rx->sta->rx_packets is no longer incremented for valid action frames,
> since we return immediately after queuing to sdata.
Good catch, I guess I broke that earlier and also with other frames that
are put onto the skb queue. I don't think I want to go back and fix it
so I'll go add a patch to the series that takes care of this for all the
possible cases.
johannes
^ permalink raw reply
* Re: [RFC v2 06/22] mac80211: pull mgmt frame rx into rx handler
From: Johannes Berg @ 2010-06-10 6:28 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <19472.26203.835523.525595@gargle.gargle.HOWL>
On Thu, 2010-06-10 at 09:43 +0530, Sujith wrote:
> Johannes Berg wrote:
> > -ieee80211_rx_result
> > -ieee80211_mesh_rx_mgmt(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
> > -{
> > - struct ieee80211_local *local = sdata->local;
> > - struct ieee80211_mgmt *mgmt;
> > - u16 fc;
> > -
> > - if (skb->len < 24)
> > - return RX_DROP_MONITOR;
> > -
> > - mgmt = (struct ieee80211_mgmt *) skb->data;
> > - fc = le16_to_cpu(mgmt->frame_control);
> > -
> > - switch (fc & IEEE80211_FCTL_STYPE) {
> > - case IEEE80211_STYPE_ACTION:
> > - case IEEE80211_STYPE_PROBE_RESP:
> > - case IEEE80211_STYPE_BEACON:
> > - skb_queue_tail(&sdata->skb_queue, skb);
> > - ieee80211_queue_work(&local->hw, &sdata->work);
> > - return RX_QUEUED;
> > - }
> > -
> > - return RX_CONTINUE;
>
> Am not familiar with mesh code, but this changes the semantics, no ?
>
> > - if (ieee80211_vif_is_mesh(&sdata->vif))
> > - return ieee80211_mesh_rx_mgmt(sdata, rx->skb);
> > + stype = mgmt->frame_control & cpu_to_le16(IEEE80211_FCTL_STYPE);
> > +
> > + if (!ieee80211_vif_is_mesh(&sdata->vif) &&
> > + sdata->vif.type != NL80211_IFTYPE_ADHOC &&
> > + sdata->vif.type != NL80211_IFTYPE_STATION)
> > + return RX_DROP_MONITOR;
> >
> > - if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
> > - return ieee80211_ibss_rx_mgmt(sdata, rx->skb);
> > + switch (stype) {
> > + case cpu_to_le16(IEEE80211_STYPE_BEACON):
> > + case cpu_to_le16(IEEE80211_STYPE_PROBE_RESP):
> > + /* process for all: mesh, mlme, ibss */
> > + break;
> > + case cpu_to_le16(IEEE80211_STYPE_DEAUTH):
> > + case cpu_to_le16(IEEE80211_STYPE_DISASSOC):
> > + /* process only for station */
> > + if (sdata->vif.type != NL80211_IFTYPE_STATION)
> > + return RX_DROP_MONITOR;
> > + break;
> > + case cpu_to_le16(IEEE80211_STYPE_PROBE_REQ):
> > + case cpu_to_le16(IEEE80211_STYPE_AUTH):
> > + /* process only for ibss */
> > + if (sdata->vif.type != NL80211_IFTYPE_ADHOC)
> > + return RX_DROP_MONITOR;
> > + break;
> > + default:
> > + return RX_DROP_MONITOR;
> > + }
> >
> > - if (sdata->vif.type == NL80211_IFTYPE_STATION)
> > - return ieee80211_sta_rx_mgmt(sdata, rx->skb);
> > + /* queue up frame and kick off work to process it */
> > + skb_queue_tail(&sdata->skb_queue, rx->skb);
> > + ieee80211_queue_work(&rx->local->hw, &sdata->work);
> >
> > - return RX_DROP_MONITOR;
> > + return RX_QUEUED;
> > }
>
> RX_QUEUED is the default return status for IBSS/Managed but mesh
> originally used RX_CONTINUE.
Mesh also used (and needed to!) RX_QUEUED for the case where it actually
wanted the packet. I just wrote the code the other way around -- before
it was returning RX_QUEUED if wanted, now it short-cuts to
"RX_DROP_MONITOR" if unwanted.
> Wouldn't this change mesh mode's existing behavior ?
No, I don't think it does, in ieee80211_rx_h_mgmt() RX_CONTINUE and
RX_DROP_MONITOR are equivalent since that's the last possible thing to
happen with a (management) frame. Unless I'm misunderstanding you?
johannes
^ permalink raw reply
* Re: [RFC v2 06/22] mac80211: pull mgmt frame rx into rx handler
From: Sujith @ 2010-06-10 6:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1276151288.3623.4.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> Mesh also used (and needed to!) RX_QUEUED for the case where it actually
> wanted the packet. I just wrote the code the other way around -- before
> it was returning RX_QUEUED if wanted, now it short-cuts to
> "RX_DROP_MONITOR" if unwanted.
>
> > Wouldn't this change mesh mode's existing behavior ?
>
> No, I don't think it does, in ieee80211_rx_h_mgmt() RX_CONTINUE and
> RX_DROP_MONITOR are equivalent since that's the last possible thing to
> happen with a (management) frame. Unless I'm misunderstanding you?
Ok. I assumed that RX_CONTINUE was needed by mesh for some purpose.
Sujith
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox