X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Stupid question though (again, I'm a grossly underqualified sysadmin).

How can I tell if the blacklisting worked correctly?

When I type in:

# lspci -v | more

this is what it outputs for the VGA section:

08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
        Subsystem: Super Micro Computer Inc Device 062f
        Flags: bus master, medium devsel, latency 64, IRQ 11
        Memory at dd000000 (32-bit, prefetchable) [size=16M]
        Memory at df800000 (32-bit, non-prefetchable) [size=16K]
        Memory at df000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [dc] Power Management version 1
        Kernel modules: mgag200

Is there another way to confirm that the blacklisting did what it was
supposed to?

Thanks.

On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel <hiangel999 at gmail.com> wrote:

> On 7 December 2017 at 06:19, Hi-Angel <hiangel999 at gmail.com> wrote:
> > On 7 December 2017 at 06:05, Ewen Chan <chan.ewen at gmail.com> wrote:
> >> Hi-Angel:
> >>
> >> Thank you for that!!!
> >>
> >> Two questions:
> >>
> >> 1) Will the commands from the CentOS distro work with SuSE?
> >
> > Well, the linked post doesn't show how to blacklist because it was
> > created after the fact (author forgot to re-build initramfs). For an
> > example of doing that you can refer e.g. this
> > https://askubuntu.com/a/110343/266507 Except I am not sure how to
> > rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
> > mkinitcpio -p linux`.
> >
> >> 2) Do you think there will be problems using the VESA driver instead of
> the
> >> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
> >> behaviours?
> >
> > Nothing that I know of. You'd obviously get a lower graphics
> > performance, but otherwise I think it should be fine.
>
> You know, btw, another silly idea: if blacklisting the driver will
> help, but you actually care of graphics performance — you could try
> enabling it back, and then installing modesetting driver, and forcing
> Xorg to use it through a xorg.conf. Per my understanding the leak
> could specifically be in Matrox DDX driver — if this is the case, by
> replacing it with modesetting DDX you'd keep the performance and get
> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
> implemented on top of whatever driver provides OpenGL functional.
>
> It should be noted though that if leaks are in the matrox's provision
> of OpenGL, it won't help.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20171207/f895c4dc/attachment-0001.html>