Repository navigation
apple_avd: H.264 decode jobs fail with order-10 page allocation failure in avd_init_job (green frames / stalled playback in Chrome) #628
Description
Summary
Since the AVD driver became available (linux-asahi 7.1.13.asahi3-1), H.264 hardware decoding fails intermittently and then consistently once memory is moderately fragmented. avd_init_job performs an order-10 (4 MB contiguous) kmalloc per decode job, which triggers warn_alloc page allocation failures. The decode job then never delivers frames.
User-visible symptoms in Chrome 153 (which picks up the new V4L2 stateless decoder for H.264):
- HLS/H.264 streams: solid green video with working audio
- Plain H.264 MP4 playback: player stuck at 0:00, spinner forever (the
<video>element hangs) - VP9/AV1 content (e.g. most of YouTube) is unaffected (software decode), which makes the issue look "random" to users
Hardware / versions
- Apple MacBook Pro (16-inch, M1 Pro, 2021) — MacBookPro18,1 / J316s
- linux-asahi 7.1.13.asahi3-1
- mesa 26.1.8-1
- google-chrome 153.0.8010.47 (confirmed holding
/dev/video0open viafuser)
Reproduction
- Boot, use the machine normally for a while (fragmentation makes it reliable; on a fresh boot it may take longer).
google-chrome --user-data-dir=$(mktemp -d) --no-first-run --autoplay-policy=no-user-gesture-required "https://interactive-examples.mdn.mozilla.net/media/cc0-videos/flower.mp4"- Within ~15 s, dmesg shows the allocation failure below and the video never starts (or renders green for streaming H.264 content).
Reproduced multiple times; each H.264 playback attempt logs one trace.
dmesg
[ 6963.063490] ThreadPoolSingl: page allocation failure: order:10, mode:0x40dc0(GFP_KERNEL|__GFP_ZERO|__GFP_COMP), nodemask=(null)
[ 6963.063499] CPU: 4 UID: 1001 PID: 163183 Comm: ThreadPoolSingl Tainted: G S 7.1.13-3-1-ARCH #1
[ 6963.063501] Tainted: [S]=CPU_OUT_OF_SPEC
[ 6963.063502] Hardware name: Apple Inc. MacBookPro18,1/J316s, BIOS 2026.07 07/01/2026
[ 6963.063503] Call trace:
[ 6963.063503] show_stack+0x18/0x24 (C)
[ 6963.063509] dump_stack_lvl+0x5c/0x7c
[ 6963.063511] dump_stack+0x18/0x24
[ 6963.063513] warn_alloc+0x118/0x1a0
[ 6963.063516] __alloc_frozen_pages_noprof+0xa1c/0x13a8
[ 6963.063519] ___kmalloc_large_node+0xd4/0x100
[ 6963.063520] __kmalloc_large_node_noprof+0x28/0x198
[ 6963.063521] __kmalloc_noprof+0x36c/0x448
[ 6963.063523] avd_init_job+0x2c/0x54 [apple_avd]
[ 6963.063527] avd_h264_run+0x918/0x18f4 [apple_avd]
[ 6963.063529] avd_device_run+0x48/0x108 [apple_avd]
[ 6963.063530] v4l2_m2m_try_run+0x80/0x13c [v4l2_mem2mem]
[ 6963.063533] v4l2_m2m_request_queue+0xdc/0x130 [v4l2_mem2mem]
[ 6963.063535] media_request_ioctl+0x178/0x430 [mc]
[ 6963.063539] __arm64_sys_ioctl+0x2ec/0xad4
Analysis
avd_init_job allocates a large per-job buffer with plain kmalloc (order-10 → 4 MB contiguous). Under normal desktop uptime, physically contiguous 4 MB chunks are frequently unavailable, so the allocation fails and the queued job is never completed — the m2m context stalls and userspace waits forever (Chrome's media pipeline hangs or composites empty/green frames). A kvmalloc/vmalloc or a preallocated/DMA pool for this buffer would avoid the failure mode entirely; failing that, the driver should fail the job cleanly so userspace can fall back to software decoding instead of hanging.
Workaround
--disable-accelerated-video-decode in Chrome restores software decoding and fully resolves the user-visible issue.
Activity
sofus13 commentedon Sep 17, 2026
#615 would likely fix it. The chrome thing is also likely a user space issue. Please dont use llms to generate issues for you
thijsbrilleman commentedon Sep 17, 2026
Confirming this on an M1 Max (MacBookPro18,1 / J316s), linux-asahi 7.1.13.asahi3-1, with the same
avd_init_joborder-10 trace. Two things to add.VP9 is also affected, contrary to "VP9/AV1 content is unaffected (software decode)". AVD advertises a VP9 path (
v4l2_vp9is loaded and held byapple_avd) and Chrome takes it:A solid-magenta VP9 clip renders green, and
--disable-accelerated-video-decodefixes it. VP9 on YouTube may look unaffected because a lot of what YouTube serves is AV1, which has no AVD path.The VP9 failure may be a second mechanism. In my VP9 runs the frames come back zeroed with no
warn_alloctrace indmesgat all, while the H.264 runs log one allocation failure per playback attempt. So fixing the order-10 allocation may not be sufficient for VP9.On method: a solid-colour clip makes this measurable rather than subjective, since the whole frame is one known value and a screenshot can be measured.
ffmpeg -y -f lavfi -i "color=c=#FF00FF:s=640x480:d=10,format=yuv420p" \ -c:v libx264 -pix_fmt yuv420p /tmp/magenta.mp4I measured RGB(0,124,0) where magenta was expected, which is what an all-zero YUV buffer gives through the YUV->RGB conversion — consistent with the job never delivering frames rather than delivering wrong ones.
Two controls that may save others time:
--disable-gpuand--use-angle=swiftshader, so it is not Mesa, the GPU driver or the compositor.Separately, this reaches more users than it might appear:
google-chromeon Arch Linux ARM ships with VA-API enabled and picks up AVD automatically, so on distributions that installlibva-v4l2_request-avdby default all H.264/VP9 video in Chrome breaks with no user action. Filed downstream at omacom/omarchy#12317.