Maybe @PolynomialDivision might be able to help you there. Curious, if either ath11k wifi driver or your setting might affect something in Dawn, so that its actions can crash/lock your radio.
Based on your logs, one possible thing is that something is tried to be done forcefully during the DFS scanning period, when the radio is unusable to large extent.
EDIT: corrected ath11k
I was going to use it for better AP transitioning on legacy devices, smart switches, sensors, etc. but hadn't really dug into it yet.
Worth reporting to @PolynomialDivision as removing DAWN from my builds seems to have eliminated my problems.
Did a little playing with the IRQ's... I noticed that everything was basically pulling from CPU0. irqbalance didn't seem to do anything, so I manually moved some of them around based on feedback from the Xiaomi AX3600 thread since the hardware is extremely comparable.
Below you will see what I added to the startup script, and what the outcome was. Previously everything was on CPU0. Definitely balances the load and I notice less latency as well. Processor frequencies ramp up evenly (generally speaking) across the CPUs now also. Next I may play with the processor frequencies and responsiveness to see if I can further accelerate. If anyone has any feedback or requests on what I've done, let me know!
#assign 4 rx interrupts to each cores
echo 8 > /proc/irq/50/smp_affinity
echo 4 > /proc/irq/51/smp_affinity
echo 2 > /proc/irq/52/smp_affinity
echo 1 > /proc/irq/53/smp_affinity
#assign 3 tcl completions to 3 CPUs
echo 4 > /proc/irq/73/smp_affinity
echo 2 > /proc/irq/74/smp_affinity
echo 1 > /proc/irq/75/smp_affinity
root@OpenWrt:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
9: 0 0 0 0 GIC-0 39 Level arch_mem_timer
13: 52555543 10352022 19393113 13975357 GIC-0 20 Level arch_timer
16: 2 0 0 0 GIC-0 354 Edge smp2p
17: 0 0 0 0 GIC-0 216 Level 4a9000.thermal-sensor
18: 0 0 0 0 GIC-0 239 Level bam_dma
21: 0 0 0 0 GIC-0 270 Level bam_dma
22: 6 0 0 0 GIC-0 340 Level msm_serial0
23: 57057 0 0 0 GIC-0 178 Level bam_dma
24: 0 0 0 0 GIC-0 35 Edge wdt_bark
25: 0 0 0 0 GIC-0 357 Edge q6v5 wdog
29: 5 0 0 0 GIC-0 348 Edge ce0
30: 64186812 0 0 0 GIC-0 347 Edge ce1
31: 7329517 0 0 0 GIC-0 346 Edge ce2
32: 158815 0 0 0 GIC-0 343 Edge ce3
34: 688 0 0 0 GIC-0 443 Edge ce5
36: 124780 0 0 0 GIC-0 72 Edge ce7
38: 0 0 0 0 GIC-0 334 Edge ce9
39: 0 0 0 0 GIC-0 333 Edge ce10
40: 0 0 0 0 GIC-0 69 Edge ce11
47: 0 0 0 0 GIC-0 323 Edge reo2ost-exception
48: 1686954 0 0 0 GIC-0 322 Edge wbm2host-rx-release
49: 2067 0 0 0 GIC-0 321 Edge reo2host-status
50: 0 0 0 4516536 GIC-0 320 Edge reo2host-destination-ring4
51: 2 0 3737029 0 GIC-0 271 Edge reo2host-destination-ring3
52: 0 2951387 0 0 GIC-0 268 Edge reo2host-destination-ring2
53: 1931130 0 0 0 GIC-0 267 Edge reo2host-destination-ring1
57: 5646371 0 0 0 GIC-0 263 Edge ppdu-end-interrupts-mac3
58: 0 0 0 0 GIC-0 262 Edge ppdu-end-interrupts-mac2
59: 21969296 0 0 0 GIC-0 261 Edge ppdu-end-interrupts-mac1
60: 1 0 0 0 GIC-0 260 Edge rxdma2host-monitor-status-ring-mac3
61: 0 0 0 0 GIC-0 256 Edge rxdma2host-monitor-status-ring-mac2
62: 1 0 0 0 GIC-0 255 Edge rxdma2host-monitor-status-ring-mac1
63: 1 0 0 0 GIC-0 235 Edge host2rxdma-host-buf-ring-mac3
64: 0 0 0 0 GIC-0 215 Edge host2rxdma-host-buf-ring-mac2
65: 1 0 0 0 GIC-0 212 Edge host2rxdma-host-buf-ring-mac1
66: 0 0 0 0 GIC-0 211 Edge rxdma2host-destination-ring-mac3
67: 0 0 0 0 GIC-0 210 Edge rxdma2host-destination-ring-mac2
68: 0 0 0 0 GIC-0 209 Edge rxdma2host-destination-ring-mac1
73: 0 0 197806 0 GIC-0 191 Edge wbm2host-tx-completions-ring3
74: 1 126375 0 0 GIC-0 190 Edge wbm2host-tx-completions-ring2
75: 11096332 0 0 0 GIC-0 189 Edge wbm2host-tx-completions-ring1
77: 20 0 0 0 GIC-0 47 Edge cpr3
78: 21994960 0 0 0 GIC-0 377 Level edma_txcmpl
79: 0 0 0 0 GIC-0 385 Level edma_rxfill
80: 38117855 0 0 0 GIC-0 393 Level edma_rxdesc
81: 0 0 0 0 GIC-0 376 Level edma_misc
82: 0 0 0 0 pmic_arb 51380237 Edge pm-adc5
83: 0 0 0 0 smp2p 0 Edge q6v5 fatal
84: 1 0 0 0 smp2p 1 Edge q6v5 ready
85: 0 0 0 0 smp2p 2 Edge q6v5 handover
86: 0 0 0 0 smp2p 3 Edge q6v5 stop
87: 0 0 0 0 msmgpio 34 Edge keys
88: 0 0 0 0 msmgpio 63 Edge keys
89: 0 0 0 0 GIC-0 172 Level xhci-hcd:usb1
90: 64 0 0 0 GIC-0 353 Edge glink-native
IPI0: 59290 63469 78156 97112 Rescheduling interrupts
IPI1: 2178892 22114276 11563475 8193955 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 38784 41950 40609 35496 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0
Please keep us updated with your final results and instruction on how to apply it, Thank you,
Just a quick question: do you have any test result by changing software /hardware flow offloading and packet steering? (possibly no effect with hardware offloading as this hardware does not support it)
I do not at present - no. My previous dealings with both of those has tended to be less than optimal, but that was with @ACwifidude NSS builds for the R7800. I will test with this router as time proceeds.
So everything basically uses a single core? Darn its a fast router then...because i get 250+ wireguard speed together with a mesh. Had other routers that gave up at 150 with wireguard.
You surely know, that this just the hex-encoded client IP: 192.168.10.10
Looks like there is a bootfile parameter which maybe would control the TFTP filename:
root@DL-WRX36-7DE ~ # strings /dev/mtd15 | grep boot | grep file
.callbacks:callbacks,.flags:flags,baudrate:baudrate,bootfile:bootfile,ipaddr:ipaddr,gatewayip:gatewayip,netmask:netmask,serverip:serverip,nvlan:nvlan,vlan:vlan,ethaddr:ethaddr,loadaddr:loadaddr,stdin:console,stdout:console,stderr:console,
bootfile
** No boot file defined **
No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>
*** Warning: no boot file name; using '%s'
By the way the U-Boot won't enter automatically to this TFTP recovery if one keeps pushing the RESET or the WPS button while powering on the device?
Nicely spotted. 
They have funny humor.
They have! 
I had to learn it in the hard way with the AX3600, as it does DHCP while TFTP recovery, so if one configure DHCP differently then it would request the file with different name. 
Well, then is actually maybe not hard-coded, but based on logic regarding the IP.
Might be that if u-boot is configured differently regarding the IPs, its TFTP module might search other filename.
I did not know
I already tried turning off the router and then connecting the router to electricity while pressing and holding:
I also had serial connected and noticed u-boot did nothing, it went straight into OpenWRT
my personal experience is that schedutil is rubbish vs ondemand with a higher incentive to be more aggressive
echo 60 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
schedutil is too slow to turn demand active .. note - this is against the overall consensus of this entire openwrt forum that schedutil is best !
Just started a Attended SysUpgrade from R20036 to R20063 .
However, the installation takes more than 5 minutes (previously it only take 2 minutes at most) now, and my wrx36 still not rebooted.
How to find out what is going on? How to decide if it is OK to force reboot? How to abort it?
I've noticed this as well - it stays at 1ghz the vast majority of the time and even causes processor usage spikes up to 40% sometimes during minuscule tasks. I'm going to test with both ondemand and performance to see how they compare. With my R7800's I always ran performance because the power consumption differences were so negligible and the router temps only increased a degree or two. Curious how this will respond as well. I know that many stock firmware's don't allow so many frequencies to be selected, but rather two or three at most and most stock firmware have very aggressive up sampling as well.
I see the ondemand governor isn’t baked in to default snapshot… just schedutil and performance. Interesting…
You wait some more, then you investigate using serial console.
I guess I was hit by the same issue. Used serial to recover
I sysupgraded yesterday quite normally from 20036 to 20063, with an image self-built with imagebuilder.
"recover"? What was the actual situation? Something shown in the console?
Did the router not boot at all? Was serial really needed?
Sysupgrade is just scripts that checks compatibility do the flashing in certain pieces (kernel + rootfs separately). If it gets stuck before any flashing is done, normal reboot should be enough)
I described it earlier: used root+ssh to install OpenWrt in memory then by using ubi. All went ok and I had luci installed. Then upgraded to a new snapshot via UI and rebooted. It was stuck on purple led no matter what I tried. I had to disassemble the unit and hook up to the console port. Was able to go though steps all the way this time. A bit hesitant to upgrade again though 
Its a minor issue though. The biggest one is the inability to use 160mhz channels normally and missing upper 5ghz channels. I dunno why people turn other way from this problem in a supposedly 'recommended' WiFi router.
Just for comparison. My phicomm K3 which I got for 40 bucks shipped 3 years ago is based on (shunned) Broadcom and still works perfectly with OpenWrt since 19.x (after tweaks) - irqbalance works, 1gbps nat works, 3(!) 160mhz channels work, no hardcoded regdb. Uptime is till next power loss.
I hoped for upgrade to ax (no real need, just curiosity, I guess) but oh well...