ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100

[Baochen Qiang]

On 5/5/2026 5:08 AM, Marcus Glocker wrote:
> Hi,
> 
> We're porting ath12k to OpenBSD as the qwz(4) driver, targeting Samsung
> Galaxy Book4 Edge (X1E80100 SoC, WCN7850 hw2.0).  Scan, auth, 4-way
> handshake all complete; ~2 seconds after WPA2 AUTHORIZE the WCN7850
> firmware crashes deterministically with:
> 
> 	dlpager_main.c:147 Non Page Fault Exception cause code 0x 23
> 	at Address: 0x 1792000
> 
> Cause code 0x23 isn't a valid arm64 exception -- the fault is on the
> WCN7850's on-die Hexagon Q6 DSP, with QURT's generic exception handler
> (which happens to live in dlpager_main.c) printing it.  So this is not
> a host CPU fault.
> 
> Per the RDDM segment table (at the start of the dump), VA 0x01792000
> is the start of the chip's WLAON_DUMP region (size 0x820).  The Q6 is
> trying to read its own always-on hardware state region and the chip
> refuses the access.
> 
> (Samsung, Asus, Honor) with multiple FW builds.  Currently testing
> with WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> (fw 0x110cffff, 2025-06-25) -- the exact blob a Linux ath12k user
> runs successfully on the identical Samsung hardware.  Same board-2.bin,
> same compiled DTB (upstream hamoa.dtsi based).
> 
> We've field-compared qwz against ath12k and ruled out (byte-level or
> wire-level):
> 
>   * QMI host_cap, m3_info, wlan_cfg, wlan_ini, bdf_download (all
>     fields including ce_config, svc_to_ce_map, shadow_reg_v3,
>     feature_list, m3 paddr/size, nm_modem)
>   * MHI bringup ordering (BHI -> wait SBL EE -> wait M0 -> BHIE)
>   * BHI/BHIE DMA coherency
>   * ASPM disable before MHI start
>   * WLAON_WARM_SW_ENTRY zeroing + QFPROM_PWR_CTRL VDD4BLOW clear
>   * static_window_map=false + window-bank register init
>   * Per-chunk vs monolithic respond_mem allocation
>   * WMI_PEER_MIMO_PS_STATE = WMI_PEER_SMPS_PS_NONE (added matching
>     ath12k_setup_peer_smps; doesn't help)
>   * FW image variation (c5 and c7 both fail identically)
> 
> Specifically NOT involved (we have evidence either way):
> 
>   * Gunyah -- X1E80100 is reportedly run in EL2 without Gunyah by
>     users where ath12k works; so Gunyah isn't programming WLAON
>     access for the Q6.
>   * SMMU / pcie_smmu -- pcie_smmu is status="reserved" upstream,
>     pcie4 has no iommus property; PCIe DMA bypasses SMMU.
>   * SCM/PAS -- ath12k's PCIe path makes no qcom_scm_* calls.
> 
> Question: what subsystem inside the WCN7850 firmware touches the
> WLAON region at 0x01792000 around 2 seconds after the host sends
> WMI_PEER_AUTHORIZE?  And what host-side configuration (WMI command,
> HTT message, MHI state, etc.) primes that path so the access
> succeeds on Linux?
> 
> Even a pointer at the right Linux code path or the right FW-side
> component would unblock us.  We have full RDDM dumps and dmesg
> captures available; happy to share off-list or as attachments.

please help collect ath12k successful dmesg log and qwz failed dmesg log for compare.

Please enable verbose ath12k log when loading ath12k driver:

If you are using the latest upstream ath12k:

	sudo modprobe ath12k debug_mask=0xffffffff
	sudo modprobe ath12k_wifi7

If you are using an old ath12k:

	sudo modprobe ath12k debug_mask=0xffffffff

> 
> Thanks,
> Marcus
>