• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    April 2014
    M T W T F S S
    « Dec    
     123456
    78910111213
    14151617181920
    21222324252627
    282930  
  • Archives

FreeBSD 8.1 Intel Ethernet Driver

I’ve updated a few FreeBSD servers in the last days.  They all went smooth with one exception: a pretty recent, state of the art small business custom server based on Intel’s S3420GPLC motherboard and an LGA1156 Xeon CPU.

The code built fast from source but after rebooting with the new 8.1 kernel I could no longer connect to the machine.  Not practical when the machine is 1000 Km away and unattended.  I waited the next day to guide an employee on location in the process of booting with the old kernel (straight forward).  Then I went about investigating the issue.

# cat messages | grep em0

FreeBSD 8.1 (not working):

Aug 26 23:51:10 synapse kernel: em0:  port 0x2040-0x205f mem 0xb1a00000-0xb1a1ffff,0xb1a25000-0xb1a25fff irq 20 at device 25.0 on pci0
Aug 26 23:51:10 synapse kernel: em0: Using MSI interrupt
Aug 26 23:51:10 synapse kernel: em0: [FILTER]
Aug 26 23:51:10 synapse kernel: em0: Ethernet address: 00:15:17:__:__:29

FreeBSD 8.0 (working):

Aug 27 11:24:57 synapse kernel: em0:  port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2
Aug 27 11:24:57 synapse kernel: em0: Using MSIX interrupts
Aug 27 11:24:57 synapse kernel: em0: [ITHREAD]
Aug 27 11:24:57 synapse kernel: em0: Ethernet address: 00:15:17:__:__:28
Aug 27 11:24:59 synapse kernel: em0: link state changed to UP

The board has two on-board ethernet interfaces and it seems that between FreeBSD 8.0 and 8.1 em0 has changed assignment from one to the other.  The physical cable is still connected to the same interface.  The interface being configured by FreeBSD 8.1 has no cable attached hence I can’t connect.

To verify:

# cat messages | grep em1

only FreeBSD 8.1 showed em1, and indeed with the ethernet address assigned to em0 by FreeBSD 8.0:

Aug 26 23:51:10 synapse kernel: em1:  port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2
Aug 26 23:51:10 synapse kernel: em1: Using MSIX interrupts with 5 vectors
Aug 26 23:51:10 synapse kernel: em1: [ITHREAD]
Aug 26 23:51:10 synapse kernel: em1: Ethernet address: 00:15:17:__:__:28

After editing /etc/rc.conf to configure em1 instead of em0 I was able to reboot the 8.1 kernel and connect.

Hugin-0.8.0 for FreeBSD

hugin-logoFreeBSD is my favorite server operating system. IMO it is the right choice for a conservative environment, where robustness is more important than the bleeding edge. I’ve never really used it on the desktop, but I know some people do. Software is distributed to FreeBSD users mainly through the ports collection, a system of scripts that will fetch the source code and build it automatically.

A FreeBSD port can be quite complex to set up – witness the size of the FreeBSD Porter’s Handbook. But once it’s working, making incremental changes is not that difficult and a good learning experience to understand the system better.

So I poked Vasil Dimov, the maintainer of the Hugin port on FreeBSD. I did not ask him to do the job. I attempted to modify the port myself as a learning experience. I forwarded him my modifications and asked him for feedback. The major difficulty was that I currently don’t have a running FreeBSD desktop available for testing. Nevertheless, it worked out pretty well.

Anatomy of a Port

A FreeBSD port is basically a Makefile that runs the show; a distinfo file that lists the source code packages and their checksums; a pkg-descr file that describes the port; a pkg-plist file that lists the files that the port will install on the system; and a files folder that contains modification to the source code and other detail changes to make the package conform with FreeBSD standards.

Makefile

Besides some administrivia such as the version and revision of the port, the most important part of the Makefile are the dependencies. Specifically, for Hugin-0.8.0 we added a build dependency on GLEW and an optional dependency on LaPACK. This second one apparently did not work because of some undefined symbols.

What I did not notice in the Makefile, and that Vasil fixed, are the improved man pages. And some post-configure tasks. The complete changes are here.

distinfo

distinfo was the easiest to fix – just download the tarball from Sourceforge, check its size, run the md5 and sha256 tools to get the checksums. I got it 100% right.

pkg-descr

pkg-descr has not changed.

pkg-plist

We’ve added quite some files between 0.7.0 and 0.8.0 and there is no automatic way to generated this file. Vasil shared his trick with me: he does a make PREFIX=/tmp/foobar install and then checks the files under /tmp/foobar (assuming it was non-existent before)

files

There are currently five patches in the files folder that will be applied (and a few more outdated ones in the “Attic”). I see Vasil has updated two of them following my poking. I have not spent enough time to understand them all, but it seems to me that some of them could be adopted upstream. I’ll investigate.

Current Status

I don’t have access to a FreeBSD desktop to verify if it works. I would appreciate feedback from FreeBSD users. Does Hugin-0.8.0 work for you?

Upgrade: 9.04

Today I upgraded my last box to Ubuntu 9.04. It’s my test box and media player, an energy efficient Intel Atom motherboard in an old Mac Quadra box sitting next to a color calibrated 47″ LG LCD TV (the easy way to get an S-IPS flat panel without paying the Apple tax or playing the panel lottery). It was a pleasant surprise: previous versions had issues with the Logitech diNovo Edge keyboard, requiring me to unplug and re-plug the USB-Bluetooth dongle after booting. Now it works like a charm with Kubuntu.

After the glitches I experienced a year ago upgrading to 8.04 my share of time spent in Ubuntu has diminished considerably and for all practical purposes I skipped on 8.10. Kernel upgrades broke VMWare; driver upgrades broke my dual screen display configuration; Wine upgrades broke emulation of Photoshop/Windows. Nothing that can’t be fixed, but every minute spent maintaining the system is a minute of lost productivity. I needed remarkably little effort to keep Windows XP going on my workstation, despite repeated abuse such as booting it from within the VMWare environment.

With 9.04 the glitches seem to be a thing of the past, at least for now. I replaced VMWare with Virtualbox and it has withstood a kernel update, dual screen works like a charm. We’ll see how long I will last this time.

In the end, the choice of system is driven by the use made of it. And for most applications there are solutions on every major platform. I favor platform-agnostic software whose behavior is 80%+ consistent across systems: learn once, use everywhere.

For basic office work, email and web access, OpenOffice, Thunderbird and Firefox feel pretty much the same on Ubuntu and on Windows and are mature, production grade tools. Free software works, and in some cases it can even be the 800 pound gorilla in the pack.

So the choice of system boils down to the infamous “killer apps” – applications that are so desirable that they determine all other choices:

  • Photoshop is a killer app for me. Not because what it does is unique, but because I know it so well that I am now faster than on any image retouching application. I’ve tried to use the GIMP to produce the upcoming group photo for Libre Graphics Meeting and failed miserably. I spent hours trying to figure out how to do things that in Photoshop are instinctive to me. After wasting a weekend trying hard, I realized that the result is more important than the tool.
  • SONY Vegas Platinum has become a killer app for me in the past few months: I love my camcorder but the bundled software is useless. Looking for usable software to edit AVCHD videos (mostly home videos) I found that SONY Vegas Platinum had all I needed with an intuitive user interface and at a reasonable price tag. It’s cool to edit movies rather than fiddle with system libraries and other stuff to try to make something work. The downside is that it is available only for Windows. Bassam’s speech at LGM inspired me to try Blender. Blender’s user interface may seem intimidating at first, but dip the toe in the water and you’ll find that it is very consistent, well thought through, and connects efficiently the user with an extremely broad and complex set of functionalities. And, oh, it’s platform agnostic!
  • And so the killer app that got me onto Ubuntu again? MathMap. Although a Windows alpha version is out there, it is much easier to build and install on Ubuntu. And I was going to use the notebook for a presentation at LGM.

MathMap motivated me to refresh the Ubuntu installs on my workstation and on my notebook and to give myself another chance at trying to make the switch to Ubuntu. And on the server? FreeBSD rules!

Out of order

I try to automate as much of my process as I can – time is too short to do manually what a computer can do automagically. One of my favorite tools for such automated processing is ImageMagick. It runs on a FreeBSD server in the closet. I drop my stitched panoramas via the network at one end and at the other end I get a whole bunch of output formats. When I need a new type of output, I just update my scripts and run them all over my archive of images.

I regularly update the server. The FreeBSD ports collection is one of the best things I’ve ever seen for system upgrade and maintenance, I have been a happy user for years. The nature of the system is such that sometimes a package will break despite the robustness of the ports system as a whole. When it does, careful analysis is required. Is this a problem of my specific system configuration or a bug with a software package or library? And if it is a problem of a software package or of a library, which one is it?

After the last upgrade to ImageMagick 6.4.1.8 my engine broke down. Before filing a bug report with ImageMagick I looked for confirmation from other ImageMagick users on the Magick users mailing list. Is it a problem with my specific system, or with ImageMagick? I don’t know yet.

I was surprised to say the least by this reply asking me to file a bug report on a web based forum. Web based forums don’t even work as proper mailing list replacement (can’t read/reply offline). Now they are supposed to replace a bug tracker?

Compare it with dedicated bug trackers like the SourceForge bug tracker (not the best one) that we use for hugin; Bugzilla used amongst other by the Mozilla foundation and Gnome; trac used amongst others by WordPress and wxWidgets.

Can a web based forum keep track of the status of a bug? assign it? prioritize it? find duplicates? close a bug?

17 pages, 814 topics (bugs?)! that looks like a lot of noise to me. Purge! A bug tracker should only list relevant information, and if there are 17 pages of open bugs against a package the size of ImageMagick, something is badly broken. Web based forums smell stale.

I wish I had the time and resources to confirm if the problem with manipulating TIFFs in ImageMagick is specific to my box or a bug in the code, and to file a bug report if necessary. Unfortunately I currently lack the time and resources. I found a workaround for my specific situation: GraphicsMagick. In my glue script, it worked as a drop in replacement for ImageMagick. And it has a bugtracker where I can file bug reports without the nuisances of a web based forum. I will get back to ImageMagick when I have the time to make my system work again with it.

Bare Metal

Antec 900Bare metal recovery. The equivalent of of a nuclear accident in IT terms. It happened to me on Monday.

Once again I hit the ceiling of my server’s storage capacity. I was going to add two new terabyte disks. I shut down the server. It has been in operation for over twelve months and needed a cleanup. After adding the drives, I turned it back on. The system drive was dead!

Drives die inevitably, this is why RAID is such a good thing. I keep all of my data in RAID, but not the system. It’s a box that can stand a little bit of downtime, and setting it up from scratch is always an opportunity to clean up and improve it. An upgrade was already planned for later this year, but I had no choice now.

The ten year old Dell XPS-T500 has served me well. It has been upgraded many times, but the core is still the old Pentium III, the SuperMicro disk rack was stacked on top of it with cables dangling all over, and it was painfully slow when rendering VR – although this happened in overnight batches, so I did not really mind.

While the new box was on transit with UPS, I quickly loaded FreeBSD on my old spare workstation (AMD Athlon XP 2500+). It will become my next server. The data migrated overnight. 2x250GB + 2x500GB moved over to the new 2x1TB. No data was lost.

I always use RAID1 for storage even if it is less space efficient than RAID5. In a RAID5 configuration the controller is the single point of failure. The disks are useless without the specific controller. With RAID1 I can simply connect one of the two disks to the onboard SATA controller of any motherboard and access all the data. Not all RAID1 can do this, but the one set up on the RocketRAID 2220 can.

The box arrived today. It’s an Antec 900. A gamer’s box. Just perfect for a server with its nine 5″25 bays and huge cooling capacity. I had to modify it a little bit to accept the SuperMicro disk rack, even if the two front loaded cages are in the same 3×5″25 form factor. Besides that, the physical install went well. There are now nine drives in that box, and I will continue to phase out the older, smaller drives for newer, larger ones.

I planned to wait for FreeBSD 7 (which is currently at the 7.0 release candidate). Instead I installed FreeBSD 6.3. It was the opportunity to upgrade it to MySQL 5.1, and to Apache 2.2. With the documentation from the old setup, 80% functionality was restored within a few hours. Tomorrow is business as usual again.

FreeBSD port of Hugin and Enblend updated

Vasil Dimov recently upgraded the the Hugin port in the FreeBSD ports collection. He has also taken responsibility for the Enblend port in the FreeBSD ports collection who has been without official maintainer for more than a year.

Users of FreeBSD can now experience first hand the new functions.

This is another sign of the growing interest for Hugin and a testimonial to the level of maturity that the current code base has reached ahead of the nearing official release.