Gentoo loopt vast bij processorbelastingen

[deepbass909]

Ik heb sinds een weekje gentoo 2004.3 op mijn pc staan, maar elke keer als ik een groot pakket probeer te compilere (bijvoorbeeld KDE of Mozilla) loopt de pc vast met de volgende foutmelding:

code:

<1>Unable to handle kernel paging request at virtual address 35c56118
 printing eip:
c012d39a
*pde = 00000000
Oops:  0000
CPU:     0
EIP:     0010:[<c012d39a>]   Not tainted
EFLAGS:  00010006
eax: d78de040   ebx: d78de040   ecx: d78de040   edx: 00000000
esi: c1589bb8   edi: 00000246   ebp: 000001f0   esp: d5ad7f48
de: 0018   es: 0018   ss: 0018
Process bash (pid: 12130, stackpage=d5ad7000)
Stack: 00000af0 d5ad6000 dfd714c0 d5ad65a0 fffffff4 d5bac000 c0115826 c1589bb8
       000001f0 41e57727 00000000 00006007 d5ad7f98 d5ad7f98 c013f8c5 df016cc0       00000000 c013d15d d5ad7f98 bffffb24 df016cc0 d5ad6000 bffffbd4 00000000
Call Trace:    [<c0115826>] [<c013f8c5>] [<c013d15d>] [<c0105a7>] [<c0106f3f>]

Code: 8b 44 81 18 0f af 5e 18 89 41 14 03 59 0c 40 74 18 57 9d 89

Na verloop van tijd verschijnt er weer een soort gelijke melding, met iets andere e*x, Process en Stack waarden. En elke actie die daarna gedaan wordt, al is het maar het indrukken van een toets, leidt tot meer van dit soort meldingen.

Ik weet niet goed wat ik hiermee aan moet. Zit het probleem in de software of hardware?

De gebruikte hardware is:

code:

CPU:     AMD Duron 1600
MB:      MSI K7T Turbo 2
Geheugen: 2 x 256MB sdram
Video:    Geforce 2 GTS 32 MB

Hardware heb ik overigens uitvoerig getest met o.a. burn-in test en memtest86 na eerdere problemen. Er waren toen wat problemen met mijn geheugen, maar die lijken nu opgelost (memtest86 geeft niet langer fouten in het geheugen aan).

Wat compilatie betreft, alles wordt met gedaan met de volgende settings:
USE="-gtk -glx qt cdr kde dvd -gnome -alsa"
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=athlon-xp -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

Daarnaast maakt het niet uit welke kernel ik gebruik, of het nou 2.4.28 of 2.6.9 van gentoo is of 2.4.28 standaard kernel.

Kortom ik zit echt vast.

[Flydude]

Als ik het goed begrijp komt een kernel oops alleen vanuit kernel-bugs of vanuit brakke hardware. Aangezien je al aan geeft dat memtest problemen aangaf, denk ik dat je probleem toch bij je geheugen ligt. Je zegt: de problemen lijken opgelost. Wat heb je gedaan om deze problemen op te lossen. Die verdwijnen nl. niet vanzelf.

Ik zou zeggen, probeer het eens met een andere geheugenmodule en kijk wat er dan gebeurt.

[deepbass909]

wat jij zegt, is precies wat ik heb gedaan. Om de één of andere vage reden wouden 2 dezelfde modules niet goed samen werken (2 spektek modules van 256MB, gelijke specs).
Memtest86 gaf in 1 specifieke test (weet even niet meer welke) fouten bij de adressen waar de 2de module begon. Omwisselen van modulles maakte niet uit. Ik heb toen een andere 256MB module gepakt (ander merk), en daarna heeft memtest86 geen fouten meer gegeven. Ik ga er daarmee vanuit dat mijn eventuele geheugen problemen verholpen zijn.

vandaar mijn twijfel...

[WHiZZi]

AMD Duron != -march=athlon-xp

Een duron is geen Athlon XP hoor (zou je willen ). Je moet -march=athlon gebruiken in je make.conf

Dat zou ook meteen verklaren waarom je systeem niet vastloopt na zo'n melding, normaal gesproken als je die melding ziet heb je een kernel crash gehad oid.

Mijn advies is gewoon een nieuwe stage3 te installeren voor AMD Athlon / Duron ipv de stage3 voor athlon-XP, want die geeft inderdaad dit soort vreemde meldingen..

[ Voor 102% gewijzigd door WHiZZi op 19-01-2005 13:00 ]

[Wilke]

WHiZZi schreef op woensdag 19 januari 2005 @ 12:53:
AMD Duron != -march=athlon-xp

Check, dat zal het zijn inderdaad.

Verder heb je inderdaad geen heftige optimalisatie-settings, en dat zou ik ook zo houden - het is het gelazer wat je er vroeg of laat mee krijgt niet waard.

[deepbass909]

Ik heb uit andere topics begrepen dat een Duron 1600 een Athlon-XP was met minder cache geheugen, lagere clock snelheid, maar met dezelfde core. Ik ging ervan uit dat ik daarom zou kunnen optimaliseren voor de Athlon-XP. Ik ga maar een herinstall doen met de Athlon/Duron stage en een andere make config...

ps. memtest86 heeft inmiddels 9 cycli doorlopen zonder fouten te gegeneren, ik concludeer daar dus (terrecht neem ik aan) uit dat mijn geheugen in orde is.

[deepbass909]

WHiZZi schreef op woensdag 19 januari 2005 @ 12:53:
AMD Duron != -march=athlon-xp

Een duron is geen Athlon XP hoor (zou je willen ). Je moet -march=athlon gebruiken in je make.conf

Dat zou ook meteen verklaren waarom je systeem niet vastloopt na zo'n melding, normaal gesproken als je die melding ziet heb je een kernel crash gehad oid.

Mijn advies is gewoon een nieuwe stage3 te installeren voor AMD Athlon / Duron ipv de stage3 voor athlon-XP, want die geeft inderdaad dit soort vreemde meldingen..

Er is voor de Athlon/Duron geen speciale Stage 3 tarball... welke kan ik dan beter kiezen, de x86 of i686? ik kan daar bij gentoo namelijk niet zo snel antwoord op vinden.

[bigben04]

deepbass909 schreef op woensdag 19 januari 2005 @ 17:52:
[...]


Er is voor de Athlon/Duron geen speciale Stage 3 tarball... welke kan ik dan beter kiezen, de x86 of i686? ik kan daar bij gentoo namelijk niet zo snel antwoord op vinden.

i686. x86 is bijvoorbeeld al geschikt voor 386 processoren terwijl i686 pas vanaf pentium en athlon bruikbaar is volgens mij.

[wacko]

Ja, ik zou eerst je CFLAGS in /etc/make.conf eens een beetje opschonen naar een redelijk default waarde. Als je heel fanatiek bent kun je ook eventueel vanaf stage1 opnieuw installeren. Als je dan nog steeds problemen krijgt kun je nog proberen een andere kernel te nemen (2.4 ipv 2.6 of andersom bijvoorbeeld).

[deepbass909]

om eerlijk te zijn, vind ik mijn CFLAGS vrij sober, als ik naar de mogelijkheden kijk.
Maar waarschijnlijk waren er toch meer verschillen tussen de AthlonXP en de laatste durons dan ik verwachtte, want sinds ik de i686 stage3 heb gepakt, en als -march=athlon gebruik, heb ik nog geen vastloper gehad (tenminste... 1 keer nu, maar zonder die fout)

[matthijsln]

deepbass909 schreef op woensdag 19 januari 2005 @ 10:59:
Ik weet niet goed wat ik hiermee aan moet. Zit het probleem in de software of hardware?

De gebruikte hardware is:

code:

CPU:     AMD Duron 1600
MB:      MSI K7T Turbo 2
Geheugen: 2 x 256MB sdram
Video:    Geforce 2 GTS 32 MB

Controleer ook eens of de condensatoren op je moederbord nog in orde zijn: MSI K7T kapot door lekkende condensatoren *pics*

[deepbass909]

Dat heb ik ook toevallig laatst gedaan. Optisch is mijn pc helemaal in orde, hij is zelfs stof vrij. Maar tot nog toe lijkt hij goed te lopen, mogen maar even de echte test doen, en kijken of ik KDE geinstalleerd kan krijgen... daar wordt het nu te laat voor... hij namelijk er veeeeeel voor compileren...
Ik wou hem op een andere kamer zetten, en via ssh starten, maar helaas, dat wou nog even niet zo snel lukken..

[AlterEgo]

deepbass909 schreef op woensdag 19 januari 2005 @ 17:27:
Ik heb uit andere topics begrepen dat een Duron 1600 een Athlon-XP was met minder cache geheugen, lagere clock snelheid, maar met dezelfde core.

Dat is correct. Je -march zal geen problemen veroorzaken.

[Sir Isaac]

Duron is vanaf 1.0 Ghz een uitgeklede Athlon XP, tot 950 Mhz een Athlon. Zou het kunnen zijn dat de spanning op je processor te laag wordt als je systeem zwaar belast wordt? Houdt dat een in de gaten (lm_sensors). Wat voor voeding heb je, hoeveel schijven (hd, cd)?

[_JGC_]

WHiZZi schreef op woensdag 19 januari 2005 @ 12:53:
AMD Duron != -march=athlon-xp

Een duron is geen Athlon XP hoor (zou je willen ). Je moet -march=athlon gebruiken in je make.conf

Dat zou ook meteen verklaren waarom je systeem niet vastloopt na zo'n melding, normaal gesproken als je die melding ziet heb je een kernel crash gehad oid.

Mijn advies is gewoon een nieuwe stage3 te installeren voor AMD Athlon / Duron ipv de stage3 voor athlon-XP, want die geeft inderdaad dit soort vreemde meldingen..

Duron 1600 is gelijk of zelfs beter dan een Athlon XP 1600+
De Duron 1600 heeft alles wat een Athlon XP ook heeft, alleen wat minder cache (alhoewel dat bij de Duron 1600 Applebread wel meevalt)

[deepbass909]

Helaas, hij is me net weer vastgelopen bij het compileren van KDE...

De samenstelling van mijn pc is:

code:

MB:        MSI K7T Turbo2
Processor: AMD Duron 1600
Geheugen:  512MB (1 spectek 256Mb & 1 256mb merk onebekend)
Video:     Asus v7700 Deluxe (GeForce2 GTS, 32MB)
Netwerk:   3com 905C-TX-M
Geluid:    SBLive! (eerste generatie)
Harddiks:  Western Digital WD400 (40GB, 7200rpm, Windows)
           Western Digital Caviar 38400 (8,4GB, 5400 rpm, Gentoo)
CD-rom:    Acer 52x CD-rom
Brander:   Nec ND-1300
Voeding:   Q-Tec ADT-350 (350Watt, 12V 15Amp, 5V 30Amp)

Wat betreft hardware monitoring onder linux, heb ik nog niet de kans gehad om dat uit te zoeken, dus als iemand mij kan vertellen hoe het moet, graag.
Ik zal zo een linkje naar de HTML-output van MBM onder windows 2000 posten, maar de waarden zijn erg stabiel. En ik zal een temperatuur sensor in mijn voeding hangen, om te kijken of die net te warm wordt.

[edit]
Hier staan de read-outs in HTML van MBM 5 onder win2k. De Case fan was afgekoppeld, maar draait inmiddels weer mee.

[ Voor 12% gewijzigd door deepbass909 op 20-01-2005 12:39 ]

[deepbass909]

Ik heb net mijn hele pc opnieuw aangesloten, hij zit nu ook op randaarde, en er draait een extra case fan, en tot nog toe (klop klop) blijft hij goed draaien...
maar hij is pas bij pakket 4 van de 75...

ik ga het zo afbreken, en de athlon-xp stage er weer opzetten, aangezien die sneller en beter moet lopen dan de i686 met athlon optimalisaties...

ps. de temperatuur in mijn voeding staat nu al een tijdje stabiel op 31 graden bij een omgevings temperatuur van 20 graden... die wordt dus niet echt overdreven warm

[ Voor 58% gewijzigd door deepbass909 op 20-01-2005 14:00 ]

[_JGC_]

Verwacht geen wonderen tussen i686 en athlon-xp optimalisaties. Die hele gentoo gekte met al dat gecompileer heeft helemaal geen nut tot op zekere hoogte: de programma's die je gebruikt staan 99% van de tijd op user input te wachten, en die user is niet geoptimaliseerd door zn moeder op de wereld gezet

[deepbass909]

maar het is wel gewoon leuk :-p

en het is een proef installatie voor een dual PPro server, die ik zo optimaal mogelijk wil laten draaien (5% snelheidswinst is op die machine wel te merken, want dat betekend gewoon meer bandbreedte beschikbaar voor samba en apache)

[AlterEgo]

deepbass909 schreef op donderdag 20 januari 2005 @ 11:58:
Wat betreft hardware monitoring onder linux, heb ik nog niet de kans gehad om dat uit te zoeken, dus als iemand mij kan vertellen hoe het moet, graag.

Met gkrellm2 en de benodigde i2c en sensor modules van de 2.6 kernel heb je redelijk snel een system monitor die grafiekjes schrijft van voltages, temps, en cpu load. Let daar eens op: als je cpu gebruik omhoog schiet, storten je voltages dan in (Vcore, 5 en 12 V) ? Gaat je temp heel snel omhoog? Dat zijn giveaways voor hardware problemen (ik geloof dat brakke elco's op kt133 borden al genoemd waren in dit topic).

[deepbass909]

Ik draai nu de 2.4.28 kernel, maar ik zal 2.6.9 er ook eens opzetten en kijken wat er gebeurt. Overigens heb ik nog geen X (tenminste... hij heeft als het goed is vannacht staan compileren, maar ik ben nog niet weer thuis geweest sinds het gestart is) en kan dus nog niks grafisch zien.

Maar als je naar mijn MBM readout onder win2k kijkt, dan zie je dat mijn voedingslijnen eigenlijk wel stabiel zijn.

code:

core:   1.49 V
+3.3:   3.36 - 3.37 V
+5.00:  5.10 - 5.13 V
+12.00: 12.07 - 12.13 V

Volgens mijn hardware monitor wijkt de 5 volt dus maar iets van 2 à 3% af en de 12 volt lijn zelfs maar max 1%... Nu zijn dit niet 100% betrouwbare metingen, omdat er geen onafhankelijke stabiele referentie spanning is (zoals bij een multimeter). Ik zal vanmiddag eens mijn multimeter erop zetten, en kijken wat die aangeeft. Daarnaast neem ik voor de zekerheid een 450Watt Q-Tec van mijn werk mee.

Wat temperaturen betreft, de processor temperatuur is eigenlijk altijd 10 tot 17 graden boven de temperatuur in mijn kast, dus ook niet spectaculair. Ik heb een tijdje terug Burn-In test maximaal laten belasten, en dat had op de waarden ook geen enkel effect, de CPU werd zelfs niet warmer.

Er lijken dus qua hardware readouts totaal geen indicaties te zijn dat er ergens een storing zit.

[AlterEgo]

Waarden zeggen niet heel veel: veranderingen, schommelingen van waarden onder wisselende belastingen: dat zegt een hoop.

[deepbass909]

Ik heb nu een multimeter aan de 12volt lijn zitten, en die schommelt tussen 11,97 V en 12,00 Volt. Hij is nu even aan het compileren, en de 12 Volt zit op 11,99 Volt, af en toe 11,98 Volt, niet wat je slecht noemt.

De 5 Volt lijn zit op 5,13 - 5,14 Volt.... en de 3,3 Volt lijn zit op 3,34 stabiel.

Alle lijnen lijken dus toch echt ok...

Alleen de negatieve lijnen zijn wat afwijkend, -5 Volt is -4,6 Volt en -12 Volt is -11,60 Volt, maar nog steeds niets verontrustends...

Ik heb zojuist wel de 8,4GB schijf als enige harddisk in mijn systeem gezet, en heb een andere voeding klaar liggen om te testen, misschien dat mijn huidige te veel ruis geeft, wat ik nu helaas niet kan meten.

Een laatste mogelijkheid is eventueel uit voorzorg de elco's vervangen, maar dat doe ik eigenlijk liever niet...

[ Voor 41% gewijzigd door deepbass909 op 21-01-2005 14:34 ]

[deepbass909]

Ik heb er nu een Q-Tec 400 Watt low noise in gehad, maar wederom een vastlopen... tenminste... het is eigenlijk geen echte vastlopen, alleen de kernel crasht....

Zou het probleem misschien in een verkeerd geconfigureerde kernel kunnen zitten? Deze storingen treden eigenlijk pas op nadat ik met een eigen kernel heb opgestart..

Als laatste hardware zit ik eventueel ook te denken in richting van de harddisk die ik op het moment gebruik... De foutmelding wijst richting het virueel geheugen, ofwel de swap partitie...

[Arx]

deepbass909 schreef op vrijdag 21 januari 2005 @ 19:41:
Ik heb er nu een Q-Tec 400 Watt low noise in gehad, maar wederom een vastlopen... tenminste... het is eigenlijk geen echte vastlopen, alleen de kernel crasht....

Zou het probleem misschien in een verkeerd geconfigureerde kernel kunnen zitten? Deze storingen treden eigenlijk pas op nadat ik met een eigen kernel heb opgestart..

Als laatste hardware zit ik eventueel ook te denken in richting van de harddisk die ik op het moment gebruik... De foutmelding wijst richting het virueel geheugen, ofwel de swap partitie...

Als ik het goed lees uit je error is het je main memory. Er wordt een een stuk geheugen gelezen met het adres van een null-pointer en dat vindt ie niet leuk. De vraag alleen is waarom is die pointer (*pde) 0. ? Dat het je cache geheugen is, denk ik niet. Dan zou je veel sneller problemen hebben, dat ding loopt namelijk heel snel vol.

Je zegt in je eerste post dat je het met verschillende kernels hebt, in je laatste post dat het alleen met je eigen kernen hebt? Wat is het nou? Ik las een thread op linuxquestions over een soort gelijk probleem. Die jongen heeft zijn spanning een stukje hoger gezet en toen was het opgelost. Dat wil niet zeggen dat het voor jou de oplossing is.

Bizar is het in ieder geval wel.

[ Voor 3% gewijzigd door Arx op 21-01-2005 20:32 ]

[deepbass909]

Ik ben inmiddels al 2 keer alles opnieuw installeren verder... vandaar dat ik nu nog maar 1 kernel gecompileerd heb (maak ze dus zelf en gebruik niet de genkernel).

Welke spanning zette hij precies hoger? ik neem aan van zijn processor?

[Verwijderd]

Als je kijkt naar de eerste regel:

code:

<1>Unable to handle kernel paging request at virtual address 35c56118

De kernel wil een geheugenplaats gebruiken en dat lukt niet. Het gaat dus over geheugen. Dan nu wat voor geheugen, ze hebben het over 'paging' en een 'virtual address'.
'paging' is volgens mij een andere naam voor swappen/pagen en een 'virtual address' is dus een virtueel geheugenadres, werkgeheugen werkt niet met virtueel geheugen. Wat ik dus denk is dat het je swapgeheugen is vooral omdat je zegt dat je het hebt bij de zwaardere compilaties.

Als ik jou was zou ik eens je swappartitie checken of de swappartitie uitschakelen.

Disclaimer, ik weet het niet zeker

[ Voor 15% gewijzigd door Verwijderd op 21-01-2005 23:44 ]

[Arx]

Het zou met swappen te maken kunnen hebben.

Hier is de thread waar ik dat las:

http://www.linuxquestions...ostid=1415055#post1415055

[Verwijderd]

Arx schreef op zaterdag 22 januari 2005 @ 00:12:
Het zou met swappen te maken kunnen hebben.

Hier is de thread waar ik dat las:

http://www.linuxquestions...ostid=1415055#post1415055

offtopic:
-1 dubbelpost

[Arx]

Verwijderd schreef op zaterdag 22 januari 2005 @ 00:41:
[...]

offtopic:
-1 dubbelpost

offtopic:
Hahaha, Sorry

[Lancer]

Hoewel nuttig om te checken heeft een virtueel adres niets te maken met swap geheugen. Ieder proces krijgt zijn eigen stuk geheugen met dezelfde adressen. Deze zijn virtueel. De kernel vertaalt het vervolgens naar de fysieke pagina's in het geheugen (of in het swap geheugen)

[deepbass909]

Ik heb vanavond 1 reep van mijn geheugen eruit gehaald, en draai nu nog op 256MB. Rond 18.00 uur heb ik weer de compilatie gestart van X en nu KDE, en tot op heden loopt alles nog steeds soepel, terwijl bij eerdere pogingen deze compilaties altijd stuk liepen. Hij dus inmiddels 6 uur stabiel aan het compileren.

Er zat dus iets fout met betrekking tot het geheugen, welke zowel individueel als samen volgens memtest86 foutloos zouden zijn... schiet mij maar lek...

[Ronald]

Ik heb eerder een geheugen probleem gezien waar memtest86 48 uur feilloos was, maar zodra ik maar wat dan ook onder linux deed het binnen 10 minuten plat ging.

(meer geheugen dan moederbord ondersteunde, chipset ondersteunde het wel, maar dus niet voldoende stabiel)

Dus ja het kan dat memtest86 je probleem niet geeft, maar linux wel overal en altijd op zijn bek gaat. Zoiezo lijken die nullpointer oopsen vaak op hardware te duiden.

Mobo en geheugens die mekaar niet lekker vinden komt nogal eens voor, lastig om te identificeren hoe en wat. succes!