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