[BUG] IPC4: second concurrent compressed-offload stream fails with ENOMEM in module adapter output-buffer allocation

[naveen-manohar]

Summary

On PTL/WCL IPC4 device, a 2nd concurrent AAC compressed-offload stream fails in firmware while preparing the second graph.
The firmware trace shows the second graph being created, then failing with-ENOMEM while module_adapter allocates output buffers.

Platform

• Platform: Intel PTL/WCL

To Reproduce
Steps to reproduce the behavior: (e.g. list commands or actions used to reproduce the bug)

/data/cplay_aac_adts -c 0 -d 50 /data/Echoplex-10s.aac
/data/cplay_aac_adts -c 0 -d 52 /data/Echoplex-10s.aac

Reproduction Rate
How often does the issue happen ? i.e. 1/10 (once in ten attempts), 1/1000 or all the time.
ALL the Time 2nd compressed Stream Fails

Expected behavior
Both compressed streams Compr 50(Jack) & Compr 52(Amp) should be created, prepared, started, and stopped
successfully, or the failing userspace client should receive an error if the
second graph cannot be allocated.

/data/cplay_aac_adts -c 0 -d 50 /data/Echoplex-10s.aac'
Playing file /data/Echoplex-10s.aac On Card 0 device 52, with buffer of 0 bytes
Finish Playing.... Close Normally
Format 6 Channels 2, 48000 Hz, Bit Rate 0

Actual Result

/data/cplay_aac_adts -c 0 -d 52 /data/Echoplex-10s.aac'
Playing file /data/Echoplex-10s.aac On Card 0 device 52, with buffer of 0 bytes

console:/ # /data/cplay_aac_adts -c 0 -d 50 /data/Echoplex-10s.aac
Playing file /data/Echoplex-10s.aac On Card 0 device 50, with buffer of 0 bytes
Format 6 Channels 2, 48000 Hz, Bit Rate 0
Finish Playing.... Close Normally
data/cplay_aac_adts -c 0 -d 50 /data/Echoplex-10s.aac                         <
<4>[ 1606.252268][ T7533] Oops: invalid opcode: 0000 [#1] SMP NOPTI
<4>[ 1606.259405][ T7533] CPU: 3 UID: 0 PID: 7533 Comm: cplay_aac_adts Tainted: G     U     O        6.18.24-android17-5-maybe-dirty #1 PREEMPT  e253a8e89a4fd20be11005e5c363a8e
<4>[ 1606.278622][ T7533] Tainted: [U]=USER, [O]=OOT_MODULE
<4>[ 1606.284900][ T7533] Hardware name: Google Ocelot/Ocelot, BIOS Google_Ocelot.16602.0.0 03/06/2026
<4>[ 1606.295589][ T7533] RIP: 0010:sdw_compute_params+0x1244/0x1eb0 [soundwire_generic_allocation]
<4>[ 1606.305980][ T7533] Code: c1 e8 20 6e b7 c8 e9 db f9 ff ff 67 0f b9 80 9b 00 00 00 67 0f b9 40 52 67 0f b9 80 9d 00 00 00 67 0f b9 40 54 67 0f b9 40 68 <67> 0f b9 80 89 7
<4>[ 1606.329288][ T7533] RSP: 0018:ffff9a25e7acbbb0 EFLAGS: 00010297
<4>[ 1606.336594][ T7533] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000004
<4>[ 1606.346154][ T7533] RDX: 0000000000000000 RSI: ffff8e1937c46300 RDI: ffff8e1937c46178
<4>[ 1606.355702][ T7533] RBP: 0000000000000004 R08: 0000000000000004 R09: 0000000000000004
<4>[ 1606.365256][ T7533] R10: 000000000000bb80 R11: 0000000000000001 R12: 0000000000000001
<4>[ 1606.374812][ T7533] R13: ffff8e1937c46178 R14: ffff8e1937c463c8 R15: ffff8e193df77830
<4>[ 1606.384149][ T7533] FS:  00007e3025a05fb8(0000) GS:ffff8e1ae59d1000(0000) knlGS:0000000000000000
<4>[ 1606.394831][ T7533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 1606.402746][ T7533] CR2: 00007e2d8d9ee000 CR3: 0000000236c82003 CR4: 0000000100f72eb0
<4>[ 1606.412299][ T7533] PKRU: 55555554
<4>[ 1606.416627][ T7533] Call Trace:
<4>[ 1606.420648][ T7533]  <TASK>
<4>[ 1606.424259][ T7533]  sdw_prepare_stream+0x15c/0x2e0 [soundwire_bus 2fa06e0b90a83bee6722393e778abe6f3d827f46]
<4>[ 1606.435937][ T7533]  snd_soc_link_prepare+0x35/0x60
<4>[ 1606.442011][ T7533]  __soc_pcm_prepare+0x16/0xf0
<4>[ 1606.447771][ T7533]  dpcm_be_dai_prepare+0x136/0x180
<4>[ 1606.453944][ T7533]  soc_compr_set_params_fe+0xf5/0x1c0
<4>[ 1606.460419][ T7533]  snd_compr_ioctl+0x12bf/0x1670
<4>[ 1606.466391][ T7533]  ? selinux_file_ioctl+0x144/0x370
<4>[ 1606.472668][ T7533]  __se_sys_ioctl+0x7a/0xd0
<4>[ 1606.478127][ T7533]  do_syscall_64+0x61/0xf10
<4>[ 1606.483462][ T7533]  ? arch_exit_to_user_mode_prepare+0x9/0xe0
<4>[ 1606.490497][ T7533]  asm_fred_entrypoint_user+0x41/0x41
<4>[ 1606.496976][ T7533] RIP: 0033:0x7e301e713ddf

Firmware Trace Evidence
The second graph is created as pipelines 2 and 3. DMA reference count reaches 2:

[22.275625] <inf> [core 0] pipe.pipeline_new:  pipeline new pipe_id 2 priority 0
[22.276050] <inf> [core 0] dma.z_impl_sof_dma_get:  dma_get() ID 0 sref = 2 busy channels 0
[22.279943] <inf> [core 0] pipe.pipeline_new:  pipeline new pipe_id 3 priority 0
[22.282213] <inf> [core 0] dma.z_impl_sof_dma_get:  dma_get() ID 0 sref = 2 busy channels 0

Prepare of the second graph then fails: -12 is ENOMEM

[22.294535] <err> [core 0] module_adapter.module_adapter_prepare:  comp:2 0x11005 failed to allocate output buffers
[22.294540] <err> [core 0] pipe.pipeline_prepare:  pipe:2 0x0 ret = -12, dev->comp.id = 0x40003
[22.294543] <err> [core 0] ipc.ipc4_pcm_params:  ipc: pipe 2 comp 0 prepare failed -12
[22.294673] <err> [core 0] ipc.ipc_cmd:  ipc4: FW_GEN_MSG failed with err 7

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
While 1st Compr Stream runs 2nd compr one is not allowed to run and will Fail for usecases like Video Conference

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

• IPC: IPC4
• Kernel: 6.18.24-android17-5-maybe-dirty Google Tree, Ported Compr Patches from sof-dev-rebase
• Firmware: sof-wcl.ri_ipc4_compr_20260811_01 from main branch
• Trace source: /sys/kernel/debug/sof/mtrace/core0

SOF:v2.14-pre-rc-1215-ge9747dd83a2d
Branch: sof/main Commit: 331b37851a1fe6f936bc554964fa86c522d6123a
zephyr:v4.4.0-9180-g9885b002c1bd
src hash 0x3e3ba1c8
2) Name of the topology file
    * Topology: sof-sdca-amp-compr.tplg, sof-sdca-jack-compr.tplg
3) Name of the platform(s) on which the bug is observed.
    * Platform: WCL-RVP

**Screenshots or console output**
If applicable, add a screenshot (drag-and-drop an image), or console logs
(cut-and-paste text and put a code fence (\`\`\`) before and after, to help
explain the issue.

Please also include the relevant sections from the firmware log and kernel log in the report (and attach the full logs for complete reference). Kernel log is taken from *dmesg* and firmware log from *sof-logger*. See 

This trace does not show a cadence_codec_init_memory_tables allocation failure.
The failure occurs earlier, in module_adapter_prepare, while component 0x11005 allocates output buffers for the second compressed graph.
But @ujfalusi observed this at his end
`[ 6823.619151] <err> [core 1] cadence_codec.cadence_codec_init_memory_tables: comp:2 0x10004 error 0: failed to allocate memory for 1`

This appears to be insufficient DSP heap/buffer capacity for two simultaneous
compressed-offload graphs, or an incorrect topology/module memory reservation for the second graph.

**LOG PFA**
[cplay_d50.log](https://github.com/user-attachments/files/31058213/cplay_d50.log)
[cplay_d52.log](https://github.com/user-attachments/files/31058211/cplay_d52.log)
[dmesg_before.txt](https://github.com/user-attachments/files/31058214/dmesg_before.txt)
[dmesg_live_host.log](https://github.com/user-attachments/files/31058212/dmesg_live_host.log)
[firmware_mtrace_host.log](https://github.com/user-attachments/files/31058209/firmware_mtrace_host.log)
[pcm_before.txt](https://github.com/user-attachments/files/31058216/pcm_before.txt)
[sof_debug.txt](https://github.com/user-attachments/files/31058210/sof_debug.txt)

[ujfalusi]

@naveen-manohar, the kernel crash will be fixed by the first commit in thesofproject/linux#5875

The DSP runs out of memory when the second compress stream is starting and it fails.