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

[Marcus Glocker]

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
enabled, plus the resulting RDDM binary after the firmware crash:

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/x-gunzip
Size: 83823 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath12k/attachments/20260512/adc41604/attachment-0001.bin>