search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
10.96k stars 4.93k forks source link

DRM_IOCTL_PRIME_FD_TO_HANDLE fails with ENOMEM and swiotlb reports error #3411

Open jdapena opened 4 years ago

jdapena commented 4 years ago

Describe the bug

Launching chromium ozone wayland backend fails on initialization.

To reproduce

  1. Compile with yocto zeus and meta-raspberrypi zeus branch, using chromium stable in meta-lgsvl-browser.
  2. Launch chromium: 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

drmPrimeFDToHandle() failed: Cannot allocate memory Failed to create scanout resource. [729:745:0117/092134.206095:ERROR:gl_surface_egl.cc(668)] EGL Driver message (Critical) eglCreateImageKHR: dri2_create_image_khr_texture

Kernel log:

Jan 17 09:21:34 raspberrypi4-64 user.debug kernel: [ 588.263651] [drm:drm_ioctl] pid=745, dev=0xe280, auth=1, DRM_IOCTL_PRIME_FD_TO_HANDLE Jan 17 09:21:34 raspberrypi4-64 user.debug kernel: [ 588.263696] [drm:drm_ioctl] pid=745, dev=0xe280, auth=1, V3D_GET_BO_OFFSET Jan 17 09:21:34 raspberrypi4-64 user.debug kernel: [ 588.263726] [drm:drm_ioctl] pid=745, dev=0xe280, auth=1, DRM_IOCTL_PRIME_HANDLE_TO_FD Jan 17 09:21:34 raspberrypi4-64 user.debug kernel: [ 588.263749] [drm:drm_ioctl] pid=745, dev=0xe201, auth=1, DRM_IOCTL_PRIME_FD_TO_HANDLE Jan 17 09:21:34 raspberrypi4-64 user.warn kernel: [ 588.264006] vc4-drm soc:gpu: swiotlb buffer is full (sz: 806912 bytes) Jan 17 09:21:34 raspberrypi4-64 user.err kernel: [ 588.264031] vc4-drm soc:gpu: DMA: Out of SW-IOMMU space for 806912 bytes Jan 17 09:21:34 raspberrypi4-64 user.debug kernel: [ 588.264056] [drm:drm_ioctl] pid=745, ret = -12

jdapena commented 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!

JamesH65 commented 4 years ago

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?

jdapena commented 4 years ago

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).

pelwell commented 4 years ago

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.

jdapena commented 4 years ago

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
youndong commented 4 years ago

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.

jdapena commented 4 years ago

@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.

jdapena commented 4 years ago

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).

FallingSnow commented 3 years ago

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.