drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising zeising+freebsd at daemonic.se
Tue Apr 14 19:53:40 UTC 2020

On 2020-04-14 21:38, Kevin Oberman wrote:
> On Tue, Apr 14, 2020 at 5:15 AM Niclas Zeising 
> <zeising+freebsd at daemonic.se <mailto:zeising%2Bfreebsd at daemonic.se>> wrote:
>     On 2020-04-14 13:57, Tomasz CEDRO wrote:
>      > Hello world :-)
>      >
>      > I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
>      > AMD64 with latest intel driver from 2018???) - it eats out all of the
>      > RAM, then it eats all of the SWAP, then system gets unusable for
>      > anything except hard reset :-( This happens when it works together
>      > with latest DRM i915KMS. On hard computer use that means workstation
>      > gets useless in around 15 minutes. Closing applications does not free
>      > the memory resources, once it get some some it never returns.
>     Which driver are you talking about? xf86-video-intel or
>     drm-fbsd12.0-kmod?
>      >
>      > I have set the UXA as the default for i5-5300U CPU.
>      >
>      > On the other hand the DRM i915kms works fine with SCFB on the same
>      > load and hardware. I am working on DRM + i915kms + SCFB so far.
>     If you are using SCFB, you are not using i915kms.
>      >
>      > This is why I suspect problem with X11-INTEL driver? Maybe it
>     does not
>      > like latest Xorg changes?
>      >
>      > I also sometimes get this DRM warning on the dmesg:
>      > [drm] Reducing the compressed framebuffer size. This may lead to less
>      > power savings than a non-reduced-size. Try to increase stolen memory
>      > size if available in BIOS.
>     This is unrelated to this issue.
>     Have you tried using the modesetting xorg driver instead?
>     Regards
>     -- 
>     Niclas
>     _______________________________________________
>     freebsd-x11 at freebsd.org <mailto:freebsd-x11 at freebsd.org> mailing list
>     https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     To unsubscribe, send any mail to
>     "freebsd-x11-unsubscribe at freebsd.org
>     <mailto:freebsd-x11-unsubscribe at freebsd.org>"
> A day or two ago I saw a post to this list stating that modesetting was 
> not interesting because it did not support 3-D acceleration. At least on 
> my Sandy Bridge system running the latest available software for FreeBSD 
> 12-STABLE, 3-D acceleration works just fine. This assumes the most 
> recently committed mesa, server, drm-fbsd12.0-kmod, etc. It may be that 
> modesetting does not provide 3-D on other platforms, but that is not the 
> norm, I suspect. If it does normally work, a clear statement to that 
> effect would be a "good  thing", though, other than this mailing list, I 
> have no idea where to find current status and no idea where else users 
> would look.
> If it is not going to be maintained, please take down the graphics wiki 
> page! It list supporting evdev as "Not started" and everything on it 
> seems over a year old. I'm tempted to volunteer to try to update it 
> myself, but I am hardly the best informed. I only discovered the 
> modesetting driver as an option for Intel GPUs when I had serious issues 
> and someone (Jan) suggested I try it.

The modesetting xorg-server driver works fine, and has been working fine 
for quite a number of years.  It is the driver used by default, in the 
default set up.  You need to explicitly install another xf86-video-* 
driver to get something else.  It also should give 3D acceleration (and 
has always, to my knowledge, done so).  If you, or anyone else on the 
mailing list, have problems using it, it is most likely a bug.
I've been telling people this on mailing lists for a long time, and as I 
said before, it is the default configuration.  I don't know what else to 
do to squash rumors like this.  It is even stated on the graphics wiki 
page that you don't need for instance xf86-video-intel when using drm-kmod.

More information about the freebsd-questions mailing list