Note: this bug isn't reproducable - but I have a generally unstable
system. Can someone give me hints on this? (more further down)
linux 2.2.9
I got a whole lot of Oops's when running chat (for initializing a ppp
connection):
Unable to handle kernel NULL pointer dereference at virtual address
000000cb
current->tss.cr3 = 00c43000, %cr3 = 00c43000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[sys_read+92/240]
EFLAGS: 00010202
eax: c0c65a7d ebx: c372a9e0 ecx: bffff56b
edx: 00000063 esi: 00000046 edi: 00000077
ebp: c0d30000 esp: c0d31fb8
ds: 0018 es: 0018 ss: 0018
Process chat (pid: 749, process nr: 40, stackpage=c0d31000)
Stack: 0804d5f0 bffff56c c0108a9c 00000000 bffff56b 00000001
bffff5bd 0804d5f0 bffff56c 00000003 0000002b 0000002b 00000003
400bc534 00000023 00000282 bffff550 0000002b
I looked inside sys_read ():
asmlinkage ssize_t sys_read(unsigned int fd, char * buf, size_t count)
{
ssize_t ret;
struct file * file;
ssize_t (*read)(struct file *, char *, size_t, loff_t *);
lock_kernel();
ret = -EBADF;
file = fget(fd);
if (!file)
goto bad_file;
if (!(file->f_mode & FMODE_READ))
goto out;
ret = locks_verify_area(FLOCK_VERIFY_READ,
file->f_dentry->d_inode,
file, file->f_pos, count);
<snip>
locks_verify_area dereferences file->f_dentry->d_inode. But d_inode
is a weird number (0x0000063) - I determined this by disassembling the
code (file->f_dentry->d_inode is %edx).
So something's clobbering the f_dentry struct? I can't reproduce the
bug (I'm on the net now ;-)
In general, I've had a very unstable system in the since 2.2.x (from
2.2.1, 2.2.2, 2.2.5, 2.2.9)
One reproducable bug I need to investigate is I've written a program
that always crashes ALSA's OSS emulation...could be related (esound
is running at the same time as internet connection, so perhaps ALSA's
clobbering lots of things ???)
Any ideas? What's a good way to hunt for this kind of bug?
I'm assuming that ALSA has write access to all of kernel-space (is this
correct?)
Andrew Clausen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/