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