Skip to content

Getting Matrox drivers to work with Gentoo and Xorg

I have a Matrox M9148 graphics card I use to drive 4 monitors. Matrox is very slow to respond to changes in both the kernel and Xorg software, and so some modification is needed. I’m sure some of the changes will make for a slightly unstable system (kernel drivers are involved), but so far so good. First off, you need to limit yourself to Xorg server v1.10.*. The latest as of this writing is 1.12.xx, so you need to mask that by adding these lines to /etc/portage/package.mask:

>x11-base/xorg-server-1.10.99
>x11-base/xorg-drivers-1.10.99
>x11-libs/libpciaccess-0.12.1
>x11-proto/inputproto-2.0.2

If you’ve already upgraded past that point, then make sure to unmerge the new stuff, then reinstall:

# as root, or with sudo
emerge --unmerge xorg-server xorg-drivers
emerge xorg-server xorg-drivers xf86-input-mouse xf86-input-keyboard

The last two are required because unmerging xf86-drivers seems to largely wipe out the available drivers.

Finally, when you download the latest matrox drivers, you need to do some modification if you’re using kernel 3.0 or higher:

./m9xdriver-x86_64-1.3.1.004-20111025.run --extract-only
cd "wherever you extracted to"
vi kernel/src/m9x_client.c

I made a few changes to the m9x_client.c, specifically changing the spinlock mechanism to use the spin_lock_irq mechanism instead of the older spin_lock version. Here’s a patch file for that file, but the changes were pretty straightforward (I used this spin lock documentation to do the conversion.).

Once all that was done, I ran the install script as normal. I just wish Matrox were a bit more responsive to changes. 1+ years between Linux driver releases? Really? The community would love to help, just let us in already!

Posted 22 March 2012 † Ian Roddis § Computers ‡ Comments (0) ° Tagged: , , ,

OS X Lion and mDNSResponder

OS X Lion (latest patch as of now) has an issue that affects laptops after they have been put to sleep, then brought back by opening the lid. DNS from the GUI stops working completely, but it’s still accessible from the command line.

The reason is the service mDNSResponder, the proxy daemon that takes name resolution requests from GUI applications, does the requested lookup, and returns the result. If it stops working, why do the command line utilities work? Because they go directly to the gethostbyname system call, accessing the resolv.conf and bypassing mDNSResponder completely.

After wiping and reinstalling OS X, only to face the problem again, I’ve found a strange solution that seems to work: Removing all preferences except Xsan from /Library/Preferences, rebooting, restoring them, and rebooting again:


mkdir ~/tmp/prefs
sudo rsync -arv /Library/Preferences/. ~/tmp/prefs/.
cd /Library/Preferences
ls | grep -v Xsan | while read i; do sudo rm -rf "$i"; done
*reboot*
sudo rsync -arv ~/tmp/prefs/. /Library/Preferences/.
*reboot*

I have no idea if this is reproducible, but it’s worked for me so far. Good luck!

Posted 16 March 2012 † Ian Roddis § Computers ‡ Comments (0) °