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.e...@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 <hiangel...@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.e...@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 <hiangel...@gmail.com> wrote: >> >> >> >> On 7 December 2017 at 06:19, Hi-Angel <hiangel...@gmail.com> wrote: >> >> > On 7 December 2017 at 06:05, Ewen Chan <chan.e...@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. >> > >> > > > _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
