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.
Post a Comment
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!
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.
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.
"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.