[Gentoo][Linux-2.4.19] Linux kan niet tegen veel RAM?

[MadEgg]

Ik heb vandaag op de 29e Friese Computerbeurs voor een zacht prijsje 3 x 512 MB 333 MHz DDR RAM gekocht, ter vervanging van de 1 x 256 MB 266 DDR RAM die in mijn computer zat.

Na dit vervangen te hebben, startte Windows zonder probleem op.
Toen ik echter Linux probeerde te booten kreeg ik een zwart scherm. Niet zo mooi.

Ik heb de Gentoo installatie CD erbij gehaald, en via daar mn root gemount. In de kernel-config kwam ik erachter dat ik, indien ik meer dan 1 GB RAM had, High memory op 4GB moest zetten in plaats van 1GB. Dat dus gedaan, en gerecompiled. Kernel geinstalleerd, en rebooten maar. Helaas, nog steeds een zwart scherm.

Nogmaals via de install-CD erop gegaan, en geprobeerd om vga=0x301 als bootparam weg te halen, zodat Gentoo gewoon in text-modus zou booten. Na een reboot kreeg startte Linux weer op.

In XFree86 kreeg ik echter nog meer problemen. Ik probeerde vendetta te spelen, maar na op het Play knopje gedrukt te hebben, vloog deze eruit met de melding: Segmentatie fout.

Hierna merkte ik dat, na de kernel-recompile, mn alternatieve emu10k1 module overschreven was, dus ik ik probeerde deze opnieuw te compilen. Ik kreeg hier echter ook een error.
Ik heb daarna nog geprobeerd om Soldier of Fortune II, Diablo II en Starcraft te draaien via Wine en WineX. Deze donderden er ook allemaal uit met Segmentatie fouten.

Ik dacht, dan zal waarschijnlijk het aan mij verkochte geheugen brak zijn, dus ik downloadde memtest86. Deze heb probeerde ik te compileren, maar kreeg hier de volgende error:

code:

test.c:12: conflicterende types voor `v'
test.h:280: eerdere declaratie van `v'
make: *** [test.o] Fout 1

Daarna heb ik maar de DOS/Windows install voor memtest86 gedownload en de memtest.bin naar /dev/fd0 gekopieerd.
Deze test is net succesvol afgerond, zonder enige fouten te vinden. Het geheugen lijkt dus in orde.

Ik heb getracht te zoeken, maar heb niet echt een goede zoekstring kunnen formuleren, zowel op GoT als op google. 'wine much ram', 'veel ram', 'ram crashes', 'segmentation fault' leverde mij alleen de informatie op dat,

richardt schreef op 09 August 2002 @ 08:08:
Een segmentation fault treedt inderdaad op bij het lezen van en schrijven naar foutieve geheugenadressen, en is voor een programmeur cq. gebruiker vaak 1 van de vervelendste problemen om op te lossen.

Mis ik soms nog kernel opties? Of werkt meer dan 1 GB RAM niet goed samen met bv preemptible patches, niet geschikt voor desktopgebruik of wat dan ook?

Ik weet niet of het verder belangrijk is, maar mijn swap partitie is 512 MB groot. Voor verdere system-specs zie mijn signature.

[Verwijderd]

Het is altijd het best van slechts 2 geheugenbanken te gebruiken met RAM van hetzelfde merk, type en grootte.

[Wilke]

Wat denk je, zou Linux >1 GB RAM ondersteunen?

Dit is wel een vrij raar probleem..maar ik zie in je sig dat je wel je CPU (en dus ws. ook je geheugen) hebt overgeklokt...klopt dat, en zo ja doe dat eens niet en probeer het dan nog eens?

[MadEgg]

Oke, topic-title niet helemaal goed geformuleerd. Ik bedoelde meer, niet tegen veel RAM voor desktop-gebruik.

Op servers ben ik zeker bekend dat Linux er goed mee om kan gaan. Maar daar worden doorgaans geen pre-emptible patches en dergelijke performance patches gebruikt.

Verder, in reactie op stuartje, ik vind dat als er 3 banken op mijn mobo zitten, ik ze alle drie moet kunnen gebruiken. Verder zijn de drie reepjes RAM hetzelfde merk, snelheid en type, ik heb ze tegelijk gekocht namelijk.

Het overclocken zou misschien nog kunnen, zal het even proberen. Result will follow

[Verwijderd]

Sja, voor DDR-RAM wordt nochtans aangeraden om er slechts 2 te gebruiken omdat anders de snelheid terugvalt en er conflicten kunnen zijn.
Ik heb die regel niet gemaakt

[AlterEgo]

Heb je je kernel-sources schoongemaakt met "make mrproper" voordat je ke kernel opnieuw compileerde (denk aan backup van je .config!).
Soms lost dat eigenaardige problemen in 1 keer op.

[MadEgg]

Verwijderd schreef op 30 maart 2003 @ 23:56:
Sja, voor DDR-RAM wordt nochtans aangeraden om er slechts 2 te gebruiken omdat anders de snelheid terugvalt en er conflicten kunnen zijn.
Ik heb die regel niet gemaakt

Waarom werkt het in Windows XP dan wel gewoon? En bovendien geeft memtest86 geen fouten aan bij het doorlopen van het hele geheugen.


Het terugclocken van mijn CPU laat de spellen weer werken, maar niet het compilen van memtest86 3.0, maar misschien is dit dus werkelijk een fout in de broncode oid.
De vraag die mij dan natuurlijk voor ogen komt is, waarom het geen problemen oplevert met 256 MB RAM, en wel met 1536...
De RAM-snelheid is verhoogt, en beide zijn nou niet echt van een hyper-bekend merk. Dus kwaliteitsverschillen in die zin lijken me stug.

[Wilke]

stuartje heeft trouwens toch wel gelijk wat betreft die combinatie 2 geheugenbankjes, Pentium 4 en DDR geheugen. Als iemand een URL kan vinden waar het staat...

Memtest86 3.0 bevat geen fouten in de broncode, maar misschien moet je even 'make clean' doen, want er zit al een precompiled ding bij (die je overigens ook gewoon kunt gebruiken).

Maar goed, de spellen werken dus weer als het overklokken teruggedraaid is...lukt een Linux kernel compileren ook?

[MadEgg]

Een linux kernel compilen lukte al terwijl hij nog wel overgeclocked was, en nu nog steeds.

Verder heeft het terugclocken nog niet tot gevolg dat mijn grafische(framebuffer) boot-console niet meer werkt. Ik krijg met vga=0x301 nog steeds een zwart scherm en verder niets.

Verder heb ik een DDR-moederbord, met 3 DDR-geheugenbanken. Waarom zetten ze er 3 in als je er in principe maar 2 kan gebruiken?

Ik weet nog dat je in de oude moederborden, met SIMM-etjes, ze er altijd per twee in moest stoppen, maar daar was dan ook altijd een even aantal banken op het mobo.

[edit]
Na het terugklokken van de CPU doet UT2003 het niet meer, nu krijg ik daar een segmentation fault, terwijl die het wel goed deed terwijl ie nog wel overclocked was

[ Voor 14% gewijzigd door MadEgg op 31-03-2003 01:10 ]

[deadinspace]

MadEgg schreef op 31 maart 2003 @ 00:14:
Het terugclocken van mijn CPU laat de spellen weer werken, maar niet het compilen van memtest86 3.0, maar misschien is dit dus werkelijk een fout in de broncode oid.

Die fouten bij het compilen van memtest86 zien er sowieso uit als fouten in de source of source die andere versies van header-files verwacht oid, geen fout die door brak geheugen veroorzaakt wordt.

Wilke schreef op 31 maart 2003 @ 00:19:
stuartje heeft trouwens toch wel gelijk wat betreft die combinatie 2 geheugenbankjes, Pentium 4 en DDR geheugen. Als iemand een URL kan vinden waar het staat...

Ik weet geen URL, maar ik weet wel dat de i845 chipsets (alle varianten afaik) slechts 4 memory banks ondersteunen. Een memory bank is een "zijde" van een memory slot. Elk memory slot bestaat dus uit twee banks. Drie memory slots zijn goed voor 6 banks, maar hiervan kun je er maar 4 gebruiken. Dat komt in de praktijk neer op twee double-sided dimms of één double-sided dimm en twee single-sided dimms (en alle variaties met minder dimms). Als het goed is staat dat ook beschreven in je moederbord handleiding (ervanuitgaand dat je een mobo met i845 chipset hebt).

Ik heb overigens verhalen gehoord dat drie double-sided dimms wel eens wil werken. Dat "wel eens" is misschien waar je nu tegenaan loopt?

MadEgg schreef op 31 March 2003 @ 00:24:
Na het terugklokken van de CPU doet UT2003 het niet meer, nu krijg ik daar een segmentation fault, terwijl die het wel goed deed terwijl ie nog wel overclocked was

Klinkt lekker gaar

Overigens... Je hebt het over pre-emtive patches, en vraagt of die invloed zouden kunnen hebben (ik vermoed sterk van niet overigens)... Maareh, ik zou zeggen: probeer het uit?

Heb je trouwens al het standaard RAM troubleshooten gedaan? Maar één DIMM gebruiken? Of twee? Twee varierenden, zodat er telkens een andere niet in je machine zit? In verschillende geheugenslots proberen? Dat soort dingen.

[ Voor 3% gewijzigd door deadinspace op 31-03-2003 01:40 ]

[MadEgg]

Relevante stukken van www.ecs.com:

Processor: Intel® Pentium® 4 CPU, Socket 478, 400MHz

Chipset: VIA® Apollo P4X266 North Bridge VT8753
VIA® VT8233 South Bridge
Super I/O: ITE IT8705F

Zie ik geen i845 of iets in die geest tussen staan. Zal vanmiddag m'n mobo-boekje even erbij pakken(als ik die kan vinden ), en het geheugen even doorwisselen.

[wzzrd]

Wat deadinspace hierboven zegt geldt niet alleen voor i845 chips geloof ik. Oook KTx33 chips kunnen slechts een bepaald maximum aan DIMMs vreten.

[Kippenijzer]

Het feit dat je framebuffer niet werkt ligt volgens mij inderdaad gewoon aan de framemuffer implementatie in de kernel, bij mij wijgerde hij ook beeld te geven na van 512 naar 1gb op een highmem kernel te zijn gegaan... Bye Bye framebuffer dus.... (Ti4400 @ KT333 Athlon system)

[Remenic]

Ik las net iets interessants op OSnews.com over iemand die Linux op een 64GB x86 server heeft weten te installeren.

http://osnews.com/comment.php?news_id=3157

"...his patch overcomes the 1GB mem_map virtual space limitation imposed by x86 32-bit servers, without which the kernel over-runs allowable memory space..."

Misschien dat dit bij jou ook het probleem is?

[MadEgg]

Mwah. Ik probeer geen 64 GB te installeren . En uit dat verhaal maak ik op dat de performance minder is zonder die patch, niet dat het niet werkt.

Ik heb vandaag ook maar even gcc, glibc, xfree en vele andere packages opnieuw gecompiled met march=pentium3 ipv march=pentium4 aangezien die laatste foute SSE2 instructies scheen te produceren.

Dit verhielp het UT2003 probleem echter niet. Ik krijg de volgende melding:

code:

[14]  ./ut2003-bin [0x805520e]
[15]  ./ut2003-bin(main+0x296e) [0x805820e]
[16]  /lib/libc.so.6(__libc_start_main+0xa4) [0x40babdc4]
[17]  ./ut2003-bin(ValidateCDKey__Fv+0x4d) [0x80512d1]
Signal: SIGSEGV [segmentation fault]
Aborting.

Het feit dat ie stopt bij ValidateCDKey laat me denken dat hij de CD-key is kwijtgeraakt, ik zal eens proberen om UT2003 opnieuw te installeren, kijken of het dan werkt.

[ajvdvegt]

Is dit wel een geheugen probleem, en geen compiler-versie probleem? Gcc3.2 is niet compatible met 2.9x. Als je alles vers hebt geemergd lijkt het me dat je 3.2 hebt, en UT2003 zal wel met gcc2.9x zijn gecompileerd.

[deadinspace]

Remenic schreef op 31 maart 2003 @ 12:07:
Ik las net iets interessants op OSnews.com over iemand die Linux op een 64GB x86 server heeft weten te installeren.

http://osnews.com/comment.php?news_id=3157

"...his patch overcomes the 1GB mem_map virtual space limitation imposed by x86 32-bit servers, without which the kernel over-runs allowable memory space..."

Dat is hier niet van toepassing

Het probleem met x86 met veel RAM is dat er (grofweg) slechts één GB aan RAM in kernelspace gemapt kan worden. Een aantal dingen moeten binnen die 1 GB gemapt worden. Geheugen is verdeeld in pages, en de kernel moet van elke page de status bijhouden (zoals in het mem_map array bv). Hoe meer RAM, hoe meer pages, hoe groter dergelijke boekhoudings-informatie wordt. Als je 64 GB hebt, dan is meer dan 800 MB nodig voor dergelijke informatie. Dat betekent dat de kernel nog maar iets van 200 MB overhoudt aan kernelspace memory, en dat heeft een zeer negatieve invloed op performance.

Met 1.5 GB RAM is maar een meg of 20 a 25 nodig voor dergelijke informatie, en dat is geen significant deel van de 1 GB kernel memory space.

[MadEgg]

ajvdvegt schreef op 31 maart 2003 @ 22:04:
Is dit wel een geheugen probleem, en geen compiler-versie probleem? Gcc3.2 is niet compatible met 2.9x. Als je alles vers hebt geemergd lijkt het me dat je 3.2 hebt, en UT2003 zal wel met gcc2.9x zijn gecompileerd.

UT2003 deed het voor de memory upgrade wel. En toen was ook m'n systeem met Gcc3.2 gecompileerd.

Verder komt UT2003 met z'n eigen SDL-libs en dergelijke, waarschijnlijk zodat dat soort problemen niet kunnen onstaan. Best slim bedacht

Sommige Linux-users schijnen iets tegen dat soort dingen te hebben, ik vind het juist een uitvinding Maar di's nogal offtopic.

In ieder geval kan het geen compiler-versie probleem zijn. Waarschijnlijk die key, maar ik heb ut nog niet opnieuw geinstalleerd * MadEgg is lui

[MadEgg]

Mkay. Dat hielp.. UT2003 ge reinstalled en het werkt weer als een zonnetje... naja, nog altijd minder FPS dan in Windows, maar goed. Da's niet mijn fout

[Apache]

MadEgg schreef op 01 April 2003 @ 10:27:
Mkay. Dat hielp.. UT2003 ge reinstalled en het werkt weer als een zonnetje... naja, nog altijd minder FPS dan in Windows, maar goed. Da's niet mijn fout

komt door de minder goede opengl renderen bij UT2003, onder windows kan je switchen direct3D & opengl en dan krijg je ook mindere performance.

[NaliXL]

deadinspace schreef op 31 maart 2003 @ 01:38:
Ik weet geen URL, maar ik weet wel dat de i845 chipsets (alle varianten afaik) slechts 4 memory banks ondersteunen. Een memory bank is een "zijde" van een memory slot. Elk memory slot bestaat dus uit twee banks. Drie memory slots zijn goed voor 6 banks, maar hiervan kun je er maar 4 gebruiken.

En ik heb ooit eens gelezen (ook weer geen URL), dat Linux begint bij het vullen van het bovenste van het geheugen, terwijl Windows bij het onderste begint. Aangezien het probleem wat jij hier beschrijft dus bij de laatste DIMM zit, is het vrij logisch dat Linux problemen krijgt en Windows niet, dacht ik zo...... Of zie ik dat verkeerd?

[deadinspace]

Dat zou kunnen ja. Verschillende geheugen-indeling is sowieso één van de verschillen die bij brakke hardware tot heel verschillende resultaten kan leiden in Windows en GNU/Linux.

[_nethack]

Dat zwarte scherm had ik ook last van bij een upgrade naar een gigabyte.
Het lijkt dat de framebuffer code het videogeheugen (dubbel!!) onder de 1 gigabyte grens probeert te mappen, iets wat niet meer lukt met een gig intern ram.
Bij het opgeven van de parameter mem=768M aan de kernel deed de framebuffer het wel. (videokaart met 128M ram)

[MadEgg]

Apache schreef op 01 April 2003 @ 11:23:
[...]
komt door de minder goede opengl renderen bij UT2003, onder windows kan je switchen direct3D & opengl en dan krijg je ook mindere performance.

Wat me ook opvalt in de ut2003.log file dat hij zegt: "32 MB AGP Memory allocated" of iets in die geest, terwijl ik 128 MB RAM op mn nvidia gf4 ti4400 heb...

_nethack schreef op 01 april 2003 @ 14:22:
Dat zwarte scherm had ik ook last van bij een upgrade naar een gigabyte.
Het lijkt dat de framebuffer code het videogeheugen (dubbel!!) onder de 1 gigabyte grens probeert te mappen, iets wat niet meer lukt met een gig intern ram.
Bij het opgeven van de parameter mem=768M aan de kernel deed de framebuffer het wel. (videokaart met 128M ram)

Maar dan heb je dus 256 MB RAM minder, of niet? En werkt die methode ook nog met meer dan 1 GB RAM?
Want als ik dus 512 eraf zou halen kan het nog niet in die 1 GB gemapt worden...
Nouja, zoveel is die penguin bij het opstarten me nou ook weer niet waard

[_nethack]

Klopt, in jou geval zou je dus de helft van je memory gaan missen.
Het ging mij overigens niet echt om de penguin, maar meer om het feit dat m'n TFT scherm op 1024x768 het mooiste, scherpste beeld geeft.

[MadEgg]

Ik gebruik toch voornamelijk X, en in de console vind ik 80x25 regels toch nog altijd ut mooiste

Maarja, die Tux_at_the_Beach bootlogo heeft me overgehaald om de framebuffer maar eens aan te zetten...