# Nach 4GB Ram geht garnix mehr :(

## ConiKost

Hallo!

Ich habe ein System mit 2GB RAM bis heute gehabt. Da ich auch Windows nutze und dort einiges treibe habe ich auf 4GB RAM aufgerüstet ...

Mein Sys -> http://www.sysprofile.de/id388

Das Resultat ist nun: Gentoo Linux braucht bei "decompressing kernel ..." ca. 10-20 sekunden, aber dann ist es sehr flott erkennt 4gb ram ...

Windows XP x64 und Vista x64 dagegen brauchen ca. 30 Minuten um überhaupt ein Login zu zeigen ... jemand ne Idee was hier los ist?

Und warum hängt Gentoo bei decompessing kernel so lange?

Bei 2GB geht alles fix!

----------

## Keruskerfuerst

Vielleicht ist ein Biosupdate nötig.

----------

## ConiKost

 *Keruskerfuerst wrote:*   

> Vielleicht ist ein Biosupdate nötig.

 

Bereits das neuste drauf.

----------

## think4urs11

High Memory Support im Kernel steht auf off/4GB/65GB?

Wg. Windows würde ich besser in einem Windowsforum fragen  :Wink: 

----------

## ConiKost

 *Think4UrS11 wrote:*   

> High Memory Support im Kernel steht auf off/4GB/65GB?
> 
> Wg. Windows würde ich besser in einem Windowsforum fragen 

 

Jo, 4GB ist aktiv im Kernel ... trotzdem warum bootet der dann den Kernel so lange beim dekomprimieren?

----------

## Mr. Anderson

Kernel ist für AMD64 oder x86 kompiliert? (Bzw. auch der Rest vom System)

----------

## Keruskerfuerst

Unterstützt denn das Mainboard überhaupt die eingesteckte Anzahl von Rammodulen?

----------

## ConiKost

Hallo!

Laut Handbuch bis zu 4GB ...

Kompelt x86_64 ...

----------

## Haldir

Inkompatible Module, schaltet auf Kompatibilitätsmodus zurück.

----------

## Waldi

Inkompatible Module wär aber komisch, denn laut sysProfile hat er 4 identische drin, und wenn er davon nur 2 verwendet läuft ja anscheinend alles flüssig.

Wäre ein Speicherfehler in einem der zwei neuen Module möglich? Schon verschiedene Kombinationen probiert und memtest ausgeführt?

----------

## blu3bird

Er braucht nur beim Uncompressing lange, oder? In dem Fall liegt der Fehler beim Bootloader. Wenn du grub benutzt probier mal lilo und wenn du lilo benutzt probier mal grub.

----------

## -Craig-

 *blu3bird wrote:*   

> Er braucht nur beim Uncompressing lange, oder? In dem Fall liegt der Fehler beim Bootloader. Wenn du grub benutzt probier mal lilo und wenn du lilo benutzt probier mal grub.

 

So ein Quatsch! Wie kommst du denn bitte auf die Idee?

----------

## Keruskerfuerst

Probier mal memtest aus: http://www.memtest.org/

----------

## blu3bird

 *-Craig- wrote:*   

>  *blu3bird wrote:*   Er braucht nur beim Uncompressing lange, oder? In dem Fall liegt der Fehler beim Bootloader. Wenn du grub benutzt probier mal lilo und wenn du lilo benutzt probier mal grub. 
> 
> So ein Quatsch! Wie kommst du denn bitte auf die Idee?

 

Mit dem eigentliche Uncompressing hat der Bootloader nichts zu tun, das ist schon richtig(siehe lib/inflate.c). Aber der Bootloader alloziert den Speicher für den Kernel und lädt ihn dann in den Speicher. Wenn der Bootloader nun z.B. zuwenig Speicher alloziert muss sich der Kernel während er beim uncompressing ist neuen Speicher hohlen.

Ps: chainloader benutzt du keinen oder?

----------

## ConiKost

So!

Sry, dass ich mich erst jetzt melde ...

Also der neuste Stand ist nun wie folgt:

Bei aktivierem Memory Remapping, damit volle 4GB erkannt werden, lahmt vieles einfach ... Gentoo übrigens lahm auch, sobald mehr als 3GB voll sind! Dann fangen die Probleme an ... scheint so als ob das Remapping nicht funktioniert?

Wenn ich aber nun Memory Remapping deaktiviere, bleiben ca. 3.25GB übrig. Hier funktioniert alles nun prächtig!

Der Speicher ist zu 100% ok. Habe jedes einzelne Modul mit Memtest86+ 5 Stunden lang getetestet!

Nein und ich nutze keinen Chainloader!

Für mich scheint das Memory Remapping nicht richtig zu funktionieren?

----------

## Anarcho

Wozu benötigt man bei einem 64 Bit System bei 4 GB RAM Remapping? Mit den 64 Bit extensions kannst du deutlich mehr RAM direkt addressieren.

----------

## ConiKost

 *Anarcho wrote:*   

> Wozu benötigt man bei einem 64 Bit System bei 4 GB RAM Remapping? Mit den 64 Bit extensions kannst du deutlich mehr RAM direkt addressieren.

 

Hä? Das versteh ich jetzt nicht ... wenn ich das Remapping deaktiviere, stellt das Bios nur 3.xx GB zur Verfügung und Gentoo findet keine 4GB mehr (im Kernel ist aber 4GB aktiviert)

Also wie soll das ohne Remapping gehen?

----------

## schachti

 *Anarcho wrote:*   

> 
> 
> Wozu benötigt man bei einem 64 Bit System bei 4 GB RAM Remapping? Mit den 64 Bit extensions kannst du deutlich mehr RAM direkt addressieren.

 

Weil ohne Remapping ein paar hundert MB des RAM verdeckt werden. Remapping blendet diese paar hundert MB "weiter oben" wieder ein und macht sie nutzbar.

----------

## Keruskerfuerst

Bei den aktuellen AMD 64 Bit Prozessoren hat man laut /cat/proc/cpuinfo einen Adressraum von 40 Bit.

Daraus folgt: maximal adressierbarer Speicherbereich von 128 GB.

Eingentlich sollte Gentoo auch bei deaktiviertem Mapping die ganzen 4GB erkennen.

----------

## schachti

Nein, wie ich schon schrieb kann das Betriebssystem zwar addressieren, er wird aber verdeckt. Nur das Remapping macht ihn sicht- und damit zugreifbar. Siehe http://www.heise.de/ct/05/05/096/ unter "Das Adressloch".

----------

## Mr. Anderson

 *schachti wrote:*   

> Nein, wie ich schon schrieb kann das Betriebssystem zwar addressieren, er wird aber verdeckt. Nur das Remapping macht ihn sicht- und damit zugreifbar. Siehe http://www.heise.de/ct/05/05/096/ unter "Das Adressloch".

 

Wenn ich den Artikel richtig verstehe, gibt es eine Komponente, die dieses Loch verursacht. Das AMD64-System würde sonst weit jenseits von 4 GB mappen. Grafikkarte? Ne PCI-Karte? ...?

----------

