Számítógép hiba? Kernel hiba?

Ubuntu Linux

Tisztelet!

Néhány napja küzködök a következő problémákkal. Linux 2.6.38-8-generic kernel + ubuntu natty fut a gépen jelenleg - friss telepítés, okát későbbiekben kifejtem. Néhány órán keresztül hibátlanul fut minden kiszolgálói programmal együtt. (nginx, ftpd, smtp stb...) Ezután pedig megszakad a kapcsolat a géppel. (rendszerűen) Nincs kernel pánikra vonatkozó és log bejegyzés sem, nem reagál az usb/ps2 billentyűzetre, nem küld VGA jelet sem. A táp megy, a ventik forognak, a vinyók dolgoznak. HDD smart szerint a merevlemezek rendben vannak, hőfok adatok szerint a CPU és a chipset is rendben van.

adatok: asus p8h61 / core i5 2500k

előzmények:
http://ubuntu.hu/node/29371

Minden vélemény/ötlet jól jön, lehet már próbáltam de lehet nem.

köszi előre is:
wolfi

Én nem tudom, de szerintem egy memtest-et mindenképpen kéne futtatni, ha van rá lehetőség.
Főleg ha standard kernel, standard telepítés és semmi extra modul nincs betöltve.
Illetve ha állítod, hogy eddig ment és most nem jó. Veszteni nem veszthetsz vele.
Ha nem lehet sokáig leállítani és van feles memória modulod, akkor cseréld ki őket, rakd át másik gépből, amit le lehet állítani.
Memória hibát mindenképpen ki kellene zárni. Hátha.

Igen ezzel játszadoztam már. Maga a chipset elég gagyi, az a tulajdonsága intel részről, hogy ugyan 16GB-ig kezel, de elég finnyás. Csak olyan ram modulokkal tud 16GB-t lekezelni ahol nem két oldalon vannak a memória chipek. (ilyesmit olvastam, de ott a rev lista). Így aztán 8GB-val használjuk. Cserélgettem a foglalatokat is és a tartalék ramokat is már.

/off

The null reference was invented by C.A.R. Hoare in 1965 as part of the Algol W language. Hoare later (2009) described his invention as a "billion-dollar mistake":


I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

(http://en.wikipedia.org/wiki/Null_pointer#Null_pointer)

:D je

@szerk:
Fellépett éppen egy olyan érdekesség hogy nem tudok kapcsolódni a gépről máshoz. wget-tel le szerettem volna tölteni a gépre, és nem tudja feloldani a címet, google.hu-t sem tudom pingelni, apt-n a csomaglistát be tudja frissíteni az internetről, de a hu.archive.ubuntu.com tükörhöz már nem tud kapcsolódni. A gépet elérem SSH-n is természetesen...

valami mocskosul szét van verve a rendszerben, ha le is áll (alighanem null pointer dereference miatt), meg a névfeloldás sem működik tökéletesen. Ha jól tévedek, ez két olyan hiba, ami ég és föld. Saját szerverem lenne -> újrahúznám az egészet, nem vesződnék a hiba utáni nyomozással.

memtest!

memtest úton van, épp használják a konzolt.

A gépen pedig friss telepítés van, alig 9órás 11.04natty serv. :/ egy apt-get upgrade volt rá nyomva, a kernel frissítésen kívül mindent megcsinált. 2.6.38-13-ast ajánl fel a frissítő, nem telepítettem még.

@szerk: megkaptam a resit, nincs log bejegyzés (kernlog/syslog) egyszer csak "megállt".

nagyon sok idő rá fog menni, de az egyetlen épkézláb ötletem az, hogy fusson a régi kernellel duplaannyi időt, amennyi alatt a régi esetben már biztosan megállt volna. ekkor majdnem 100%, hogy bibis a kernel, oda meg kevés vagyok. vannak azonban itt olyan emberek, akik láttak ilyet közelről, és tudnak segíteni.

nem lehet egyébként, hogy maga az ubuntu szar? annyira nem tartják magukat a KISS principle-höz, hogy a szénné patchelt cuccaikban jó nagy, bonyolultságból eredő bugok lehetnek.

olvasgattam az uborka.hu-ra tett loggolást. ejha! szerintem már akkor gondok vannak a működéssel, mikor szerinted még minden megy. ha jól értem, még a régi kernellel is előfordult, hogy 'cannot handle kernel paging request', ami sosem jó ómen. aztán (ismétlem, ha jól értem), az új kernellel is sorozatosan jönnek a null pointer dereference hibák, KILL signalt kap az irq handler, a cron, és még ki tudja, mi. itt valami úgy el van tekerve, hogy öröm lesz megtalálni. jól gondolom, hogy ez egy kvm-mel virtualizált uborka?

( tbs v | 2012. 03. 09., p – 09:10 )

Szvsz vas. Az előző 250 napban hányszor lett újrabútolva..? Könnyen lehet, hogy egyszerű táphibával szívsz. (Figyelem! A "táp" egy része alaplapon lakik..!)

A gép működése közben véletlenszerű terhelést generál, ami a tápcsatornát is véletlenszerűen húzogatja. Random előforduló hibáknak, amik nem feltétlenül torkolnak értelmes logba nagyon sokszor táphiba az oka.

A rendszer változása miatt változott a terhelési séma. De az is lehet, hogy eddig piszok mázlid volt.

A helyedben kihoznám onnan a gépet, megtekerném memtest-tel félnapig, ha nem hullik el, akkor 99.73% hogy táphiba. Végy egy rendes tápot (85%+-os hatásfokút lehetőleg), és készülj egy alaplapcserére is lélekben. Ilyen bizonytalan gépet csavarhúzótávolságon kívülről "javítani" reménytelen.

(Lehet hogy egy szétszed/összerak ciklus is rendbe hozza. Láttam már ilyet. Minden ilyesformán betegeskedő gép javítását úgy kezdem, hogy istenesen megrázom az egész cuccot. Volt, ahol elég volt az is. Éljenek a mikrorepedések, az átvezetési ellenállások és a túlhúzott csavarok..! :DDD )

Aha, egy egyszerű tárolós már mutatja is a fölösleges lejtőket/emelkedőket. Mondjuk szkópárból komplett cseregépet is össze lehet rakni... :DDD Cserélgetni szoktam csak, baromira nem kifizetődő (időben főleg) konkrét hibát felkutatni ilyen cuccoknál. Tápot még csakcsak, de alaplapi generátorokat már egyáltalán nem szívesen javítgatnék...

Majdnem.
Első ránézésre meg lehet mondani vele, ha rossz a táp.
Azt viszont nem lehet megmondani, hogy jó-e.

Tudod, ideális esetben a tápegység egyenfeszültségeket állít elő. (És ugyancsak ideális esetben a gép memóriája végtelen.)
Gyakorlatilag a kisebb súly (anyagköltség, ár) érdekében ún. kapcsoló üzemű tápegységek dolgoznak a gépekben, amiknek a kimenő feszültsége soha nem egyen, mindig lüktet.
Ha gyenguska, akkor terhelés hatására sokkal jobban hullámzik.
A BIOS ezt a lüktetést nem tudja kimutatni, de persze egy kézi voltmérő sem.

Ha azzal rossz tápot látsz, az már régen rossz.
Biosban kb. semmit nem csinál a gép, ráadásul a hardverek jó része inicializálva sincsen, kisebb az áramfelvétel.
Terhelés alatt megnő az áramigény, gyenge/rossz táp nem tudja kiszolgálni, emiatt leeshet a feszültség olyan alacsony szintre, ami miatt a memória vagy a processzor hibázhat számítás közben, rossz paritás jön ki, az átviteli buszon torzulnak a jelek, stb...
--
Discover It - Have a lot of fun!

az nem az igazi :)

ez olyan, mintha egy diaknak azt mondanad, ertekelje a feleletet :)

merjel ra kulso eszkozzel. a bios diagnosztikai cuccok kb arra jok, hogy ha nem azt mutatja amit kell, akkor gond van. ha nem mutat semmi elterot, attol meg a problema ott lehet.
es ne csak a tapot merd onmagaban, terheles alatt is vizsgald meg

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

A táp jó. Fennt a szerver termes kollegák segítettek, szétszedtük, bemértük műszerrel is, valamint az ideiglenes gép is erről fut, 18órája hibátlanul. Mi jelenleg most a H61 chipsetre, és a nagyon rossz memória kezelésére gyanakszunk. Sok fórumon olvastam, hogy többszörösen foltozták a chipsetet, mivel rengeteg gond volt vele. Nekünk a rev 3-as kiadás van, de ezekszerint ez sem tökéletes. Ja memtest eredményét hamarosan írom!

:O igazából logikus a dolog, de még mindig nem fér a fejembe az a dolog, hogy idehaza (ráadásul!) egy olcsó kakinak vallott phenom x4 alapú gépet hajtok 4-5éve hibátlanul, napi 18órákat megy a gép mert kocka vagyok... ez a cucc pedig Augusztus óta van fennt, Inteles, legdrágább asus alaplappal, WD merevlemezekkel, smukk a kövön minden (természetesen az átlag júzer kategóriában, mivel pro ibm/hp szerver cuccokra nincs keret), és azt írjátok kábel hiba lenne...

Miért kakinak tartott egy Phenom X4? Abban másképp kapcsol a növekményes MOSFET, mint az Intelben?

Ez lehet akár az alaplapi kapcsolóüzemű táp zaja miatt is szerintem. Vagy zajos táp, RAM, HDD, kábel. Lényegében bármi, ami megzavarhatja a kommunikációt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem úgy értettem hogy egy az egyben kaki, mivel tökéletesen meg vagyok vele elégedve. Arra gondoltam, hogy minden reklám anyag, és fórum szaki azt szajkózza, hogy az intel megoldásai mennyivel stabilabbak és gyorsabbak, ergó lehet drágább de "megéri". Az egész egy vicc.

Nekem egy AMD Phenom II X4 955 CPU megy a gépemben. Stabil, sohasem fekszik meg. Bár, amióta napvilágra került, hogy bizonyos esetekben talán a POP és RET utasítások környékén(?) rosszul kezelik a stack pointert egyes CPU-k, azóta rettegve várom a CPU-k listáját az AMD-től. S közben reménykedem, mikrokód cserével javítható.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mitől javított? A TLB bugra gondolsz? Előtte nekem 9550-esem volt, de a 2.2 GHz lassúnak tűnt. Nyilván a 4 mag jó, ha olyan az alkalmazás, vagy az egyik process mellett valami más is futásidő-igényes, viszont, ha egy szálon fut valami, így egy magot használ ki, akkor néha kevésnek tűnik a 2.2 GHz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezek szerint nem ott a baj. Valami másba gabalyodik bele. Volt már olyan, hogy kitéptem az összes hajamat, mert gondom volt VIA chipseten DMA-val. Mértem, s azt láttam, ilyen nem történhet meg. Mit ad Isten, utánanéztem, erre a Linux kernel dokumentációban megtalálom, hogy az adott VIA chip bizonyos körülmények között hibásan működik, s leírták ugyanazt a jelenséget, amit magam is mértem. Kevés hajam van már... :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hagyd azt a vasat a francba. Építs újat. Alaplaptypusváltás + új memória mindenképp, a többi maradhat, ha úgy látod.

Kiskoromban BP6-okkal (2db) szopkodtam vagy ~fél évet a beteg HPT miatt mire kivágtam a francba az egészet. Ja, van két eladó BP6-om bontatlan like orig dobozban. Nem érdekel..? :D :D

2.6.32-vel is pusztulgat..?

BP6-nál én is úgy éreztem, hogy gamma-tesztelő vagyok. Egy ideig instabil volt a hpt366. De aztán jöttek BIOS frissítések és driver workaround-ok, aztán elég stabilan ment hosszú évekig. Két celeronnal. Akkor még élveztem a nyalókázást. Azóta felnőttem...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( wolfnet | 2012. 03. 15., cs – 09:55 )

Új alaplap és új tápegység beüzemelve. Garis srác szerint az alaplapi cpu foglalaton egy sornyi láb el volt ferdülve. (WTF?!). Egyetlen egyszer nyúltunk hozzá amikor beletettük, majd lefeszítettük előírás szerint. (Ha nem érintkezett volna a processzorral a foglalat gondolom el sem indult volna az egész igaz?)
Ja igen memtest eredményei amúgy (mert elfelejtettem leírni): 13órát futott, 100%pass, 4dimm - 16G.

b***. Komolyan mondjátok hogy érintkezési (kontaktos) probléma ilyet tud okozni?! Amúgy megint csak az AMD pártjára állok akkor, hiszen ha tegyük fel van annyi IQ-m hogy látom a jelzéseket és jól be tudom tenni a socket-be a cpu-t onnantól kezdve az benne van. Ahogy elméletileg ez is, de mégsem.

Igen, reméljük mi is nagyon. Második napnál tartunk hiba nélkül, valamilyen szinten ez már bíztató. :)

Magam is arra céloztam, hogy szerintem nem gondoltad végig a kérdésed. Például az AMD Phenom II X4 955 maximális disszipációja 125 W, ehhez 1.5 V tápfeszültség tartozik. Jó, nem a teljes disszipáció jön a core voltage-ból, így egy felső becslés lesz az áramra a 83 A. Ez ugye egy hatalmas áram. Gondolom, nyilvánvaló, hogy a CPU-nak nem egy GND és nem egy VDDcore lába kell legyen, mert azon, illetve a lábtól chip-hez hozzávezetésen cca. 80 A-t elvezetni képtelenség. Tehát nagyon sok GND és nagyon sok VDDcore lába kell legyen. Ha ezek közül néhány nem érintkezik, a többin megnő az áramsűrűség, a CPU GND-je megemelkedik a külvilághoz képest, a belső tápfeszültség csökken, a zaj nő, a statikus zajtartalék csökken, a CPU maximálisan kihasználható sebessége csökken, a stabilitás szintén csökken. Már feltéve, hogy nem megy tönkre a CPU.

Szóval erre utaltam. Tehát a hibás foglalat nem csak azt okozhatja, hogy egyáltalán nem működik a gép, mert egy fontos vezérlő láb, vagy a busz egyik lába nem érintkezik, hanem stabilitási gondokat is okozhat, ha ez a tápfeszültség, GND lábakkal történik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( wolfnet | 2012. 04. 09., h – 09:19 )

Hej! Most találkoztam a problémával, amelyre a fórumokban sincs konkrét egyértelmű válasz. Igazság szerint lassulást, hátráltatást (még) nem okozott, egyszerűen csak van és létezik. Először a migration/1 folyamat járt 99%-on, majd amikor szépen napról napra csökkenni kezdett, jött a migration/0, és most a migration/2 is. Olvasataim szerint a kernel idő egyeztetéssel van valami, de nem igazán értem. Össz load-ot nem befolyásolta eddig még, illetve csak webminben látható. Ötlet? :)

Jahogyja. Sztem ez egy ps output. Topban lehet, hogy nem ennyi a cpu usage... ;)

Ha nem fogja a gépet SEMMI, akkor a ps néha félrevezető infót ad az RT processzek cpu usage-jéről. Ha fogja valami, akkor meg kell nézni, hogy ki az a Béla, aki ennyit kontext-szviccsel, hogy megkergül a kernel scheduler...

Amúgy cat /proc/version és tsai..?

igen igen, htop/top sem ír rá semennyit. az összes fórumban így jelentkezik a dolog.
a kérésedre már is keresek választ :D

ui.: itt is

Linux version 3.0.0-16-generic-pae (buildd@zirconium) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #29-Ubuntu SMP Tue Feb 14 13:56:31 UTC 2012