posted by Robert Minvielle on Mon 22nd Sep 2003 19:29 UTC
IconEarly last week I received an AMD Opteron 240 and an Asus SK8N motherboard. I was so anxious to get Linux on it I could hardly sit still... A week later, Linux is on it, in 32 bit mode only, and my hard drive has informed me that if I reinstall again it is going to go on strike.

I will first describe the hardware in general terms, since it has been reviewed in detail at various locations on the net, and then I will go into the good, the bad and the ugly of running Linux for the AMD64, aka Hammer, aka Opteron.

The AMD Opteron chip is a marvel of silicon technology no doubt. The first thing we note is that unlike the AMD XP series, the die is concealed in a metal casing which covers almost the entire package. Unlike the previous CPU's, there is no "notch in the pin layout" on the bottom, but a tiny notch in the package itself with an even smaller arrow pointing to the pin that corresponds to the corner of the ZIP (Zero Insertion Force) socket for proper alignment. There are a few pins missing on the bottom in a non ambiguous way, but obviously forcing it would be hazardous to its health. The heatsink is (relatively speaking) gigantic and heavy. The model I received was an Opteron 240, non-oem (e.g. the "Processor in a box" according to AMD) and therefore the heatsink and fan were included, along with a nice full color instruction set on how to install the mounting bracket (it was already installed on the Asus), CPU and heatsink. The heatsink has a fairly standard mounting clip, with the addition of a locking cam so that it can not come off, and the installer is pretty much certain it is in once the cam is locked. The heatsink-cpu combo is very heavy. so heavy in fact that the mounting bracket (in my opinion) really serves to keep the motherboard from flexing or breaking under the weight of the heatsink. The heatsink itself seems of good construction, with Al fins and a Cu bottom plate. The fan is not as loud as I expected also.

The motherboard has been reviewed on the net, so only brief points are noted here: Seems like any other motherboard (generally), of interesting note however is the very small heatsink on the Nforce3 chipset. It does not get very hot in operation also. Layout is nice, with the power supply connectors out of the way. Electrolytic capacitors and small heavy gauge wirewound iron core inductors abound on this motherboard, indicative of the power requirements and low noise in the voltage rails required by the Opteron. The only other point of interest is a funny locking clip on the AGP slot, which was a real pain to close as my video card extended well past the end of the AGP slot. I ignored this as long as all the pins on the edge of the card were in the APG slot.

As stated in the into, I will recount my good, bad and ugly experiences with this setup, first however, a little background on what else I am using and my previous bleeding edge experience. Also, I will go in reverse order, presenting the ugly, bad and then good, and final comments.

My AMD Opteron/Asus rig: This motherboard-cpu combo replaced my old ABIT-AMD XP (1.6Ghz) setup in my main machine. The case is a Lian-Li PC60 case, Enermax 360watt power supply, Nvidia GeForce4-TI (by MSI), dual 3Com 3c509 boomerang nics, old Adaptec SCSI-UW card, Yamaha SCSI CD-RW drive, and two Maxtor 20gig 7200 rpm drives. (I am a little behind the curve in storage, having replaced my 4 2.1 gig SCSI UW drives a while back). There is also a Lite-On IDE CD-ROM drive for installing software at high speed. All fans in the case are active, and the system runs cool and was rock solid (with the ABIT setup).

I am not a newcomer to the 64 bit world, and I have in fact been running old Sun Ultra machines with Solaris, and also an IBM RS/6000 machine. I have also installed Linux on the Sun machine(s) in the past. As far as bleeding edge goes, I have not been on it in some time, and the last I can recall was getting an AMD K6 right when they were released, having been stuck on a 486/25 for some time. I am not new to kernel hacking, nor am I new to having to compile and modify drivers and software to get it to work under Linux. That experience still did not prepare me for the little things that could not easily be circumvented in this situation.

The ugly:
Having built my own systems since as long as I can recall (getting a kit in for my first computer and breaking out the soldering iron), I am not new to system building, nor to receiving broken parts. That said, the ASUS arrived DOA. Ok, I can deal with that, I have received a bad motherboard from almost every manufacturer in the past, no biggie. What was a biggie was that the vendor was back-ordered for weeks, as I apparently received the second to last one in stock. I ordered another one from a different vendor, and it arrived two days later. It failed to work also, but this time the motherboard was not DOA, but giving me a RAM error beep code. Strange, I purchased 1 GB of Crucial memory explicitly for this motherboard. (PC2100, DDR, ECC, Registered) I put the ram in the Abit and it worked perfectly. I then noted that I had PC2100, ECC, Registered ram in another machine (two 256 MB sticks from Crucial also) and they worked in the ASUS SK8N. Strange, a call to Crucial and the tech said the same thing "Strange, that should work Sir, especially if the others (same model it turns out) work". A friend of mine claims he had a similar experience with ASUS in that they did not play well with 512 MB sticks. I also upgraded the BIOS with the 256 MB sticks in it, but that proved useless also, with the exception that I am running the latest BIOS now. Ah well, I want to play with it, so I move on.

The BIOS is interesting, as it has some nice built in over clocking features (which I was not about to play with on my new $240 CPU), and another interesting note is the lack of boot device order options. I merely state this as it has less than my other machines (e.g. boot order is: CD, Floppy, HD0, HD1, etc). Other than that, it seems pretty standard.

First choice of the matter, which Linux distribution do I put on my shiny new system? I have heard that Suse, Mandrake, Redhat (beta), and Gentoo have ports. I was running RedHat and also have run Gentoo on my previous ABIT so I grab the Gentoo CD while I have RedHat beta (Taroon-AMD64) downloading on another machine.

The bad:
The Gentoo install was fairly painless at first, and there was no appreciable difference. The initial dmesg output showed an Opteron 240 and 1MB cache (what a good feeling). I will note, however, that something seemed sluggish. It seemed like transferring files or writing to the drive was slow. After the stage3 tar-ball was on the drive (see http://www.gentoo.org under installation for more details on stages), I tried to download a kernel to build, but this resulted in it telling me the image was masked. Apparently the KEYWORD option in the make.conf file was set to the default and it did not match certain kernels. In fact, a lot of packages in the portage tree were not ported yet, and therefore did not (by default) want to emerge with the amd64 keyword. I quickly downloaded the vanilla-source tree and was on my way. The rest of the install went fairly smooth (after I found out about the emerge issue) and I was then rebooting, anxiously awaiting my 64 bit bliss. Upon rebooting it crashed and burned. It would not boot at all and was kernel panic'ing on me. Grabbing the Gentoo CD and going through the install again, I hopped on the #gentoo channel on IRC from the second terminal after emerging an IRC client (now that is nice, getting support _while_ you are installing on the machine you are installing on). It just so happens that a Gentoo developer was online who was playing with the 64 bit system also. They informed me of a few important notes which I share here:

1) only the 2.4.21 kernels have success, not the newer ones under gentoo. 2) I can forget the Nvidia Geforce4, or any other Nvidia chipset video card. The Nvidia driver from the Nvidia site fails miserably, as I found out personally later on. 3) drive access is poor, since it defaults to PIO. The Gentoo developer did provide me with a patch for the amd7xx source code which fixed this issue.

Table of contents
  1. "Intro, the ugly, the bad"
  2. "The bad continued, the good, conclusion"
e p (0)    59 Comment(s)

Technology White Papers

See More