Revert "hisilicon-opensdk: bump 7fa06b2 → 28a30ca (#2126)"#2128
Merged
Conversation
The bump pulled openhisilicon PR #178 (FEND event-type extension, ISP and MIPI RX edge-detect, ring/counter changes) into nightly images for every HiSilicon SoC in the matrix, but PR #178 was hardware- validated only on ev300 (V4 / IMX335) and av300 (cv500 / IMX415). On V2A / hi3518ev200, the changes inside kernel/isp/arch/hi3516cv200/ firmware/drv/isp.c shift ISP_ISR timing enough to surface a latent i2c-from-hardirq race (rt_mutex_trylock WARN at rtmutex.c:1545, sensor_i2c_write → i2c_transfer chain), and majestic can no longer read /image.jpg (HTTP 000, 10s timeout). The kernel itself stays alive — SSH works, sensor i2c just fails under contention — so cameras on a nightly build are recoverable, but the regression must stop shipping immediately. Pinning back to 7fa06b2 (the prior known-good opensdk version) until openhisilicon PR #178 / #179 are re-scoped to explicitly exclude SoCs without a hardware validation bench. Tracking re-land in openhisilicon, not here.
Merged
4 tasks
widgetii
added a commit
to OpenIPC/openhisilicon
that referenced
this pull request
May 23, 2026
…182) The hi3516cv200 family build also produces the firmware-shipped hi3518e_isp.ko for hi3518ev200 boards (same CHIPARCH=hi3516cv200, same open_isp.ko renamed at install time). The openipc_frame_ts_push call I added to the cv200 ISP_ISR in PR #178 adds a few µs to the ISR hot path which, on real hi3518ev200 hardware streaming with majestic, tips a latent i2c-from-hardirq race: kernel WARN at rtmutex.c:1545 via rt_mutex_trylock → hi_sensor_i2c_write → i2c_transfer; majestic loses sensor i2c and /image.jpg returns HTTP 000 / 10s timeout. Pre-existing backtrace surfaced by my timing shift; openipc/firmware nightly built and shipped the regression to V2A boards before it was caught. Comment out the cv200 ISP_ISR push call until: - the i2c-in-IRQ path is fixed upstream, OR - the hook is hardware-validated on both hi3516cv200 AND hi3518ev200 cameras under a real majestic stream. The chrdev /dev/openipc-frame-ts still loads cleanly on these SoCs, just emits no events; consumers see an empty stream and fall back to clock_gettime() (same as on a kernel without the modules). README updated to list hi3516cv200/hi3518ev200 as "not validated" with a full explanation of the i2c race and the re-enable criteria. Other SoC hooks (V4 ev200/ev300/gk7205v200, cv500/av300) are unchanged — they're hardware-validated and continue to fire. Tracking: OpenIPC/firmware#2128 reverted the opensdk bump that shipped the regression to nightly users. Co-authored-by: Your Name <you@example.com>
This was referenced May 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Urgent revert — nightly with #2126 bricked majestic on at least one hi3518ev200 (V2A) board: kernel WARN at `rtmutex.c:1545` (rt_mutex_trylock from inside ISP_ISR via `hi_sensor_i2c_write → i2c_transfer`), camera reachable via SSH but `curl http://localhost/image.jpg\` returns HTTP 000 / 10 s timeout.
The bump pulled in openhisilicon PR #178, which was hardware-validated only on hi3516ev300 (V4 / IMX335) and hi3516av300 (cv500 / IMX415). My changes inside `kernel/isp/arch/hi3516cv200/firmware/drv/isp.c` shift ISP_ISR timing enough to surface a latent i2c-from-hardirq race on V2A / hi3518ev200; backtrace is identical to a pre-existing issue, so the bug isn't strictly new, but my code is what tipped it past the threshold and that's enough to brick majestic on those boards.
Pin back to 7fa06b2 (prior known-good opensdk version) until PR #178 is re-scoped to explicitly exclude SoCs without a hardware-validation bench (V2A / hi3518e variants in particular).
Re-land plan tracked in openhisilicon, not here.