Trying to create UMP memory with unaligned size. Size: 5760000

[j...@mailb.org]

trying to get X11 running with EGL I get a segfault using
xf86-video-mali and xf86-video-sunxifb about unaligned memory.
anyone alse seen this?
this happens with a kernel build from current sunxi-3.4 branch.
attached dmesg with crash and screen info.

[Siarhei Siamashka]

Thanks for the report.

Yes, UMP wants the buffers to be perfectly 4KiB page aligned. As such,
the code which tries to split the framebuffer into two parts of equal
sizes for GET_UMP_SECURE_ID_BUF1 and GET_UMP_SECURE_ID_BUF2 may break
this assumption for certain screen resolutions and is very suspicious
at best:

https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-v3.4.24-r1/drivers/video/sunxi/disp/disp_ump.c#L39

I did not like it right from the start, but but decided not to touch it
because nobody reported real problems up to now and some people
even supposedly had some success with double buffering:

https://groups.google.com/d/msg/linux-sunxi/ON2fzPOSmpc/roiAL124XeoJ
https://groups.google.com/d/msg/linux-sunxi/qnxpVaqp1Ys/aVTq09DVih0J

Actually I still don't really believe that page flipping can be
successfully used with xf86-video-mali. The related DRI2 code is a
bloody mess and contains some glaring bugs (which might be
admittedly somehow cancelled by the corresponding bugs in the mali
binary blob, so I can't be totally sure).

The xf86-video-sunxifb still does GET_UMP_SECURE_ID_BUF1 and
GET_UMP_SECURE_ID_BUF2 ioctls just to make sure that the secure id
assignment is not messed up and GET_UMP_SECURE_ID_SUNXI_FB never gets
secure id equal to 1 or 2:

https://github.com/ssvb/xf86-video-sunxifb/blob/0.2.0/src/sunxi_mali_ump_dri2.c#L491

The same could have been also accomplished by just doing two dummy UMP
buffer allocations instead of asking for GET_UMP_SECURE_ID_BUF1 and
GET_UMP_SECURE_ID_BUF2.

Regarding the page flipping itself. Apparently the mali blob is
likely doing something like this when requesting for DRI2 buffers:

1. DRI2GetBuffers request for one DRI2BufferBackLeft buffer
2. DRI2SwapBuffers
3. DRI2GetBuffers request for one DRI2BufferBackLeft buffer

After doing this, it probably assumes that the buffer allocated
in (1) is now the DRI2BufferFrontLeft and the buffer allocated
in (3) is now DRI2BufferBackLeft. But normally the DRI2 clients
are supposed to to allocated both buffers with one call.

In fact the DRI2 code in the DDX driver observes that it is requested
to destroy buffer (1), and this request comes from the X server DRI2
framework. Moreover, the DRI2 framework has some sort of "buffers reuse"
functionality, so predicting what happens to this destroyed
buffer becomes rather interesting. As can be seen from the point
of view of the DDX driver, the actual rendering happens to the
destroyed buffer, and this messes up page flipping really bad.

I can predict this to some extent and get page flipping successfully
working in xf86-video-sunxifb, but this requires a somewhat convoluted
logic for additionally tracking DRI2 buffers the way they are seen by
the mali blob.

To sum it up. We can just forcefully align the UMP buffers at 4K
boundary for GET_UMP_SECURE_ID_BUF1 and GET_UMP_SECURE_ID_BUF2. This
may be wrong for xf86-video-mali, but in my opinion it is already badly
broken and can't become much worse. I'll send some patches later today.

As a workaround, you can try to avoid setting fb0_framebuffer_num
and/or fb0_framebuffer_num to 2 in your .fex file. The bigger numbers
should work better. Just because 32MiB of RAM is already reserved at
boot time, the users setting low values for fbX_framebuffer_num values
are not reducing memory usage at all and accomplishing nothing
(probably contrary to their expectations).

--
Best regards,
Siarhei Siamashka