Another FreeBSD server upgrade…

A few years ago, I wrote about how I upgraded my FreeBSD server. Well, a few days ago, the computer seized up, and it no longer wanted to boot. I could turn it on, and the fans and HDD started spinning, keyboard leds would light up, but there was no display output. It also did not start the boot sequence (I normally run it without a monitor anyway, and it will boot up FreeBSD without any user intervention if you just turn it on).

So, that didn’t really last long, did it? Less than 3 years. Which is rather ironic. Most of the machines I described in the previous blog have run for longer than 3 years, and many of them still run today, or at least could be made running if I installed a working PSU. And they were not new to begin with. This was the first time I actually bought a new system, and it is also the first time that it dies on me for other reasons than obvious wear from HDDs or PSUs of more than a decade old.

It was rather difficult to diagnose the exact problem, and also mostly irrelevant. I first tried another PSU on this board. But it did not do anything more than with its own PSU. I then decided to test the PSU on another board, and that board booted up fine. I also hooked up the HDD to that other board, so that I could see if it still worked, and at least temporarily get the system back up so that I could access its data. The HDD appeared to be fine.

So that means the problem is either with the board, the memory or the CPU. I tested with some other memory in that board, and it did not make a difference. I figured that the memory probably was not the issue then, so I didn’t bother to verify that it worked in the other board. Even if it was bad, I’d still have other memory, and the memory would not be the only problem.

So it would come down to either the motherboard or the CPU. Well, in theory I could have tested the CPU in the other board, since they are both socket 775. But I didn’t quite feel like removing the huge cooler on there, and messing with thermal paste and all that. So instead I decided to take a gamble. I would just buy a new board for this system, because in my experience it is extremely unlikely that the CPU goes bad. Motherboards, especially cheap ones, have a tendency to die, or at least damage though.

Killing two birds with one stone

I decided that if I had to buy a new motherboard anyway, I could select one that could also be used as an on-site machine for work assignments such as dome projections and such. The machine we currently use for that is getting rather long in the tooth, and is not capable of HDMI capture whatsoever (HD capture is only possible with a PCI-e card or USB 3.0 device, and the board has no USB 3.0, and only has one PCI-e slot, which we need for the videocard, since the onboard video is very weak), so we are stuck with analog PAL images. We were in the process of building a new machine, but we more or less had our hearts set on AMD’s Trinity APU, since its quadruple monitor capabilities and relatively powerful GPU make it very interesting for our specific needs.

The problem with Trinity is that it is not for sale yet (there have been some OEM systems from HP and Acer, but I have not been able to buy those here either). For a moment I entertained the idea of building a Llano system in this case, but it did not work out favourably. The system still uses DDR2 memory and an IDE HDD and DVD-RW (which were surplus articles, in the true tradition of Llano systems are incompatible with this, so I’d have to replace everything except the case and PSU. Since it is nearly the cost of a full system, I would want to invest that kind of money in a Trinity rather than a Llano-based system, since it will give significantly better GPU performance, at probably the same price-point.

So I figured I’d just try to fix this system as cheaply as possible, and just get a replacement socket 775 board. What I wanted was at least one PCI-e 1x slot, so I could use the Blackmagic Intensity HDMI capture card that I bought a while ago, but haven’t been able to use on-site yet, because of our outdated machine not having a spare slot for it. I also wanted a PCI-e 16x slot, so I could use a discrete videocard to add extra video outputs, and offer extra performance, since the onboard video would be Intel, and probably not really fast enough for our needs, other than for the GUI view of our app. I also wanted some USB 3.0 ports, so that I can connect additional HDMI capture devices. And it still had to support IDE, so that I did not have to get a new HDD. And of course, it had to have an ethernet adapter onboard for its server duties, preferably 1 Gbps.

Killing a third bird

As I started looking at socket 775 boards, I quickly concluded that DDR2 severely limited my choices. DDR2 was generally only supported by older boards, which also had older chipsets, so slower onboard video, and no USB 3.0 either. However, DDR3 memory is quite cheap. Also, I still have that other Core i7 system with rather flaky memory. Increasing the voltages made it quite usable, but it never was 100% stable. Especially during very hot or very cold days, it could act up a bit. Now, if I would replace that memory with a set of 2×4 GB sticks, which can run at 1.5v rather than 1.65v, it should make things a lot more reliable. I could then use two of the four 2 GB sticks in the other machine, and run them at 1.5v as well. They are still rated 1333 MHz at 1.5v, so fine for any socket 775 system.

So, now that I had given myself the choice of DDR3 boards, it was much easier to find one that matched my requirements. I ended up with an Asrock G41MH/USB3 R2.0:

This is the first-ever Asrock board I’ve had, and so far I quite like it. It seems to have good build quality (looks a class above the flimsy Asus I took out of the barebone at least), and it has good tweakability. Also, the PCI-e 1x slot is *above* the PCI-e 16x slot. On some boards I’ve see, it was below it. Which meant that if you were to use a dual-slot video card (which most of the ones we’d be interested in would be), the PCI-e 1x slot would be blocked, and we’d STILL not be able to use the HDMI capture card.

My assumption was correct: the CPU was in perfect working order, and I could boot up the system without a problem once I had installed the new board.

And also, my hunch about the memory in the Core i7 seems to be right: I replaced it with Corsair Vengeance memory, and now the IMC can run at its stock voltage of 1.10v, and the memory can easily run 1600 MHz at 1.5v. The memory I have is actually rated at 1866 MHz with 1.5v, but 1600 MHz is the highest speed the Lynnfield IMC will do without overclocking the CPU. So for now I have decided to stick with 1600 MHz. So I get the same performance as before, but without having to stress the IMC with high voltages. It has been running like this for little over a week, and so far I have not had any problem, despite some VERY hot days.

To FreeBSD or not to FreeBSD, that is the question

Although the hardware was now in order, the software was not. The first issue I ran into was that although the HDD could boot with the new machine, the IDE controller had different /dev entries than the previous board. So it stopped booting after it loaded the generic kernel, and I had to manually mount the partitions from there. Annoyingly enough, by default it mounts / as read-only. So I had to re-mount that as read-write (which luckily can be done without rebooting and extra hassle) before I could edit /etc/fstab to fix the /dev entries for all partitions.

The second issue was rather more annoying, and is more or less related to one of my pet-peeves with open source software: the lack of a stable binary environment. Namely, although the Asrock board comes with an onboard Realtek 1 Gbps NIC, it did not come up automatically. After some investigation, I found out that it did indeed detect the device, but the driver could not be loaded because my chip reported a revision that was too new for my FreeBSD 8.0 installation.

This meant that I had only two options:

  1. Upgrade my entire installation to a newer version of FreeBSD, which should contain a  compatible driver.
  2. Build the driver from source.

I decided to go with option 2 first. Which in itself is difficult enough. I had to grab an old Intel 100 Mbps PCI card to get the thing onto the network in the first place, so that I could get the proper files on there.

I grabbed the source files from Realtek’s own website (how nice of them that they support FreeBSD at all), and followed their directions. Which was to build a new kernel, where the Realtek driver was disabled, and instead build their driver as a module, and then use kldload to load the module on-the-fly.

This did not quite work as advertised. I had the latest source code, but it still refused to give me an re0 device. Apparently it still suffered from the issue that my revision was not included in the list. So I tried to edit the code manually, and build the module again. This time I did actually get it to the point where re0 appeared in the ifconfig list. However, it always reported a ‘link down’ status, so it did not actually work.

At this point I’ve just given up, and decided to stick with the Intel card until I have some time to do a complete upgrade. But oh how much easier would it have been if FreeBSD was a bit more like Windows in this respect. I installed Windows 7 x64 on a second HDD, for the work plans we have with the machine. And although Windows 7 did not include drivers for this apparently very new Realtek chip either, I could just download some binary drivers and install them, and the network was up and running in no time. Wouldn’t it be nice if you could just download working binary modules for your hardware? And not having to recompile your kernel to actually REMOVE drivers from it? Let alone having to update your entire OS because apparently older kernels can not be made compatible with newer hardware in any way. And what is old, really? I am running FreeBSD 8.0 AMD64, which is about as old as Windows 7 x64.

This entry was posted in Hardware news, Uncategorized and tagged , , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Another FreeBSD server upgrade…

  1. snemarch says:

    Hm, I actually thought FreeBSD had a pretty stable ABI, also for kernel-mode?

    Doesn’t help a lot, though, when the driver is built into the kernel, and thus can’t be upgraded *just* by installing a new loadable module 🙂

    • Scali says:

      Well they might, never really looked into that, since the drivers are not distributed in binary form in the first place. Which I think they should be. Also, all (or at least most) drivers should be loaded as modules, to avoid issues like these.

      But the biggest problem is that you apparently need to update your entire kernel tree before you can build the proper drivers in the first place. That’s a nasty dependency, even if it would be artificial (which is hard to verify).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s