Ticket #2253 (new defect)

Opened 3 years ago

Last modified 5 months ago

AR5213 & AR5413/AR5414: 5GHz AP mode unusable/broken

Reported by: konrad.pioro@zask.pl Assigned to:
Priority: critical Milestone:
Component: madwifi: driver Version: trunk
Keywords: master mode 5ghz madwifi Cc:
Patch is attached: 0 Pending: 0

Description

-> System specs:

Linux 2.6.28.7
madwifi-ng r3952
hostapd 0.6.8

-> Cards tested for AP:

SparkLAN WMIA-123AG
Senao 8601 ETSI
Senao 8602 ETSI

-> Cards tested for Stations:

Same as for AP with addition of IWL3945.

-> Background information:

2.4GHz AP mode works fine on both chipsets, although the AR5413/4 gets stuck beacons quite often so is unusable (I switched to the older AR5213 SparkLAN to fix this issue for the time beeing). The AP is listed on available AP list by all Stations. Can connect and have stable transmission in both hostapd and non-hostapd operating modes.

-> Problem description:

5GHz AP mode on the tested cards does not work at all or is extremely rare to work. After bringing up the interface the AP does not show in the available AP list and is not detected by the Stations in both hostapd and non-hostapd mode. The hostapd startup logs are exactly the same as the 2.4GHz logs, no errors reported. And now for the best part: I left the AP and one Station alone and went to do something else, and half hour later a miracle happened, they connected and the connection was quite stable. Once disconnected never got a second chance to connect despite few days of heavy tests. I'm quite desperate here, deciding to wait or to build all links in 2.4GHz (shooting myself in the foot). Please advise what to do or what tests to perform in order to debug this issue.

Change History

09/17/09 23:52:12 changed by ppingxu@tranzeo.com

How about if you try to disable beacon calibration using parameter 'beacon_cal=0' to start ath_pci?

09/18/09 20:27:40 changed by ppingxu@tranzeo.com

I saw the same issue on my embedded target with AP mode in 5GHz, but not for station mode or in 2.4GHz.

  • HARWARE:
    • Target CPU: AMCC PowerPC PPC405EP 333MHz
    • Radio: miniPCI ZCOM AG-623C
  • SOFTWARE:
    • Openwrt trunk rev.17239
    • Madwifi trunk rev.4075
    • Linux 2.6.26.8
  • CONFIGURE:
    • AP mode, Channel 149, No security

Two approaches I worked around the issue:

  1. disable beacon calibration using parameter 'beacon_cal=0' to start ath_pci, or
  2. when madwifi is running (it may needs to do several times): 
    input 'echo 1 > /proc/sys/dev/wifi0/intmit'
then  'echo 0 > /proc/sys/dev/wifi0/intmit'

Suspect causing: With some investigation of source code, I suspect calling ath_reset in interrupt handler (ath_intr) causes the issue.

  1. ath_intr calls ath_beacon_send when receiving SWBA interrupt
  2. ath_beacon_send calls ath_calibration when beacon calibration is enabled and calibration timer is expired
  3. ath_calibration calls ath_reset
  4. ath_reset calls ath_startrecv

I noticed that no SWBA interrupt comes again when the issue happened. An interesting thing is that the issue would not happen if I printk a long string (len>32) in ath_startrecv (between ath_hal_startpcurecv and ath_override_intmit_if_disabled). I have not got time to dig deeply. Hopefully, this would help others to continue to investigate.