#2674 (I mint I/O)

Hogy debugol az ember merevlemez-műveleteket? Valami baj van a rendszeremmel, és nem tudom mi az. A tünetek megvannak: a hibás valami tekeri a merevlemezt, mint az őrült, a transfer rate brutálisan lecsökken - nem mutatok grafikont, annyira borzasztó - a vas pedig közel használhatatlanná válik. Első körben a merevlemezre gyanakodtam, de az összes elérhető S.M.A.R.T. ellenőrző eszköz szerint rendben van. Néztem olyat, ami csak azt mutatja mennyire van jó karban (92%), olyat, ami lebontja S.M.A.R.T. összetevőkre, egyiken sincs gond.

Marad az, hogy szoftveres a probléma. Visszaálltam egy régebbi image-re, ami mágikusan - frissítések és fekete kakas vére - egy-két hét alatt megint el fogja magát cseszni, addig ki kéne találni, hogymivan.

#2672 (stabil sirály)

ubi

Meg kéne változtatni az Ubuntu rilízciklusát, erre jutottam, miközben néztem, ahogy valami ultralassú hostról csorgott le lassan a 9.04-es telepítő lemezképe. amivel majd helyreállítom a széthalt otthoni vasat. A mostani Bugos Béka vonal maradhatna, de lehetne később, mondjuk a ciklus felénél egy új kiadás - tehát X.01 és X.07 - a Stabil Sirály. Vagy valami ilyesmi.

És igen, persze nekem is lehetett volna annyi eszem, hogy várjak egy hónapot a frissítéssel.

#2618 (v mint vudu)

Az este programja az lesz, hogy kitaláljam 1, mi miatt tűnik el a Bluetooth modul, ha suspendbe teszem a gépet 2, melyik frissítéssel implementálták ezt a remek funkciót, mert régen működött. Ebédidőben kiugrok a vásárcsarnokba, mert állítólag a debughoz elengedhetetlenül fontos egy fekete kakas vére.

Debug

Az ‘ahogy azt Móricka elképzeli illetve megérti’ rovatból

Egyszercsak azon kaptam a gépemet, hogy a ha nincs csatlakoztatva töltőhöz, akkor a System folyamat 23-25 százalékot eszik meg a processzorból. Az első pánik után megcéloztam a Google-t a problémával. Három alap válaszfajtát találtam a System CPU zabálására:

  1. Az valójában a System Idle Process, teljesen normális, hogy sokat eszik. Ezt főleg ott írták, ahol a probléma megértésére se fordítottak elég gondot, csak osztják az észt.
  2. A Thinkpad fórumokon inkább a ‘mindjárt szét fog rohadni’ és az ‘enyém is ezt csinálta mielőtt kigyulladt’ - túlzok, bocsánat - jellegű pánik megy. A hardverhibával kapcsolatos gondolatokat el lehet hessegetni egy más verziójú, működő Windowst bootolva.
  3. Az ember végül eljut a SysInternalsra, ahol ott várja Mark Russinovich cikke arról, hogy az ilyen típusú hibákat okát hogyan kell kinyomozni: The Case of the System Process CPU Spikes. Aki hasonló hibától szenved, az kattintson is tovább oda, itt már csak a kalandok leírása következik.

A Russinovich cikk megtalálása után valójában már nem nehéz az ügy. Ha szerencsénk van, akkor a SysInternalsról letölthető Process Explorer beszerzése, a Debugging Tools telepítsése és a Symbol szerver beállítása után lesz ötletünk, hogy mi történik. Vagy legalább arról, hogy milyen threadekre kéne rákeresni.

Nekem az ExpWorkerThread és az ntkrnlpa.exe volt az, ami a CPU-t ette, ezzel a rendszer dolgaira és a driverekre szűkítettük le a problémát, illetve száguldva hagytuk el azt a területet, ahol még értem mi történik. Innentől jött a bicskás hályogkovács üzemmód annak biztos tudatában, hogy a külső winchesteren egy néhány hetes teljes backup ül, amit egy óra alatt vissza lehet állítani rendszerestül, mindenestül.

System process: valami nincs rendben

A Process Explorer által duplakattra kiírt stack infótól nem lettem okosabb, úgyhogy a javasolt Kernrate Viewerrel néztem rá a kernel threadekre. (A -wx kapcsolóval nem zárja be azonnal az ablakot a figyelés megállítása után.) Az első lelet itt is az ntkrnlpa.exe volt, utána viszont következtek olyan nagyfogysztók (igaz csak 8 százalékkal), amit be tudtam azonosítani: ő volt az integrált Intel grafikus mag drivere. Itt ugrott be, hogy valóban nem a Lenovo által megszentelt régebbi videodriver van fent, hanem egy újabb.

Közjáték: miközben nyomoztam, lejött a többi driver legújabb példánya és felkerült egy igazából semmi fontosat nem tartalmazó, de ártani nem árthat osztályú BIOS update is. Ezek valamelyike kikapcsolta az ujjlenyomat-olvasót, amitől egyik ámulatból a másikba estem, de végül egyszerűen vissza lehetett kapcsolni.

A géphez járó ThinkVantage driverfrissítő nem szeret feleslegesen letölteni, az összes szükséges driver megvan többnyire helyben. A Lenovo áldását nem bíró Intel driver lekerült, majd reboot. A visszatéréskor kapott kép nem szép, csuklóból nem a normál felbontásra állt be a gép, viszont akárhogy húzgálom ki a tápot a System folyamat nem kezdi el rágni az erőforrásokat. Ezután felkerült a legfrissebb gyári driver, reboot, és most minden oké.

A legszebb persze az, hogy ez csak az egyik olyan probléma, ami az ntkrnlpa.exe megnövekedett éhségét okozhatja. Más fórumokban a fizikai cím kiterjesztésének (PAE) letiltása segített, ami persze egy 2 gigabájt memóriával rendelkező gépnél több mint vudu lett volna. Megint máshol a Norton Internet Security akadt össze úgy a hálózati driverekkel, hogy ilyen problémát okozott.

Hozzávalók: