This killed off syslogd completely, which is rather annoying (though better
than a full system crash, I suppose).
Here's OOPS number one (sorry, it got cut off a bit, so information is
rather limited):
Unable to handle kernel paging request at virtual address c7200720
current->tss.cr3 = 0020e000, %cr3 = 0020e000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:07200720
EFLAGS: 00010202
eax: 07200720 ebx: 00000000 ecx: 0000000b edx: 00005cc0
esi: bfffeb95 edi: 0005d000 ebp: 00000000 esp: 003eaf30
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process syslogd (pid: 74, process nr: 5, stackpage=003ea000)
Stack: 0016d274 0005d000 0005d000 00442d20 000951e0 00000061 001f7a80 003cbc0c
003eaf4c 001698f7 0005d000 000951e0 bfffeb34 00000061 000951e0 00442d20
00000061 bfffeb34 0011e1dc 00442d20 000951e0 bfffeb34 00000061 003cbc0c
Call Trace: 0016d274 001698f7 0011e1dc 0011fc84 0010a479
Code: <1>
(has anyone considered larger kernel message buffers, by the way? I for one
would really appreciate it when debuggin my ARCnet driver, as well as this)
ksymoops says:
Using /boot/System.map1.3.37' to map addresses to symbols.
Trace: 16d274 <write_chan+124/1f0>
Trace: 1698f7 <tty_write+d7/100>
Trace: 11e1dc <sys_write+9c/f0>
Trace: 11fc84 <sys_fsync+54/70>
Trace: 10a479 <system_call+59/a0>
(EIP is some kind of garbage value, it seems)
For OOPS number 2 (got the whole thing, this time):
nable to handle kernel paging request at virtual address c7200720
current->tss.cr3 = 0020e000, %cr3 = 0020e000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:0010aa1b
EFLAGS: 00010202
eax: 00000010 ebx: 0009002b ecx: 07200720 edx: 00000020
esi: 00000000 edi: 003eb000 ebp: 003eaef4 esp: 003eaea0
ds: 0018 es: 0018 fs: 0010 gs: 002b ss: 0018
Process syslogd (pid: 74, process nr: 5, stackpage=003ea000)
Stack: 0018002b 00000000 c7200720 00050000 003eaef4 00d00000 01000000 00800000
00180018 0010fdbb 00180941 003eaef4 00050000 0010fb60 bfffeb95 0005d000
00000000 001a55c0 0010a63b 003eaef4 00050000 00000000 0000000b 00005cc0
Call Trace: 00d00000 01000000 00800000 0010fdbb 0010fb60 0010a63b 0016d274
001698f7 0011e1dc 0011fc84 0010a479
Code: 64 8a 04 0e 0f a1 88 c2 81 e2 ff 00 00 00 89 54 24 10 52 68
And ksymoops:
Using /boot/System.map1.3.37' to map addresses to symbols.
>>EIP: 10aa1b <die_if_kernel+28b/2e0>
Trace: d00000
Trace: 1000000
Trace: 800000
Trace: 10fdbb <do_page_fault+25b/270>
Trace: 10fdbb <do_page_fault+25b/270>
Trace: 10a63b <error_code+4b/60>
Trace: 16d274 <write_chan+124/1f0>
Trace: 1698f7 <tty_write+d7/100>
Trace: 11e1dc <sys_write+9c/f0>
Trace: 11fc84 <sys_fsync+54/70>
Trace: 10a479 <system_call+59/a0>
Code: 10aa1b <die_if_kernel+28b/2e0> movb %fs:(%esi,%ecx,1),%al
Code: 10aa1f <die_if_kernel+28f/2e0> popl %fs
Code: 10aa21 <die_if_kernel+291/2e0> movb %al,%dl
Code: 10aa23 <die_if_kernel+293/2e0> andl $0xff,%edx
Code: 10aa29 <die_if_kernel+299/2e0> movl %edx,0x10(%esp,1)
Code: 10aa2d <die_if_kernel+29d/2e0> pushl %edx
Code: 10aa2e <die_if_kernel+29e/2e0> pushl $0x90909000
My system is still running happily. (I'm using it as an internet router as I
write this message!) However, upon restarting syslogd I got this:
Warning: dev (04:0c) tty->count(2) != #fd's(1) in tty_open
Warning: bad magic number for tty struct (04:0c) in tty_ioctl
Warning: bad magic number for tty struct (04:0c) in tty_write
Warning: bad magic number for tty struct (04:0c) in release_dev
Sounds none too healthy.
...hmm, upon further testing, I can generate these messgages upon _ANY_
attempt to open /dev/tty12 now. tty11 is fine. At least it isn't OOPS'ing
anymore.
Can anybody explain this one?
Avery