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

[Baochen Qiang]

On 5/13/2026 3:59 AM, Marcus Glocker wrote:
> On Tue, May 12, 2026 at 11:38:06AM +0800, Baochen Qiang wrote:
> 
>>
>>
>> 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
>>>
>>
> 
> Hi Baochen,
>                                         
> Thanks for coming back on this topic.
>                                         
> Attached the OpenBSD dmesg, with full ath12k driver debug logging

the dmesg shows several WMI_INIT cmd instances which is not expected, because in normal
operation this command should be sent only once.

cat dmesg |grep -w 'sending WMI command 0x1'
May 12 19:35:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
May 12 19:37:20 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
May 12 19:37:41 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
May 12 19:37:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
May 12 19:37:50 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1

other than that I don't find any other clues.

> enabled, plus the resulting RDDM binary after the firmware crash:

how did you collect the RDDM binary, seems not in the right format, my tool can not parse
it correctly. Looking into the binary, at least the magic 'ATH12K-FW-DUMP' is not present
at the very beginning.

And from which Linux version you take the ath12k codebase?

> 
> https://nazgul.ch/pub/qwz0-rddm.bin.gz
>                                         
> The command sequence on OpenBSD to re-produce that was:
>                                         
> ifconfig qwz0 up                        # Bring the ath12k device up
> ifconfig qwz0 scan                      # Scan for networks
> ifconfig qwz0 nwid nazgul wpakey xxx    # Start association
>                                         
> Hi Max,
>                                         
> Since you have Linux running on exactly the same Samsung Galaxy Book4
> Edge 14" laptop, where ath12k works, would you be so kind and also
> provide the dmesg output showing an successful association with the
> ath12k driver debug logging enabled?  See above how to enable that.
> That would be very helpful!
>                                         
> Thanks and Regards,
> Marcus