KMS overlay causes OOM oops on 3A+
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux-raspi (Ubuntu) |
New
|
Low
|
Jose Ogando Justo | ||
Bug Description
Came across something bizarre when investigating the audio situation with server on the Pi 5 (LP: #2038924). Moving the server images to use the KMS overlay solves the situation, and would be preferable as it would eliminate another difference between server and desktop images. However, it also renders the 512MB 3A+ unbootable with an out-of-memory error. The reason this is strange is that the 512MB Zero 2W continues to boot quite happily. I'm attaching the serial output from the kernel up to the point of the crash (screenlog.0).
The only changes made to the stock server config.txt were the addition of these lines under the final "[all]" section:
[all]
dtoverlay=
disable_
This setup booted happily on all other boards. A trivial workaround is to manually specify a smaller CMA on the 3A+ with:
dtoverlay=
With this alteration, it boots happily (and I'll be using this in an appropriate [section] to work around the issue), but it might be nice to understand why this is required on this board specifically (and why the 512MB Zero 2W doesn't exhibit the same issue).
| Dave Jones (waveform) wrote | #1 |
| Changed in linux-raspi (Ubuntu): | |
| importance: | Undecided → Low |
| Changed in linux-raspi (Ubuntu): | |
| assignee: | nobody → Jose Ogando Justo (joseogando) |
| tags: | added: kern-10444 |
| Dave Jones (waveform) wrote | #2 |
Have now also observed this on the Zero 2W with the current noble daily server image. Interestingly, it *didn't* occur directly on the image at first. This booted happily on the Zero 2W. However, this same card was then used to test a 3A+. On the 3A+ I regenerated the initramfs (testing a reported issue on low-memory boards), then moved the card back to the Zero 2W and observed the same OOM issue on boot as the 3A+ does without the CMA-128 workaround.
I also tried re-generating the initrd on the Zero 2W, but it still booted happily after that without the workaround. This implies there's something about the initrd, which is triggering the issue (sizing, position in memory, I'm not sure?) but that the Zero 2W may coincidentally run into the issue in normal operation.
Placing the CMA-128 workaround on the KMS overlay worked around the issue, so I'll now add a [pi02] section in the config.txt applying the same workaround for this board too.