Pi 5 kernel8.img for 6.6.62 causes audio players to freeze with a looping sound #6504
Comments
|
What device are you outputting audio to? (e.g. hdmi?) |
|
Yes, latest Bookworm release and output to HDMI-0 -- both from LightDM with Wayland+labwc and from console mode. |
|
I can confirm rolling back the linux-image-6.6.62 --> linux-image-6.6.51 with the kernel8.img enabled works as expected. |
|
I'm not a regular ffpmeg user, but it's working for me to HDMI0. There is no audible difference between kernel8.img and kernel_2712.img.
|
|
Just tried
Only on Pi4, I must stop wireplumber (not pipewire) else mplayer immediately reports "Audio device got stuck!" |
|
If you have a spare SD card, try a clean install of the latest 64-bit OS - it works with ffplay, speaker-test, aplay and mplayer (which I did have to apt install). Yes, speaker-test doesn't like Ctrl-C, and ffplay doesn't exit and the end of the file, but those are common problems. |
|
Happy to oblige -- used ffplay essentially gets stuck and speaker-test studders horribly @ ~60 seconds per period instead of constant pink noise for ~11 |
|
Can you confirm the issue occurs without the overclock? |
|
No problem, I had posted a "clean" config.txt from the start but certainly worth a try off the "clean" install. I do see a quick flash on the console from power up with the kernel of a |
|
That's interesting. Does changing: to help? Note: you can see those messages by running |
|
Well that was a magic bullet -- I updated linux images on both the SD card clean install and then my NVME boot (with overclocking) and sound works for all my use-cases using the kernel8.img now. |
|
You should see the cma messages in dmesg if you hit the issue (i.e. without the The question is, what needs so much cma on your system? Can you show output of |
|
Post url from |
... nets only: 82288 kB |
|
I checked the Pi 4, it shows 524288 allocated using stock settings off the stock kernel. |
|
See: #6361 It's a deliberate change. We are not planning to revert that. |
Just to confirm. Do you have the looping sound issue on an sdcard install (with kernel8), or only the NVME boot? |
|
In summary:
|
|
This is the surprising part. so most of the default 64M cma is still free. This is after booting to desktop. I need about 16M cma. You need 82M cma. What is the difference. |
|
I get identical numbers here using your config.txt as-is: |
|
So sad: I am assuming raspinfo was not revealing any between our Pi 5 boards and startup configurations then. Would attaching the initial ramdisk help? If I use the stock kernel, I get 64M allocated with 16032 kB free. I personally do not mind any coupling of kernel8.img with a hardwired cma upsizing overlay in the config.txt I could not speak to the differences between the kernel & kernel8 build as to why they would behave so differently on initial startup. I just know that some software emulation cores will not work using kernel and must have kernel8 to mitigate some complication with how its memory is allocated. |
|
You've got our attention, and we do believe you - we're just having some difficulty finding the differentiating factor. And it looks like you may not be alone: https://forums.raspberrypi.com/viewtopic.php?p=2263123 |
|
It's kind of tricky to get good information on where cma allocations come from. Can you try adding to cmdline.txt (on existing line): boot up (ideally with the clean sdcard image with kernel8 that has cma allocation failures) |
|
Here's a trace as requested by @popcornmix |
|
|
Okay, that narrows it down. The call stack is: and that seems to be called 15 times each wanting 4M of CMA. Running that again but without Was this an sdcard boot? If so can you confirm if removing |
Here is the log without kernel8: https://paste.debian.net/hidden/928f3ddc/ The system boots off a USB-connected SATA SSD (Kingston A400 ICIM). The nvme drive is a data/work disk. No |
The |
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: raspberrypi#6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: raspberrypi#6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: raspberrypi#6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
|
After a lot of head scratching and research I've come up with a highly technical potential workaround for the problem, which you'll find in #6510. --- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1936,6 +1936,7 @@ static void nvme_free_host_mem(struct nvme_dev *dev)
dev->nr_host_mem_descs = 0;
}
+#if 0
static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred,
u32 chunk_size)
{
@@ -2003,9 +2004,11 @@ static int __nvme_alloc_host_mem(struct nvme_dev *dev, u64 preferred,
dev->host_mem_descs = NULL;
return -ENOMEM;
}
+#endif
static int nvme_alloc_host_mem(struct nvme_dev *dev, u64 min, u64 preferred)
{
+#if 0
u64 min_chunk = min_t(u64, preferred, PAGE_SIZE * MAX_ORDER_NR_PAGES);
u64 hmminds = max_t(u32, dev->ctrl.hmminds * 4096, PAGE_SIZE * 2);
u64 chunk_size;
@@ -2018,6 +2021,7 @@ static int nvme_alloc_host_mem(struct nvme_dev *dev, u64 min, u64 preferred)
nvme_free_host_mem(dev);
}
}
+#endif
return -ENOMEM;
}If you wait about 40 minutes for the autobuilds to complete, you'll be able install a trial kernel with |
|
I Installed the rpi-update kernel and running with |
|
Do you notice any reduction in NVME speed? |
|
Ran some quick, smallish tests. Both are 8G Pi5 systems with a Kingston A400 SSD and a Kingston NV2 data disk. All tests done on the NV2. There is a difference in the NVME adapters however. host
rpi-updated raw speed slightly better than non-rpi-updated on same hardware. But, looks like the NVME adapter in Simple test (using the same 4.8GB IMG, copied locally). yea, it's a little small, but went for breadth
Result Summary:
pw disk on pit (no rpi-update) kernel8 logging on real 0m8.479s real 0m8.026s kernel8 logging off real 0m8.901s real 0m9.271s pit disk on pit (rpi-updated) kernel8 logging off real 0m8.711s pit disk on pw (rpi-updated) kernel8 logging on real 0m10.748s kernel8 logging off real 0m9.375s pw disk on pw (no rpi-update) kernel8 logging off real 0m9.335s |
|
I believe geekbench doesn't do any file access within the benchmark (it loads the data files it uses before starting the timing), so I wouldn't expect it to be affected by pr6510. Might be worth running the geekbench tests again to see if the scores are consistent. I do find that these small changes (the odd percent) tend to be in the noise and you need multiple runs to be sure if something is consistently better. |
|
Agreed with all of that and understand my Samsung SSD with Geekworm X1001 is different too. |
|
Thanks for the feedback - it all sounds pretty positive. I'll merge the PR as it stands - there should be no doubt about what it is doing - and wait for complaints about performance. |
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Some NVME drives seem to request significant amounts of DMA coherent memory - enough to exhaust our standard 64MB CMA allocation. Try disabling the feature to see what effect it has - drives should continue to function without it. Link: #6504 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Describe the bug
config.txt
Steps to reproduce the behaviour
ffplay sound.wavrace condition with studdering sound until killed.If I comment out kernel8.img, ffplay runs fine, but some other software will segfault without kernel8.
Device (s)
Raspberry Pi 5
System
uname -r6.6.62+rpt-rpi-v8
If I rollback to 6.6.51, it kernel8.img and sound events run fine.
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: