[Linux] D.net RC5-72 'bevriest' server

[[NUT]]

/me De oplossing was meer koeling, dus het onderstaande probleem is niet meer van toepassing... lees iig het hele topic even door als je toch wilt reageren *

Soft.Spex:
Debian r3.0
Linux Kernel 2.4.20
D.net RC5-72 clients 478 en 481(betaRC) (dnetc4xx-linux-x86-elf)

Hard.Spex:
Tyan Tiger MP
2x Athlon MP1800+ met Coolermaster HFC-L61 Silent
(verdere specs, zie signature)

Search
Gezocht en niet veel gevonden

Het probleem
Het moment waarop het gebeurt is tot nu toe altijd random geweest, en ik heb 1 keer een melding gezien op het scherm van mijn server, en daarbij werd er door de kernel geschreeuwt dat het d.net proggie voor de problemen zorgde waarop de kernel vervolgens crashte... maar niets te vinden in de logs enzo... dus had ik niets om naar d.net te sturen. De server 'bevriest' hierbij gewoon. Als ik de server gewoon zonder client laat draaien, is er niets aan de hand en fietst het gewoon vrolijk door, echter zodra ik de d.net client start is het weer deut... meestal binnen een dag of 2, soms na een week en 1x na 48dagen uptime...

Mijn Systeem
Als je naar de site toe gaat in mijn sig. staan er onderaan de specs van de server, en weer daaronder staan links naar de piccies van die server. Zoals je hebt kunnen zien als je bent wezen kijken, gaat het hier om een silenced Midi Chieftech Dragon kast. Echter zijn er genoeg fans in beweging om de temps in de kast redelijk laag te houden.

De Tests vooraf
Tot ik er Linux op installeerde heb ik met windows (oops! ) 2000prof en de Tyan tools het systeem met het windows (doe ik het weer! ) d.net proggie getest, op stabiliteit en temperaturen. op z'n aller heetst werden de CPU's 49 en 51 graden, en voor cpu's die max 90 mogen worden, is dat zeer redelijk . WEKEN heeft de machine zo gestaan, zonder 1x te crashen... dus ik *denk* dat het m'n hardware niet is.

De Finale Test
Maar voor ik d.net ga bestoken met emails en het forum daar vol ga posten met mijn beschuldigingen jegens de client en hun onkunde ( ) een redelijk proggie inmekaar te flanzen wil ik de trouwe beestjes onder de motorkap van deze server het vuur aan de schenen leggen met een ander programma, die ook 100% cpu gebruik aanwend om te doen wat het moet doen. Maar dan heb ik het dus over een programma wat dus beide CPU's pakt om te doen wat het doet, zoals de d.net client. Voor windows () zijn er bijvoorbeeld BurnK7 of Prime95 om die taken over te nemen, maar voor Linux weet(ken) ik er geen, heb gezocht op Google -en ook op GoT- maar uit de zoek resultaten word ik niet wijs of er wel zo'n programma bestaat

De Vraag!
WIE oh wie heeft er een proggie voor me, of een linkje waarmee ik dit kan testen.

Het moet
- 100% cpu gebruiken
- Dual CPU's ondersteunen (tegelijk)
- continue kunnen draaien

Mocht er iemand zijn die zegt van 'Goh dat heb ik ook!' of merkt dat bijvoorbeeld 1 CPU plots stopt en die ge-'reboot' moet worden voor hij verder wil, gaarne mij hier op de hoogte stellen...

Ik dank u voor uw aandacht

[ Voor 9% gewijzigd door [NUT] op 09-03-2003 02:45 . Reden: typo's ]

[deadinspace]

[NUT] schreef op 04 March 2003 @ 02:22:
Het moment waarop het gebeurt is tot nu toe altijd random geweest, en ik heb 1 keer een melding gezien op het scherm van mijn server, en daarbij werd er door de kernel geschreeuwt dat het d.net proggie voor de problemen zorgde waarop de kernel vervolgens crashte...

Niet om vervelend te doen, maar heb je die melding misschien opgeschreven? De exacte melding kan heel interessant zijn voor het vaststellen van de oorzaak.

op z'n aller heetst werden de CPU's 49 en 51 graden, en voor cpu's die max 90 mogen worden, is dat zeer redelijk

Die 90 graden is afaik de core temp, terwijl sensoren op het moederbord doorgaans de tempereatuur van de buitenkant van de die meten. Op het moment dat die sensoren 90 graden aangeven is de core een stuk heter
Afaik zit daar een graad of 20 verschil tussen; de sensoren "mogen" dus iets van 70 graden aangeven.

Maar voor ik d.net ga bestoken met emails en het forum daar vol ga posten met mijn beschuldigingen jegens de client en hun onkunde ( )

Mja... Al is het een fout in de client dan nog mag zoiets je machine niet op zijn bek helpen. Wat een programma (dat als user draait) ook doet, het mag niet tot een crash leiden.
Omdat dnetc iets redelijk eenvoudigs is dat geen enge dingen (zoals frambuffer zut, DRI, directe device access, etc) doet verdenk ik toch eigenlijk als eerste de hardware...

Voor windows () zijn er bijvoorbeeld BurnK7 of Prime95 om die taken over te nemen, maar voor Linux weet(ken) ik er geen, heb gezocht op Google -en ook op GoT- maar uit de zoek resultaten word ik niet wijs of er wel zo'n programma bestaat

Voortaan ook zoeken op packages.debian.org dan

Overigens zit die package niet in stable, maar je kunt gewoon de .deb uit unstable downloaden en installeren.
Ook doet hij niks met meerdere CPU's, maar de oplossing daarvoor is eenvoudig: twee instances van het programma draaien

[Verwijderd]

sander@Debian:~$ apt-cache search cpuburn
cpuburn - a collection of programs to put heavy load on CPU

zit in unstable, have fun

[[NUT]]

deadinspace schreef op 04 March 2003 @ 05:26:
Niet om vervelend te doen, maar heb je die melding misschien opgeschreven? De exacte melding kan heel interessant zijn voor het vaststellen van de oorzaak.

Eh... nee, omdat ik hoopte dat dat in de kernellogs zou staan... en daarna ben ik het niet meer tegen gekomen omdat de screensaver het scherm zwart had gemaakt...

Die 90 graden is afaik de core temp, terwijl sensoren op het moederbord doorgaans de tempereatuur van de buitenkant van de die meten. Op het moment dat die sensoren 90 graden aangeven is de core een stuk heter
Afaik zit daar een graad of 20 verschil tussen; de sensoren "mogen" dus iets van 70 graden aangeven.

In het geval van MP's en een Tyan mamma plankje gaat het hier om de interne diode temps... ik meen zelfs dat er geen temp sensor onder de cpu's op het mobo zitten... maar dat weet ik niet zeker meer (iemand?)

Mja... Al is het een fout in de client dan nog mag zoiets je machine niet op zijn bek helpen. Wat een programma (dat als user draait) ook doet, het mag niet tot een crash leiden.
Omdat dnetc iets redelijk eenvoudigs is dat geen enge dingen (zoals frambuffer zut, DRI, directe device access, etc) doet verdenk ik toch eigenlijk als eerste de hardware...

En toch verdenk ik dnetc ervan... mede door de foutmelding die ik heb gezien, en door dat de client een bepaalde tijd terug heel rare load gaf (varierend) en toen ik de client herstartte was alles back to normal...

Voortaan ook zoeken op packages.debian.org dan

Overigens zit die package niet in stable, maar je kunt gewoon de .deb uit unstable downloaden en installeren.
Ook doet hij niks met meerdere CPU's, maar de oplossing daarvoor is eenvoudig: twee instances van het programma draaien

Done... draait nu en we zullen zien wat er gebeurt...

Ok, Terwijl ik dit zit te schrijven pleurt burnK7 de server dus plat...

Dus het ligt niet aan dnetc... en ook hierbij geen meldingen op het scherm zichtbaar...

maar waaraan kan het dan liggen

Heb me al het apezuur gezocht weken terug, waarmee ik die screensaver uit kan zetten, maar ik kan niets vinden of ik zoek gewoon verkeert. iemand een suggestie?

[ Voor 7% gewijzigd door [NUT] op 04-03-2003 12:21 ]

[moto-moi]

[NUT] schreef op 04 March 2003 @ 12:14:
Heb me al het apezuur gezocht weken terug, waarmee ik die screensaver uit kan zetten, maar ik kan niets vinden of ik zoek gewoon verkeert. iemand een suggestie?

Kom op, in de topiclijst op dit moment staat dit topic : [rml][ RH7.2] -> Monitor NIET op standby, hoe?[/rml]

[[NUT]]

moto-moi schreef op 04 maart 2003 @ 13:22:
[...]

Kom op, in de topiclijst op dit moment staat dit topic : [rml][ RH7.2] -> Monitor NIET op standby, hoe?[/rml]

Lol, niet op het forum dus, maar op mijn server

ok, check ik dat topic ff

[edit]
Ok, daar ga ik weer, burnK7 test 2

[ Voor 8% gewijzigd door [NUT] op 04-03-2003 15:03 ]

[[NUT]]

Ok... weer een crash en geen melding te zien

Dan maar weer dnetc draaien en kijken wat die doet/zegt...

als iemand een idee heeft waar dit aan kan liggen, zeg het dan!

Even voor alle duidelijkheid... met Windows 2000Prof had ik deze problemen niet... toen ook getest met cpuburn trouwens... dus het is iets met linux/kernel iets denk ik

[edit]
Nu heb ik helaas ook geen melding met dnetc jammer genoeg....

[ Voor 10% gewijzigd door [NUT] op 04-03-2003 17:55 ]

[TumbleCow]

Ik zou idd eens een nieuwe kernel proberen (of een stable kernel, als je nu unstable draait)
Het mag zowiezo nooit voorkomen dat een userspace-programma (zoals dnetc) uberhaubt de rechten heeft om het hele systeem plat te leggen. Als je zeker weet dat het niet je hardware is, dan lijkt het me dus zowiezo een kernel-probleem.

Nu moet gezegd worden dat SMP vaak voor iets vreemdere problemen en lock-ups kan zorgen. Zorg iig dat je de Linux-smp-howto leest. Hier staat onder andere in dat je op SMP machines iig ook RealTime Clock support en MTRR aan moet zetten voor goede stabiliteit, en dat je APM (advanced power management) juist UIT moet zetten om crashes te voorkomen.

[[NUT]]

wHiTeRaZoR schreef op 04 March 2003 @ 17:02:
Ik zou idd eens een nieuwe kernel proberen (of een stable kernel, als je nu unstable draait)
Het mag zowiezo nooit voorkomen dat een userspace-programma (zoals dnetc) uberhaubt de rechten heeft om het hele systeem plat te leggen. Als je zeker weet dat het niet je hardware is, dan lijkt het me dus zowiezo een kernel-probleem.

Nu moet gezegd worden dat SMP vaak voor iets vreemdere problemen en lock-ups kan zorgen. Zorg iig dat je de Linux-smp-howto leest. Hier staat onder andere in dat je op SMP machines iig ook RealTime Clock support en MTRR aan moet zetten voor goede stabiliteit, en dat je APM (advanced power management) juist UIT moet zetten om crashes te voorkomen.

Ik meen dat ik alles heb gedaan om een stabiele SMP kernel te bouwen, maar ik zal deze howto eens door spitten, want deze kende ik niet...

het gaat hier om een Production kernel, 2.4.20 zonder patches...

dank voor de link, hoop dat het wat gaat opleveren!

[[NUT]]

Helaas ook in die howto staat niets vreemds...

Voor de techies of mensen die vaker met kernels hebben zitten frutsellen heb ik mijn .config van de huidige kernel even online gezet -> Klik <-

[TumbleCow]

Het enigste dat me 'opvalt' is dat je de rtc (als ik het goed bekijk) als module compiled. Vervolgens weet ik niet of je die module ook laad, misschien dat het helpt om de module te laden en/of vast te compilen ipv als module?

verder moet ik ook eerlijk zeggen dat ik geen idee heb of het iets met je probleem te maken heeft, maar smp en rtc worden nog wel eens samen genoemd.

[[NUT]]

# modinfo rtc
filename: /lib/modules/2.4.20/kernel/drivers/char/rtc.o
description: <none>
author: "Paul Gortmaker"
license: "GPL"

Net even gecontroleerd, en die word idd gewoon geladen... waarom als mod? denk door de texten die er bij stonden, heb alles 1 voor 1 in menuconfig gelezen en bepaald of ik het nodig had, tevens heb ik bij een aantal dingen gedaan wat ze me aanraden... de kernel compilatie is al weer een tijd geleden, dus waarom weet ik zo snel even niet, maar het heeft vast een reden

Whiterazor, tot zover bedankt anyway

* [NUT] duikt de menuconfig weer even in... check check double check

[edit]
Ok, in de .config staat CONFIG_PM=y en dat is het 'normale' power management... zou dat de zelfde invloed hebben als APM? dan is dat het misschien wel...

[ Voor 32% gewijzigd door [NUT] op 04-03-2003 19:43 . Reden: toevoegingen ]

[TumbleCow]

hmm.. op z'n minst worth a try.

edit: Ik draai zelf een dual celeron 366 waarvan ik wel een 2.4.20 kernel config kan posten als je daar iets aan hebt.

[ Voor 67% gewijzigd door TumbleCow op 05-03-2003 12:07 ]

[[NUT]]

wHiTeRaZoR schreef op 05 March 2003 @ 11:44:
hmm.. op z'n minst worth a try.

edit: Ik draai zelf een dual celeron 366 waarvan ik wel een 2.4.20 kernel config kan posten als je daar iets aan hebt.

Ik heb gisteren een nieuwe kernel gebouwt, met een aantal aanpassingen, veelal modules veranderd naar core-components, en het een en ander verwijderd (o.a. power management en intel chipset support) wat ik toch niet nodig had... tevens een nieuwe bios en een aantal gewijzigde bios instellingen. helaas bieden die aanpassingen ook de oplossing niet

heb jij bij toeval een dnetc of cpuburn pakketje om te kijken hoe die het doen op jou kernel? cpuburn is bij mij de gene die mijn machine binnen 30min plat krijgt. Ik vroeg me af of jij het ook eens kon proberen...

[TumbleCow]

./dnetc heeft op mijn bak voorheen eigenlijk altijd op gedraaid, en dan meestal een dag of 60 aan een stuk voordat er iemand over een kabeltje heen struikelde, aan het verkeerde knopje zat, water in een stopcontact kiepte enz..
Inmiddels is die bak bezig met taken waarvan ik liever heb dat hij niet vastloopt, dus ik probeer liever geen cpuburn. Maar dnetc heeft er zeker een jaar zonder problemen op gedraaid onder linux.

misschien dat je eens een oude 2.2 kernel kan proberen oid? Als dat werkt heb je iig een goede reden om op de linux kernel mailinglist oid te gaan posten over problemen met je kernel. Ik verwacht ook niet dat het een generic linux smp probleem is, want dan hadden ongetwijfeld al meer mensen het opgemerkt.

Op google zie je een hoop problemen staan met tyan tigers. Een aantal oplossingen gaan over betere voedingen, en ander geheugen, tot het resetten van de bios wat opeens alle problemen fixed.

Het blijft een vaag probleem, misschien dat het een goed idee is om eerst eens een dagje memtest te runnen om *zeker* te weten dat het geen hardwareprobleem is.

[ Voor 7% gewijzigd door TumbleCow op 05-03-2003 15:40 ]

[[NUT]]

wHiTeRaZoR schreef op 05 March 2003 @ 15:38:
./dnetc heeft op mijn bak voorheen eigenlijk altijd op gedraaid, en dan meestal een dag of 60 aan een stuk voordat er iemand over een kabeltje heen struikelde, aan het verkeerde knopje zat, water in een stopcontact kiepte enz..
Inmiddels is die bak bezig met taken waarvan ik liever heb dat hij niet vastloopt, dus ik probeer liever geen cpuburn. Maar dnetc heeft er zeker een jaar zonder problemen op gedraaid onder linux.

ok, no probs

knippperdeknip

Ok... nu wil hij het wel... ik heb de fans in de server aangepast, en kabels verlegt, omdat door tussentijdse werkzaamheden hij wat rommelig was geworden, en daarbij ook de fan-controlls er af gehaald... nu maakt hij meer lawaai (voor zover 2 YS-tech fans lawaai maken), maar tot nu toe wel stabiel...

* [NUT] houd vingers gekruist de aankomende uren...

Toch maar eens een kernel bouwen met i2c+lm_sensors ... kan ik de temps eindelijk eens zien in linux............

[deadinspace]

[NUT] schreef op 05 maart 2003 @ 14:57:
cpuburn is bij mij de gene die mijn machine binnen 30min plat krijgt.

Ik verdenk dan toch de hardware. dnetc rekent veel en belast dus je CPU, en dat gaat blijkbaar af en toe fout. cpuburn is gemaakt om je CPU zo zwaar mogelijk te belasten, en dat gaat blijkbaar ook sneller fout.

Merk bovendien op dat beide programma's alleen maar rekenen, en meer niet. Nauwelijks tot geen systemcalls, geen directe hardware toegang of whatever. Dan nog zou het aan de kernel kunnen liggen ivm race condities oid, maar dan zou je dat hoogstwaarschijnlijk ook met minder zware belasting merken (en je zou niet de enige moeten zijn).

Je zou eventueel SMP issues nog kunnen proberen uit te sluiten door een uniproc kernel te compilen en booten, en daarmee te testen.

[NUT] schreef op 05 maart 2003 @ 17:45:
Toch maar eens een kernel bouwen met i2c+lm_sensors ... kan ik de temps eindelijk eens zien in linux............

Als hij crashed, dan kun je hem resetten en snel in de BIOS kijken wat de temperaturen zijn. Dat is niet 100% betrouwbaar, maar beter dan niets

[[NUT]]

nut@earth:~$ uptime
19:03:40 up 2:36, 7 users, load average: 2.00, 1.99, 1.91

Gaat de goede kant op

[edit]
Oh, dit is trouwens met een uur(!) burnK7 en nu dnetc....

[ Voor 22% gewijzigd door [NUT] op 05-03-2003 19:08 ]

[Heidistein]

Mischien heb je dit al gedaan, maar je weet maar nooit
memtest86... Maar mischien zeg ik wel iets doms, want de meesten krijgen wel dingetjes in beeld dan...

[[NUT]]

Heidistein schreef op 05 March 2003 @ 19:45:
Mischien heb je dit al gedaan, maar je weet maar nooit
memtest86... Maar mischien zeg ik wel iets doms, want de meesten krijgen wel dingetjes in beeld dan...

Die heb ik idd nog niet gedaan, maar juist omdat dat voor bijna iedereen wel iets oplevert... dus probeer ik het eerst even zo...

[GeeMoney]

Ik zou ook eerst denken aan het geheugen, al gebruikt dnetc en cpuburn volgens mij toch bijna geen geheugen alleen maar CPU gebruik.
Toch lijken de spontane vastlopers op of overhitting problemen, geheugen problemen, kernel maar aangezien de temps goed zijn en de kernel al een keer gere-compiled is is dit denk ik toch neit het probleem.
Ik zou het gokken op het geheugen

[deadinspace]

Als je met memtest86 gaat testen, dan is het misschien ook interessant om een ronde te testen met de fans op de oude manier, en een ronde met de fans op de nieuwe manier. Mocht het de temperatuur van de CPU's zijn, dan zal dit waarschijnlijk ook in memtest86 naar voren komen, omdat memtest86 natuurlijk wel van de CPU(s) gebruik maakt om het geheugen te testen.

[[NUT]]

16:14:18 up 23:47, 7 users, load average: 3.68, 3.22, 2.96

nog net geen 24h... maar hij draait nogsteeds

ik zal eens kijken of ik die memtest86 kan opduikelen... dat 86 ... is dat een versie? of hangt dat samen met XFree86? want X heb ik hier niet geinstalleerd...

[edit]
Nee dus (net package sysutils geinstalleerd, daar zit 'memtest' in) maar aangezien deze machine een router/webserver/firewall is kan ik 'em niet zomaar een lange tijd offline pleuren.... dus memtest86 valt om die reden al af...

[ Voor 31% gewijzigd door [NUT] op 06-03-2003 16:31 ]

[[NUT]]

code:

memtest all 1000 --log

Run 10 completed in 908 seconds (0 tests showed errors).

niets tot zover... Mijn server beschikt over ECC mem, met ECC ingeschakeld, dus ik denk ook niet dat de overige 990passes iets zullen opleveren, maar ik laat 'em voorlopig gewoon even draaien...

[[NUT]]

[NUT] schreef op 06 March 2003 @ 19:26:

code:

memtest all 1000 --log

[...]


niets tot zover... Mijn server beschikt over ECC mem, met ECC ingeschakeld, dus ik denk ook niet dat de overige 990passes iets zullen opleveren, maar ik laat 'em voorlopig gewoon even draaien...

ook na zo'n 120 tests niets gevonden... dus het mem is het niet...

ik ben bang dat de koel pasta is uitgedroogt, of omdat de koelers redelijk los(ze schuiven makkelijk, maar ik kan ze niet optillen) op de CPU's zitten die geen goede aansluiting (meer) hebben...

[deadinspace]

Goede koelpasta zou niet moeten uitdrogen, maar echt los horen koelblokken niet te zitten

Maar is je server nog op zijn bek gegaan door dnetc of cpuburn na de veranderingen aan je fans?

[[NUT]]

deadinspace schreef op 08 maart 2003 @ 00:40:
Goede koelpasta zou niet moeten uitdrogen, maar echt los horen koelblokken niet te zitten

Maar is je server nog op zijn ben gegaan door dnetc of cpuburn na de veranderingen aan je fans?

De koelpasta gebruikt is Arctic Silver 2, los, mjah wat heet los, ik kan ze wat draaien en iets naar links en rechts bewegen op de socket... niet bizar ver ofzow...

nut@earth:~/tss2_rc2$ uptime
03:59:45 up 2 days, 11:32, 7 users, load average: 2.91, 2.87, 2.80

Nee dus

[TumbleCow]

ok, iig erg fijn dat je weet hoe je de symptonen kan verhelpen.

bij koeling kan het nogsteeds zo'n beetje alle hardware zijn, maar ik zou eigenlijk toch gokken op een net iets te heette processor.

[[NUT]]

wHiTeRaZoR schreef op 08 March 2003 @ 21:41:
ok, iig erg fijn dat je weet hoe je de symptonen kan verhelpen.

bij koeling kan het nogsteeds zo'n beetje alle hardware zijn, maar ik zou eigenlijk toch gokken op een net iets te heette processor.

ben blij dat het iig weer stabiel loopt, dat zeker... en eerlijk gezegt denk ik ook dat m'n proc's te heet werden, of iig 1 er van... nu is het hoe dan ook even afwachten tot ik een 2.4.20 tree heb gepatched met de 2.7.0.0 versie van i2c voor ik lm_sensors kan gaan gebruiken, echter zit ik ook met het probleem dat ik mijn gf2mx drivers niet aan de praat krijg, en dus nu wacht tot ik die in die zelfde linux tree kan patchen...

X 4.2.x wil niet draaien met de nv driver die er bij zit, omdat hij 'no screens found' geeft... maar dat is een heel ander probleem...