🚀 go-pugleaf

Hoi Christian,

> ja, genau das meinte ich. nicht mal SysRQ ging. und meine ebenso angeschlossene
> legacy-AT-tastatur ging ebenso nicht.
> (ja, zwei tastauren an einem rechener, frag nicht..)

Ok, deadlock.
 
> > Hmm, dazu muesstest Du mir schon ein wenig mehr Daten zu Deinem
> > kernel, modutils, board und CPU geben, benutzte fs und sonstige
> > Treiber, die geladen werden. Sonst wird das ein langes Raten.
> 
> hm, bin zwar fuer jede hilfe dankbar, doch kann ich mir kaum vorstellen, wie man
> damit mehr rauskriegen koennte.

:) Ich aber schon.

> deswegen dachte ich ja an ksymoops, weil das etwas "standardisierter" an die
> sache herangehen koennte.

Wenn kein oops passiert, dann nutzt Dir das nichts und ksymoops hilft auch
nicht weiter ohne, dass man die Systemdaten nicht kennt. Du muesstest den
kgdb installieren und dann einen debugger thread starten, damit Du "standar-
tisiert" rangehen kannst.
 
> > Wenn Du einen kernel deadlock hast, dann gibt es keine Moeglichkeit
> > (ausser mit UML oder kdbg) oops informationen zu erhalten.
> 
> UML, Unified Modeling Language? hm,...

Sorry, user-mode-linux meinte ich. [-> http://user-mode-linux.sf.net]
 
> ich habe hier eine Debin 2.2r2. das verzeichnis ist voll von dateien der art:
> "datum-uhrzeit.sec.ksyms" und "datum-uhrzeit.sec.mdodules" und zwischendrin ein
> paar "datum.log" files.

Oh, natuerlich, die symbol tables der verschiedenen device und objekte. Hilft
Dir gar nichts in Deinem Problem :)

> die *.mdoules datein enthalten die geladenen module, so wie es "lsmod" ausgeben
> wuerde. hier mal ein ausschnitt aus einer *.ksyms, weil's wieder so wichtig
> ausschaut:

Gib mir besser die Sachen, wonach ich frage, weil der output untern auto-
matisch von ksymoops generiert wird, falls sich ein Bug in diesem code
fragment befindet.
 
> c8ecf000
> __insmod_keybdev_O/lib/modules/2.4.7/kernel/drivers/input/keybdev.o_M3B5E09A3_V1
> 32103  [keybdev]
> c8ecf1a0 keybdev_event  [keybdev]
> c8ecf140 keybdev_ledfunc        [keybdev]
> c8ecf4a0 __insmod_keybdev_S.data_L576   [keybdev]
> c8ecf2c0 __insmod_keybdev_S.rodata_L480 [keybdev]
> c8ecf060 __insmod_keybdev_S.text_L608   [keybdev]
> c8ecd6e0 __insmod_usbkbd_S.rodata_L704  [usbkbd]
> c8ecd060 __insmod_usbkbd_S.text_L1648   [usbkbd]

Nuetzt nichts.
 
> kernel 2.4.7, ohne irgendwelche patches (vanilla?), mdoutils 2.4.6, das board

Jep, vanilla.

> ist ein Hot-555A mainboard, schon etwas aelter ja (AT), mit Intel 82437VX,
> 82438VX und 82371SB chipsatz.

Gut.

> da sind 128MB EDO Ram drauf, ein K6-2 prozessor (233mhz, nicht uebertaktet), und
> am onboard ide controller 3 IDE festplatten, 1 cdrom. kein scsi. als filesystem
> kommt vorwiedgend ReiserFS zum einsatz, (ausser fuer /boot und /root).so, und

Aha. Reiserfs! Wie lange war Dein Rechner schon am Laufen und was hast Du
zum Zeitpunkt vor dem deadlock gemacht? Wie oft ist es schon aufgetreten?

> Aug  5 13:09:05 sheep init: Switching to runlevel: 3
> Aug  5 13:09:05 sheep /usr/sbin/gpm[11296]: oops() invoked from gpn.c(239)
> Aug  5 13:09:05 sheep /usr/sbin/gpm[11296]: /var/run/gpm.pid: No such file or
> directory
> Aug  5 13:09:18 sheep init: Switching to runlevel: 2

Was hast Du danach gemacht?
 
> Aug  5 13:18:24 sheep init: Switching to runlevel: 6
> Aug  5 13:18:27 sheep /usr/sbin/gpm[13720]: oops() invoked from gpn.c(239)
> Aug  5 13:18:27 sheep /usr/sbin/gpm[13720]: /var/run/gpm.pid: No such file or
> directory
> Aug  5 13:18:28 sheep nmbd[8401]: [2001/08/05 13:18:28, 0]
> nmbd/nmbd.c:sig_term(65)
> Aug  5 13:18:28 sheep nmbd[8401]:   Got SIGTERM: going down...
> Aug  5 13:18:30 sheep snmptrapd[266]: Stopping snmptrapd
> Aug  5 13:18:31 sheep ucd-snmp[264]: Received TERM or STOP signal...  shutting
> down...
> Aug  5 13:18:31 sheep xinetd[281]: Exiting...
> Aug  5 13:18:50 sheep isdnlog: Aug 05 13:18:50 tei 71 calling T-Online with +49
> xxxx/xxxxxx, xxxxxxxxx  713.CI 20.677 DM (after 11:52:00)
> Aug  5 13:20:31 sheep kernel: SysRq: SAK
> Aug  5 13:20:53 sheep kernel: SysRq: SAK

Das muesste die AT Tastatur sein. Kein Wunder konntest Du Dich nicht mehr
einloggen. Hast Alt+SysRq+K gedrueckt und all Prozesse gekillt. Nur noch
(UID==0 && CAP_SYS_ADMIN) kann sich einloggen. Jetzt ist auch klar, warum
der gpm bockt. Lies am besten /usr/src/linux/Documentation/SAK.txt.

> Aug  5 13:21:05 sheep squid[304]: Preparing for shutdown after 9495 requests
> 
> das war so: ich konnte mich nicht mehr mit normalem user-account anmelden, da
> die meldung erschien "System Startup in Progress - please wait". nur root durfte
> sich noch anmelden. hab dann versuch das mit einem wechsel in ein anderes
> runlevel (3 und dann wieder in 2) zu beheben, klappte aber nicht. /etc/nologin
> war angelegt worden. naja, hier trotzdem mal die module, die geladen waren:
> und wie es scheint hat SysRQ ddch was bewirkt, aber ich hatte keine ausgabe auf
> dem bildschirm. squid hat dann sich noch beendet, die platten wurden aber nich
> gesynct, reiserfs musste da ein paar transactions wiedereinspielen.

Du musst manchmal Alt+SysRq+s lange gedrueckt halten, bis es funktioniert, da
der scheduler in einem oops Fall oder SAK nicht immer fair task switching er-
laubt.

> parport                25312   1 (autoclean) [parport_pc lp]
> af_packet              11808   0 (autoclean)

Fuer was brauchst Du das? Hast Du ein Kabelmodem oder ADSL?

> isdn                   94384   4 [hisax]
> slhc                    4768   1 [isdn]
> 3c59x                  24608   1
> 
> Also, nicht dass Du mich falsch verstehst: das kommt echt nicht oft vor, dass
> der rechner einfach so stehenbleibt. also eigentlich nie, ich hab das mal immer
> als waermeproblem abgetan, ist vieleicht auch manchmal bissl heiss da drin,
> naja, die gehaeuseabdeckung hab ich jetzt wieder abgenommen. ich dachte nur, man
> koennte da auch als normal sterblicher zumindest grob herauskriegen, was denn da
> zuerst den geist aufgegeben hat. (war es hier in dem fall  "gpm" ?) aber wie es

Ja und Nein, der gpm hat sich aufgehaengt, weil dies SAK policy ist, was nun
wirklich Dein Problem ist, kann ich ehrlich gesagt auch nicht sagen, muesste
mehr lockups haben.

> ausschaut, ist der aufwand doch etwas groesser. also: will ich hier mal nicht
> unnoetig geistige resourcen in anspruch nehmen, der rechner lebt ja noch. die
> informationen die man fuer eine diganose wohl braucht, habe ich aber trotzdem
> man zusammengestellt, wenn Du dir echt die zeit dafuer nehmen willst, bin ich
> Dir natuerlich dankbar :-)

Sag mir einfach, wenn es nochmals auftritt, was Du gerade zuvor gemacht hast
und die uptime.

Cheers,
Roberto Nibali, ratz

-- 
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`