here is a 2.1.90 oops:
Unable to handle kernel paging request at virtual address 60411008
current->tss.cr3 = 00101000, Xr3 = 00101000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[close_fp+36/136]
EFLAGS: 00010202
eax: 60411000 ebx: 00000003 ecx: 700722f4 edx: 72321f20
esi: 72321f20 edi: 70896260 ebp: 708962f0 esp: 70d0def0
ds: 0018 es: 0018 ss: 0018
Process kvt (pid: 2964, process nr: 64, stackpage=70d0d000)
Stack: 00000003 000003ff 70896260 70116a54 72321f20 70896260 0000000b 70d0c000
0000000b 70d0dfc4 00000001 701098d1 0000000b 70d0c000 6ffffaec 080895d0
6ffffa70 70d0df38 0000000b 00000000 00000000 00000000 00000000 00000b94
Call Trace: [do_exit+276/532] [do_signal+621/716] [do_page_fault+351/816]
[sys_sigreturn+196/220] [signal_return+18/48]
Code: 83 78 08 00 74 0e 8b 44 24 14 50 56 e8 47 ab 00 00 83 c4 08
It wasn't really that bad, because just the kvt (KDE xterm) was dead
afterwards. Everything else worked fine. (The FS didn't get unmounted on
kernel shutdown, but I'm not sure, if this is related to this oops.)
What I was doing: I renamed a vgetty logfile, created a new, empty, one,
gzip'ed the old one (that was wrong, I suppose, because it was still opened
by vgetty) and killed [15] vgetty (it's respawned by init after).
I should have killed it before gzipping, but it shouldn't give an oops.
[gzip should unlink the file to delete. There still is one open fd to it, so
it shouldn't be physically deleted before vgetty closes it.]
I don't even now, if there's a connection between the oops and the logfile
action.
P.S: Is somebody working on making the ksymoops work with klogd processed
Oopses ?
-- Kurt Garloff, Dortmund <K.Garloff@ping.de> PGP key on http://student.physik.uni-dortmund.de/homepages/garloff- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu