[GENTOO] gcc upgrade 3.3.6 -> 3.4.4-r1

[ArchRAIDen]

Ik probeer te upgraden naar de laatste stable versie van gcc.
Ik gebruik de gcc upgrade guide op
http://www.gentoo.org/doc/en/gcc-upgrading.xml
tijdens het compileren van de nieuwe gcc versie ( emerge -uav gcc )
loopt m'n systeem vast en het beeld doet vreemd, alsof
bepaalde tekens HEEL snel wijzigen.
Ook ben ik een keer tijdens het compileren vreemde tekens tekengekomen
die ergens in de ASCII set vanaf 128 voorkomen.
Dit is niet normaal tijdens een compile, overigens liep het systeem toen ook vast.

ik ben reeds geupgrade naar kernel 2.6.15.1 maar gcc wil nog steeds niet.
Ook andere CFLAGS -mcpu=i686 i.p.v. -march=pentium4 werken ook niet.

[irondog]

Dit lijkt me zeer weinig met het updaten van GCC te maken te hebben. Eerlijk gezegd denk ik eerder dat het probleem veroorzaakt wordt door een instabiel systeem of een brakke console (of framebuffer) driver.

[ArchRAIDen]

Na vannacht denk ik dat ook.
Vreemde is dat het systeem 75 dagen zonder problemen gedraaid heeft.
Gisteravond rond 20:00 heb ik mijn systeem opnieuw opgestart.
Vanmorgen keek ik, en bleek: vastgelopen
opnieuw opgestart en draait weer, aan logs is niets te zien.

Het gaat trouwens om een server systeempje, er draait geen X op
en deze heb ik geexclude uit mijn use flags, alsmede -kde.

[BoAC]

Heb je al memtest gedraait?
Is de koeling van je systeem nog wel goed?
Wat voor een console/framebuffer-driver gebruik je?

Misschien is je hardware wel aan het overlijden

[ArchRAIDen]

Koeling ga ik vanavond even controleren.
Achter zitten er in ieder geval twee 80 mm ventilatoren in de kast (doen het nog).
en een ventilator in de voeding.
en voorin de kast nog een 80 mm ventilator.
Processor koeler zou ik even moeten controleren.

console/framebuffer driver -> waar kan ik dat controleren?
zit waarschijnlijk in de kernel?

[BoAC]

ArchRAIDen schreef op woensdag 25 januari 2006 @ 10:43:
Koeling ga ik vanavond even controleren.
Achter zitten er in ieder geval twee 80 mm ventilatoren in de kast (doen het nog).
en een ventilator in de voeding.
en voorin de kast nog een 80 mm ventilator.
Processor koeler zou ik even moeten controleren.

Kijk dan ook gelijk naar de rest van je hardware

console/framebuffer driver -> waar kan ik dat controleren?
zit waarschijnlijk in de kernel?

Yep
_{Deze is uit te schakelen dmv kernel-parameters tijdens het booten}

[ Voor 8% gewijzigd door BoAC op 25-01-2006 11:00 . Reden: Kernel params ]

[Boudewijn]

waarom zou je een fb driver in een server draaien?
Althans ik neem aan dat het een server is, vwg geen X.

[SandStar]

als je compile actie van gcc niet goed is gegaan schakelt ie ook niet over naar de nieuwe versie. Zou dus betekenen dat je gcc (en/of hardware) al brak was voordat je een nieuwe versie ging compilen.

[ArchRAIDen]

Boudewijn schreef op woensdag 25 januari 2006 @ 16:07:
waarom zou je een fb driver in een server draaien?
Althans ik neem aan dat het een server is, vwg geen X.

is idd een server

zojuis kernel opties gecontroleerd:
support for frame buffer devices staat uit
ik heb echter wel agpgart aan staan, deze zou ook uitkunnen.

kast open gemaakt, ventilator doen het allemaal nog. (2 achter, 1 voeding, voor 1, 1 cpu).
ik zie nu wel dat ik de memory slots verkeerd heb ingedeeld.
Het is een P4P800-VM bordje, en ik heb 2 DDR modules in A1 en A2 gestoken
(blauwe en een zwarte) volgens het boekje moeten ze blauw-blauw en zwart-zwart,
dus dat ga ik even omprikken.

Overigens heeft dat ding wel nu de hele dag gedraaid.

[LollieStick]

Doet eens memtest86

[ArchRAIDen]

LollieStick schreef op donderdag 26 januari 2006 @ 00:38:
Doet eens memtest86

vannacht (na omwisselen van de DDR modules) de gehele nacht
met memtest86 laten draaien, heeft 12,5 uur gedraaid, nul errors.
Dat lijkt in orde.

vanavond ga ik weer kijken of gcc wil compilen.

Heeft het nut om ook agpgart uit te zetten?

[BoAC]

ArchRAIDen schreef op donderdag 26 januari 2006 @ 08:33:
...

Heeft het nut om ook agpgart uit te zetten?

Mag op zich geen invloed hebben.
Het enige wat is nog overblijft wat een probleem kan geven is je voeding denk ik.

[_JGC_]

een GCC compile is nog intensiever dan een kernel compile, en memtest86 0 errors wil niet altijd zeggen dat je ook 0 fouten hebt.
Kijk eens naar condensatoren op je moederbord of in je voeding: als die bol staan kan het idle goed gaan, maar zodra je load op je doos gooit gaat ie neer.

[ArchRAIDen]

Zojuist GCC 3.4.4-r1 kunnen compilen.

Enige wat ik dus gedaan heb:

- DDR modules in de juiste sloten gezet.
- CFLAGS: -O2 i.p.v. -O3

weet iemand de extra waarde van -O3? (opties die nuttig zijn?)
huidige CFLAGS: -march=pentium4 -O2 -pipe -fomit-frame-pointer

[Verwijderd]

ArchRAIDen schreef op donderdag 26 januari 2006 @ 20:29:
Zojuist GCC 3.4.4-r1 kunnen compilen.

Enige wat ik dus gedaan heb:

- DDR modules in de juiste sloten gezet.
- CFLAGS: -O2 i.p.v. -O3

weet iemand de extra waarde van -O3? (opties die nuttig zijn?)
huidige CFLAGS: -march=pentium4 -O2 -pipe -fomit-frame-pointer

Waarom zet je uberhaubt compilerflags als je niet snapt wat ze doen?

http://gcc.gnu.org/online...ons.html#Optimize-Options

Lees dat eens door.

En als je toch bezig bent:
http://gcc.gnu.org/onlinedocs/

Eigenlijk zou iedereen dit moeten lezen voordat ze aan de slag gaan met compilerflags, het zou een boel leed voorkomen.

[ Voor 15% gewijzigd door Verwijderd op 26-01-2006 20:47 ]

[_JGC_]

Sowieso is je compiler er niet blij mee als je zelf CFLAGS gaat zetten. Sommige CFLAGS genereren nou eenmaal brakke code. Op Archlinux gebruiken we CFLAGS="-march=i686 -O2 -pipe", wat op zich meer dan genoeg optimalisatie geeft. Ik heb een tijdje Gentoo gedraaid, maar dat was zeker niet sneller dan Archlinux naar mijn ervaring.

[irondog]

_JGC_ schreef op donderdag 26 januari 2006 @ 22:26:
Sowieso is je compiler er niet blij mee als je zelf CFLAGS gaat zetten. Sommige CFLAGS genereren nou eenmaal brakke code.

Juist. Laat mij er wel even aan toevoegen dat een systeem die een niet-brakke kernel draait, nooit zal crashen (=volledig hangen) op brakke user-code gegenereerd door een ge-overclockte compiler.

Op Archlinux gebruiken we CFLAGS="-march=i686 -O2 -pipe", wat op zich meer dan genoeg optimalisatie geeft. Ik heb een tijdje Gentoo gedraaid, maar dat was zeker niet sneller dan Archlinux naar mijn ervaring.

Ach tuurlijk niet. Die optimalisatie flauwekul komt veelal van mensen af die niet inzien dat performance in de source zit en natuurlijk nooit in de gekozen CFLAGS. Sommige mensen zitten gewoon om de haverklap hun hele world en system opnieuw te compilen omdat ze ergens weer een of andere nieuwe flag gevonden hebben op een vaag forum. Naar mijn mening levert dit in het beste geval 0,05% executie-winst op terwijl je je systeem achterlaat met een sterk verhoogde filesystem-fragmentatie.

Als je snapt wat bepaalde flags doen, kun je wel winst halen. Winst, zoals in: de resultaten zijn voorspelbaar en daarom goed voor mijn systeem. Mijn CFLAGS beperken zich tot wat jij hebt plus -fomit-frame-pointer. Deze flag is vrijwel nooit standaard (in welke distro dan ook), maar levert zonder twijfel winst op. Flags die code mogelijk vergroten (zoals -funroll-loops) mijd ik onder het mom van: een harddisk is al zo traag vergroot de IO op deze bottleneck dus niet.

Maar het is gewoon nonsense om het hele systeem te compilen met een complexe CFLAGS-configuratie en dan te verwachten dat het voor alle applicaties baat. -O3 is eigenlijk al teveel van het goede. Ach ja. Je moet mensen in hun waarde laten. Ik heb liever een /bin/ls die werkt dan eentje die een halve instructie minder uitvoert.

[ Voor 7% gewijzigd door irondog op 27-01-2006 00:18 ]

[Verwijderd]

irondog schreef op vrijdag 27 januari 2006 @ 00:01:
[...]
Juist. Laat mij er wel even aan toevoegen dat een systeem die een niet-brakke kernel draait, nooit zal crashen (=volledig hangen) op brakke user-code gegenereerd door een ge-overclockte compiler.


[...]

<knip>
Als je snapt wat bepaalde flags doen, kun je wel winst halen. Winst, zoals in: de resultaten zijn voorspelbaar en daarom goed voor mijn systeem. Mijn CFLAGS beperken zich tot wat jij hebt plus -fomit-frame-pointer. Deze flag is vrijwel nooit standaard (in welke distro dan ook), maar levert zonder twijfel winst op. Flags die code mogelijk vergroten (zoals -funroll-loops) mijd ik onder het mom van: een harddisk is al zo traag vergroot de IO op deze bottleneck dus niet.
<knip>

Dit is de Gentoo default:
CFLAGS="-O2 -pipe -march=arch -fomit-frame-pointer"

[ArchRAIDen]

Wat een upgrade al niet teweeg brengt....

Het is overigens zo dat packages in Gentoo soms hun eigen Compiler Flags
mee brengen, omdat ze bijvoorbeeld met -O3 niet goed gaan compileren.

Inmiddels is mijn systeem weer up-to-date tot de laatse stable packages.
Misschien dat dit nog een interessant topic kan worden m.b.t. Compiler Flags.

[Verwijderd]

ArchRAIDen schreef op zaterdag 28 januari 2006 @ 09:53:
Wat een upgrade al niet teweeg brengt....

Het is overigens zo dat packages in Gentoo soms hun eigen Compiler Flags
mee brengen, omdat ze bijvoorbeeld met -O3 niet goed gaan compileren.

Inmiddels is mijn systeem weer up-to-date tot de laatse stable packages.
Misschien dat dit nog een interessant topic kan worden m.b.t. Compiler Flags.

Wat Gentoo al niet teweeg brengt....

[_JGC_]

irondog schreef op vrijdag 27 januari 2006 @ 00:01:
[...]
Juist. Laat mij er wel even aan toevoegen dat een systeem die een niet-brakke kernel draait, nooit zal crashen (=volledig hangen) op brakke user-code gegenereerd door een ge-overclockte compiler.

Behalve als de compiler zelf gecompileerd is met deze brakke CFLAGS, en deze weer gebruikt is om een brakke kernel mee te bakken met brakke CFLAGS

Meestal zijn dit soort hangers gewoon hardware storingen overigens. Alle vage problemen die ik tot nu toe gehad heb met linux:
- Hangers bij veel disk I/O: een disk die de IDE bus ophing (Maxtor ATA66 disk van 6GB )
- Internal compiler errors, vaak crashes: 3 DDR geheugenslots gebruiken op een socketA bord op DDR333
- Vastloper bij het controleren van een reiserfs volume: een CPU die niet helemaal ondersteund werd door een moederbord, een reiserfsck triggerde net een cache instructie die de hele boel ophing.

[irondog]

_JGC_ schreef op zaterdag 28 januari 2006 @ 14:01:
Behalve als de compiler zelf gecompileerd is met deze brakke CFLAGS, en deze weer gebruikt is om een brakke kernel mee te bakken met brakke CFLAGS

Haha. idd. Daarom zeg ik met een niet-brakke kernel. Brakke usercode geeft gewoon excepties en kernels weten hier natuulijk echt wel raad mee. Een kernel die te crashen is met usercode is buggy.

Meestal zijn dit soort hangers gewoon hardware storingen overigens.

Tuurlijk, maar ik kan met mijn eigen buggy framebuffer drivertje het zaakje ook aan het hangen krijgen.
Het compileren genereert veel output en als dat op een framebuffer console gebeurt ben je niet alleen je CPU aan het stressen, maar ook de framebuffer driver.

Ik wilde met mijn eerste post eigenlijk het gebruik van een brakke versie van een patchset kernel niet meteen wegschuiven als oorzaak.