mt7615: wifi restart issue using dbdc mode

Hello,

I'm investigating an issue after wifi interfaces restart, where clients can not connect to APs.

CPU board: UniElec 7621-06
WiFi: BPI-7615 (running in DBDC mode)
OpenWRT: cfbda6627956af0cab380d03fd9275574e67921e (1.12.2020)
MT76 driver: 066cc441eb8fcec7a3aeb6a320f5f9e6c21790f1 (21.11.2020)

Configuration is very simple: 1 AP on each radio, unique BSSID, unique SSID, without encryption, fixed channels (if any help I can attach configuration)
After reboot both APs are working (2.4GHz and 5GHz) just fine: beacons are visible in the air (using external sniffer), clients can connect to both APs, ....

Now, the fun begins. After running script /sbin/wifi strange things starts.

In some rare cases (1 of 5) everything is working just fine. But in other cases WiFi clients can not connect to any AP. In logs I can see this:
Wed Dec 2 13:07:08 2020 daemon.info hostapd: wlan1: STA 60:8b:0e:08:a9:99 IEEE 802.11: authenticated
Wed Dec 2 13:07:08 2020 daemon.info hostapd: wlan1: STA 60:8b:0e:08:a9:99 IEEE 802.11: associated (aid 1)
Wed Dec 2 13:07:08 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 60:8b:0e:08:a9:99
Wed Dec 2 13:07:08 2020 daemon.info hostapd: wlan1: STA 60:8b:0e:08:a9:99 RADIUS: starting accounting session 7BB47469AFF75D02
Wed Dec 2 13:07:10 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 60:8b:0e:08:a9:99
Wed Dec 2 13:07:10 2020 daemon.info hostapd: wlan1: STA 60:8b:0e:08:a9:99 IEEE 802.11: disassociated
Wed Dec 2 13:07:11 2020 daemon.info hostapd: wlan1: STA 60:8b:0e:08:a9:99 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

Enabling hostapd debug logs (-d):
Wed Dec 2 13:14:39 2020 daemon.debug hostapd: wlan1: Event RX_MGMT (18) received
Wed Dec 2 13:14:39 2020 daemon.debug hostapd: mgmt::disassoc
Wed Dec 2 13:14:39 2020 daemon.debug hostapd: disassocation: STA=60:8b:0e:08:a9:99 reason_code=8
Wed Dec 2 13:14:39 2020 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 60:8b:0e:08:a9:99

It is the client who is sending disconnect frame to APs. But why?

Investigating it further, it turned out, that there are no beacon frames in the air from my APs (in 100ms interval) when issue arise. But both APs do respond to Probe Request frames.

By my understanding MT7615 sends out beacon frames without CPU intervention. CPU has to prepare beacon frame content and give it to MCU for periodic transmit. If this is correct, my additional debugs could help to solve this.
I have added debugs to mt7615_mcu_add_beacon_offload function.
After reboot I see this values (every 6 seconds):
req: omac_idx: 0x00, enable: 0x1, wlan_idx: 0x0, band_idx: 0x1
req: omac_idx: 0x11, enable: 0x1, wlan_idx: 0x0, band_idx: 0x0
If system is working fine, I get same output. If not, I get this:
req: omac_idx: 0x00, enable: 0x1, wlan_idx: 0x0, band_idx: 0x0
req: omac_idx: 0x11, enable: 0x1, wlan_idx: 0x0, band_idx: 0x1
Can someone help me understand what happens in non working case. Is there interface bring up order issue?

Other things I have tried already:

• using mt7615 in non DBDC mode - can not reproduce issue
• same setup with two ath9k devices with MT7621 board - can not reproduce issue

I'm not even sure it is mt76 issue.

Any suggestions, ideas, directions, debugging ideas are welcome.

Start by reproducing the failure with /sbin/wifi in MT7615 DBDC mode and compare the working and failing beacon logs. Inspect mt7615_mcu_add_beacon_offload and the reported omac_idx, enable, wlan_idx, and band_idx values, then compare the interface bring-up order. Done means identifying the cause of missing beacon frames and documenting or fixing the restart failure.