Public bug reported:
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.
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.
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
3. Decode it on venus:
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)
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
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.
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)
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).
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
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
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
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
MachineType: LENOVO 21BX001LGE
ProcEnviron:
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
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
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: arm64 resolute sc8280xp x13s
** Attachment added: "All evidence logs (redacted), see 00_INDEX.txt"
https://bugs.launchpad.net/bugs/2172673/+attachment/6013988/+files/x13s-venus-mmcx-evidence.tar.gz
--
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
