X is consuming ~100 GiB of RAM(!)

Hi-Angel hiangel999 at gmail.com
Thu Dec 7 15:32:43 UTC 2017


Yeah, nice, it worked. As for what other driver in the output should
accord to vesa or whatever that provides the basic functional of
outputting to a monitor — sorry, I don't know, I hope somebody else
here can tell it. I don't think it's important for our purposes
though.

On 7 December 2017 at 18:18, Ewen Chan <chan.ewen at gmail.com> wrote:
> Hi-Angel:
>
>> Have you rebuild initramfs after blacklisting by the way?
>
> So...I did what that thread (and the thread that it points to within that
> thread) says to do.
>
> Created blacklist.conf and then put in there:
>
> blacklist mgag200
>
> and then I ran dracut --regenerate-all --force and rebooted (per the
> thread-inside-that-thread's instructions).
>
> (like I said, I'm a grossly underqualified sysadmin so I just do what "I am
> told" from those sources.)
>
>
> Here is the output of lsmod:
>
> Module                  Size  Used by
> ebtable_filter         12827  0
> ebtables               35009  1 ebtable_filter
> ip6table_filter        12815  0
> ip6_tables             27025  1 ip6table_filter
> iptable_filter         12810  0
> ip_tables              27239  1 iptable_filter
> x_tables               34059  5
> ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
> af_packet              39847  0
> fuse                   95758  3
> iscsi_ibft             12862  0
> iscsi_boot_sysfs       16051  1 iscsi_ibft
> raw                    13091  0
> msr                    12865  0
> joydev                 17344  0
> iTCO_wdt               13480  0
> iTCO_vendor_support    13718  1 iTCO_wdt
> dm_mod                110780  0
> intel_rapl             18783  0
> intel_powerclamp       14690  0
> coretemp               13435  0
> kvm_intel             151399  0
> kvm                   496652  1 kvm_intel
> crct10dif_pclmul       14307  0
> crc32_pclmul           13133  0
> crc32c_intel           22094  0
> pcspkr                 12718  0
> sb_edac                26894  0
> edac_core              66438  1 sb_edac
> igb                   204492  0
> ptp                    18933  1 igb
> i2c_i801               22557  0
> pps_core               19333  1 ptp
> ipmi_si                57482  0
> i2c_algo_bit           13413  1 igb
> ipmi_msghandler        49676  1 ipmi_si
> mei_me                 18355  0
> wmi                    19193  0
> mei                    86782  1 mei_me
> lpc_ich                21093  0
> ioatdma                71777  0
> mfd_core               13435  1 lpc_ich
> shpchp                 32951  0
> dca                    15130  2 igb,ioatdma
> processor              44678  0
> button                 13971  0
> hid_generic            12559  0
> usbhid                 52573  0
> btrfs                1022893  2
> xor                    21411  1 btrfs
> raid6_pq              101908  1 btrfs
> sd_mod                 50160  4
> ghash_clmulni_intel    13230  0
> aesni_intel            52860  0
> isci                  149868  0
> aes_x86_64             17131  1 aesni_intel
> glue_helper            13990  1 aesni_intel
> lrw                    13286  1 aesni_intel
> gf128mul               14951  1 lrw
> ablk_helper            13597  1 aesni_intel
> cryptd                 16263  3 ghash_clmulni_intel,aesni_intel,ablk_helper
> ehci_pci               12914  0
> libsas                 87336  1 isci
> ehci_hcd               79237  1 ehci_pci
> ahci                   29929  2
> scsi_transport_sas     45130  2 isci,libsas
> libahci                36105  1 ahci
> usbcore               254961  3 ehci_hcd,ehci_pci,usbhid
> libata                244519  3 ahci,libahci,libsas
> usb_common             13057  1 usbcore
> sg                     40629  0
> scsi_mod              244588  6
> sg,isci,scsi_transport_sas,libata,libsas,sd_mod
> autofs4                42930  2
>
> Out of that list, I don't see mgag200 there, but then again, I also don't
> see any module that I recognize as being a "video driver" either.
>
> I hope that helps answer your questions(? 0.o?)
>
> Thanks.
>
> Sincerely,
> Ewen
>
>
> On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel <hiangel999 at gmail.com> wrote:
>>
>> Don't worry, I don't believe in Laplace's demon, and hence I believe
>> everybody don't know something.
>>
>> Tbh I'm not sure if the output of lspci implies the module is still
>> loaded, although I would assume it still is. Either way, to be sure
>> you can use `lsmod` command, it lists all currently loaded modules.
>> Have you rebuild initramfs after blacklisting by the way?
>>
>> On 7 December 2017 at 08:32, Ewen Chan <chan.ewen at gmail.com> wrote:
>> > 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.
>> >
>> >
>
>


More information about the xorg mailing list