Open jdapena opened 4 years ago
For clarification, I'd like to state we are not asking for a fix (that'd be great). It would be helpful if we could get some hints on what could be wrong, so we can implement and provide a fix as needed. Thanks!
We've not done any work on Wayland for some years, so not sure what help can be provided. Although it does appear to be a DRM problem rather than Wayland, which is currently under development. @6by9 Any thoughts?
FTR, just before the error happens, I see around 50-60 V3D_CREATE_BO calls, many of them of 256KB and 128KB, plus a few ones that are bigger (4MB, 1MB). The total of buffer allocated before the error happens, that are bigger or equal to 128KB is around 12MB. The 256KB ones are mostly as a result of glTexImage2D calls, but not only (there are also internal calls in mesa driver for internal tiles, and other buffers used for rendering apparently).
It's probably not relevant, but I found a bug in the mesa driver that would occasionally cause prefetch exceptions in the V3D MMU - it was failing to allow enough space at the end of a page. It appeared to be harmless until the MMU exception handling was enabled, but it could have other subtle side effects. The bug has now been fixed upstream and the latest Raspbian mesa driver package includes the fix.
Applied the patch on top of mesa-19.1.6 and tried. It still fails.
Patch:
commit 18a09e788d8d0e122263159cb6cb1c70d243b02d
Author: Iago Toral Quiroga <itoral@igalia.com>
Date: Tue Nov 26 15:28:52 2019 +0100
v3d: fix indirect BO allocation for uniforms
Log:
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.663072] [drm:drm_ioctl] pid=2547, dev=0xe280, auth=1, V3D_CREATE_BO
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.676789] [drm:drm_ioctl] pid=2547, dev=0xe280, auth=1, DRM_IOCTL_PRIME_HANDLE_TO_FD
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.678954] [drm:drm_ioctl] pid=2539, dev=0xe280, auth=1, DRM_IOCTL_PRIME_FD_TO_HANDLE
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.679006] [drm:drm_ioctl] pid=2539, dev=0xe280, auth=1, V3D_GET_BO_OFFSET
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.679040] [drm:drm_ioctl] pid=2539, dev=0xe280, auth=1, DRM_IOCTL_PRIME_HANDLE_TO_FD
Jan 17 11:28:08 raspberrypi4-64 user.debug kernel: [ 3935.679065] [drm:drm_ioctl] pid=2539, dev=0xe201, auth=1, DRM_IOCTL_PRIME_FD_TO_HANDLE
Jan 17 11:28:08 raspberrypi4-64 user.warn kernel: [ 3935.680675] vc4-drm soc:gpu: swiotlb buffer is full (sz: 774144 bytes)
Jan 17 11:28:08 raspberrypi4-64 user.err kernel: [ 3935.680705] vc4-drm soc:gpu: DMA: Out of SW-IOMMU space for 774144 bytes
Hi, @jdapena I also had the same error when chromium is started on Raspberry Pi 4 with zeus branch. How did you fix the error? Thanks.
@youndong < This is still failing in both rpi4 and rpi4-64 (but working on rpi3, rpi3-64). It is apparently related to the rpi4 graphics stack used in Yocto, not sure if it has the proper mix of vc4 and v4d.
It is still broken in dunfell.
If you want to still run chromium in rpi4 with ozone wayland, you need to build it disabling wayland GBM (GN arg use_wayland_gbm=false). But right now build with that flag set to false is broken (will propse a fix today).
I've run into ENOMEM before while working with DRM and rpi4. I think it had do with my setting of the buffers bpp (https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_mode.h#L571) might be worth checking out.
Describe the bug
Launching chromium ozone wayland backend fails on initialization.
To reproduce
chromium --no-sandbox --ozone-platform
Expected behaviour No error initailizing EGL, window is visible accelerated.
Actual behaviour
Chromium GPU acceleration fails, it falls back to software pipeline and performance is poor.
System
Logs
Error log on chromium
Kernel log: