This is with a stock 1.3.8, gcc-2.5.8, but the interesting part is that
it was compiled with "-g" already. (This was because I was trying to find
the NULL deref. in eth_copy_and_sum() that was stopping me from booting
another machine.) As it didn't crash completly, I was able use gdb on it
right then and there. This made debugging easier. :-) I also saved
a copy of the oops'ed /proc/kcore in case there is any useful information
in it that somebody (Ted?) wants me to look up post-mortem. (I can do a
"gdb vmlinux /tmp/saved.kcore" anytime later.)
(The time stamps were all the same so I removed them for clarity)
Unable to handle kernel paging request at virtual address c7200720
current->tss.cr3 = 00a92000, 4r3 = 00a92000
*pde = 00000000
Oops: 0000
EIP: 0010:07200720
The EIP appears to be garbage, but if we look at the call trace, it
starts with 0x10a619 which is in system_call (0010a5c0 -> 0010a660).
>From there it progresses as follows:
0x11f504 is in sys_write (read_write.c:139).
139 written = file->f_op->write(inode,file,buf,count);
0x164ce4 is in tty_write (tty_io.c:751).
751 i = (tty->ldisc.write)(tty,file,(unsigned char *)buf,(unsigned int)count);
0x168a02 is in write_chan (n_tty.c:948).
948 tty->driver.flush_chars(tty);
which is where it jumps into a black hole, as tty->driver.flush_chars
must have been stomped on by something and points to never-never land.
EFLAGS: 00010202
eax: 07200720 ebx: 00000000 ecx: 00000001 edx: 00000001
esi: 0003f417 edi: 00097000 ebp: 00000000 esp: 00a7df38
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process tcsh (pid: 86, process nr: 3, stackpage=00a7d000)
Stack: 00168a02 00097000 00097000 0097bb60 00b38570 0003f408 00a90000 00a7df50
00164ce4 00097000 00b38570 0003f408 0000000f 00b38570 0097bb60 0000000f
0011f504 0097bb60 00b38570 0003f408 0000000f 00a90000 00000000 00043c70
Call Trace: 00168a02 00164ce4 0011f504 0010a619
Code: <1>Unable to handle kernel paging request at virtual address c7200720
current->tss.cr3 = 00a92000, 4r3 = 00a92000
Note that while trying to dump the "Code:" for the first oops, it
generated a second oops! The second oops is as follows:
*pde = 00000000
Oops: 0000
EIP: 0010:0010ad17
0x10ad17 is in die_if_kernel (traps.c:160).
158 printk("\nCode: ");
159 for(i=0;i<20;i++)
160 printk("%02x ",0xff & get_seg_byte(regs->cs,(i+(char *)regs->eip)));
161 printk("\n");
EFLAGS: 00010212
eax: 00000010 ebx: 0010002b ecx: 07200720 edx: 009f4000
esi: 00000000 edi: 00a7e000 ebp: 00a7defc esp: 00a7deac
ds: 0018 es: 0018 fs: 0010 gs: 002b ss: 0018
Process tcsh (pid: 86, process nr: 3, stackpage=00a7d000)
Stack: 0010002b 00000000 c7200720 00030000 00a7defc 01440000 01800000 01000000
00100018 0010fdf7 0010fbb7 00a7defc 00030000 0010fbbc 0003f417 00097000
00000000 0010a7db 00a7defc 00030000 00000000 00000001 00000001 0003f417
Call Trace: 01440000 01800000 01000000 0010fdf7 0010fbb7 0010fbbc 0010a7db
00160018 00168a02 00164ce4 0011f504 0010a619
Code: 64 8a 04 0e 0f a1 88 c2 81 e2 ff 00 00 00 89 54 24 10 52 68
Warning: bad magic number for tty struct (4, 2) in release_dev
Warning: dev (4, 2) tty->count(4) != #fd's(3) in tty_open
Warning: bad magic number for tty struct (4, 2) in tty_ioctl
and later when agetty tried to restart....
Warning: bad magic number for tty struct (4, 2) in tty_ioctl
Warning: bad magic number for tty struct (4, 2) in release_dev
Warning: dev (4, 2) tty->count(5) != #fd's(3) in tty_open
Warning: bad magic number for tty struct (4, 2) in tty_ioctl
until I removed tty2 from inittab. tty2 is completely broken, but at
least the magic #'s pick it up from doing more damage.
~# echo hello > /dev/tty2
Warning: dev (4, 2) tty->count(58) != #fd's(2) in tty_open
Warning: bad magic number for tty struct (4, 2) in tty_ioctl
Warning: bad magic number for tty struct (4, 2) in tty_write
Warning: bad magic number for tty struct (4, 2) in release_dev
~# cat /dev/tty2
Warning: dev (4, 2) tty->count(59) != #fd's(2) in tty_open
Warning: bad magic number for tty struct (4, 2) in tty_read
cat: /dev/tty2: I/O error
Warning: bad magic number for tty struct (4, 2) in release_dev
~#
The question still remains as to who/what stomped on the tty struct.
Regards,
Paul.