Since it’s now officially in the FreeBSD ports tree, I decided to upgrade my work desktop to Xorg 7.2 today. The process is mostly painless as long as you are a good user and follow all the steps in /usr/ports/UPDATING – everyone reads that before upgrading anything, right?, right? 😉
The only gotcha I came across related to the modular nature of Xorg, mainly the “where’s my $DRIVER gone to?!” problem. To be honest I’d forgotten about this part even though 7.x has been out for a while, and I probably came across it on various Gentoo upgrades in the past. Running “startx” will simply dump you back out to the console with complaints about not being able to find your keyboard or mouse driver.
However it was pretty easy to infer what the problem was. In the caveats section of the Xorg UPDATING notes they mention you should probably have the x11/xorg meta-port installed. If you don’t have this installed (like me), it’s more than likely Xorg won’t start first go since it’s basically missing all the necessary modules required to load properly. So unless you don’t mind using X without luxuries like a keyboard or mouse you’d better install some drivers.
Luckily these are all packaged up nicely, I simply had to do:
* Replace that with your video card – you can probably guess the correct driver to install by looking at /usr/ports/x11-drivers
But..there was still another issue to tackle. Fonts. These are now also their own separate package. When starting X it appeared to get a little further, however it died just before loading the window manager with a message about not being able to find the “fixed” font. So, another portinstall was required:
3rd time lucky, now I have a working Xorg 7.2 install.
So everything seems to have remained stable over the past few days – and theres now a commit to the ng_fec code:
We managed to finally (hopefully) fix an annoying problem with one of our FreeBSD boxes and IPv6.
For some background; we used the ng_fec (4) device on FreeBSD 6.2-RELEASE to make a logical network interface out of two physical interfaces. This is referred to as bonding on Linux, IP Multipathing on Solaris and I think Cisco call it Ether Channel. Whatever way you go about it, the end result is that you get a network interface that is reachable via a multiple different paths. If each physical interface is plugged into a different switch, you get a nice amount of resiliency.
This works great in FreeBSD with ng_fec, however if you try to use an IPv6 address on the logical interface thats where things start to get interesting. Without getting into too much detail – the problems relate to how IPv6 maps IP addresses to MAC addresses, this is done by way of “neighbour advertisement” messages sent via multicast. However the ng_fec driver was not telling the physical network interfaces to join the correct multicast groups so these neighbour advertisement messages could not be processed correctly, which led to very flaky and mostly unavailable IPv6 connectivity. From what I can gather, you can use other drivers in -CURRENT that don’t exhibit this problem.
But with some diagnoses and a patch to ng_fec.c from Dave Malone we managed to correct the issue. This may make it up into the FreeBSD source tree at some point.
Hopefully things will stay stable from now on
Edit: Ah, there is a bug report raised for this already.
Following on from my earlier post about nspluginwrapper and Firefox; I noticed that the plugin likes to keep its file handles open even after you’ve finished viewing a flash-based site. This is a bit of an issue with things like the sound device – /dev/dsp0:
[rob@tachikoma] >> fstat | grep dsp
rob mplayer 80327 9 /dev 45 crw-rw-rw- dsp0.1 w
rob npviewer.bin 80305 63 /dev 42 crw-rw-rw- dsp0.0 rw
rob npviewer.bin 80299 63 /dev 42 crw-rw-rw- dsp0.0 rw
So if you happen to forget about this and go to play an mp3 or something later on, you’ll be left scratching your head. I didn’t feel like running a sound daemon like esound or arts, luckily FreeBSD has a kernel-based solution to this problem in the form of virtual sound channels which can be configured using the standard sysctl MIBs.
So we’ll try to allocate out 4 virtual sound channels:
[rob@tachikoma] >> sudo sysctl hw.snd.pcm0.vchans=4
sysctl: hw.snd.pcm0.vchans: Device busy
Oops, of course we must first close any programs that are using the sound card.
[rob@tachikoma] >> sudo sysctl hw.snd.pcm0.vchans=4
hw.snd.pcm0.vchans: 0 -> 4
[rob@tachikoma] >> sudo sysctl hw.snd.maxautovchans=4
hw.snd.maxautovchans: 0 -> 4
hw.snd.pcm0.vchans is the number of virtual channels pcm0 has and hw.snd.maxautovchans is the number of virtual channels given to new devices. All the virtual channels are automagically allocated using devfs.
I was then able to view flash sites, and open up audio applications afterwards without any problems – I’m starting to see the benefits of the move to devfs
Rong-En Fan mentioned the recently added www/nspluginwrapper port in his blog. It’s a compatibility layer for Firefox/Netscape that lets you use Linux plugins such as Adobe Flash, Acrobat natively.
I installed the port and ran
…which picked up plugins I had installed previously, adding them to my ~/.mozilla/plugins directory. A quick restart of Firefox and an about:plugins showed I now had Flash (7) and Acrobat available. I was then able to view all those – previously annoying – Flash-based sites as normal. Nice!
Flash was previously available through the linuxpluginwrapper port, however the Flash plugin was withdrawn due to licensing issues. I’d written up a page a number of years ago describing the old method for getting Flash etc.. to work in FreeBSD, guess it’s time to update that
If you’re an opera user, Linux plugin support has also been available for a while through the opera-linuxplugins port.