Linux PC 2007 ("Blackbird")

This page describes my way to a very special machine, based on a Zalman TNN500-AF heatsink case, therefore completely fanless and consequently almost noiseless (there's still the hard drive, but if you pick a silent one like a Seagate Barracuda that's not really an issue). Selecting the right components is a major headache, though, and you can run into all sorts of unexpected problems, so I thought this page might be helpful to people who'd like to tackle the issue. Before I start, I'd like to thank Andy Ford from QuietPC who spent quite some time answering a lot of my questions before I myself took the plunge, which was really a breath of fresh air in times of hotline monkeys who can read you their ten standard answers and nothing more.

Getting the case

The case is a very macho affair. Less deep than a regular midi case, but a lot wider (and heavier, 26kg empty), with two massive rows of cooling fins on either side. All cases come equipped with 400W passively-cooled PSUs (basically the PSU has one side of the case entirely to itself to keep it cool). CPU and graphics card are cooled via sets of 25W heatpipes attached to the case (6 for the CPU, 3 for the GPU and there's once for the northbridge, too). The case can thus cool CPUs up to 150W (although over 100W still requires a fan, apparently to keep motherboard components very close to the CPU alive) and graphics cards up to 75W. Which dates the case, obviously, since these days graphics cards tend to draw a lot more juice than CPUs. And these heatpipes pose a major problem when choosing components, because attaching these heatpipes to your components requires very specific mounting holes on said components and whether specific components are compatible with the case is very hard to find out other than by actually trying to install them. Zalman do have a list of recommended components on their website, but that's hopelessly out of date and therefore completely useless unless you're planning to build an oldtimer. So all you can do is search the web regarding what other people have used... and hope for the best.

The components

The assembly: oh the pain!

Right, next attempt. The adapter basically consists of two aluminium bars which you screw onto your motherboard and which provides the screw holes at the place where socket 939 coolers expect them, so that's that problem fixed... or so I thought, until I realized that the screws I got with the TNN for the CPU cooling block were much too short, so I couldn't attach the bracket. Since these aren't metric screws, I failed miserably in my attempt to get longer ones here in the munich area (OK, some shops were also closed since this was shortly after christmas, but I don't think I'd have had a lot more success at any other time). So now what? The TNN screws thicken in the middle and that's where they'll sit on the CPU bracket. In other words, if you widen the screw-holes of the CPU bracket (only about a millimetre will do the trick), the screws will be too long all of a sudden; that problem can easily be solved with a couple of washers, though, so when operation "longer screws" failed I got a steel drill and some washers instead and fixed the bracket (another delay of a couple of days while I pondered the problem and alternative solutions). So now at last the CPU cooler will fit perfectly... wrong again, but this time fortunately only very slightly. The problem is that one of the screws also has to fit between two heatpipes and Zalman designed this so "perfectly" that the slightly thicker part of the screw is already too much to fit between the heatpipes without strain. The two innermost heatpipes will therefore end up slightly bent, which'll compromise their performance somewhat. Not really an issue for me, since the Athlon X2 4600+ EE CPUs are rated at 65W TDP and the 6 CPU heatpipes deliver up to 25W each, so even if the two middle ones stopped working completely (which they certainly won't), I'd still have 100W of heat transfer capacity, way more than I need. You shouldn't install a CPU with TDP > 100W to begin with (since that'll necessitate a fan), so it's pretty much a moot point anyway. However, the moral of the story for me is: if you need the AM2 adapter, I'd recommend just telling the guys at endpcnoise that you want to use it in a TNN case and whether they can please include some longer screws; they know the case and I'm sure they'll do it.

So now, can we finally assemble this goddamn thing? Amazingly enough, the answer now is yes. So let's devise a strategy for the cooling blocks first of all. The big problem here is the panel over the rear motherboard connectors which'll establish a good, "professional" fit of the motherboard; unfortunately, this panel doesn't stay on the motherboard on its own accord and you'll need both hands to get the motherboard in the right place on the first attempt. Solution: duct-tape the sucker onto the motherboard via its little metal tongues. This really shouldn't be a problem even if you leave the tape there after you installed the motherboard (you mustn't attach the tape in such a way that it's visible from the outside, of course). Use real duct-tape as approved by terrorists, hijackers and other professionals who have to be able to rely stuff stays exactly where you stuck it, not some flimsy transparent film for office work and Bob's your uncle. Once that's done, attach the cooling blocks on the backside of the motherboard, in particular near the CPU socket and wherever else you see big FETs on the front. Make sure you stay away from soldering spots and other places that might cause a short. The adhesive thermal pad doesn't appear to be electrically conductive, but solering spots may pierce the pad and touch the aluminium of the block; two of these on one pad and you'll have a serious problem, so better stay clear from the outset. Another word of advice: don't use alcohol for cleaning the motherboard. I tried this carefully at a spot and the protective laquer immediately turned dull, so I quickly removed the alcohol again (no harm done, apparently, but clearly not a good idea in the first place). Once the blocks are in place, make sure the board will fit before removing the protective tape from the other side of the blocks. I'd also advise to get the screws which held the CPU cooling block in place in the empty TNN case; these are very long and also fit the holes for attaching the motherboard, so you can use these to make sure you guide the motherboard into the right place while still at a safe enough distance to avoid the thermal pads sticking to the case. With this approach, I found it pretty straightforward to install the motherboard without any problems at my first attempt (didn't even need another pair of hands); just don't rush anything and you should be fine. The CPU cooler should now be pretty easy to install and you can take some deserved time to admire this first and most fundamental stage.

Time for some serious problems again. The manual describes how to install your drives, which basically requires unscrewing some brackets, mounting the drives on them and screwing the whole thing back in. What the manual doesn't describe is the fact that these screws might have merged with the case on a molecular level, at least that appeared to be the case in my specimen. It's not that I was too weak, the screwheads were (they could hardly take the insane amount of force you had to apply to loosen them). After completely busting the first pair of screws in an attempt to loosen them and liberal amounts of cursing and sweating, I actually had to resort to WD40, thongs and a hammer! You know that dry, creaky sound a really rusty screw makes when it finally gives? These screws made that sound, and it was the sweetest music to my ears; the only sweeter sound would have been the choking death-rattle of the moron who fixed these screws in the first place should I ever get my hands on the motherfucker. The WD40 was probably the biggest factor in getting them loose at all, and I even managed to remove the busted ones with the thongs after enough soaking time. If you're running into the same problems: try to find the looser one of the two screws for each bracket (the one that Schwarzenegger can open on a good day, that is); if you can remove that one completely, you can tilt the bracket and that way loosen the other one. If you can't, apply more WD40 and wait, with a bit of luck you'll be able to remove all the brackets, which you definitely should do, at least I really wouldn't like the idea of having to give the case blunt force trauma when installing a second hard drive one day. Once all brackets are open, put some lubricant into the holes to avoid the same problems in the foreseeable future (if you'll have to remove the drives one day and find out the whole crap is fused again, you'll be in for some real problems). Why Zalman put such crappy screws into such an expensive and otherwise well-built case is beyond me. Is decent steel really too much to ask, did it have to be this pathetically soft metal screwed in by a lunatic and fused shut by the ages? Although this episode is now several months past it still gets my blood boiling and I'm planning to replace all of them with decent steel screws if I can find good matches (hoping these don't have a really exotic thread like the CPU screws). In hindsight, I'd recommend opening all screws (the ones holding the drive brackets as well as the ones holding the yoke over the PCI slots) before you do anything else, i.e. before you even install the motherboard; that gives you much more freedom with heavy tools should you need it. Why the yoke too? Well, Zalman put a metal panel over the PCI slot section at the back (with holes for the PCI cards), but if your card has stuff protruding close to the edge (like RME HDSP cards), you won't be able to insert or remove the card because the panel gets in the way. The only solution is cutting out a piece of the panel and in order to do that you have to remove the yoke, so make sure you can open the screws holding it down as well or you may have to turn heavy tools on a populated case if you get a new card which won't fit through the panel's holes. That aside, we're now only left with the northbridge. The Asus motherboard provides its own heatpipe/heatspreader solution, but that's designed for air-cooled cases, the heatspreader won't work in a TNN case. The rear-mounted blocks will take most of the heat to the side of the case, but it would still be nice to attach the case's northbridge heatpipe (a single one for a change) to the northbridge. I didn't manage to do that, since the heatpipe is a bit too short and the graphics card is in the way, neither can you easily connect the case's heatpipe with the motherboard heatpipe connecting northbridge and heatspreader because they're at a very awkward angle against each other, so this is the one thing I'm not quite happy with yet and will probably tackle sooner or later, although it doesn't appear to be a problem at all. Anyway, everything should be in place now and you're ready for the first power-up test.

Wait, what about the graphics card? I recommend putting it in with its factory-fitted fan for the time being. Some cards die quickly after purchase, which is rare but you'll have a far easier time getting RMA if you didn't modify the card yet. Once the whole thing ran for one or two weeks and survived some stress tests you can install the case heatpipes and enjoy the bliss of a completely silent PC while playing Doom 3 at ultra quality. Because the modification also belongs to "assemble", I'll describe it right away; but bear in mind that I did it after the machine had its OS installed and the card had to prove its metal during a Quake 4 single player campaign. The Gainward card is rather big (double-height) with a cooler to match. The cooler is quite easy to remove, just some screws and a spring mechanism slightly reminiscent of a mouse trap, and it can be easily restored should that ever be necessary (e.g. RMA...). The mounting holes were also in the right place (actually, the GPU blocks provided with the TNN case are quite flexible and support a lot of screw positions), so this card does install very well into the TNN case. The modification was unexpectedly simple -- ironically enough, since I expected the biggest problems here, but got them with CPU cooler and case screws instead. You'll probably have to play around with how to spread out the heatpipes so they don't bend too much, but that's about it. I ran out of Zalman-heatpaste while modifying the graphics card, though, so it was definitely a good idea I got additional paste on a hunch. Oh wait, one almost-problem: the motherboard's IDE-connector is very close to the GPU heatpipes (they'll definitely touch the cable). So if you need to use the IDE bus (like I do for the DVD writer), better make sure your IDE cable has some protection near the connector (most decent IDE cables do anyway). And to put the whole thing into perspective, the heatpipes don't get boiling hot on the outside even under heavy use, so the regular plastic protection commonly used on the better IDE cables should be perfectly fine, but avoid cheap ones where the data lines are only protected by their insulation.

Ready? Hold your breath and power it up. What a relief to see the BIOS screen and all components listed correctly after drills, hammers, thongs, WD40 and enough swearwords to make a sailor blush. This concludes the hardware section, so what are my conclusions as far as the assembly is concerned (for views about the finished product see conclusions, this section only concerns the assembly)? It's doable for a private Joe, provided you work slowly and you're prepared to improvise as the need arises. It's highly annoying and an amazingly large amount of problems can manifest in areas where you didn't even expect them. If you're planning to build a TNN system yourself to save a couple of hundred bucks, I strongly advise against it; if you can afford the case in the first place, this savings really isn't even remotely worth the pain and is far better invested in someone doing it for you professionally. Things may have been simpler in ancient times when Zalman first released the case, their recommended components could still be found outside of computer museums, GeForce 6800 was top-of-the-line, screws also unscrewed and CPUs used more power than GPUs, but putting today's components into the TNN case without a dealer's luxury of having alternatives for everything at your disposal is very annoying work. If you can find a dealer in your vicinity who'll build/sell you a working TNN system, go for it and save your nerves. I couldn't, unfortunately, so I had no alternative but do it myself. I would have gladly paid more and avoided this procedure, but at least I got the machine I wanted in the end. If you decide to build one yourself despite these words of warning here's a final one: be aware that you might have to buy components twice, be it because they turn out to be incompatible (if the IDE connector on my motherboard was shifted by 1cm, it probably would have blocked off the GPU heatpipes completely; heatpipe blocks may not be attachable to CPU/GPU) or because you killed one (heatblocks on the backside of the motherboard in a position that causes a short or a makeshift "solution" for a bad heatpipe fit backfires and overheats something). If this sort of thing will rip a crucial hole in your budget, don't even think about building a TNN system. Don't think experience in building a conventional air-cooled system will be much help either, you really can't compare widely standardized, orthogonal air-cooling (components can mostly be seen independent of each other) with very specific, interdependent cooling in a TNN case. I think I was lucky as far as my components were concerned, except for the northbridge I could attach all of them firmly to the heatpipes and the temperature readings confirm a well-cooled system. It wouldn't have taken much to turn this completely on its head, though.

AMD64 Gentoo, or "the pain continues"

Initially, I was pleasantly surprised: the system booted straight into a Gnome environment without hassles and all my components were recognized out of the box, including my USB mouse (I didn't check sound, since I couldn't have cared less at this stage). So I tried installing Gentoo on my system (my first with Gentoo, so far having only experience with Debian and some classic Unix systems). And that's when surprises turned considerably less pleasant. I had the choice between stage1/2/3 installs, and since the documentation was rather nonexistent (unless you count reading all documentation on the Gentoo webpage, which, let's face it, is a bit too much to ask from new users, even ones fanatical enough to give a source-only distro a try), I just tried stage1/2 first. Bad idea, didn't work. So I entered this in Gentoo bugzilla as BUG-159795 and got the reply that stage2 was currently "a tad broken", but since stage1/2 installs were to be removed soon anyway, this wouldn't be fixed. Oh lovely, then why the hell is this option still available on the latest (at the time) LiveCD? OK, next attempt: stage3 installs, as the other options were apparently ruled out. So I started the stage3 installs using non-binary packages and all ran OK for quite a while but then aborted while building libusb. So another Bugzilla report, BUG-159992, which basically told me to install manually. OK, so at this point it could no longer be ignored that the LiveCD was almost completely useless. One more try: stage3 install using binary packages -- although an utterly pointless configuration, since if I wanted a binary distro I'd have picked one in the first place. In keeping with the LiveCD quality hitherto experienced, this too aborted installation, IIRC in xclock or something equally "critical". You'd think the installer could tell a critical error from a minor glitch, but unfortunately it just breaks, sends hours of emerging down the drain. In addition, the log window was so badly programmed that it was almost impossible to select anything in order to paste it into a bug report or anything (probably not a coincidence), because the window polled for new output a couple of times a second and cleared the selection, regardless of whether there was new text or not. The only solution was being very quick in clicking on "Select All" in the window menu, followed immediately by CTRL-C (for copy-to-clipboard). Anyway, the conclusion is quite obvious: the LiveCD installer is a completely useless piece of garbage. Well, OK, you can use it to partition your drive, but that's it, really. That still makes it one of the biggest pieces of crap I've ever had the misfortune to come across.

Right, final attempt: manual installation as described in the Gentoo handbook. This actually worked as described, at least up to the point where you get a system that's actually bootable so you can scrap this piece-of-crap LiveCD and speed up your process by orders of magnitude. One of the many annoyances of the failed attempts to get a stage3 install out of the LiveCD installer was the download of the stage3 tarball every time you gave it another try, so if I wanted to avoid downloading this 130MB tarball every time (on a 2000Mbps DSL line at the time) I actually had to have a second machine running which served the tarball locally. But as soon as I tried to emerge my system, things ceased to work as described again because apparently Portage, the Gentoo package manager, is unable to resolve circular dependencies caused by USE-flags. I had specified a rather huge number of packages in my USE-flags because I was sick of my rather dated Debian system at the time, so I had a few of those. Like lots of packages depending on Doxygen because I had added doc to my USE-flags, but Doxygen itself depended on lots of these packages (directly or transitively), so it wasn't possible to emerge my system that way. I had to identify crucial packages by hand and try to break their dependencies by reducing the USE-flags for these packages. Another classic example was that emerging xorg required some OpenGL includes provided by Mesa, but Mesa in turn depending on xorg, resulting in a dependency deadlock which forced me to work in the console all the time (or have another machine running and working via ssh). The reason was that one Mesa plugin depended on xorg for mode switching or something, so I emerged Mesa without X support (USE="-X" emerge mesa), which then finally allowed me to emerge the X window system and leave the console. I got the whole system up and running that way eventually, but it was certainly much more work than I had anticipated, the blame for which rests firmly on Portage. It also took me a while to activate the device-mapper for encrypted home and swap partitions (so far I had used the cryptoloop and not the device mapper); in part this was due to the sparse documentation about this, plus some downright wrong examples on the net (physical and mapped devices swapped), and I also got the hash algorithm mixed up at some point, but I did get it to work eventually. The problem of the circular dependencies still doesn't bode well for Portage: a package manager must be able to deal with this sort of thing by automatically building packages with reduced USE-flags to break the dependency graph, then building them again with full flags afterwards. It's really a travesty that the user is left to do it by hand (and possibly forgets to rebuild packages with full USE-flags afterwards, which happened to me with emacs). The package manager could do a much more efficient job of it too, by identifying the minimal set of flags and packages causing the dependency deadlock, something you'll hardly manage on foot.

But I can live with this sort of thing if it pays off later when maintaining the system. I'm used to the fact that Unix systems are a bitch to install in such a way that they do everything the way I want them to (which is a lot more than slapping a bunch of standard packages on the system and calling it "finished"). So what about Gentoo in use? Well, the first couple of rounds of emerge --sync; emerge --update world went fine, but the sheer volume of updates (barely a week below 50MB) pretty much rules out Gentoo for anyone without flatrate DSL (which I have, but it's still worth mentioning). I also frequently got an absolute shitload of new config-files in /etc that needed updating; initially, I tried to deal with this by hand, which I really wouldn't recommend for two reasons: 1) it's tedious and 2) the likelihood of mistakes is very high and unless you did a very good job of keeping track of your changes you may end up with a severely compromised system. This happened to me because for some reason (which I can't for the life of me reconstruct) I ended up with a /etc/init.d/net script which was identical to /etc/init.d/net.lo and caused the system to hang during boot. No feedback why it hung, nothing in the system logs, it just hung (probably trying to parse the device from its filename (lo, eth0, ...) and not being able to cope with an empty result). I found out how to still boot the system via CTRL-C followed by interactive boot mode and tried to fix the problem for weeks before I was finally able to track the cuplrit with the aid of Gentoo Bugzilla (yes, something positive to say about it at last). Based on this experience, I strongly recommend you use dispatch-conf with a database of changes in the background. Why this system isn't part of the standard emerge cycle is beyond me, though. And there's another "tool" which really makes you question the sanity of the Portage designers: revdep-rebuild. After some updates, I suddenly found that a large number of programs on my system weren't linking any more because of a missing libdbus. Apparently this lib had wandered into glibc (or had been taken out, I can't remember the details) and anything linking against it ("only" about all the Gnome stuff, nothing serious) was no longer working. At another occasion, some lib had its version numbers upped and of course everything linking against the old lib didn't work anymore either. When I first came across this effect, I manually rebuilt some crucial libs and got things working again, but come on: you use the package manager to update your system and it becomes inconsistent in the process? Later on I found revdep-rebuild which automates this process, i.e. it looks for reverse dependencies, packages that need rebuilding after the libs they depend on changed, and re-emerges the packages in question. Which is nice and all, but offering this as a separate tool rather than something built into the very core of the package manager where it rightfully belongs is outrageous! What's the Gentoo philosophy here, pray tell? "We update your system, but consistency is optional"? Sorry folks, but what revdep-rebuild does is not optional, it's the most fundamental functionality a package manager must provide: keeping the system consistent at all times. Without that, I might as well scrap the package manager altogether and do everything by hand. ATM (May 2007) I can only use revdep-rebuild partially because unfortunately it has a bug that finds bogus linking problems in GCC (BUG-125728/179239) -- and since GCC takes over an hour (!!!) to build on this not exactly shabby system (probably twice the normal time since it's a multilib installation), it's really out of the question to just rebuild it on the side, so I can only use it to gather stats in --pretend mode. And isn't the difference in numeric values of these two bugs rather suspicious? Yes, if you look at the dates you'll notice that this bug has been known for over a year now, and still hasn't been fixed. Some people tried to solve it via symbolic links, but with mixed results. Speaking of GCC: currently the ebuild only uses one parallel thread and therefore wastes massive amounts of CPU resources on multicore systems (i.e. pretty much any up-to-date machine); BUG-179240, but again nobody seems to give a damn. So amongst other things a vital (and bizarrely enough external) tool of the Gentoo package system has been compromised for over a year and apparently nobody at Gentoo cares; jolly good, fellas, I think I'll pick something Debian-based again for my next machine.

Then, just when I felt comfortable with the system again, something really irritating happened: after a large update involving X-libs and a new X-Server (xorg-server-1.1.1-r5) I did on the weekend of 7/8 Apr 2007, I started Wine to continue my Far Cry game and all of a sudden tree textures at a distance were completely screwed up (an engine optimization which apparently reduces the distant trees to just a rectangle with a transparent texture, which becomes inactive when you get closer). I tried different Wine versions and all of a sudden the real bummer: right on launching Wine, the screen turned black and the system was completely dead, not even ALT-CTRL-F1 worked any more, only ALT-SYSRQ-[SUB] still worked (no blinking LEDs, though, so apparently not a kernel panic). Nothing in the system logs, just regular messages and then my SYSRQ-keypresses all of a sudden. I tried again and got the same result when I repeatedly ran Wine and Far Cry: it usually worked the first time, but then it'd total my machine. I'm pretty sure it only happened with Far Cry and not some other, equally shader-intensive games like Max Payne II. Nor were there any problems with native games, hours of Quake 4 produced neither crashes nor texture/shader bugs (so hardware defects were pretty much out of the question). I tried emerging xorg-server from the command line rather than an X environment to be on the safe side, but that didn't fix it either (it goes without saying that I always end my X-session and start a new one after emerging a new X-server, or after a large update involving X-related libraries). Temperature had nothing to do with it either, since the system was usually quite cold when these crashes occurred and they happened either right at startup or not at all. So I downgraded to xorg-server-1.1.1-r4 on a hunch and lo and behold: no more crashes, but tree textures in Far Cry remained screwed up. The following weeks saw massive updates to X-libs and also an update to nvidia-drivers, none of which changed the Far Cry texture bug. Then, on the weekend of 5/6 May 2007, there was another huge update involving X stuff, which unfortunately removed xorg-server-1.1.1-r4 from the portage tree, so I had the choice of trying xorg-server-1.1.1-r5 once more or downgrading to xorg-server-1.1.1. In the light of the massive updates of previous weeks, I decided to give r5 another try and guess what: 1) no more crashes and 2) the tree textures in Far Cry were perfect once again. Can anyone explain this to me? How can one system update cause drawing errors and complete system crashes in one specific program (Wine with Far Cry), while everything else I tried still worked fine, a downgrade of the X-server cure the crashes but not the drawing errors and a later update involving the exact same X-server which previously crashed the entire system for this program now not only not crash (which could be explained with the update of nvidia-drivers, I guess) but also miraculously cure the drawing errors all of a sudden? At this time, I was quite familiar with revdep-rebuild, so the system was consistent at every stage as far as system tools allowed me to know. So what was going on here and how likely is it to return? Was it a bug that only manifested with the older nvidia-drivers and the newer xorg-server? Clearly, xorg-server-1.1.1-r5 in itself wasn't the cuplrit since it didn't crash when I installed it the second time. Was there a problem in the 64->32bit emulation layer I have to use to run Wine? As far as I can see, the 32bit-X-libs haven't changed in months. I think I can comfortably rule out hardware defects since a system surviving torture tests like hours of Quake 4 or huge compile jobs during system updates without the slightest problems is fine on the hardware side. Either way I turn this problem, I can't make heads or tails of it and it's making me rather uneasy. Any way I turn it, I notice an interconnectedness that's rather unsettling. Maybe it was a one-off problem I'll never see again, but if it wasn't... Basically, I still don't feel really comfortable with Gentoo at this stage. Maybe I just picked a bad time, especially for the AMD64 branch, but so far reliability isn't quite what I expected; Debian was a lot better in this respect. It's still too early for final thoughts on this matter, though, I'll wait another couple of months before I do that. So far it was definitely a lot more work than I expected, and a lot more work than necessary due to totally broken LiveCD installer and vital package manager functionality offered as "optional tools". Let's leave it at that for now.

RME HDSP9632: more pain on the way

Well, the fact that the last posts regarding this card on the Alsa project homepage were about three years old, thus even predating Alsa 1.0, should probably have made me suspicious from the start, but I thought they'd at least bother to post additional problems that popped up since then... looks like I was asking too much here. Anyway, I couldn't get the card to work, or much more annoyingly: some bits of it appeared to work, but none of them correctly. For instance I could record from the digital inputs, but recording lasted twice the amount of time I had specified and playing back the recorded signal (via the working onboard sound) played everything twice as fast; when I tried to play something, the sound was played at half speed, but nothing could be heard. The additional programs hdspconf and hdspmixer frequently mentioned as part of the alsa tools/utils packages were nowhere to be found in my corresponding Gentoo packages either and the sources I downloaded didn't compile without modifications. When I ran them, they did recognize the card and displayed a lot of info about it (including noise of the analog inputs around -110dB and level of active playback channels), but no matter what buttons I pushed in hdspmixer, I got no sound out of the card. The main problem here is that the HDSP cards are highly complex to configure due to their internal mixer matrix, so if you misconfigured that (easily done), you won't hear anything. Plus one of the pages describing usage of the card under Linux mentioned the card providing an odd interleaved audio format that few apps understand, so considering there were no problems reported on the Alsa page and the half speed effects I described above, you tend to think you're doing something wrong rather than blaming the driver. When I still hadn't managed to get the card working after several months (games were a considerable distraction on this wonderful new toy, I admit, so I didn't spend that much time on the card, really), I searched the web again and eventually found a document mentioning firmware incompatibilities; add "firmware" to your web search string and you'll start to find the relevant pages which had up to then been buried in static. The gist of it is: firmware versions newer than 1.51 are unsupported by Alsa and cause the bizarre effects I described above. All cards currently sold have firmware 1.52 or newer and will therefore not work at all under Linux. The cards can be flashed down via the legacy firmware archives on the RME webpages, but flashers are only available for Windows (fut_win_dsp.zip) and Mac. It is therefore impossible to get current HDSP 9632 cards to work on Linux without physically putting the card into a Windows/Mac computer and reflashing it there (and to avoid making things too easy, using the flasher requires installing the HDSP drivers first, at least on Windows); these cards must therefore be considered unsupported under Linux. The fact that the Alsa project page doesn't mention this "tiny" problem with a single word (at the time of writing, may 2007) is outrageous! So after I had wished the pox on the responsible Alsa maintainers, I grumblingly went in search of a Windows machine and reflashed my card. This fixed the issues mentioned above, so I can now finally record and play back with this card. I still have a lot to learn about the mixer, though; I'll continue this section once I know more.

Temperatures (the pain takes a break)

Idle temperature readings, not terribly much to see here. No averaging, so you can see the rather erratic jumps of the raw sensor data. GPU is much hotter than the rest of the components, but as far as I know this is perfectly normal for this generation of graphics processors.

Temperatures during a long emerge --update world session (involving GCC again) followed by a half-hour cooling stage (basically leading to the idle temperatures in the first graph), averaged over 4 values. The log doesn't start from idle temperatures, I measured this shortly after a Far Cry session. Even during this huge sequence of compile jobs, the CPU doesn't go over 50 C.

Temperatures during a 90 minute session of Quake 4 (Ultra Quality at 1280x1024 resolution), using the SMP client. Values were sampled with 1s resolution and the plot shows the averages over 16 samples. Sudden drops in GPU temperature are times spent in the main menu or the loading screen between levels (I had a short break around the 50 minute mark, obviously). The CPU doesn't go over 50 C in this case either; GPU core is much hotter but still way below its critical limit, plus it drops to 55 C almost immediately as soon as you leave the game, only the further drop to its idle temperature a little below 50 C takes a considerably longer time (classic exponential curve, basically). After 90 minutes I had reached my most hated part of the game, the rail-shooter where you have to take out the missile launchers while the driver jerks you around to make sure you always hit air at the crucial moment, so I figured this was a fine place to call it a day. In case you're wondering what the CPU was doing after 100 minutes all of a sudden: I emerged a couple more packages, but continued the measurement nevertheless since I consider the GPU temperatures to be the most important aspect of this measurement.

The continuation of the Quake 4 campaign started above, in a giant > 5 hours session which took me from the hated rail-shooter to the end of the bit where you clean out the basement of Iron Maidens and other Strogg vermin. Settings were the same as above, but averaged over 32 sensor samples. Ambient temperatures very pretty hot that day, so this time around the GPU does reach 75 C, the CPU goes to about 52 C and the cooled down temperature is a little higher than usual as well. Still pretty good readings, IMHO.

And finally, the ending of this Quake 4 campaign, from the basement assignment to a busted brain in another 3.5 hour session. Settings the same as in previous Quake 4 readings, and again averaged over 32 sensor samples. Ambient temperatures were considerably cooler this time (what a relief, I hate sweating my butt off all day), so CPU and GPU stay about 2--3 C cooler than in the second session. Hmm... adding my playing times, that's around 10 hours for all of Quake 4; not bad by my standards, considering I wasn't attempting a speedrun or anything. Maybe I should play through Doom 3 again some time... just in the interest of science / temperature readings, of course ;-).

Temperatures during a 20 minute session of Unreal Tournament 2004, including a 10 minute cooling down phase, averaged over 4 samples; playing resolution was 1600x1200. Note the GPU temperature is considerably below that of Quake 4, although I had all quality settings pushed to max. Everything else is as already seen above.

Temperatures at the end of a longish session in the 3rd party level Trite Breeding Factory for Doom 3, at ultra quality in 1600x1200 resolution, sampling the sensors every second and averaged over 10 seconds. I had forgotten to write this to a logfile, so I had to grab it from the console, hence I only got the last 40 minutes or so. Ambient temperatures were rather hot, so the GPU peaks around 74 C at times, but it averages out around 70 C, and the CPU appears to have little to do all in all. Funny how time passes, the Doom 3 engine can hardly be called demanding any more even at ultra quality.

Temperatures during an hour-long session of Far Cry under Wine (versions 0.9.33 and newer, IIRC), averaged over 4 samples; playing resolution was 1600x1200. Note that the shader-heaviness of this game reflects in the GPU core temperatures which are a good 5 C above those on UT2004, even higher than the ones for Quake 4, which is particularily interesting since there's emulation overhead in this case that doesn't exist in Quake 4 and Far Cry actually predates Quake 4. The breathtakingly delicous looking water comes at a price, apparently, but boy is it worth it! I cut the cooling off sequence early, but as you can see it takes the same plunge as previous measurements.

Temperatures during an hour-long session of Stubbs the Zombie under Wine, again averaged over 4 samples and using 1600x1200 resolution. Pretty much the same as Far Cry, this game is very shader-heavy and pushes GPU temperatures up to 75 C while the CPU doesn't even scrape the 50 C mark.

Whoa, we peaked! This is the log of a two hour session of Stubbs the Zombie under Wine at 1600x1200 resolution, sampling sensors every second and averaged over 20 values. It was pretty hot again when I did the measurement and this time the shaders really pushed the GPU the furthest I've seen it so far, up to around 79 C. The remarkable thing here is that the temperatures show exactly the opposite of what you'd expect in an emulated game (high CPU load due to emulation overhead, low GPU load because the emulated machine can't feed the GPU as fast as a native one). But here the CPU appears to be doing less than in Quake 4 and it's the GPU that gets the thorough workout. Looks like most of the game is running on the shaders. In case you're interested: the session started with Stubbs getting his first tank and ends with about the tenth futile attempt to put an end to Andrew Monday (but fear not, in a second session later that day I finally cracked that nut, and a bloody tough nut it was).

Conclusions: I think temperatures are fine, if not excellent. GPU core temperature is maybe a bit higher than I anticipated, but modern GPUs are designed to take a lot more heat than CPUs and considering I'm still 5-10 C below the readings of QuietPC's 7950GT card and nvidia-settings reports the critical temperature for this card at 135 C, I guess I have more than enough headroom. These temperatures appear to be perfectly normal for this generation of cards, as confirmed by a measurement for a bunch of 7900GS cards done by AnAndTech. The idle temperatures for their cards ranged from 49 C to 55 C, load temperatures from 63 C to 73 C, which is roughly how my card behaves. Exact comparisons are hard to make because a lot of relevant information is missing, for instance ambient temperatures which can have an impact on idle temperatures in particular. Then what's your definition of an idle measurement? One where the entire system is idle or one where only the graphics card is? In the first case, my card is cooler (at 48 C, see first graph) than any of the ones AnAndTech measured; in the second case, it's still doing OK (at 54 C, see second graph). Then there's load... they measured a special demo for a mere 5 minutes and claim this was representative of long gaming sessions, which I have rather serious doubts about. Games like Far Cry, Stubbs the Zombie or Quake 4 don't give the GPU much of a breather either and even if I add about 2 minutes loading time at the start of my measurements, you'll see that my card is still barely touching 70 C around the 420s mark. They don't mention whether there were any delays (however small) between the end of the stress test and the temperature measurement and whether they did any averaging or just picked whatever value the sensor showed. Considering that my measurements were much more thorough and longer than theirs, I certainly won't waste any sleep over being a coupled of degrees hotter after 5 hours under real-life load than their hottest card after 5 minutes worth of synthetic tests. Anyway, I never experienced any temperature-related instabilities, the only crashes I had with this system were the ones I described at the end of the Gentoo section and those happened regardless of system temperatures. I suppose I must have done something right after all.

Preliminary thoughts and conclusions

Oh yes, and in case you're wondering why I called it Blackbird, this is of course in honour of the famous Lockheed SR-71 "Blackbird" strategic reconnaissance jet, which is also fast, black and extremely stylish, albeit a lot louder than my Blackbird...

And for a minute there I thought the pain was over...

Linux cryptography still run by retards

1. they changed a crucial keyword without thinking about the consequences this would have for anyone who overlooked the config file changes during system updates (very easily done, believe me, even if you noticed that there were changes in the config file);
2. despite changing the keyword, they didn't even think of extending the "parser" far enough to just abort on a syntactical error, which would have easily avoided disaster;
3. the parser is also too retarded to abort on obvious semantical errors like having multiple source specs for the same section. Again, this would have avoided disaster.

I thought things had gotten better in the past couple of years, but apparently the people involved in the Linux cryptography modules are still pretty much the biggest bunch of morons to be found in the entire open source scene. In the 2.4 kernel series, they made an incompatible change to the CryptoAPI from one minor kernel version to the next (2.4.21 to 2.4.22, IIRC), without an official/guaranteed way of reading old partitions with the new framework, thus making it impossible to migrate to the newer framework without first copying all your encrypted data to an unencrypted medium, which is completely unacceptable to anyone actually using cryptographic storage rather than just playing around with it. And now this combination of brainless maintainers and an equally brainless parser leading to a valid config file for one version causing busted partitions for the next minor version-- it's really hard to believe how retards like this are allowed anywhere near software development. And to all smartass backseat-drivers out there: I'm not complaining that overlooking a change of config file causes the package not to work correctly; I'm complaining that overlooking a change of config file causes irreparable damage because there were no precautions whatsoever taken to trap even the most obvious errors, although it should have been perfectly clear that there's a certain likelihood that older config files might be encountered. I don't have a problem with something not working due to an oversight on my part, but which I can fix after I found the error; only having one chance to get it right and having your partitions wiped if you don't get it right at first try is something else entirely. Would anyone accept a change like this for fstab, no matter what warnings are output during the system update? Fat chance. So I can only repeat: fucking retards!

And while the major fault lies with the cryptsetup-luks maintainers, let's not forget Gentoo either. The fact that something as fundamentally broken as this cryptsetup-luks update made it through their "quality control" by being unmasked is also a critical fault on behalf of this distribution. It should have never been allowed in the stable packages unless the maintainers added at least the most primitive attempts at error checking to their config file parser. I sure hope the Debian crowd will be smarter than this.

The many consistency holes of Portage, part 239847

Of broken motherboards and RMA procedures

With the PSU out of the equation, that basically left the motherboard as prime suspect, in particular in light of the clock oddities on one hand and the perfect system stability if the machine survived the boot process on the other. The mere thought of replacing the motherboard made me sick to my stomach, considering that the motherboard is a lot of work to exchange even in a normal system, and it's a lot more work in a TNN case due to the heatpipes and most of all the rear-mounted cooling blocks (the latter being one-way due to their thermal pads). Still, the motherboard had to go first, so I took on the arduous task of removing it from the TNN case one afternoon. This proved less of a problem than I had feared, though. Getting the CPU block off is a bit fiddly since thermal paste and pressure give it a rather strong suction to the CPU, but if you twist it a little here and there it'll come off without major problems. Removing the graphics card is pretty easy as well if you do it right: only open the heatpipe block on the case, then remove the card with its entire heatpipe assembly (which naturally includes the heatpipes). As far as the rear-mounted cooling blocks are concerned, it became obvious why they're one-way, with the thermal pads partly sticking to case/block/motherboard and generally speaking in no state that encourages reuse. That done, I filed an RMA with the dealer (HIQ24), at length describing the problem (switch off before POST, clock going haywire) and dispatched the package. I got a confirmation very quickly, but the fault description there was completely wrong ("board crashes and freezes occasionally"); I addressed this and asked for clarification but never got an answer. Then about 5 weeks passed without hearing anything about the board either. I used this time to find ways to reuse the rear-mounted cooling blocks, which basically meant finding replacement thermal pads which are thick enough and adhesive on both sides (unfortunately, Andy Ford couldn't help me with these). As I came to realize, these are practically impossible to find. The closest thing were Aquacomputer Ramplex pads which are about 1mm thick, but only adhesive on one side; still, I figured there'd always be ways to glue the other side, so I ordered a bunch or those (with enough spares for 2 motherboards). When I finally got the board back, there was the next oddity: no repair report, which I'd expect from any decent repair shop. Unfortunately I didn't have the spare components to actually test the motherboard without the extreme amount of work required to put the board into the TNN case, so due to lack of less work-intensive alternatives I took a deep breath one sunday afternoon and reassembled Blackbird. The biggest problem were the rear-mounted cooling blocks, as expected, since I found out that the Ramplex pads aren't really adhesive on either side, certainly nowhere near enough to hold the blocks in place during motherboard installation. I experimented around with thermal glue and duct tape, where in hindsight the thermal glue was definitely a bad idea because that requires rigid components to work, whereas the pads are flexible, which causes the connection to break at the slightest bending. In the end, I got everything in place, largely thanks to the duct tape, and once the motherboard was in place, the rest was quite easy (including the graphics card: if you removed it like I described above, all it takes to put it back in is basically adding thermal grease to the case block and sticking it back in). After something like 4 hours of very fiddly work, the machine was assembled again, and I hit the power button. It lit up, the drives spun up, and after about 3 seconds the machine switched off again. What the FUCK?!?

In the following days, I tried various things without effect: removing all drives, removing the front-panel connectors etc., but none of these fixed the problems. I thought I'd hit something when the machine booted again after I'd removed all front panel connectors, but when I tried again with the same configuration the next day, it was dead again. Little remark re. Gentoo: with all the delays involved, I had almost two months worth of system updates in the queue when I acutally managed to boot the system eventually, resulting in about 700 MB of downloads and around 7 hours of non-stop compilation for the updates; just to give people an idea about the update volume and time, should they consider using Gentoo. The system clock was still going cucko when I got the machine up and running, which fueled the suspicion that the board was still broken. Without spare parts to test everything else, there was little I could do save for either buying a minimum set of spare parts (graphics card, CPU, RAM) or buying a new motherboard and trying whether that would work with the existing components. I also searched the web for problems reported for the Asus M2N-series motherboards and came up with quite a few hits where people had exactly these symptoms across the entire range, so it looks like Asus really messed up with these boards. Consequently, I chose trying a replacement motherboard first, partly because it was still by far the most likely candidate judging by the symptoms of my board and other peoples' boards, and partly because a new motherboard was also the cheapest route (albeit the most work-intesive by a long shot). Since I wanted a smooth transition without having to reinstall a new kernel from a LiveCD just to get the board running, I chose one with the same chipset (nForce 570) but naturally avoided anything Asus like the plague. I eventually picked a Gigabyte GA-M57SLI-S4, which lacked some of the things the Asus board had, but I either didn't need those anyway (like a second ethernet port) or they could easily be addressed with a bracket (like an E-SATA connector); it did have one thing I needed onboard, though, which is a parallel port, thus all in all I gained about the same I lost. The board was also rather inexpensive (80 Euros in September 2007), so there wasn't much to lose (apart from my work hours, of course). Putting in the board went slightly faster than the last time, but not by much, since the rear-mounted cooling blocks still took a lot of work because most of them still relied on thermal glue which came lose when I removed the Asus board. But this time around I was smarter and did everything with duct tape, ensuring that the thermal blocks will be far easier to reuse in the future (may that day be many years off!). There was a nasty surprise regarding the CPU cooler bracket, which in contrast to the Asus board wasn't screwed in but held in place with some plastic contraption (which can be removed in a reversible manner, fortunately), so I couldn't use my Socket939-adapter unless I used the backplate of the Asus-board -- which I couldn't do, since it was clear that if the new board worked, the Asus-board would go back. I lucked out on that count, though, since rummaging through my "unused small parts and other junk" collection I found some of these things which look like the head ends of screws, but have an inner thread opposite the head, which fit the adapter's screws like a dream and were just the right length, at least after adding some thick rubber which I needed as insulation anyway. What I'd feared would become a haphazard construction thus turned into a basically perfect fit. Maybe a few additional words on the board layout are called for: some things are better than on the Asus board (like the location of the IDE-connector and everything's less cramped), some things are worse (like the location of the floppy drive connector at the bottom of the board, the front panel audio connectors at the back, or the screwholes of the motherboard, where the third column doesn't match the case's mounts -- I thought ATX clearly specified that kind of thing...?), so once again I lost about as much as I gained. The northbridge heatsink is a bit close to the graphics card, but on the other hand I think there may even be a way to connect the northbridge heatpipe this time. At the time of writing, the floppy drive still isn't connected because I lack a cable long enough to reach there and survive the opening of the TNN case, but that'll soon be fixed. The most important thing is: when I switched the machine on, it started right away, it booted into Linux just fine (apart from some clock and network interface issues I'll go into below) and it hasn't shown any signs of instability yet. So it should be pretty clear now that the Asus board was indeed still broken, the RMA-procedure just another hoax. I then made a mental list of my RMA-procedures in the past 5 years and came up with the following:

1. Plextor PX-W4012A (warranty, 25 Feb 2003): got working replacement drive free of charge
2. Unicomp Customizer Keyboard (warranty, 10 Apr 2003): got working replacement for DOA keyboard, free of charge
3. SilentMaxx PSU (warranty):
   • (21 Apr 2004): "repaired" PSU, DOA.
   • (14 May 2004): repaired PSU, now working
4. Plextor PX-W4012A (warranty):
   • (2 Nov 2004): got replacement drive free of charge, DOA
   • (12 Nov 2004): got replacement drive free of charge, DOA
   • (25 Nov 2004): got replacement PX-W52/24/52A free of charge, finally working.
5. Zalman TNN-500 PSU (warranty, 13 Jul 2007): got replacement PSU free of charge, working.
6. Asus M2N-SLI Deluxe motherboard (warranty):
   • (25 Sep 2007): got "repaired" motherboard after 5 weeks, DOA
   • to be continued

I'd also like to add that it's a very sad day for german customer service if it takes 5 bloody weeks to get back a broken motherboard (which I also had to pay postage for) where Zalman managed to send a working replacement PSU from Korea within a week, free of charge, no questions asked.

Further software issues to sort out

Everything? Well, of course not. When I shut down the machine after all of this, content with having everything up and running again, I got a kernel crash while shutting down Alsa, in the hdsp-driver module! Now that's a really nasty shock, I can tell you. The next day I tried accessing the Hammerfall-card with amixer, but as soon as I tried reading anything from there, the amixer-processes hung hard (no way of killing them). So I cursed, shut down the machine (which this time "just" hung indefinitely while stopping Alsa and once again went to bed with problems on my mind. Since the machine now worked correctly again even with kernel 2.6.20 (after network and clock problems turned out to be caused by other factors), at least I could finally use the machine after all this time. I searched the web and found that other people had this problem as well, which by the looks of it was caused by recent changes to hdsp.c, and some apparently managed to fix it via a firmware upgrade to 1.52 (which, as you may remember, was still completely unsupported and had to be downflashed to 1.51 in a Windows machine for the Alsa drivers available at the time I got this card). Since I didn't want to get stuck with the 2.6.20 kernel (the way I was stuck with the 2.4.21 kernel on bthunder due to CryptoAPI changes), I decided to file a bug report on the Gentoo Bugzilla (BUG-196612), which quickly traced the problem to an uncaught division-by-zero in the hdsp-driver and was resolved with a patch which should appear in gentoo-sources-2.6.22-r10 and upstream soon (both the official kernel sources and the offending Alsa-version 1.0.14).

So will the pain ever end?