ath10k: QCA6174 hw3.2 DMAR write fault on RX of 802.11k Beacon Request (fw WLAN.RM.4.4.1-00309)

[Tom Janssens]

Hi,

I'm seeing a reproducible IOMMU (VT-d) DMA write fault from a QCA6174
that is triggered by received 802.11k Beacon Request frames.

Client (laptop)
- Dell XPS 13 9380
- 02:00.0 Qualcomm Atheros QCA6174 [168c:003e] rev 32, subsystem Rivet
Networks Killer 1435 [1a56:143a]
- ath10k_pci: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:143a
- firmware ver WLAN.RM.4.4.1-00309- api 6 features
wowlan,ignore-otp,mfp crc32 0793bcf2
- board_file api 2 crc32 d2863f91
- htt-ver 3.87 wmi-op 4 htt-op 3
- Kernel 7.0.0-31-generic (Ubuntu), intel_iommu enabled (default
DMA/DMA-FQ domain)

Access point
- Xiaomi Mi Router AX3000T (mediatek/filogic), OpenWrt 25.12.4 r32933-4ccb782af7
- wpad-openssl 2025.08.26~ca266cc2-r1, dawn 2025.11.07~7414c34a-r1
- DAWN: update_beacon_reports=20, rrm_mode=pat (source of the 20 s
beacon requests)
- 5 GHz, ch 36, 802.11k enabled, PMF active (requests have the
Protected bit set)

Symptom
While associated, the following appears every ~20 s:

  DMAR: DRHD: handling fault status reg 2
  DMAR: [DMA Write NO_PASID] Request device [02:00.0] fault addr
0xfc2d1000 [fault reason 0x05] PTE Write access is not set

The fault address is different every time. There are no ath10k
warnings, firmware crashes or restarts, and connectivity is not
visibly affected.

Trigger
An AP-side monitor capture shows that DAWN makes hostapd send the
client two Radio Measurement Requests every 20 s, 5 s apart:

- Beacon Request, op class 129, ch 36, BSSID = the associated AP,
passive, duration 0.
  The client answers within 1-2 ms with a Radio Measurement Report,
mode 0x04 (refused).
  Body starts: 05 00 67 00 00 26 1d 01 00 05 81 24 00 00 00 00 00 a4
a9 30 c8 5e 5f 00 ...
  Reply body:  05 01 67 27 03 01 04 05
- Beacon Request, op class 129, ch 116, BSSID = a second AP. The
client sends no reply.

Using the ath10k tracepoints, each fault precedes the ath10k_wmi_event
for the ch 36 request (id 0x7001 / mgmt rx, len 152) by a constant 76
ms (+/- <1 ms) over several cycles. The 5 s / 15 s interleaving of the
two requests matches the fault/no-fault pattern.

What changes it
- Stopping DAWN on the AP (no more beacon requests): periodic faults stop.
- Client disconnected but interface up: faults stop.

No effect
- AP width 160 -> 80 MHz : faults continue.
- Disabling ASPM L1 (incl. L1.1/L1.2) on 02:00.0 via sysfs: faults continue.
- Wi-Fi power save off: faults continue.
- Continuous traffic: faults continue.
- Runtime PM: not active (power/control = on), so not a factor.

Additionally, even with DAWN stopped, a single fault appears once
after each (re)association. I haven't confirmed whether that is also
RRM-related.

It looks like the firmware writes to a stale or unmapped host buffer
when it handles an incoming (protected) RRM Beacon Request. I can
provide the full dmesg, the ath10k trace and the AP-side pcap, and I'm
happy to test patches or collect more debug data.

Thanks,
Waldo Janssens