Rögzítette a százezredik oops-ot a kerneloops.org

Kernel

Az Intel alkalmazásában álló Arjan van de Ven nemrég jelezte, hogy az általa életrehívott kerneloops.org első születésnapja közeledtével rögzítette adatbázisába a százezredik oops-ot. A fejlesztő azzal a céllal hívta életre tavaly decemberben a projektet, hogy "egy helyre gyűjtse össze az egyes kernelverziókkal kapcsolatos oops üzeneteket és warning report-okat, amelyek jelenleg elszórva találhatók különböző levelezési listákon és bugzillákban". A weboldal már több alkalommal bizonyította, hogy hasznos információkkal képes ellátni a kernelfejlesztőket. Az első születésnap alkalmából Arjan egy gyors statisztikát adott közre a projektről.

( trey | 2008. 11. 19., sze – 13:24 )

A minőségi madwifi.

--
trey @ gépház

A telepítés után volt (még mindig van) pár problémám. Ezeket beírtam a google-be, majd kijött egy rakás Ubuntu hibajegy, amelyekben -némelyiknél 2005 óta- ott rágódnak szerencsétlen userek, hogy mikor lesz már megoldva.

A cégnél a támogatott platform a Windows, a két szép szememért valószínűleg nem fognak csak azért mérnököt hívatni a távoli Afrikából, hogy kiderítse, miért rohad meg a notebookomon ez az echte autentik oroszlántrágya két-öt naponként.

Fórumozni/bugreportolni a fentiek után nem sok kedvem van, meg aztán nem tudom, hogy abból az információból, amely jelenleg rendelkezésemre áll (=0, csak úgy minden nélkül csonttá fagy a gép, grafikus felület beáll, pingelni nem lehet) mit is tudnának (ha egyáltalán akarnának) kibogozni.

Kb. két héttel ezelőttig valóban ez volt a helyzet, de mint írtam, nem érkezett meg az ígért RAM, így hirtelen jött felindulásból letöröltem, és felraktam az ubuntut.

FreeBSD-t leginkább azért nem, mert kell azért a windowsos környezet is (céges standard), a virtualizációs szoftverekben pedig sajnos nem épp bajnok. :-O

Azt nem tudom, hogy ezen a gépen suspendelni tudnék-e vele, az az egyik legalapvetőbb elvárás. :)

(ha a suspend és pld. a virtualbox menne, már dobnám is ki a Linuxot)

És vajon kernel miatt fagy?

Első lépésként kipróbálhatnál mást Ubuntu helyett, hátha az a gáz.
Másodikként hardver csere.

Nekem is szokott fagyni a gép. Viszont a syslogban meg is találtam, hogy miért. Szar a dvd meghajtó a laptopban, és ha a hal folyton baszogatja, akkor egy idő után amikor nem válaszol a buszon, akkor van 100% kernel.

Oops nincs, mert nem történik kernel hiba, csak terhelés van.

A megoldás az lett, hogy vagy kiveszem a drive-ot boot elött, vagy bejelentkezés után leállítom a hal-t.

Na. Csak azt akarom mondani, hogy a fagyás sokmindentől lehet, nem biztos, hogy kernel.

G

( MGy v | 2008. 11. 19., sze – 15:54 )

Engem a parport meglepett. Nem hittem volna, hogy ennyire bonyolult lenne - talán azért, mert ennek a hardware-nek azt hiszem, hogy értem a működését.

( Botond | 2008. 11. 20., cs – 23:38 )

Kíváncsi lennék, hogy a cifs modul hogy szerepel. Az automount + cifs duó elég régóta borzolja a kedélyeket.

Sokkal gyorsabb. Nálunk itt simán megy a 60 MB/s, lényegében a vinyó sebessége korlátoz csak. Ez a sebesség Windows-on sci-fi kategória.
De nem erről van szó. Próbálj autofs szabályt létrehozni egy cifs share-re, menj bele az adott könyvtárba (erre az autofs fölmountolja az adott share-t), majd a másik oldalon levő szervert indítsd újra! Mikor a másik gépen a Samba, vagy a Windows megosztás helyreáll, a helyi gép kifagy. Elég könnyen reprodukálható, allátólag 2.6.18 környékén javított hiba, de azóta is rendszeresen előjön. Sokan panaszkodnak rá az interneten, ezért lettem volna kíváncsi a cifs modul helyezésére.