** Description changed:
+ SRU Justification:
+
+ [ Impact ]
+ On the Lenovo ThinkPad X13s (SC8280XP), the Ubuntu SAUCE venus enablement
never votes the MMCX rail, and since 7.0.0-38 not MX either. Its OPP table is
written in the wrong clock's units and starts the decoder at 533 MHz. The first
hardware video decode (Firefox via V4L2-M2M, ffmpeg h264_v4l2m2m) makes the
venus firmware fault (arm-smmu context fault), hang and storm its IRQ. The
machine then hard-resets when the screen blanks, sometimes immediately. Unsaved
work is lost.
+ Workaround: blacklist venus_core/venus_dec/venus_enc (no hardware video
decoding).
+
+ [ Fix ]
+ Four UBUNTU: SAUCE patches. They are SAUCE because the venus SC8280XP
enablement itself is SAUCE (LP: #2078929), and upstream drives SC8280XP with
the iris driver since v7.3-rc1 (3a52eef16b97).
+ - binding: allow the mmcx power domain (as upstream ab128251dace does for
SM8250);
+ - driver: attach mx and mmcx (as f45fd3dbb5f6 does for SM8250);
+ - driver: use vcodec0_core as the OPP clock;
+ - DT: add MMCX and use the upstream iris SC8280XP OPP table.
+
+ [ Test Plan ]
+ On an X13s, on a fresh boot.
+ Clips: ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 3 -c:v libx264
-pix_fmt yuv420p 1080p30.mp4; make the same with size=3840x2160:rate=60, and a
20 s 1080p30 clip (-t 20).
+ 1. Check that venus probed: the venus decoder is listed in
/sys/class/video4linux/*/name, and dmesg shows no venus probe error.
+ 2. Decode with ffmpeg -re -c:v h264_v4l2m2m -i <clip> -f null - : first
1080p30, then 2160p60. Also decode 2x 2160p60 in parallel without -re, to reach
the 444 MHz OPP. Expected: all frames, and no "corrupt decoded frame" in the
-re runs.
+ 3. During step 2, /sys/kernel/debug/pm_genpd/pm_genpd_summary lists
aa00000.video-codec under mx and mmcx with non-zero levels.
+ 4. Decode the 20 s 1080p30 clip with -re and turn the display off after 4 s
for 12 s. Then turn the display off for 60 s with venus idle.
+ Expected: no "context fault" or "idle fail", runtime_status returns to
"suspended", and the machine does not reset. On the stock kernel the first
decode faults or resets the machine, and a display-off after the fault resets
it.
+ Known, and not a failure: decoding much faster than real time (no -re) at the
lowest OPP can give corrupt frames (see the bug).
+
+ [ Where problems could occur ]
+ Only sc8280xp.dtsi uses qcom,sm8350-venus, and only the X13s enables it. The
driver change adds an optional opp_clk_name field to the common venus
resources. It is set only for sm8350/sc8280xp; all other platforms keep "core".
+ On the X13s, venus could:
+ - fail to probe, for example with a user-supplied old DTB (the packaged
kernel embeds the matching DTB);
+ - decode or encode more slowly than before, because the clocks are lower;
+ - produce corrupt frames when decoding faster than real time at the lowest
OPP (see the bug).
+ The encoder and suspend/resume share the changed OPP path and were not tested.
+
+ [ Other Info ]
+ Tested on one X13s, in one boot, with H.264 only, using out-of-tree modules
and the test DTB (stubble.dtb_override=false). The encoder, VP9/HEVC, Firefox
playback, suspend/resume and the 533/560 MHz OPPs were not tested.
+ The current stable release 26.10 (linux 7.3) uses the upstream iris node for
the X13s (3a52eef16b97) and not the venus SM8350 SAUCE resources, so this SRU
is for resolute only. This was checked in the stonking git; 27.04 was not
checked.
+
+ ===
+
SUMMARY
On the Lenovo ThinkPad X13s (Qualcomm SC8280XP), the Ubuntu-only venus
video decoder enablement never votes for the MMCX power rail. The video
core's GDSCs (mvs0c/mvs0) are MMCX subdomains, and in our measurements
MMCX was held up only by the display controllers.
A hardware video decode (Firefox uses venus via V4L2-M2M; or ffmpeg
h264_v4l2m2m) then either:
- (a) triggers an SMMU fault from the venus firmware, after which the
firmware hangs, runtime PM goes into "error" and the venus IRQ storms on CPU0;
the machine hard-resets later, reliably within ~1 s when the display blanks; or
- (b) hard-resets the machine immediately, about 0.1 s after the decoder
powers on.
+ (a) triggers an SMMU fault from the venus firmware, after which the
firmware hangs, runtime PM goes into "error" and the venus IRQ storms on CPU0;
the machine hard-resets later, reliably within ~1 s when the display blanks; or
+ (b) hard-resets the machine immediately, about 0.1 s after the decoder
powers on.
Hard resets leave no panic, no log entry and an empty pstore. Unsaved work is
lost.
With MMCX held at RPMh level NOM (256) by an out-of-tree test module, 3
of 3 decodes on fresh boots were clean, and the machine survived a 60 s
display-off in each case. Holding only MX did not help (n=1). Details
and limits are below.
Labels used: [measured] = observed on this machine in the attached logs;
[inferred] = from code reading or timing, not directly measured.
-
SYSTEM
- Hardware: Lenovo ThinkPad X13s, 21BX001LGE, BIOS N3HET95W (1.67)
12/11/2025 [from dmesg DMI line]
- Release: Ubuntu 26.04.1 LTS (resolute)
- Kernel: 7.0.0-42-generic (7.0.0-42.42); the same fault is also in the
logs of 7.0.0-28 and 7.0.0-30
- Cmdline: clk_ignore_unused pd_ignore_unused arm64.nopauth (plus
defaults). Note: pd_ignore_unused/clk_ignore_unused affect genpd/clock
behaviour.
- Firmware: qcom/sc8280xp/LENOVO/21BX/qcvss8280.mbn, linux-firmware
20260319.git217ca6e4.1ubuntu;
QC_IMAGE_VERSION_STRING=video-firmware.1.1-b158087140355883dc40b004032856a8feb5d565,
BUILD_DATE Jun 20 2023 (installed file identical to upstream linux-firmware,
sha256 187d9ebe0bb015a6...)
- Browsers: Firefox 151.0.2 (snap), Chromium 150.0.7871.128 (snap); ffmpeg
7:8.0.1-3ubuntu2+esm5
- Desktop: GNOME (Wayland), idle-delay 300 s (screen blanks after 5 min),
automatic suspend on AC disabled
- Power: on AC with a full battery during all tests (makes a
battery-side supply problem unlikely)
- Code origin: the venus SC8280XP enablement (DT node video-codec@aa00000,
sm8350_res/sc8280xp_res in drivers/media/platform/qcom/venus/core.c) is Ubuntu
SAUCE (LP: #2078929), not upstream. The X13s DT uses compatible
"qcom,sm8350-venus", so sm8350_res is the struct in use.
-
+ Hardware: Lenovo ThinkPad X13s, 21BX001LGE, BIOS N3HET95W (1.67)
12/11/2025 [from dmesg DMI line]
+ Release: Ubuntu 26.04.1 LTS (resolute)
+ Kernel: 7.0.0-42-generic (7.0.0-42.42); the same fault is also in the
logs of 7.0.0-28 and 7.0.0-30
+ Cmdline: clk_ignore_unused pd_ignore_unused arm64.nopauth (plus
defaults). Note: pd_ignore_unused/clk_ignore_unused affect genpd/clock
behaviour.
+ Firmware: qcom/sc8280xp/LENOVO/21BX/qcvss8280.mbn, linux-firmware
20260319.git217ca6e4.1ubuntu;
QC_IMAGE_VERSION_STRING=video-firmware.1.1-b158087140355883dc40b004032856a8feb5d565,
BUILD_DATE Jun 20 2023 (installed file identical to upstream linux-firmware,
sha256 187d9ebe0bb015a6...)
+ Browsers: Firefox 151.0.2 (snap), Chromium 150.0.7871.128 (snap); ffmpeg
7:8.0.1-3ubuntu2+esm5
+ Desktop: GNOME (Wayland), idle-delay 300 s (screen blanks after 5 min),
automatic suspend on AC disabled
+ Power: on AC with a full battery during all tests (makes a
battery-side supply problem unlikely)
+ Code origin: the venus SC8280XP enablement (DT node video-codec@aa00000,
sm8350_res/sc8280xp_res in drivers/media/platform/qcom/venus/core.c) is Ubuntu
SAUCE (LP: #2078929), not upstream. The X13s DT uses compatible
"qcom,sm8350-venus", so sm8350_res is the struct in use.
STEPS TO REPRODUCE
WARNING: save your work. Step 3 can hard-reset the machine immediately.
Prerequisites: ffmpeg with libx264 and h264_v4l2m2m (Ubuntu's ffmpeg has
both); a GNOME Wayland session; Firefox/Chromium closed, because they
may already have used venus.
1. Boot fresh, with no hardware video decode since boot (check: "grep venus
/proc/interrupts" shows only a handful of interrupts).
2. Create a clip:
- ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 3 -c:v libx264
-pix_fmt yuv420p clip.mp4
+ ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 3 -c:v libx264
-pix_fmt yuv420p clip.mp4
3. Decode it on venus:
- timeout -k 5 60 ffmpeg -nostdin -c:v h264_v4l2m2m -i clip.mp4 -f null -
+ timeout -k 5 60 ffmpeg -nostdin -c:v h264_v4l2m2m -i clip.mp4 -f null -
4. Confirm the fault:
- sudo dmesg | grep -E 'context fault|idle fail'
- cat /sys/bus/platform/devices/aa00000.video-codec/power/runtime_status
(shows "error")
- grep venus /proc/interrupts; sleep 1; grep venus /proc/interrupts
(count rises by ~200k/s)
+ sudo dmesg | grep -E 'context fault|idle fail'
+ cat /sys/bus/platform/devices/aa00000.video-codec/power/runtime_status
(shows "error")
+ grep venus /proc/interrupts; sleep 1; grep venus /proc/interrupts
(count rises by ~200k/s)
5. Only after a fault: blank the display, either by waiting 5 min idle or, as
the session user (not via sudo):
- busctl --user set-property org.gnome.Mutter.DisplayConfig
/org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 3
+ busctl --user set-property org.gnome.Mutter.DisplayConfig
/org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 3
To watch the rails: sudo cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
| grep -A12 '^mmcx'
-
ACTUAL RESULT
Variant (a), step 3 [measured, attachment 02]: 0 frames decoded, and
- arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
iova=0x00000400, fsynr=0x110001, cbfrsynra=0x2a00, cb=3
- qcom-venus aa00000.video-codec: wait for cpu and video core idle fail
(-110)
- - runtime_status becomes "error" and stays there; the firmware stays hung
and powered [measured].
- - The venus IRQ (DT: GIC SPI 174 level = hwirq 206 in /proc/interrupts)
fires ~207-212k/s on CPU0 (CPU0 97-98 % system time) until the reset; observed
for 34-55 min [measured, attachment 08].
- - Faulting iovas seen: 0x0, 0x400, 0x100000, 0x100c00, 0x99493c10 (4
times), 0x1949bc10, 0x19493c10 [measured]. The driver's own mappings start at
0xdfa00000 (top-down IOVA allocation) [measured in a traced run]. The values
near 0 lie in the CP region (cp_size 0x25800000) [inferred]. 0x1949bc10 and
0x19493c10 differ from 0x99493c10 by one or two bits [measured]; whether this
is caused by the low voltage is speculation.
+ arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
iova=0x00000400, fsynr=0x110001, cbfrsynra=0x2a00, cb=3
+ qcom-venus aa00000.video-codec: wait for cpu and video core idle fail
(-110)
+ - runtime_status becomes "error" and stays there; the firmware stays hung
and powered [measured].
+ - The venus IRQ (DT: GIC SPI 174 level = hwirq 206 in /proc/interrupts)
fires ~207-212k/s on CPU0 (CPU0 97-98 % system time) until the reset; observed
for 34-55 min [measured, attachment 08].
+ - Faulting iovas seen: 0x0, 0x400, 0x100000, 0x100c00, 0x99493c10 (4
times), 0x1949bc10, 0x19493c10 [measured]. The driver's own mappings start at
0xdfa00000 (top-down IOVA allocation) [measured in a traced run]. The values
near 0 lie in the CP region (cp_size 0x25800000) [inferred]. 0x1949bc10 and
0x19493c10 differ from 0x99493c10 by one or two bits [measured]; whether this
is caused by the low voltage is speculation.
Variant (b) [measured, 2 of 2 runs with ftrace and venus dynamic debug
enabled]: the machine hard-reset ~0.1 s after decoder power-on (last
trace events: venus genpd/GDSC/clock enable, "venus hw version
6.10.608", first buffer mappings). No fault line was logged, because the
logs were lost in the reset.
Step 5 [measured]: in the stock run, the machine hard-reset within ~1 s
of display-off (attachment 03; the reset came before the next 1 s rails
sample). In the MX-only run (attachment 05), the 1 s sample right after
display-off caught MMCX falling from 128 (SVS, set by the display) to 64
(LOW_SVS, videocc's own vote), and then the machine reset. Two earlier
resets that day came ~5 min after the last user activity, which matches
the GNOME idle blank [inferred from timing].
-
EXPECTED RESULT
The decode works, and blanking the display has no effect.
-
ANALYSIS
pm_genpd_summary on the stock kernel before decoding [measured, attachment
01]:
- mx on 0 only aec5a00.phy attached; aa00000.video-codec is NOT
attached
- mmcx on 128 aea0000.displayport-controller 128,
ae01000.display-controller 64;
- videocc abf0000 suspended (votes 64 only while venus is
powered);
- subdomains include mvs0c_gdsc and mvs0_gdsc
- - Venus never votes MMCX: the DT node lists only "venus", "vcodec0", "mx",
and sm8350_res names only "mx" [measured + source].
- - Since 7.0.0-38, MX isn't voted either. The stable backport f45fd3dbb5f6
("media: venus: scale MMCX power domain on SM8250", in the 2026-08-20 stable
update, LP: #2164666) made pm_helpers use res->opp_pmdomain_num. Ubuntu's
sm8350_res/sc8280xp_res don't set it, so it is 0 and "mx" is never attached
[source; "mx" unattached on -42 is measured]. That is a separate regression,
but not the cause here: the fault also occurs on 7.0.0-28/-30, where MX was
voted [from source, not measured].
- - The fault occurred with MMCX already aggregated at SVS (128) because of
the display [measured]. So SVS was not enough, and only NOM (256) was shown to
work.
-
-
- EXPERIMENTS (original Ubuntu venus driver; out-of-tree test module
"venus_vote", source attached)
+ mx on 0 only aec5a00.phy attached; aa00000.video-codec is NOT
attached
+ mmcx on 128 aea0000.displayport-controller 128,
ae01000.display-controller 64;
+ videocc abf0000 suspended (votes 64 only while venus is
powered);
+ subdomains include mvs0c_gdsc and mvs0_gdsc
+ - Venus never votes MMCX: the DT node lists only "venus", "vcodec0", "mx",
and sm8350_res names only "mx" [measured + source].
+ - Since 7.0.0-38, MX isn't voted either. The stable backport f45fd3dbb5f6
("media: venus: scale MMCX power domain on SM8250", in the 2026-08-20 stable
update, LP: #2164666) made pm_helpers use res->opp_pmdomain_num. Ubuntu's
sm8350_res/sc8280xp_res don't set it, so it is 0 and "mx" is never attached
[source; "mx" unattached on -42 is measured]. That is a separate regression,
but not the cause here: the fault also occurs on 7.0.0-28/-30, where MX was
voted [from source, not measured].
+ - The fault occurred with MMCX already aggregated at SVS (128) because of
the display [measured]. So SVS was not enough, and only NOM (256) was shown to
work.
+
+ EXPERIMENTS (original Ubuntu venus driver; out-of-tree test module
+ "venus_vote", source attached)
venus_vote holds RPMh performance votes: MX by attaching the venus
node's "mx" domain; MMCX by dev_pm_genpd_set_performance_state() on
videocc abf0000, which it also keeps runtime-active.
- Votes held First HW decode Display off 60
s (after the decode)
- none (stock) SMMU fault + hang: 2 of 4 runs (12:07, hard reset:
1/1 measured (16:30:54);
- 16:23; neither on a fresh boot) 2 more resets
match the 5 min idle
- immediate hard reset, no fault logged: blank by
timing [inferred]
- 2 of 4 runs (16:01, 16:06; ftrace+dyndbg)
- MX+MMCX @256 clean 2/2 (90/90 frames, runtime suspend survived 2/2
- OK, ~200 IRQs, no storm)
- MMCX @256 only clean 1/1 survived 1/1
- MX @256 only SMMU fault 1/1 (iova 0x19493c10, 0 frames) hard reset 1/1
(MMCX 128 -> 64 captured)
-
- All voted runs and the MX-only run were on fresh boots, each with one 3 s
1080p30 H.264 clip.
- Not tested: Firefox playback with the vote, long playback, VP9/HEVC/4K,
several sessions at once, suspend/resume.
- Not separated: the MMCX level itself vs. videocc being kept runtime-active
by the module (no level=0/64/128 control run).
-
+ Votes held First HW decode Display off 60
s (after the decode)
+ none (stock) SMMU fault + hang: 2 of 4 runs (12:07, hard reset:
1/1 measured (16:30:54);
+ 16:23; neither on a fresh boot) 2 more resets
match the 5 min idle
+ immediate hard reset, no fault logged: blank by
timing [inferred]
+ 2 of 4 runs (16:01, 16:06; ftrace+dyndbg)
+ MX+MMCX @256 clean 2/2 (90/90 frames, runtime suspend survived 2/2
+ OK, ~200 IRQs, no storm)
+ MMCX @256 only clean 1/1 survived 1/1
+ MX @256 only SMMU fault 1/1 (iova 0x19493c10, 0 frames) hard reset 1/1
(MMCX 128 -> 64 captured)
+
+ All voted runs and the MX-only run were on fresh boots, each with one 3 s
1080p30 H.264 clip.
+ Not tested: Firefox playback with the vote, long playback, VP9/HEVC/4K,
several sessions at once, suspend/resume.
+ Not separated: the MMCX level itself vs. videocc being kept runtime-active
by the module (no level=0/64/128 control run).
HISTORY ON THIS MACHINE [measured, attachment 09]
From /var/log/syslog*, 2026-07-28 to 2026-10-31: 13 SMMU faults with the
same signature, plus one "idle fail (-110)" without an SMMU fault
(2026-09-01 07:55), on 7.0.0-28, -30 and -42. All 14 were followed by an
unclean reset (no system shutdown before the next boot) 5-118 min later.
Four of them were preceded by qcom-battmgr "-110" property timeouts, RCU
expedited stalls and hung tasks (attachment 10). So resets also happen
during use, not only when the display blanks. The mechanism of that path
is unknown [inferred].
-
IMPACT
On an X13s with default GNOME settings, playing an H.264/VP8/VP9/HEVC video
in Firefox can trigger the fault: Firefox decodes through V4L2-M2M/venus
because VA-API is unavailable [verified on this machine with MOZ_LOG and
about:support]. The machine then hard-resets the next time the screen blanks,
sometimes sooner, including during use. Unsaved work is lost. This happened 14
times in 3 months on this machine.
Not verified: whether Firefox enables hardware decoding by default on a clean
profile; other browsers.
-
SUGGESTED FIX
- Add MMCX to the venus node (power-domains: <&rpmhpd SC8280XP_MMCX>,
power-domain-names: "mmcx"). Set .opp_pmdomain = { "mx", "mmcx" } and
.opp_pmdomain_num = 2 in sm8350_res (and sc8280xp_res), as f45fd3dbb5f6 does
for SM8250.
- Caveat: only NOM was shown to work, and SVS (128) was not enough. The
current SAUCE OPP table (720 MHz-1.332 GHz, required-opps LOW_SVS..NOM) differs
from the upstream iris SC8280XP table (240-560 MHz, up to TURBO_L1) and may
need correcting. Please verify a fix with the decode + display-off test above.
- At minimum, set .opp_pmdomain_num for the Ubuntu-only resources, to undo
the 7.0.0-38 MX regression.
- Longer term: upstream enables SC8280XP video on the iris driver (v7.3-rc1,
votes MX and MMCX). Consider switching to iris instead of carrying the venus
SAUCE patches.
- Robustness: on IRIS2, venus_isr() doesn't write WRAPPER_INTR_CLEAR (this is
upstream behaviour, also for SM8250), and the watchdog status bit is never
handled. After the hang, the level IRQ fires continuously [measured]; we
suspect the watchdog interrupt stays asserted [inferred]. The driver also never
recovers a firmware that hangs without sending SYS_ERROR.
-
WORKAROUND
Disable venus: /etc/modprobe.d/blacklist-venus.conf containing
- blacklist venus_core
- blacklist venus_dec
- blacklist venus_enc
- install venus_core /bin/false
- install venus_dec /bin/false
- install venus_enc /bin/false
+ blacklist venus_core
+ blacklist venus_dec
+ blacklist venus_enc
+ install venus_core /bin/false
+ install venus_dec /bin/false
+ install venus_enc /bin/false
then "sudo update-initramfs -u" and reboot. Verified here: no venus nodes,
h264_v4l2m2m fails harmlessly, and display-off is survived. Alternatively,
disable hardware decoding in the browser (Firefox:
media.hardware-video-decoding.enabled=false).
This report was filed with venus blacklisted, so the apport logs from
the current boot contain no venus fault; the fault logs are in the
attachments.
-
- ATTACHMENTS (personal data redacted: MACs, UUIDs, serial numbers, IPs,
username)
-
- 01_pm_genpd_summary_stock_before_decode.txt rails and clocks before a
decode, stock kernel
- 02_dmesg_stock_fault_run.log stock fault run (iova 0x400).
Note: not a fresh boot; venus fw_level=0x3f and dyndbg on hfi_venus.c (151
empty "VenusFW :" lines); IRQ moved to CPU7 before the display-off
- 03_rails_stock_display_off_until_reset.log stock run: mx 0 / mmcx 128 up
to "display OFF", then reset
- 04_dmesg_mx-only_run.log, 05_rails_mx-only_run_until_reset.log,
05b_decode_mx-only_run.log
- MX-only run: fault, 0 frames,
MMCX 128 -> 64, reset
- 06_dmesg_clean_run_mx+mmcx.log, 06b_decode_clean_run_mx+mmcx.log,
06c_rails_clean_run_mx+mmcx_display_off.log
- clean run with both rails
held: 90/90 frames, display-off survived
- 07_rails_mmcx-only_run_survived.log, 07b_decode_mmcx-only_run.log
- MMCX-only run: clean,
display-off survived
- 08_irq_storm_samples.txt /proc/interrupts samples of
the IRQ storm
- 09_history_faults_table.txt all 14 historical events,
with criteria
- 10_excerpt_2026-09-01_battmgr_rcu_hung.txt reset during use, preceded by
battmgr/RCU/hung-task messages
- 11_venus_vote.c the test module
+ ATTACHMENTS (personal data redacted: MACs, UUIDs, serial numbers, IPs,
+ username)
+
+ 01_pm_genpd_summary_stock_before_decode.txt rails and clocks before a
decode, stock kernel
+ 02_dmesg_stock_fault_run.log stock fault run (iova 0x400).
Note: not a fresh boot; venus fw_level=0x3f and dyndbg on hfi_venus.c (151
empty "VenusFW :" lines); IRQ moved to CPU7 before the display-off
+ 03_rails_stock_display_off_until_reset.log stock run: mx 0 / mmcx 128 up
to "display OFF", then reset
+ 04_dmesg_mx-only_run.log, 05_rails_mx-only_run_until_reset.log,
05b_decode_mx-only_run.log
+ MX-only run: fault, 0 frames,
MMCX 128 -> 64, reset
+ 06_dmesg_clean_run_mx+mmcx.log, 06b_decode_clean_run_mx+mmcx.log,
06c_rails_clean_run_mx+mmcx_display_off.log
+ clean run with both rails
held: 90/90 frames, display-off survived
+ 07_rails_mmcx-only_run_survived.log, 07b_decode_mmcx-only_run.log
+ MMCX-only run: clean,
display-off survived
+ 08_irq_storm_samples.txt /proc/interrupts samples of
the IRQ storm
+ 09_history_faults_table.txt all 14 historical events,
with criteria
+ 10_excerpt_2026-09-01_battmgr_rcu_hung.txt reset during use, preceded by
battmgr/RCU/hung-task messages
+ 11_venus_vote.c the test module
Related: LP: #2078929 (X13s venus enablement), LP: #2164666 (stable
update containing f45fd3dbb5f6). Similar user reports:
https://discourse.ubuntu.com/t/status-of-ubuntu-support-for-lenovo-
thinkpad-x13s/44652 (posts #299, #305/#307, #362-#366) and "X13s and
26.04LTS: opening Mouse & Touchpad settings causes instant system
crash". Upstream note on hard resets with the old venus patches on X13s:
https://lkml.iu.edu/2604.0/06208.html
-
TRANSPARENCY NOTE
The analysis, scripts and test module were written with the help of
Claude Code, an AI coding assistant. All measurements were made on the
affected X13s, and the logs are attached. Statements marked [inferred]
come from code reading or timing, not direct measurement.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: linux-image-7.0.0-42-generic 7.0.0-42.42
ProcVersionSignature: Ubuntu 7.0.0-42.42-generic 7.0.14
Uname: Linux 7.0.0-42-generic aarch64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: arm64
AudioDevicesInUse:
- USER PID ACCESS COMMAND
- /dev/snd/controlC0: oliver 4779 F.... pipewire
- oliver 5452 F.... wireplumber
- /dev/snd/seq: oliver 4779 F.... pipewire
+ USER PID ACCESS COMMAND
+ /dev/snd/controlC0: oliver 4779 F.... pipewire
+ oliver 5452 F.... wireplumber
+ /dev/snd/seq: oliver 4779 F.... pipewire
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Sat Oct 31 17:59:34 2026
EcryptfsInUse: Yes
Lspci-vt:
- -[0002:00]---00.0-[01-ff]----00.0 Shenzhen Unionmemory Information System
Ltd. AM630 PCIe 4.0 x4 NVMe SSD Controller
- -[0004:00]---00.0-[01-ff]----00.0 Foxconn International, Inc. T99W175 5G
Modem [Snapdragon X55]
- -[0006:00]---00.0-[01-ff]----00.0 Qualcomm Technologies, Inc QCNFA765
Wireless Network Adapter
+ -[0002:00]---00.0-[01-ff]----00.0 Shenzhen Unionmemory Information System
Ltd. AM630 PCIe 4.0 x4 NVMe SSD Controller
+ -[0004:00]---00.0-[01-ff]----00.0 Foxconn International, Inc. T99W175 5G
Modem [Snapdragon X55]
+ -[0006:00]---00.0-[01-ff]----00.0 Qualcomm Technologies, Inc QCNFA765
Wireless Network Adapter
MachineType: LENOVO 21BX001LGE
ProcEnviron:
- LANG=en_US.UTF-8
- PATH=(custom, no user)
- SHELL=/bin/bash
- TERM=xterm-256color
- XDG_RUNTIME_DIR=<set>
+ LANG=en_US.UTF-8
+ PATH=(custom, no user)
+ SHELL=/bin/bash
+ TERM=xterm-256color
+ XDG_RUNTIME_DIR=<set>
ProcFB: 0 msmdrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-42-generic
root=UUID=abdbc5b6-1e07-49fc-958b-6f1411c26f68 ro clk_ignore_unused
pd_ignore_unused arm64.nopauth quiet splash
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
SourcePackage: linux
UpgradeStatus: Upgraded to resolute on 2026-07-27 (96 days ago)
acpidump:
-
+
dmi.bios.date: 12/11/2025
dmi.bios.release: 1.67
dmi.bios.vendor: LENOVO
dmi.bios.version: N3HET95W (1.67 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21BX001LGE
dmi.board.vendor: LENOVO
dmi.board.version:
- SDK0T76530 WIN
- ptal����8
+ SDK0T76530 WIN
+ ptal����8
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.24
dmi.modalias:
dmi:bvnLENOVO:bvrN3HET95W(1.67):bd12/11/2025:br1.67:efr1.24:svnLENOVO:pn21BX001LGE:pvrThinkPadX13sGen1:rvnLENOVO:rn21BX001LGE:rvrSDK0T76530WINptal8:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21BX_BU_Think_FM_ThinkPadX13sGen1:pfaThinkPadX13sGen1:
dmi.product.family: ThinkPad X13s Gen 1
dmi.product.name: 21BX001LGE
dmi.product.sku: LENOVO_MT_21BX_BU_Think_FM_ThinkPad X13s Gen 1
dmi.product.version: ThinkPad X13s Gen 1
dmi.sys.vendor: LENOVO
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172673
Title:
[X13s / SC8280XP] venus never votes MMCX: hardware video decode causes
SMMU fault, firmware hang and IRQ storm, followed by hard reset
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172673/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
