🚀 go-pugleaf

"Roberto Nibali" <ratz@tac.ch> schrieb im Newsbeitrag
news:9302bf68.0108071345.14a05816@posting.google.com...
> Hoi Christian,
>
> > gestern ist mir mein rechner abgeschmiert, einfach so. ich konnte noch nicht
> > mal
> > die festplatten syncen, da der usb treiber fuer mein keyboard auch weg war.
>
> Wie weiss Du, dass der USB Treiber weg war, wenn der Rechner
> abgeschmiert ist? Ging nicht mal mehr das SysRQ+[SUB] combo?
> Vielleicht verstehe ich Dich auch falsch.

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..)

> > naja, halb so schlimm, ich habe das mal auf die hitze geschoben und da ist
> > vielleicht irgendwas zu heiss geworden. jedoch wuerde ich schon gerne
> > wissen, ob
> > es das wirklich war.
>
> 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.
deswegen dachte ich ja an ksymoops, weil das etwas "standardisierter" an die
sache herangehen koennte.

> 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,...

> > das sieht ziemlich wichtig aus, nur leider habe ich keine ahnung was das
> > ist.
>
> Ich auch nicht, scheint eine Art Ort zu sein, wo Deine Distro evt.
> oops hinwift.

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.
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:

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]

> > hat von Euch jemand damit erfahrung, oder kann mir jemand gute docu
> > empfehlen,
> > die auch non-hacker verstehen ?
>
> Ich habe schon Erfahrung mit kernel debugging, aber wie gesagt, ich
> brauche ein paar informationen mehr. Ich kann mir zum Beispiel
> vorstellen, dass Du den deadlock vom 2.4.6+ mit dem usb_core und den
> NIC interrupts eingefangen hast. Letzte Woche habe ich mit Greg-KH am
> OLS eine ziemlich herbe Debugging session gehabt und ich weiss nicht,
> ob AC die neuen USB Sachen schon gemerged hat. Es kann auch etwas
> total anderes sein ... Give me some more info, please.

ok, here we go:

kernel 2.4.7, ohne irgendwelche patches (vanilla?), mdoutils 2.4.6, das board
ist ein Hot-555A mainboard, schon etwas aelter ja (AT), mit Intel 82437VX,
82438VX und 82371SB chipsatz.
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
jetzt wollte ich eigentlich die module auflisten, die zu dem zeitpunkt geladen
waren, aber ich hab auch noch mal die logs durchgeschaut, und bin auf folegendes
gestossen:

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

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
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.

(20010805131826.modules)

iptable_mangle          2048   0 (autoclean) (unused)
iptable_filter          2080   0 (autoclean) (unused)
parport_pc             23408   1 (autoclean)
lp                      5232   0 (autoclean)
parport                25312   1 (autoclean) [parport_pc lp]
af_packet              11808   0 (autoclean)
nfsd                   66976   8 (autoclean)
lockd                  48944   1 (autoclean) [nfsd]
sunrpc                 60560   1 (autoclean) [nfsd lockd]
ipt_REDIRECT            1088   0 (autoclean)
ipt_MASQUERADE          1520   0 (autoclean)
iptable_nat            15248   0 (autoclean) [ipt_REDIRECT ipt_MASQUERADE]
ip_conntrack           14544   1 (autoclean) [ipt_REDIRECT ipt_MASQUERADE
iptable_nat]
ip_tables              10496   7 [iptable_mangle iptable_filter ipt_REDIRECT
ipt_MASQUERADE iptable_nat]
keybdev                 2048   0 (unused)
usbkbd                  3104   0 (unused)
input                   3264   0 [keybdev usbkbd]
usb-uhci               20496   0 (unused)
usbcore                50112   0 [usbkbd usb-uhci]
rtc                     5440   0 (autoclean)
serial                 42432   1 (autoclean)
es1371                 25680   0
ac97_codec              8448   0 [es1371]
soundcore               3792   4 [es1371]
hisax                 142064   3
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
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 :-)

Danke also,
Christian.