I suspected the KIOXIA module may require slightly higher voltage than the minimum specification, because hardware hibernation is initiated autonomously by the UFS device itself, not the driver. Since disabling software hibernation and gear limiting didn’t resolve the issue and if it’s not a power rail issue, what else could cause the physical layer to fail recovery from hardware H8 exit consistently?
Clock instability (PHY, PLL)?
Defective modules?
Board-level issues?
Is there a test we can run to pinpoint the root cause?
We’ve confirmed that the KIOXIA UFS device does exhibit issues when used with Linux on the Q6A platform. However, at this stage, we haven’t been able to determine whether the root cause lies in the hardware design or in the UFS initialization sequence within the bootloader/firmware.
Notably, we have not been able to reproduce this issue on other boards using the same UFS chip, which suggests the problem may be specific to the Q6A platform’s implementation.
If you’re seeing similar behavior on your side, we’d appreciate it if you could share your findings—this would help us narrow down the cause more effectively.
We’ll continue investigating this issue and keep you updated on our progress.
One question; you are saying that there are issues when used with Linux, does this mean the issue does not appear with others OSes like windows? Or hasn’t that been tried out yet?
I can confirm that using SUSE MicroOS Linux with the latest mainline kernel (6.19.11) shows the same issues. Most probably due to the same devicetree. (Any idea btw how to patch the devicetree on MicroOS using Q6A’s UEFI? Need it for getting the POE HAT’s fan working, that one is not in the embedded devicetree in the kernel, otherwise it’s running like a charm on EMMC)
Last question:
Radxa UFS3 module 128Gi is always Samsung? And 256Gi is always Kioxa?
Thank you for the update and for being transparent about the 256GB UFS module having issues specifically on the Q6A platform. I genuinely appreciate that the team is taking this seriously and has been communicating throughout the process.
That said, I do need to raise some concerns, because the situation has become difficult to accept from a consumer standpoint.
I purchased the Dragon Q6A, the Radxa 256GB UFS module, and the official Radxa power supply as a complete configuration. I did not mix incompatible third-party hardware — I bought what Radxa sells and recommends together.
I’ve been dealing with stuttering and freezes since day one, and despite following every suggestion from the support team (updating Firmware, disabling UFS hibernation, lowering the data link gear), the problem remains. The system runs on a large heatsink with fan and temperatures never exceed 35-40°C, so thermal throttling is ruled out entirely.
The only way I see as a practical workaround is to buy an M.2 drive, which is an additional expense I shouldn’t have to make for a configuration I bought in good faith.
I’d like to know what options are available to me:
Is there a realistic timeline for a fix, either through a software/firmware update or a hardware revision?
If the issue requires a hardware revision to the Q6A, will there be any exchange or upgrade path for customers who bought affected units?
If neither a fix nor an exchange is possible in a reasonable timeframe, is there any other form of resolution Radxa can offer — such as compensation toward the M.2 drive I now need to purchase?
I understand these things take time to debug, and I’m not asking for miracles overnight. I know hardware development is complex, but I do feel I’m entitled to a system that works as advertised, and I’d like to understand what Radxa can do to make this right.
Following up on my previous message with a finding that may help narrow down the root cause significantly.
I was puzzled by the fact that despite all the UFS errors seen in dmesg, performance measured in both KDiskMark and fio was up to spec!
WRITE: bw=451MiB/s (473MB/s), 451MiB/s-451MiB/s (473MB/s-473MB/s), io=2048MiB (2147MB), run=4536-4536msec
READ: bw=1829MiB/s (1917MB/s), 1829MiB/s-1829MiB/s (1917MB/s-1917MB/s), io=107GiB (115GB), run=60017-60017msec
While investigating further, I discovered that stuttering and UFS errors stop completely for the duration of a sustained fio test (and resume once the test is finished). This rules out any data corruption or permanent hardware defect, and points to the UFS hardware hibernate exit sequence (HW_H8_EXIT).
What I observed:
UFS as boot disk → errors every ~1–2 minutes, because OS background I/O creates frequent short idle gaps that trigger repeated H8 entry/exit cycles
UFS under sustained fio load → zero errors, because the device never enters H8
UFS as non-boot disk → errors appear only during system idle/wake cycles, consistent with UFS exiting H8 state
What this suggests:
The UFS device autonomously enters H8 during brief I/O gaps or when system is idle. The host PHY then consistently fails to exit H8 correctly (showing up as HW_H8_EXIT_CNT=0 in dmesg logs). This matches the behavior your team observed being specific to the Q6A platform - it would be a driver or firmware bug in the H8 exit sequence, not a defect in the UFS chip itself.
If a keep-alive mechanism can be used to prevent the UFS device from entering H8 in the first place (like a periodic dummy I/O, a kernel parameter, or a UFS driver flag to disable H8), and this eliminates the errors entirely, that would confirm the H8 exit sequence as the root cause, and give your team a clear targeted fix to work toward.
I am attaching the scripts and logs. I hope this helps focus the investigation.
Happy to run any additional tests if that would be useful.
I’ve tested on other Rockchip-based platforms, and this issue doesn’t occur there. I suspect the problem likely lies in Qualcomm’s driver or bootloader layer.
If you need to configure PoE, you might want to refer to this:
On RadxaOS, you can enable the 25W PoE+ HAT via sudo rsetup.
Regarding the UFS3 modules: I’m not certain which brand will be used in the next batch. We will also be conducting UFS module compatibility testing specifically for the Q6A soon. For users who have purchased units with Kioxia UFS, I’ll do my best to either fix the issue or explore possible compensation options. I sincerely apologize for the inconvenience this has caused you.
Based on the information you provided, I’ve written a script to prevent UFS from entering the H8 state. So far, my testing hasn’t revealed any issues—perhaps you could give it a try? This seems to narrow down the scope of the problem, and I’ll continue debugging on my end.
touch ufs_keepalive.sh
#!/bin/sh
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
}
log "Starting UFS keep-alive daemon (reading $TARGET_FILE every ${INTERVAL_MS}ms)"
while true; do
echo "keepalive" > /tmp/.ufs_ka
sleep 0.1
done
Thank you for your continued effort to investigate this issue and for your willingness to either resolve it or arrange compensation if needed.
I tested the keep-alive script you provided to prevent the UFS from entering the H8 state, and after running it for about an hour and a half, the stuttering that previously occurred every few minutes has completely disappeared. I’ve also noticed that the related errors no longer appear in dmesg during this time. I suspect that freezes are also resolved, but I’ll run it for a day or two to make sure.
This strongly suggests that the issue is indeed tied to the UFS hibernation behavior, likely at the driver or bootloader level as you suspected. I assume the next step may involve escalation to Qualcomm for further investigation.
I appreciate your efforts in pursuing a proper fix.
Although I can reproduce the stuttering issue on KIOXIA UFS, I have not been able to reproduce it on Samsung UFS. Additionally, I also failed to reproduce the issue on Qualcomm’s RB3 Gen 2 platform. Unfortunately, the RB3 Gen 2 does not support installing a UFS module, which prevents me from performing a direct comparison.
To move forward, we may need to reproduce this issue in a Yocto-based environment—only then would Qualcomm be able to assist us in pinpointing the root cause.
The ufs_keepalive.sh script ran from Wed Apr 29 12:28 to Thu Apr 30 13:03:07.
During this period, no stuttering was observed, and no accompanying UFS errors were logged.
I have attached dmesg_keepalive.log
I’m not sure how directly comparable UFS behavior is between QRB5165 and QCS6490.
They are both UFS 3.1, but they use different controller generations and system interconnects, which could affect latency and power management (less aggressive on QRB5165?). They rely on the same Linux Qualcom UFS stack (ufshcd + ufs-qcom), so the differences should be in tuning and integration, through firmware, device tree configuration and platform-specific adjustments, rather than totaly different drivers.
Regarding the Samsung vs KIOXIA modules, I wouldn’t expect identical behavior between vendors. Although UFS provides standard functionality, vendor-specific characteristics (firmware behavior, timings, power states) can impact performance, and may need specific tuning.
If reproducing it in a Yocto-based environment would help to get Qualcomm support onboard, and you can provide such a build, I’d be happy to test it.
I put the Kioxa/UFS back on the dragon-q6a-n05; installed the new kernel.
Adding it as a node to the RKE2 cluster, having logs shipped by Vector and let’s see what happens the coming hours
So Single-stream throughput: ~1.0–1.3 GB/s and fully queued throughput: ~1.9 GB/s
It seems that the Kioxia hardware has substantial internal parallelism, also latency per I/O is nontrivial, so deeper queues are needed to fully saturate the device. So under load the device can achive read of ~1.9 GB/s (although write at ~0.5 GB/s, is 1/4 of that!)
