QNN HTP fails to initialize on Snapdragon 8 Elite (SM8750P) — native “No Snapdragon SOC detected” / transport error 4000

[ivaylo681-dev]

🐛 Describe the bug

Hello!
I am opening the topic here as closing the old one (seems the old was on a wrong place).

The failure that I have is with identical failure signature as #16465 (QnnDsp: No Snapdragon SOC detected → error 4000), but on a different sun-platform device (my soc_id=639 confirmed via /sys/devices/soc0/soc_id).
In the thread that I have found it has been replied that the issue for soc_id=705 will be fixed in qnn-runtime 2.43.0. I am already with the newest version 2.48.0, but as my soc is different version of 7850 seems the problem is not solved for it.
Adding here the full description and I will be really gratefull for any help!

Summary

On a Snapdragon 8 Elite (SM8750P) Android device, the Hexagon HTP backend fails to initialize via QNN, regardless of which framework or SDK version is used to reach it. The failure occurs deep inside Qualcomm’s native QNN libraries — at DSP SoC-detection / transport-initialization — not in any application-level or third-party framework code. This has been reproduced identically through two independent, unrelated frameworks (ONNX Runtime’s QNN Execution Provider, and TensorFlow Lite’s QNN delegate), both calling into the same underlying QAIRT native libraries, both failing at the same point with the same error codes.

Device

• SoC model: SM8750P (adb shell getprop ro.soc.model)

• Board platform: sun (adb shell getprop ro.board.platform)

• Hardware: qcom

• OS: Android 16, MIUI/HyperOS (Xiaomi)

• Native QNN libs present on device (confirmed via run-as ls -la on installed APK): libQnnHtp.so, libQnnHtpV68/V69/V73/V75/V79/V81Skel.so + matching Stub.so, libQnnSystem.so — all present, correctly loaded (confirmed via nativeloader log: Load .../libqnn_delegate_jni.so ... ok)

Reproduction 1 — ONNX Runtime QNN Execution Provider

Using onnxruntime-android-qnn (tested versions 1.27.0 and 1.28.0, identical result on both):

val qnnOptions = OrtSession.SessionOptions().apply {

addQnn(mapOf(

"backend_path" to "libQnnHtp.so",

"profiling_level" to "detailed"
))

}

createdSession = ortEnv!!.createSession(modelBytes, qnnOptions)

Result — session creation does not throw, but GetCapability() silently assigns 100% of graph nodes to CPU:

W onnxruntime: [qnn_backend_manager.cc:1680 SetupBackend] Failed to setup so cleaning up

E onnxruntime: [qnn_execution_provider.cc:1046 GetCapability] QNN SetupBackend failed Failed to create device. Error: QNN_DEVICE_ERROR_INVALID_CONFIG: Invalid config values

Confirmed via enableProfiling() trace inspection: every node across multiple full inference passes shows "provider": "CPUExecutionProvider"; zero occurrences of “QNN” in the raw trace JSON.

Reproduction 2 — TensorFlow Lite QNN delegate (independent framework, same device, same app process)

Using com.qualcomm.qti:qnn-litert-delegate:

val options = QnnDelegate.Options()

options.setBackendType(QnnDelegate.Options.BackendType.HTP_BACKEND)

options.setSkelLibraryDir(context.applicationInfo.nativeLibraryDir)

val qnnDelegate = QnnDelegate(options)

val tfliteOptions = Interpreter.Options().apply { addDelegate(qnnDelegate) }

val interpreter = Interpreter(tfliteModel, tfliteOptions)

Result — this surfaces the real native failure, at the QnnDsp layer, independent of ORT entirely:

E QnnDsp: QnnDsp loadRemoteSymbols failed with err 4000

E QnnDsp: QnnDsp Failed to create transport for device, error: 4000

E QnnDsp: QnnDsp Failed to load skel, error: 4000

E QnnDsp: QnnDsp Transport layer setup failed: 14001

E QnnDsp: QnnDsp Failed to parse default platform info: 14001

E QnnDsp: QnnDsp Failed to load default platform info: 14001

E QnnDsp: QnnDsp Failed to parse platform config: 14001

This is a native-level failure inside libQnnHtp.so / the skel loading path — not a Java/Kotlin exception, not framework-specific code. Two different frameworks, two different SDK entry points, same underlying native failure.

Matches a known, previously-reported issue on the same platform

This closely matches #16465 (“QNN HTP init fails on CQ8750S (soc_id=705): ‘No Snapdragon SOC detected’”), filed against the same ro.board.platform=sun device family and already labeled partner: qualcomm by the ExecuTorch maintainers. That issue’s log shows the same error code surfacing at a slightly earlier stage of initialization:

QnnDsp No Snapdragon SOC detected

QnnDsp No Snapdragon SOC detected

QnnDsp Failed to init router

QnnDsp failed sg_htpSingletonProvider initialize: 4000

Same error code (4000), same platform family, consistent with a SoC-identification failure early in QNN’s device-detection path that cascades into transport/skel-load failure. My device reports a clean ro.soc.model=SM8750P (not the garbled CQ8750S string in that report), so this may be a related but distinct SoC-ID/SKU variant not recognized by the current QAIRT SoC lookup table.

Ruled out (not the cause)

Exhaustively tested and eliminated before concluding this is an SDK-level issue:

Variable

Tested

Result

htp_arch provider option

unset, 81, 79 (invalid — not in ORT enum), 69

No change

soc_model provider option

69

No change

Model precision

fp32, native fp16

No change — fails before model is evaluated

onnxruntime-android-qnn version

1.27.0, 1.28.0

Identical failure both versions

qnn-runtime native library version

bundled vs. explicit override to 2.48.0 (confirmed via file-size diff on installed APK: 2,642,248 ? 3,760,632 bytes — genuinely a different binary)

No change

Manual ADSP_LIBRARY_PATH override

present vs. removed entirely

No change

vtcm_mb config

unset vs. 8

No change

Op-level HTP support

checked all model ops against published QNN operator table — all supported

Not the cause; failure occurs before op-level partitioning

App-level DSP device-node permissions (disproven as the cause, included for completeness)

Initially suspected the app’s read-only access to /dev/fastrpc-cdsp (owner/group system:system) as the cause. This is disproven: a third-party benchmarking app (Geekbench AI), running with no elevated privileges, achieves genuine HTP acceleration on this exact device via its own TFLite QNN backend — confirmed via a large FP16/INT8 score differential versus its NNAPI backend on the same device (QNN: 21,627/55,112 vs. NNAPI: 485/1,111 for half-precision/quantized workloads respectively) — https://browser.geekbench.com/ai/v1/542278. This proves third-party app-level HTP access is possible on this device in principle. I do not know what QAIRT/QNN SDK version Geekbench bundles; it’s possible they have a vendor-provided or newer build with correct SoC recognition for this chip that isn’t yet available via the public qnn-runtime Maven releases I tested (through 2.48.0).

Versions

PyTorch version: 2.13.0+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Pro (10.0.26100 64-bit)
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.31.7
Libc version: N/A

Python version: 3.11.0 (main, Oct 24 2022, 18:26:48) [MSC v.1933 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.26100-SP0
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
Is XPU available: False
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: False
Caching allocator config: N/A

CPU:
Name: Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
Manufacturer: GenuineIntel
Family: 205
Architecture: 9
ProcessorType: 3
DeviceID: CPU0
CurrentClockSpeed: 2901
MaxClockSpeed: 2901
L2CacheSize: 1536
L2CacheSpeed: None
Revision: None

Versions of relevant libraries:
[pip3] numpy==2.4.6
[pip3] onnx==1.22.0
[pip3] onnxruntime==1.27.0
[pip3] onnxslim==0.1.94
[pip3] optree==0.19.1
[pip3] torch==2.13.0
[pip3] torchvision==0.28.0
[conda] Could not collect

cc @cbilgin @psiddh

[ashish-frozo]

This is a strong repro because it separates app/framework behavior from the native QNN failure path. The most useful next evidence would be a tiny device matrix: same APK/model, same QAIRT/QNN version, but different soc_id / board platform / HTP arch, with three columns: QNN setup status, provider assignment from profiling, and measured CPU load. The silent fallback part is the real deployment risk here: session creation can look successful while the graph is effectively 100% CPU.

[ivaylo681-dev]

I will receive a device from a different OEM within 60 days...
But now....
I read again #16465
And I find it useful that fast they have confirmed working soc_model=105 for soc_id=705 with the old QNN.
So as the failure here is with identical signature, could you help identify the correct soc_model value for soc_id=639 specifically?

[nil-is-all]

@ivaylo681-dev thanks for filing this issue. @haowhsu-quic @shewu-quic @winskuo-quic @DannyYuyang-quic is this SoC not supported with v2.48+ and hence causing this issue?

cc @psiddh

[ivaylo681-dev]

I have tried today to check the soc_model override across the full numeric range, but with no success. I ran an exhaustive brute-force test from 0 to 9999 on soc_id=639 (SM8750P), tested against both the real production model and a minimal static-shape control model, with session.disable_cpu_ep_fallback set to force a hard failure signal instead of a silent fallback. Every single value across the full range failed identically, with the same QNN_DEVICE_ERROR_INVALID_CONFIG error. This suggests soc_model only works when pointed at an existing table entry, rather than being something one can discover by guessing — unlike the 705→105 case above, 639 may simply have no corresponding entry in the table at all yet. Could you confirm whether soc_id=639 exists anywhere in the current SoC table, even internally/unexposed?

[shewu-quic]

Hi @ivaylo681-dev,

Could you please help to try the below command? Because SM8750P should be the same soc info as SM8750.

executorch/backends/qualcomm/serialization/qc_schema.py

Line 93 in 99924e4

QcomChipset.SM8750: SocInfo(QcomChipset.SM8750, HtpInfo(HtpArch.V79, 8)),

python mobilenet_v2.py --device <device_serial> --soc_model "SM8750" --build_folder path/to/build-android/ -d /path/to/imagenet-mini/val

[ivaylo681-dev]

Update:
soc_model="SM8750" gets past QNN init — supports this being a SoC-ID table gap, plus found a separate ExecuTorch bug along the way

Tried --soc_model "SM8750" (base chip name, since SM8750P isn't in the table) via ExecuTorch on a device reporting SM8750P / soc_id=639 / ro.board.platform=sun. Setup: executorch @ latest main as of 2026-08-07, QAIRT SDK 2.49.0.260730, Android NDK r27c, target arm64-v8a.

Result: QNN device/backend creation succeeds, graph compilation succeeds — real "Finalizing Graph Sequence" stage with actual DDR bandwidth stats, clean Destroy Qnn context / Destroy Qnn device / Destroy Qnn backend teardown, files push to device, qnn_executor_runner launches. This is useful supporting evidence for the request above: it shows this chip + QAIRT SDK combination genuinely can work once given a recognized SoC identity — reinforcing that SM8750P's soc_id=639 just needs its own table entry, same as the 705→105 fix already applied for a related device.

Tombstone (attached: tombstone_14.txt) confirms FastRPC/DSP access itself works fine on this SM8750P device once SoC detection passes — real open fds to /dev/fastrpc-cdsp, DMA buffer allocations, a live worker thread:

fd 8: /dev/fastrpc-cdsp (unowned)
fd 10: /dev/fastrpc-cdsp (unowned)
fd 5: /dev/dma_heap/system (owned by unique_fd ...)
#3 pc 0000000000035bdc /vendor/lib64/libcdsprpc.so (fastrpc_latency_thread_handler.cfi+396)

So this isn't a permissions/access issue — purely SoC recognition. (I'd earlier suspected an app-level FastRPC device-node permission restriction; this tombstone disproves that directly.)

Execution then crashes with a deterministic SIGSEGV (SEGV_MAPERR), reproducible across fully-cleared workspaces (device + host) every time:

[INFO] QnnContextCustomProtocol expected magic number: 0x5678abcd but get: 0x4034b50
[WARNING] Failed to interpret QNN context binary. Error code 30010. Try verifying binary with online-prepare format.
[INFO] Skip qnn_graph_create, graph has already been composed from Dlc.
Segmentation fault

Tried --online_prepare (the tool's own suggested fix) — no change, identical crash, byte-for-byte the same log sequence.

Traced the crash to a concrete bug, unrelated to the SoC/hardware itself — in backends/qualcomm/runtime/backends/QnnGraphCommon.cpp, QnnGraph::Configure():

cpp
Qnn_GraphHandle_t graph_handle = nullptr;
if (context_->GetCacheState() == QnnBackendCache::DESERIALIZE) {
// ... assigns graph_handle via qnn_graph_retrieve
} else if (... SERIALIZE || MULTI_GRAPH) {
// ... assigns graph_handle via qnn_graph_create
} else if (context_->GetCacheState() == QnnBackendCache::ONLINE_PREPARE) {
QNN_EXECUTORCH_LOG_INFO(
"Skip qnn_graph_create, graph has already been composed from Dlc.");
// graph_handle is never assigned in this branch
} else {
QNN_EXECUTORCH_LOG_ERROR("QNN context cache is invalid.");
return Error::Internal;
}

handle_[graph_name] = graph_handle; // stores nullptr when state == ONLINE_PREPARE

In the ONLINE_PREPARE branch — reached whenever QnnBackendCache::Configure() falls back from a failed context-binary magic-number check — graph_handle stays nullptr and is stored directly into handle_[graph_name] with no validation. Whatever later consumes that handle (GraphExecute, or wherever it's retrieved during execution) operates on a null/invalid handle — a sufficient, deterministic explanation for the crash, confirmed via a symbolized on-device lldb session (backtrace lands in generic Method::execute_instruction → event-tracer bookkeeping, consistent with invalid state entering execution rather than a hardware fault, not an unwind artifact of the earlier unsymbolized tombstone).

This second bug is separate from the main SoC-ID request above and specific to ExecuTorch's own code — flagging it here since it's what I hit while testing the workaround, but the primary ask remains: could SM8750P's soc_id=639 be added to the SoC-ID table, the same way 705 was?

tombstone_14.txt

[ivaylo681-dev]

@shewu-quic , @nil-is-all ,
I have updated few times the answer above, please re-check it and thank you for your cooperation!