possible wrong handling of memory on aarch64 for mesa-dri-drivers
judovana opened this issue · comments
Hi!
I had noticed, that - compared to 32 raspberry, 64b raspberry, mesa-dri-drivers requires enormous CMA to work properly.
See https://bugzilla.redhat.com/show_bug.cgi?id=1643484 for details. Feel free to ping for any more details, the I have the setup working.
32 and 64 have no difference in their CMA requirements. I would guess that your 32 and 64 builds are getting different cma amounts chosen by the kernel, though (look for a dmesg line like "cma: Reserved 384 MiB at 0x20000000"). You'll need 256 or so for things to generally work, though if you do a lot of graphics-related stuff (open many applications, do stuff in gnome-shell, or run games), you may still run out and there's not much we can do about that.
I've not tested aarch64 widely on graphical use cases, F-29 Workstation works fine on ARMv7 on the 3B and 3B+, I was running it the other day for 8 hours with a, albeit none accelerated, h264 video without any crashes. It wasn't fast but then as a presentation on a conference booth that was fine.
I have tested aarch64 a lot with "minimal text" images, I wonder if the 64 bit allocation mechanisms might have an effect on memory usage here. I will try to do some basic testing this week on aarch64 if I get a chance.
@judovana please provide more information than "it doesn't work"
"it doesn't work" - where I have wrote it?
I think the https://bugzilla.redhat.com/show_bug.cgi?id=1643484 is describing situation pretty well.
One need cma of 512 to run dummy mate or play video. On both those setups should be 256 pretty enough, should it?
HW is raspberry pi 3 b+; reproducer is to install mesa-dri on "low" cma (as 192) and run 720p or bigger movie, or an more "Advanced" desktop. It will stop redrawing, and you will see the memory errors in dmesg ( know it is not exactly minimalistical reproducer)
Anyway, thanx all for cooperation. Looking forward for resolution.
Best regards
J.
hi!
Any update?
Maybe this is related to the following pull request: raspberrypi#2699
It looks promising, @lategoodbye is there an upstream patch series for this too?
In the end it's only a single patch, so i think the porting to current linux-next should be easy.
But the first question: is this issue still reproducible?
The "is it reproducible" question is definitely for @judovana
Yes it is. reproducible. I should be able to selfbuild fedora kernel. Can you point me to the direct patch(es)?
@judovana reach out if you have issues and I can assist with a scratch build.
Application og raspberrypi@67d41b9 should be enogh, right?
Reproducible with which kernel version?
Since there has been a lot of fixes on vchiq, it would be nice to try at least 4.20 or staging-next.
So i suggest this: raspberrypi@74da962
That was 4.18. Fedroa now have 4.19 for f29, so I wonted to try it there.
You can try this version, but i think it's a waste of your time.