Wayland/weston opens files in suspend/resume

[Teemu K]

On Wed, Aug 22, 2018 at 12:51 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 22 Aug 2018 12:18:00 +0300
> Teemu K <maillinglists18 at gmail.com> wrote:
>
> > Hi,
> >
> > I have custom iMX6 based HW running image generated with Yocto 2.4
> > (Wayland 2.0.0) and Linux kernel 4.1.x that I've been testing with
> > suspend/resume cycles.
> >
> > I noticed that after each suspend/resume cycle open file count
> > increases. In my testing I got around 490 suspend/resume cycles until
> > libwayland gave error that there is too many open files.
> > --
> > [14:29:52.385] libwayland: dup failed: Too many open files
> > [14:29:52.385] caught signal: 6
> > The Wayland connection broke. Did the Wayland compositor die?
> > --
> > Looking at the lsof output after around 60 suspend/resume cycles I can
> > see that for example this file appears 60 more times:
> > --
> > weston      921            root   11u      CHR       29,0      0t0
> > 5323 /dev/fb0
> > --
> >
> > The 11u part changes, but other parts are same. First time there is
> > 11u and 13u but later it goes all the way to 93u (some numbers are
> > missing).
> >
> > Also my QT application running when suspending keeps keeping these
> > kinds of files open which I assume (I may be wrong) because the
> > weston.
> >
> > --
> > qtapplicat   929  965       root   11u      REG       0,18    48097
> > 12272 /run/user/root/weston-shared-24Zz9a (deleted)
> > --
> >
> > I know that the Weston is quite old since I think 4.0.0 has already
> > come out,but is there any known bug that causes this? I did a search,
> > but couldn't find any. I know it's rare to need suspend/resume over
> > 400 times without cutting power at some point, but I'm sure there'll
> > be that one customer that does it.
>
> Hi,
>
> I hope it would be more correct to say it's rare to see anyone care
> about the fbdev backend. ;-)
>
> Leaking file descriptors to /dev/fb0 over suspend/resume does not
> surprise me, but I don't recall any bug reports or fixes exactly to that
> effect. Also the fbdev device handling has been changed since Weston
> 2.0.0, so it's possible it might be already fixed. Or maybe not. I seem
> to recall that VT switching with the fbdev-backend has been broken for
> years.
>
> I would not expect Weston to ever have made a dozen open file
> descriptors to /dev/fb0. Are you sure you are not using proprietary EGL
> drivers with the fbdev-backend? If you use EGL with fbdev, then we
> certainly cannot help you.
>
> If you found fd leaking with the DRM-backend and a more recent release,
> there would be much more interest in it. However, I suppose we do still
> take patches to fix bugs in the fbdev-backend for master branch, even
> though we probably reject any feature additions (complicated ones at
> least).
>
> weston-shared-* file might be a keymap, nothing else comes to mind that
> Weston would allocate, and I hope Qt does not use weston's name for its
> own stuff.
Hi,

Well, since it's i.MX6 and NXP (still) doesn't provide proper video
driver so proprietary EGL driver is being used. I think they even made
their own fork for Weston 2.0.0 onward that they can keep using their
old driver instead fixing it to the way Wayland wants it.

I did try Etnaviv opensource graphics driver, but I couldn't get it
working even with the newer kernel so I'm stuck with the old driver.

But it seems that as I suspected it's not so much Wayland problem, but
the driver issue.

-Teemu