Early 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.
Ok, now a recompile of the kernel, install it and reboot. Gentoo comes up and
64 bit is go! This great, with the exception of two small notes: a lot of
packages that I wish to install do not work, or crash and burn during compilation
. This could be a lack of knowledge on my part, but it was a little disturbing
all the same. The other real point of note is this: I need to work in X due to
the project I have to complete in graduate school and X will not work on this
box. I did not have any other video card to try other than a TNT, which will put me in the same boat. Even pulling down the AMD64 drivers from Nvidia did not work (as the developer said they would not). One person claimed to have it working, in 2d with no GL, etc, under the Geforce, but they also stipulated that no window manager would work other than the built in one for XFree. This was going to be a major problem for me. I look at my other machine and note that I am finished downloading RedHat Taroon-AMD64 beta. Here we go…
After a moment of thought I reboot the machine and stick the RedHat Taroon disc one in the drive. It boots, and launches the kernel, but then when it gets to the install, it “looses the interrupt” for the IDE CDrom drive. Since my SCSI controller is so old, booting from it is not an option. I found out from trial and error that if I take the CD off of the secondary IDE channel it works fine.
Ok, booting into RedHat install again and it all seems fine (except for the scary blood red BETA across the install splash screen in huge spray paint like fashion). After a hitch free install of RedHat beta I reboot. Going through the booting process I see that it can not get DHCP from nic2. Hrm. I am greeted with the “final steps in X windows (works in RedHat) and complete the install and login as root. BlueCurve greets me, but I notice something else… it is excruciatingly slow to read and write from the drive. Looking over the dmesg output I notice two things, I am in PIO mode on the IDE drives and the 3Com driver is not loading due to a PCI bus conflict. Hrm. Thinking back to the
night before, I decide to rebuild the kernel and patch the IDE driver as I did
in Gentoo. The source code itself for RedHat is different, but not hard to
figure out (they just go through more checking to see what chipset is being
used). I insert the appropriate modifications for the Nforce3, and also hack the
pci_ids.h file. I then note that the Nforce3 is listed already in that file.
Strange. I save all of those, double check them and do my normal recompile.
This crashes horribly. The kernel compile can not even get past the first few
items. It seems to be crashing on everything that gcc has to touch. I look
through the rpms and see what is installed. Everything looks good, but it seems
as though what they sent in the beta release does not correspond to the version
of headers and gcc that is distributed. I give it up to it being beta (as they
warn) and sit there looking at my new hardware. I have a choice to make.
I can either run this machine in server mode with no X windows under Gentoo and
have the high speed I/O, or I can have X windows under RedHat beta and deal
with it being slow. First, let us define slow: I copied the second RedHat Taroon disc from one drive to another (approximately 650megs) and it took over 6 mins, or roughly 1Mb/s. This is unacceptable. This can be fixed under Gentoo but not
under RedHat. Under Gentoo we have no X windows.
Idea: I will go and look for other distributions, recalling that I noted earlier
that Mandrake and Suse were supposed to have AMD 64/Opteron versions out. Well, the Mandrake version is 9.0 and is now unavailable. They have a corporate server
edition out, (2.1 for AMD Opteron) and it is reasonably priced at $749. Ouch.
Well, I can not afford that (much less $100) so I head on over to the Suse web
site. They also do not have a personal edition that supports Opteron, but they
do have an “Enterprise” server edition that they would like to sell me for $767.
I give it all up and proceed with the following plan: install RedHat 9.0
standard and rebuild the kernel with the pci and IDE patches in place.
I put my RedHat 9.0 CD in and away I go. After install X windows works fine,
IDE access is slower than a 486 with a 5400 rpm drive and I am in 32
bit mode. I let out a large sigh and go back to working on my homework, oddly
enough, for my VLSI class.
The good:
Performance notations: I wish to state the following, when I started all
of this I was going to put forth some performance metrics of my own
choosing, namely the standard povray benchmark and others. On the ABIT
motherboard, with the same ram and hard drive running the AMD XP 1.6Ghz
cpu, under RedHat 9.0, the standard povray benchmark takes right at 49 mins. Under RedHat
9.0 on the Opteron/ASUS setup (same ram/hard drives, etc) the difference is
mere seconds, at just under 49 mins. Let me point out that in reality,
this is impressive. I have read all of the benchmarks on the review sites
where they go on about it being faster even though they are running a 32
bit OS, but let me remind the reader that in order for the Opteron to run
a 32 bit app, it is doing its own internal translation which takes time.
The end user really is not gaining any 64 bit performance increase, and
typically we would expect a performance penalty and not a gain. This is
a good thing. A CPU which is performing translation, taking a penalty
for it, and running a 200Mhz slower clock speed is still faster
than a CPU running natively on the same hardware (less the motherboard).
This gives us a good feeling for the performance of the opeteron, in
that it should be an excellent performer with 64 bit apps running a
64 bit operating system.
Note that I did not run this test under gentoo as povray compiles crashed
and burned and running the 32 bit app on the 64 bit OS may be interesting,
but it was not to me. I wish to see native performance of 64 bit apps on
a 64 bit OS. In particular, on Linux.
Conclusions:
Linux is close to being on the AMD 64/Opteron systems, and
in fact may be there with Suse and Mandrake (RedHat claims “sometime”),
but at that price range for the OS itself, its use will (for now) be
limited to commercial application. I wonder about personal adoption of
the platform. AMD claims that it is to be the next generation of
personal computing, and I tend to agree (in part). The normal user
may not have as much to gain as say myself, or a CAD/CAM user or someone
doing imaging, etc (there are many applications which stand to gain).
But this adoption will be slow if all of the OS vendors think that
this platform will be limited to commercial/industry use only. Funny,
this reminds me of Sun Microsystems applications. I once wanted a copy
of mathematica for my Sun Ultra workstation for my Thesis, and they could
not believe that as an individual, I owned a Sun workstation. I received
the same response from Suse, who I called and inquired about getting a
copy of the server for Opteron to use at a reduced rate. They could
not fathom that an individual would actually own an Opteron system,
much less have a need for it. Gentoo looks very promising, and I will
probably devote my spare time (when it comes along) to porting window
managers and other things to the Opteron. For those who were paying
attention, X should actually work fine with say an ATI card, as it is
the Nvidia drivers themselves which are problematic on the Nforce3 and
not the XFree server itself. A working window manager is another thing.
Then again, Nvidia may rebuild their drivers to actually work (according
to the Gentoo developers, no one has had luck getting their drivers
to work on the Nvidia).
It would be advantageous for Linux users and others if a personal
desktop edition would come from a large vendor for the AMD Opteron.
A fully working Gentoo release would be good also, but the mainstream
workstation users may not want to go that route (as eye candy may be
important to them or a less demanding install).
For the time being, its 32 bit land for my Opteron.
About the Author:
Robert Minvielle is a Ph.D. student at the Center for Advanced Computer Studies at UL at Lafayette. He has a Masters in Physics and a B.S. in Computer Engineering, and enjoys building hardware, embedded systems, and programming. He can be reached at [email protected].
I’d use SuSE, they’re QA’d for it and AFAICT have done the most testing and work with that chip of the distros.
i wanted to build a 64 bit system… good thing i did not go out and buy all the parts… looks like we wont be getting a desktop OS for the opteron for linux for quite some time now…
well, that leaves me to my second option, a dual athlon MP !
The other real point of note is this: I need to work in X due to the project I have to complete in graduate school and X will not work on this box.
It simply will not work… the 24bpp code for XFree86 is not 64-bit clean. Attempting to use 24bpp in a 64-bit build of X will quickly result in an X server crash.
Seems kind of funny that he keeps talking about nvidia’s drivers, but he doesn’t appear to indicate whether he tried the unaccelerated nv driver that comes with X. I wonder what redhat is doing to get X to work.
As I mentioned in the article, at over $700 USD, Suse
was not really an option. Also, the nv drivers under RedHat
beta and redhat 9.0 work, but are unaccelerated… so windows
seem to drag and text that is scrolling lags from time to time…
Makes you feel like you have old video with 4 megs of ram…
Hello,
as far as I know, the linux alpha run natively in 64bit mode so why not trying to recompile directly this portage ?
I installed the aurora linux port (redhat8 on sparc) but it was a little slow on a ultra one and it used 32 bit except for the apps specially compiled to use the 64bit libs so I don’t know if it can be called 64bit linux…
“I have read all of the benchmarks on the review sites where they go on about it being faster even though they are running a 32 bit OS, but let me remind the reader that in order for the Opteron to run a 32 bit app, it is doing its own internal translation which takes time.”
I may be wrong but I have read many reviews of the Opteron/Athlon64 and one thing that many make a point about is that it runs 32bit apps natively. Why would it need to do any internal translation, the registers are named exactly the same as what they are in regular x86 they only have extensions (RAX instead of EAX, which is very similar to EAX instead of AX)? The only thing that might be considered translation is that all memory addresses will be 64 bits but again they simply have to read the first 32 bits of the number. That was supposed to be one of the main strongpoints of x86-64 afaik (someone please correct me if I am wrong).
You are correct. Opteron/Athlon64 loses its new registers, ISA cleanups and wastes some precious cache bits for unusable memory locations in 32 bit mode but that is it. There is no additional emulation logic in 32 bit mode. Nonetheless 64 bit mode should be faster; ISA cleanup (less vectorpath instructions, pseudo-GPRs more “general purpose”-ized) and new registers should more than compensate for lower density and overhead of 64bit operands.
Hrm, Interesting. I will have to look further, as
this article says there are three modes:
http://www.xbitlabs.com/articles/cpu/display/hammer-preview.html
I suppose you can read that there is no translation,
and that it is just in extended mode (register wise),
but from a design point of view I wonder…
I think the performance penalty depends on how
they take care of things. For instance, in 32 bit
land we take care of overflows, carry’s etc using
certain methods. If you have 64 bits, but you are doing
32 bit operands, can you just use the extra bits?
Flags still have to be set, etc, for it to know
that the output is not going to be 64 bit, but
you must go 32 bit. I may have misspoke about a performance
penalty due to a _translation_ but I stand by my notation
(I could be proved wrong
that there is a penalty
in terms of time delay for doing 32 bit instructions
vs 64 bit instructions in the opteron.
I suppose I need to call AMD.
here’s a link for 8.2 beta for x86-64
ftp://ftp.suse.com/pub/suse/x86-64/8.2-beta/
Thank you for confirming my thoughts! Btw – I definitely wasn’t trying to imply that 64bit wouldn’t be better. Just the addition of extra registers is a great boon for anyone who has actually had to do assembly work
and I agree that it should definitely make up for the negatives you mentioned.
Default operand length in AMD64 is always 32bits, as you can check from the link you have just provided. That is how it performs as well in 32bit mode. By all means, opteron is a new Athlon revision with 64bit extensions. Here is more tha you want to know about the architecture, but opteron optimization guide is a better choice if you want to respond to this thread during today
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture…
Hello, thanks for the article! Have you tried Debian yet? It seems like they offer an amd64 port, but it isn’t official yet. It’s located at https://alioth.debian.org/projects/debian-x86-64/
OOPS! Looks like that’s now https://alioth.debian.org/projects/debian-amd64 . Sorry!
http://www.mandrakestore.com/mdksa/index.php?PAGE=tab_0/menu_1.php&…
Included with the new release is experimental support for the AMD 64-bit platform (Opteron/Athlon 64), additional/enhanced device support for USB 2.0 and Promise Serial ATA controllers, support for PAE on Pentium Pro and Xeon systems, and experimental 1:1 and M:N thread libraries.
http://bsdmall.com/fr51pr.html
I mean, my god – lost interrupts, PCI conflicts, won’t work with 512MB sticks.
I’ve been plagued by this sort of crap for years (every board I have ever loaded up with PCI cards has given me trouble if i didn’t go and disable one or more on-board ports e.g. serial.)
Does nay vendor make a board on which you can actually use all 5 PCI slots, an AGP slot, all on-board ports and not have random lockups, kernel panics or other issues (this is almost always worse under Windows for the guy who thinks XP is the answer)
What I want to run is the floowing:
NVidia GeForce
BTTV TV tuner card
Iomega Buz SCSI/MJPEG card
Event Gina multichannel sound card
RT8139-based 5port hub-on-a-PCI-board
802.11b PCI card
The machine runs 4 SCSI drives, a SCSI DAT drive, an IDE CD Burner and an IDE DVD-Reader,
+ 2 serial ports (one of which has a 56k modem attached, one of which has a GSM modem attached, at least 2 USB for memory stick and/or graphics tablet, a parallel port for my CF card reader, onboard sound for MP3s (Gina is only used for recording/multitracking)
But any machine I attempt to plug all (or even most) of these things into just seems to become crash-prone, unstable and basically useless.
I see things haven’t changed with the ’64 bit’ revolution.
I heard they’ve been working on x86-64 for quite some time.
Anyhow, I think the Linux situation on x86-64 will improve substantially once Desktops with Athlon64 start to appear. Right now it is just a server chip, so distros can afford to hose you on it.
RedHat has announced the release of 3.0 should be out next month. The current Taroon beta may not work so good but then it is the first beta of this version they’ve released.
I’ve got a dual 2Ghz Opteron 1U rackmount server with 8GB RAM on the way (commercial app obviously). Hopefully I’ll have better luck than the article poster
I won’t really need X at all though, it’ll be a back-end database server machine only.
For _servers_ the Opteron is only marginally more expensive than XEON. As soon as a few of these software issues get ironed out it will start putting a serious dent in Intel 32-bit server CPU sales I’m sure.
Linux on the AMD Opteron: Are We Ready? Doesn’t sound like it.
Is this the system that’s suppose to smoke the G5?
Why don’t you try out linux kernel 2.6? It seens that support for Opteron is much better, and you can apply also Andrew Morton last patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6….
The problem you’re probably encountering is the AGP slot if interfering with the first PCI slot. They share an IRQ after all.
Not to sound sarcastic, but optron is bleeding edge. how long did it take before anyone wrote 32bit software? mmx instructions? To be realistic, the linux developers now have amd64 cpu’s and so it will take a good 6 months (based on history) to get the new instruction set fully supported and bugs ironed out.
use hdparm to change disk IO settings.
Actually it sounds like it does not work as there are IRQ conflicts. Everything else seems to increase except for the number of IRQ’s…been the same forever lol
Howdy
Is the number of IRQ`s determined by a PCI spec?, seems strange if sharing causes conflicts why not in the next technology (PCIExpress etc) or revision just up the number allowed?
I guess you’re just ironical but here’s my config running mandrake 8.0
celera 450A ovc 300
256 meg ram (2 stick from 2 different origin)
pci adaptec scsi 2940 U2W with 2 disks UW and 1 U2W
isapnp adaptec 1505A (with my zip drive and my scanner hp4000c attached)
1cd burner (ide 48x)
1 dvd reader (ide)
2 IDE disk (both from ibm, old ones rock solide)
gf2mx
dxr3 card (mpeg decoder)
soundblaster something (the driver for alsa is snd-ens1371)
one joystick microsoft usb and my creative jukebox
I almost forgot : one bttv card (miro pctv)
1 ethernet card ether XL combo something (3cx95 or something)
and MP p3V4x asus…
the last time I tried to upgrade to mandrake 8.2, everything crashed.. really. Nothing to do … I managed to repair and to get my former install work again and since I never touched again to my config… ever.
None of the kernel I compiled by hand has ever work, nothing….
and when I talked to a mandrake expert guy in an irc channel, first he didn’t believe me unless I send him my lspci result and lsmod one and then he said something like “va mourir avec ta config de ouf” something such as “get a life with your crappy config” in english
but the saddest day was when I went to a chinese store to look for something to replace my old celeron (I thouhght I could get a 1ghz but the seller is still laughing)…..
so don’t make fun on us, poor geeky loosers……
why I’m bashing with that ? because you make me laugh with your ironical point of view. Thanks…..I needed that right now…
tomorow, I’ll bye a ps2, a standalone dvd reader divx compliant and “j’arrete les pc, ca me soule…” (I stop PCs , it’s driving me crazy)
All this pci crapp makes me want to use a Mac. I don’t know how many times I have swapped pci cards around, plugged and prayed and yelled and smashed and cursed at my computers to make them stop sharing irqs, when there are plenty of irqs to go around, but the bios will not use them. pci and plug and pray is stupider then a bag of hammers. Brought to you to intel and microsoft, the morons that they are.
My computers used to work the way I told them to when they were made to be set up manually. Jumpers were the best thing created. They kept morons from using computers and let me allocate resources the way they needed to be. Computers used to be obedient, now they are stupid and rebellious. I have often thought of just junking my wintel type hardware and getting a used Mac, but then I think about multi OS choice, and games, and hardware choice, even if it is brain dead and flaky…
Unfortunately the system before it was actually worse. If your card couldn’t change to a free interrupt then your whole config was stuffed. The problem was that card vendors where too free and components cost too much back then.
If every PCI card had a dip switch to set its IRQ from 1-15 then it would be very busy. But back then no-one though about that. instead we ended up with a slightly better problem instead of a solution.
>Not to sound sarcastic, but optron is bleeding edge. how long did it take before anyone wrote 32bit software? mmx instructions? To be realistic, the linux developers now have amd64 cpu’s and so it will take a good 6 months (based on history) to get the new instruction set fully supported and bugs ironed out.
You shouldn’t associate everything with a name “linux”. Am I left outside of this because I use FreeBSD? I think not. 64-bitness has been no news about ten years. If you recompile your software you can get significant speed gains.
Iomega Buz SCSI/MJPEG card
I havn’t actualy used this card (just the Pinnical version)
but from what I have read from the linux drivers this card has dodgy pci support which makes it picky about motherboards
Maybe this is the source of your problems
That post hits it on the head. These things are an emergent technology, and as such are not going to be even close to stable for some time. Switching to a whole new CPU that only ’emulates’ the old one is going to be headaches. Anyone here remember when Mac’s switched to PPC’s? Anyone remember the confusion over memory access with the introduction of the 386? This is nothing new.
At this time, and probably for about a year or more, the 64 bit platform is not going to be an ‘out of box’ install with ANY OS for the desktop, and anyone who would expects it to be so obviously has no clue what they are doing.
if you’re a lightweight stick to ginger ale, and leave the real stuff to those with a clue.
Its none of the cards specifically that causes the problem (the Buz has problems, I know, but that is a whole other issue) – even when i swap the buz with another advansys or a DPT SCSI controller I still get resource issues.
Its not just one machine either, I have lots of boxes, from 486s to Athlons – build em myself and from vendors such as Compaq and Dell, and none of them have ever been able to configure a full complement of PCI/onboard peripherals properly and without issues.
You simply can’t fill all the PCI slots, enable all on-board peripherals, and expect to use the system.
This is pretty crap in my view – if you can’t support 5 PCI adapters and the usual onboard serial/parallel/USB stuff, then don’t put the connectors on the board.
IRQ sharing *should* work, but it just doesn’t in practice, especially when you have 3D, sound, TV and SCSI controllers attempting to hog the PCI bus.
The BIOS is often incapable of even enumerating the hardware in the machine without removing devices, disabling onboard peripherals, adding the device back and rebooting.
Whats the point of having a 1.8GHz Opteron if it is going to crash because the shoddily engineered motherboard and buggy PCI/USB/AGP controllers (VIA, are you listening?) conspire to destroy any hopes you had of actually using the system with a full complement of devices.
Personally, i couldn’t give a rats ass how fast the front-side-bus is, or whether it supports S-ATA RAID, or whether it has fancy overclocking features if the goddamn thing won’t even stay running if you actually use the expansion slots.
However, no board manufacturer actually makes this a selling point – Is it because nobody can make an x86 motherboard that works correctly, or that it would actually cost too much to engineer a board that worked correctly and reliably?
From the Gentoo Weekly News letter:
Experimental IA-64 stage1 available
The IA-64 port can now be fully built from stage1, and an experimental IA-64 stage1 tarball is now available under experimental/ia64. There’s no LiveCD, but users are encouraged to try building a system, see how it works, and submit bugs to Bugzilla.
Finally, they invented PCI Express which is a serial switched bus which should solve all PCI bus sharing problems.
Too little, too late…
Ummm, better read that again. IA-64 is ITANIUM (by intel), and has nothing to do with this project.
well, you can get 9.0 here:
ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrake/9.0/x86_64/
But I wouldn’t bother, as current Cooker has a functional AMD64 branch, which is effectively MDK 9.2. Look here:
ftp://ftp.club-internet.fr/pub/linux/distributions/Mandrake-devel/…
(or the equivalent directory on any other Cooker mirror).
Okay, forgive my ignorance, but aren’t all the 64bit linuxes (linae?) at the alpha stage? I read the other comments, and I see
Mandrake 64bit=Cooker
Red Hat 64=Also in development
Gentoo 64=Experimental port
Suse 64=Supported and tested, but only on a narrow set of Hardware
Debian 64=Not even the woody guys would roll it out in a non-testing machine.
So they aren’t ready for prime time, correct?
So the fact that the author couldn’t get it to run properly, isn’t exactly news.
This reminds me of the usual Microsoftie to Linux switch article: I couldn’t get it to run, so Linux 64 bit sux.
http://dev.gentoo.org/~tester/amd64-tech-notes.html
http://adelie.polymtl.ca/experimental/amd64/livecd/gentoo-amd64-ful…
“Makes you feel like you have old video with 4 megs of ram…”
Hey now, I have a 2mb ATI Mach 64 in my Dual P3 and it is noticibly more responsive than under my ATI Rage Fury 32MB under X (strange, must be better utilized).
It looks like it should work rather well:
http://www.freebsd.org/relnotes/CURRENT/hardware/amd64/proc.html
Gentoo is the freebsd of linux any-how.
-mattk
thanks for your time, effort and honesty.
Is it just me or was this the most worthless review ever?
>You shouldn’t associate everything with a name “linux”. Am I left outside of this because I use FreeBSD? I think not. 64-bitness has been no news about ten years. If you recompile your software you can get significant speed gains.
What exactly are you saying? “64-bitness” as you put it has been no news on either FreeBSD or Linux for about ten years now (Linux for Alpha, since then: UltraSPARC, PowerPC 64, 64 bit S/390, PA-RISC 64, 64 bit MIPS, now Itanium). Opteron, however, is still fairly bleeding edge. FreeBSD may be further along with kernel work for the Opteron; I don’t know, but I would expect not much. I would think, however, XFree86 works no better for FreeBSD Opteron than it does for Linux Opteron. This discussion is about Linux on Opteron, not 64 bit Linux in general. Just to be clear, I think FreeBSD is great; I was just pointing out that 64 bit Linux is not at all new.
I’d like to know if others have had issues when using 512 MB RAM with an Asus motherboard. Depending on the answers, I’ll buy an Asus mobo and 256 MB sticks, or, I’ll get another mobo and 512 MB sticks.
Sorry to disappoint you, NVidia chipsets are the least supported in Linux. Because NVidia aren’t very helpful to open-source kernel developers.
Stay with AMD, VIA, ALi and SiS chipsets (all of them make K8 chipset), the AMD one should be particularly good, as it is widely used in Server products and by the kernel developers.
It’s amazing to see the Open-Source journalists publishing articles about installation of propreitery modules (NVidia binary only module in this case), and then complaining things don’t work right. Go and complain that to NVidia, they have our source, kernel developers don’t have NVidia’s kernel modules. How can you possibly expect open-source developers to help in that case?
All the best.
“but let me remind the reader that in order for the Opteron to run a 32 bit app, it is doing its own internal translation which takes time.”
WRONG. Opteron does NOT do “internal translation”. It runs 32bit apps 100% natively. It runs them like Athlon XP with more L2 and integrated mem-controller would run. 32bit is 100% native on the Opteron.
“The end user really is not gaining any 64 bit performance increase, and typically we would expect a performance penalty and not a gain.”
Wrong again!
http://www.anandtech.com/cpu/showdoc.html?i=1884&p=17
“The performance improvement here is astounding – in 64-bit mode the Athlon 64 FX managed to finish the encode 34% quicker than in 32-bit mode…”
no, as Cooker is currently frozen for MDK 9.2. I expect there’ll be an AMD64 release of 9.2.
NetBSD has a port to the AMD64 platform. Just an Idea
The first beta of Mandrake 9.2 for AMD64 (Athlon64 and Opteron) is now available here http://www.linux-mandrake.com/en/92amd64beta.php3
SuSe has a beta for 8.2Pro for AMD64 on their ftp sites. have you tried that?
On PCI…
AGP + card in slot 1 = BAD, they share IRQ, and this configuration is normally impossible on most boards as a installed AGP card blocks the first PCI slot.
Set up IRQs by by hand in the BIOS settings, or let Linux deal with that. ( Of course, VIA chipsets have problems, see below ).
Also, note that when I disabled on board USB on the VIA chipset, my PCI IRQ issues went away! I was manually assigning IRQs in the bios, but the USB controller would always pick a allocated IRQ ( Usually video card or serial port ). Disabling the broken POS VIA USB support fixed that. Everything worked perfectly after that. If his demo board uses VIA, disabling onboard USB and hand assigning IRQs may fix his problems.
Avoid VIA chipsets. For the longest time, their 686A/B controller chips had broken USB implementations. Every revision to introduce a ‘fix’ broke something else. They provided custom multi-megabyte drivers for Windows to work around the issues. Linux kernels can work around some of the bugs, but so many revisions and bugs of the 686A/B chips exist it can’t handle them all. If you HAVE a 686 chipset, disable on chip USB, and buy a plugin card. I did this, and have had flawless USB since. VIA chipsets also have IDE issues.
I read the article, seems to me your problems have less to do with Opetrons and a lot more to do with NForce drivers and Asus motherboards.
I would list most of your problems that I noted under “Motherboard Issues” including issues with interupts, drive access and the ethernet card.
You article could easily be titled Linux on the “Nforce-3: Are we ready?”
Why don’t you try some other chipsets and other MB makers like MSI? The use the Via chipset (K8T800).
Besides AMD has always been plagued by chipset issues early on in a new product release.
You have a good kernel, from Gentoo, and a good distro,
from RedHat. Use the good distro with the good kernel,
and get a linux-friendly video card. Problem solved.