# Umstieg: normaler Athlon auf Athlon 64 X2

## NightDragon

Hallo zusammen!

Ich habe vor bald meinen Server etwas auszubauen. Vom jetzigen 800Mhz AMD Athlon (kein XP, nur der ganz normale Athlon) auf Athlon 64 X2 (2,2GHz).

Weiß jemand, also Praxiserfahrung o. ä., ob der Code vom normalem Athlon auf Athlon 64 X2 lauffähig ist?

Sprich ob ich es schaffe, vorerst ohne neucompilierung durchzustarten?

Ich würde ansonsten nur die Platten und die restliche HW umstecken, hochbooten und schauen wasnoch anzupassen ist, neben Treiber und Kernel.

Anschließend würde ich direkt auf dem System, ohne der Life-CD selbst, ein emerge system -Dev machen mit anschließenden emerge world -Dev.

Dann wär der Umstieg erledigt.

----------

## Klaus Meier

Also der Code läuft. Aber du hast dann ja auch ein neues Board. Also vor dem Umstecken der Platte die Treiber des neuen Boards im Kernel aktivieren. Und dann kannst ja das System langsam anpassen.

----------

## /root

Wie Klaus Meier erwähnt hat, gilt es den Kernel vorher anzupassen und die Treiber zu aktivieren, da das Kernelimage ja parallel zum bestehenden, mit neuem Booteintrag versehen, auf der Platte liegen kann. So kannst Du beim Start zum neugebauten Kernel wechseln und zur Not nochmal mit der alten HW und dem alten Kernel booten.

Bevor du neu kompilierst würde ich mir überlegen, das System zu bootstrappen. Je nachdem mit was du installiert hast (Stage1, -2 oder -3) oder ob Du vorher auch ein Bootstrap durchgeführt hast. Auf diese Weise wird sichergestellt, dass die Toolchain, die für das bauen der restlichen Pakete verantwortlich ist, auch auf den neuen Prozessor angepast ist.

```
/usr/portage/scripts/bootstrap.sh
```

Zu den beiden emerge-Befehlen bin ich mir am überlegen ob nicht ein emerge -Dev world ausreicht, weil viele Pakete dann doppelt (Zuerst emerge system, dann emerge world) kompiliert werden... was aber sicher ist, dass mit beiden emerge-Befehlen auf jeden Fall alle Pakete neu gebaut werden.

----------

## Aldo

Wenn du es so machst wie oben beschrieben (ja, es geht so) hast du allerdings "nur" ein 32-bit-System.

Wenn du aber ein 64bit-System haben willst mußt du komplett neu aufsetzen weil sich da ja auch die CHOST ändert und auch sonst einige kleine Unterschiede sind.

Siehe dazu auch hier: http://de.gentoo-wiki.com/AMD_64

----------

## fangorn

Je nachdem wie lange der letzte emerge -uD world her ist, kann es auch sinnvoll sein, einfach /etc und /home und /var/lib/portage/world zu kopieren und ausgehend von einem neuen stage3 (kann auch eine amd64 Version sein) ein neues System aufzusetzen. Auf diese Weise sparst du dir vielleicht ein emerge -e system und kannst nach dem Anpassen der /etc/make.conf gleich mit einem emerge -e world starten.

----------

## NightDragon

Hallo zusammen!

Jope wegen Treiber usw, dass war mir klar.

Wichtig ist mir in erster Linie das der Code überhaupt läuft.

bei 4 Platten-Controllern, wird die Festplattensache eh zum Tanz...

Hm also zwecks der Toolchain hätte ich ja zuerst ein emerge system -Dev gemacht.

Da wird dann doch die gesamte Toolchain neu gebaut, oder?

Sprich wichtig ist ja mehr oder weniger nur die glibc und der gcc selbst.

@Aldo: Warum neu aufsetzen?

Ist doch das selbe wie wenn ich die CPU wechsle.

Evtl. müssen einige Lib-Pfade  angepasst werden, aber wenn ich die make.conf nach dem Umbau anpassen und alles neu baue, (sprich emerge world -Dev), dann muss das doch genügen?...

Die Frage ist nur, was passiert bei einem Mischsystem, während der Compilierung?

----------

## return13

das der server auf dem der 64er laufen soll

http://www.shadowghost.net/ ?

----------

## NightDragon

@return13

Mehr oder weniger, ja

----------

## schachti

Sorry, daß ich mich an diesen Thread anhänge, aber es paßt thematisch so gut: Ich plane einen Umstieg von einem Athlon XP auf ebenfalls einen Athlon 64 X2. Kompiliert ist mein System mit CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" und USE="3dnow 3dnowext mmx mmxext sse". Wird das mit dem neuen Prozessor laufen, ohne daß ich neu kompilieren muß? Ich sehe derzeit keinen Grund, eine 64-Bit-Installation durchzuziehen, da es ja immer noch Software gibt, die es dann nicht mehr tut (zum Beispiel Flash 9)...

----------

## Klaus Meier

Ja, der Code läuft auch auf dem neuen Prozessor. Da du ja an CHOST nichts änderst, gibt es keine Probleme. Einfach -march=k8 setzen und alles was du neu übersetzt, wird etwas schneller laufen. Das Powermanagement im Kernel mußt eventuell noch anpassen. Es sollte aber keine Probleme geben, wenn ein Teil mit -march=athlon-xp und ein anderer mit -march=k8 übersetzt ist.

----------

## NightDragon

Hallo zusammen.

Nun läuft der Server mit dem neuen System.

Der Umstieg war denkbar einfach. Es war wie ich gedacht hatte und mir hier versichert wurde:

Kernel anpassen, System runtergefahren, Platten dort raus drüben rein, System hochgefahren, alles nochmals etwas anpassen.

Fertig.

*g*

SOOO Nun kommt aber die große Frage.

Im moment läuft also 32bit Code auf einer 64Bit Machine.

Ich würde aber gern den vollen Speed nutzen.

Wenn ich folgendes mache, dürfte es doch keine Probleme geben, oder?

```
a) System runter fahren.

b) AMD 64 Live CD Booten

c) Mounten der Platte, von /dev und /proc, 

d) chroot ins alte System

e) CFLAGS und CHOST anpassen, Profile auf 64 bit wechseln

f) checken via [b]emerge world -Dupv[/b] ob Packete sich ändern oder jetzt blockiert sind.

g) bootstrapen bzw. rebuid der toolchain

h) Kernel rebuilden, backup des alten anlegen (neue Grub-Eintrag)

i) emerge system -eDv und dann emerge world -eDv

j) Configs checken

k) chroot beenden, unmounten der Platten

l) rebooten von Platte.
```

Wenn ich das alles genau so mache. Seht ihr dann Probleme? Bis auf einige wenige Lib-Laichen.

Aber booten müsste Das System dann doch oder?

----------

## Klaus Meier

Den vollen Speed? Da gibt es so gut wie keine Unterschiede.

Dann, ein Umstieg ist so gut wie nicht möglich. Du musst dein System komplett neu aufsetzen. Du bootest von einem 64-bit Kernel und machst dann ein chroot in ein 32-bit System. Und das gibt peng. Du wirst auf deinem System auch erst gar kein Profil für 64-bit finden.

Dann ist es relativ kompliziert, wenn man Suns Java und Flash nutzen will. Und es sind auch sonst einige Pakete noch nicht für 64-bit verfügbar.

Man kann inzwischen mit leben, aber es macht immer noch mehr Arbeit als 64-bit.

----------

## schachti

Wenn es überhaupt Anwendungen gibt, die unter 64 Bit schneller laufen als unter 32 Bit, dann sind das einige wenige Spezialanwendungen - bei einem normalen Desktop-System wirst Du nicht den geringsten Performance-Unterschied merken, nur mehr Probleme.

Der einzige Grund, auf einem Desktop-System 64 Bit nutzen zu müssen, ist derzeit, wenn Du mehr als 3.x GB RAM hast.

----------

## McEnroe

 *schachti wrote:*   

> Der einzige Grund, auf einem Desktop-System 64 Bit nutzen zu müssen, ist derzeit, wenn Du mehr als 3.x GB RAM hast.

 

?

Ich dachte das Problem hat nur Windows [halbwissen] mit dem für für Treiber reservierten Speicherbereichen [/halbwissen]. Afaik kann Linux in der 32bit version bis zu 4096MB RAM ansteuern...

----------

## Klaus Meier

 *McEnroe wrote:*   

>  *schachti wrote:*   Der einzige Grund, auf einem Desktop-System 64 Bit nutzen zu müssen, ist derzeit, wenn Du mehr als 3.x GB RAM hast. 
> 
> ?
> 
> Ich dachte das Problem hat nur Windows [halbwissen] mit dem für für Treiber reservierten Speicherbereichen [/halbwissen]. Afaik kann Linux in der 32bit version bis zu 4096MB RAM ansteuern...

 

Also es gibt auch Möglichkeiten, mit 32bit mehr als 3GB zu nutzen. Aber es ging hier um Argumente pro 64-bit...

----------

## NightDragon

Beim RAM gehts glaub ich in erster Linie durch die CPU direkte Adressierung.

D. h. mit 32Bit kann man weniger adressieren wie mit 64Bit.

Nutzbar sind unter beiden Systemen weit aus mehr als 4GB RAM. Windows XP hat ein Problem beim zuweisen von mehr wie 2GB pro Pozess.

(Wo mans braucht? Exchange-Server, Photoshop, etc...)

Java und Flash sind egal.

Beide werden nicht gebraucht. Das ganze ist ein Web- und File-Server mit MySQL und co.

Ihr würdet also nicht neu kompilieren. Hm ich dachte, nachdem Gentoos großer Vorteil im Sourc-Code selbst kompilieren hat, würde das System dadurch auch mehr Speed bekommen.

Nachdem das alte System dauerhaft auf 80 % ausgelastet war, denke ich wird es auch beim neuen eine Auslastung geben, wenn nicht 80%.

Und auch da können kürzere interne Latency-Zeiten helfen.

Aber okay, ich lass mich gern korrigieren, wenn ich falsch liege.

Nun gut... Ich mach mich dann mal rann, SMP im Kernel zu aktivieren...

----------

## UTgamer

Ich habe im September 2005 Gentoo direkt auf AMD64 SMP installiert gehabt und bereue keinen Tag davon.

Als Videoplayer müssen VLC und Xine herhalten.

Ich lasse sogar seit kurzem Flash 9 über einen Wrapper im 64 Bit Seamonkey (Mozilla) laufen, 

```
about:plugins

NPAPI Plugins Wrapper 0.9.91.4

    Dateiname: npwrapper.so

    nspluginwrapper is a cross-platform NPAPI plugin viewer, in particular for linux/i386 plugins.

    This is beta software available under the terms of the GNU General Public License.

MIME-Typ    Beschreibung    Endungen    Aktiviert

unknown/mime-type    Do not open    none    Ja
```

und als 64 Bit Javabrowserplugin verwende ich immer noch diese:

dev-java/blackdown-jdk

      Latest version available: 1.4.2.03-r12

      Latest version installed: 1.4.2.03-r12

      Size of downloaded files: [no/bad digest]

      Homepage:    http://www.blackdown.org

      Description: Blackdown Java Development Kit

      License:     sun-bcla-java-vm

*  dev-java/blackdown-jre

      Latest version available: 1.4.2.03-r13

      Latest version installed: 1.4.2.03-r13

      Size of downloaded files: [no/bad digest]

      Homepage:    http://www.blackdown.org

      Description: Blackdown Java Runtime Environment

      License:     sun-bcla-java-vm

Achso auch die Daten- & Adressbusse werden mal endl. voll ausgereizt.

Achso das NX - Bit bringt auch wesentlich mehr Sicherheit, Bufferoverflows zum Codeinschleusen sind endlich Geschichte, sie führen nur noch zum Absturz der Anwendung.

Wetten das mein 64 Bit-System schneller ist als eures in 32 Bit bei gleicher CPU?

Wer mir einiges wie z.B. den Flash9 Player aufm Wrapper nicht glaubt, ich habe VNC installiert, dem kann ich dies vorführen.

Wo sollen den die "kleinen" Probleme liegen, ihr ewig gestriegen?  :Laughing: 

----------

