[BUG] SoundWire BPT/BRA w/ CHAIN_DMA fails with DMA buffer-alloc failure #8751
Comments
|
@mwasko @marcinszkudlinski fyi - looks like a memory leak in the chain DMA FW driver ? |
|
I changed the code on the kernel to make sure the two TX and RX chain DMAs were handled in a symmetrical way
and I still see the failure. mtrace-alloc-sequence.log This points to a memory leak somewhere rather than a fragmentation issue. Not good news, this makes the issue even harder to root-cause. Gah. |
|
what's super weird is that the heap max_allocated value progresses by two steps of 24, and never reaches a stable point. see e.g transitions 87280 |
|
Bumping the FIFO size to 16ms (from 10ms) has surprisingly a positive effect in that I can run 295 iterations (instead of 60), but the same problem occurs with a failed memory allocation. |
|
Additional traces show there's a memory leak in the firmware! The use of the component is just wrong #if CONFIG_COMP_CHAIN_DMA
int ipc4_chain_manager_create(struct ipc4_chain_dma *cdma)
{
const struct sof_uuid uuid = {0x6a0a274f, 0x27cc, 0x4afb, {0xa3, 0xe7, 0x34,
0x44, 0x72, 0x3f, 0x43, 0x2e}};
const struct comp_driver *drv;
struct comp_dev *dev;
drv = ipc4_get_drv((uint8_t *)&uuid);
if (!drv)
return -EINVAL;
dev = drv->ops.create(drv, NULL, cdma);
if (!dev)
return -EINVAL;
/* differentiate instance by unique ids assignment */
const uint32_t comp_id = IPC4_COMP_ID(cdma->primary.r.host_dma_id
+ IPC4_MAX_MODULE_COUNT, 0);
dev->ipc_config.id = comp_id;
dev->ipc_config.pipeline_id = cdma->primary.r.host_dma_id
+ IPC4_MAX_MODULE_COUNT;
return ipc4_add_comp_dev(dev); <<<< MEMORY ALLOCATED
}
int ipc4_chain_dma_state(struct comp_dev *dev, struct ipc4_chain_dma *cdma)
{
const bool allocate = cdma->primary.r.allocate;
const bool enable = cdma->primary.r.enable;
int ret;
if (!dev)
return -EINVAL;
if (allocate) {
if (enable)
ret = comp_trigger(dev, COMP_TRIGGER_START);
else
ret = comp_trigger(dev, COMP_TRIGGER_PAUSE);
} else {
if (enable)
return -EINVAL;
/* remove chain part */
ret = comp_trigger(dev, COMP_TRIGGER_PAUSE);
if (ret < 0)
return ret;
comp_free(dev); <<<<< MEMORY NOT FREED!!!!
}
return ret;
}
#endif
|
plbossart
added a commit
to plbossart/sof
that referenced
this issue
Jan 22, 2024
The CHAIN_DMA code relies on the component code unfortunately without a symmetry between memory allocation and release. ipc4_chain_manager_create() relies on the ipc4_add_comp_dev() helper, which internally allocate 20 bytes for an icd item included in a list. ipc4_chain_dma_state() directly releases the component, without removing the icd item from the list. This slow memory leak, combined with alignment requirements, gradually prevents a DMA buffer from being allocated. This patch adds a search in the list and frees the item. With this modification the CHAIN_DMA stress tests can loop forever. Closes: thesofproject#8751 Signed-off-by: Pierre-Louis Bossart <[email protected]>
plbossart
added a commit
to plbossart/sof
that referenced
this issue
Jan 22, 2024
The CHAIN_DMA code relies on the component code unfortunately without a symmetry between memory allocation and release. ipc4_chain_manager_create() relies on the ipc4_add_comp_dev() helper, which internally allocate 20 bytes for an icd item included in a list. ipc4_chain_dma_state() directly releases the component, without removing the icd item from the list. This slow memory leak, combined with alignment requirements, gradually prevents a DMA buffer from being allocated. This patch adds a search in the list and frees the item. With this modification the CHAIN_DMA stress tests can loop forever. Closes: thesofproject#8751 Signed-off-by: Pierre-Louis Bossart <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When trying stress tests on the SoundWire BPT/BRA protocol with a CHAIN_DMA, I see a buffer allocation failure after exactly 60 iterations
To Reproduce
Need dedicated kernel branch thesofproject/linux#4679
Reproduction Rate
100%
Expected behavior
no buffer allocation issues.
Impact
showstopper for the feature, but not immediate P1
Environment
Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
Name of the topology file
n/a
Name of the platform(s) on which the bug is observed.
LNL
Screenshots or console output
chain-dma-alloc-fail.txt
The alloc failure seems to happen exactly at the same iteration, so this looks like a memory leak of sorts.
The text was updated successfully, but these errors were encountered: