X is consuming ~100 GiB of RAM(!)
Ewen Chan
chan.ewen at gmail.com
Thu Dec 7 15:18:52 UTC 2017
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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20171207/bb1a2683/attachment-0003.html>
More information about the xorg
mailing list