A kernel oops-ok követése

Kernel

Arjan van de Ven tavaly decemberben jelentette be a kerneloops.org projektet. A kerneloops.org weboldal összegyűjti egy helyre a különböző levlistákon, bugzillákban található, és a felhasználók rendszerein telepített kliens (kerneloops) által jelentett kernel oops és warning üzeneteket. Az adatokból statisztikát készít, amely megkönnyíti a kernelfejlesztők munkáját, hiszen azok pontosan láthatják, hogy a kernel melyik részén jelentkezik legtöbbször probléma és azt is, hogy mi okozza ezeket a problémákat.
Arjan szerint ezen a héten 3 670 oops és warning üzenetet jelentettek, összehasonlítva a múlt heti 3 029-cel. Várhatóan egyre több helyről érkezik majd adat, mert a kliens már nem csak a projekt weboldaláról tölthető le, hanem több Linux disztribútor is szállítja. A Fedora és a Debian az alapértelmezett telepítéskor telepíti is a klienset. Részletek a KernelTrap cikkében.

Az. Főleg, hogy kiderül, hogy az oops-ok és warningok jelentős részéért felelős dolgok:

- vmware kernel modul (zárt forrású, külső)
- proprietary firegl driver (out-of-tree)
- madwifi proprietary driver (külső)
- virtualbox out-of-tree részek
- out-of-tree nouveau driver

--
trey @ gépház

Ezek szerint rosszul értettem. Mindenesetre ha a bugok ~30%-val nem kell foglalkozni, az egy nagyon jó dolog. A 30% is nézőpont kérdése. Ha holnaptól azt mondják, hogy ugyanannyi pénzért holnaptól 30%-kal többet kell dolgoznod (8 helyett 10.4 órát kell lehúznod), valószínűleg te is azt fogod mondani, hogy jelentős.

--
trey @ gépház

Azért az elvérzők fele kb csak sz*rik bele, ami az N-edik (N>10) ilyen teszt után érthető is egy kicsit. Nem tudom, hogy mi alapján osztják be, de én pl még egyet se írtam, de tényleg ismerek olyat, aki több mint 10-et. Szóval jól hangzik, de max közelíti a valóságot, néha azt sem.

A kiinduló feltevés rossz: nem csinálsz kernelfrissítést, mert az adott 3rd party modul, ami a vmware szolgáltatás számára kritikus, adott verziójú kernelt támogat, azzal lett tesztelve. Az ESX-ben vajon miért olyan Linux kernel van, amilyen...? Egy kernelfrissítés után meg vagy lefordul, vagy sem, vagy fog működni rendesen, vagy nem -- é sez nem biztos, hogy a külső modul hibája.

Az meg pláne ebbe az irányba mutat, hogy a 2.6.24-release esetén a vmnet-bridge nem oops-ol, a 2.6.25 esetén meg igen... Höm-höm-höm...

( hege | 2008. 06. 04., sze – 13:09 )

örülök a kezdeményezésnek, a számok csak ritkán hazudnak :)

[fun]ezentúl a kernelt -funroll-oops -szal kell forgatni[/fun]

( pinyo_villany | 2008. 06. 04., sze – 13:35 )

amúgy a panic-oknál lenne ezt jó megoldani, csak azt nem olyan egyszerű nyomon követni...
kell hozzá egy másik gép, amire serial portot, fw-n, usb-n vagy etherrel csatlakozik és akkor vagy etherconsolellal vagy serialon kitolni a kernel logokat..

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

az nem dump
dump-bol sokkal tobb infot meg lehet tudni, vm hasznalatot, milyen processzek futottak, dmesg-et, meg azt is, hogy ki volt bejelentkezve a gepre a dump pillanataban.
de persze linuz szerint ez hulyeseg, tessek monitort fenykepezni, mert az a hi-tech

--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.

Nagyon egyszerű: ha nem képes tisztességes dumpot előállítani, akkor ne dumpoljon. HA képes, akkor miért ne tegye?

(Egyébként Windowson is meg tudták oldani, hogy STOP hiba esetén kiszenvedjen magából NTFS(!) fájlrendszerre egy 64k-s minidumpot, miért ne lennének képesek a linux kernel csákányolói erre?)

Nem csak 64k-s minidumpot, ha kell akkor kernel dumpot vagy akár egy teljes memória dumpot is lement, beállítás kérdése. Mondjuk az is igaz, hogy nem is mindig sikerül neki (nyilván attól függ, hogy mekkora gáz van a kernel memóriaterületével), de emiatt megborulni NTFS-t még nem láttam.