The following oops happened on a 2.1.65 system, after ftp'ing some
debian packages and trying to install them.
Unable to handle kernel paging request at virtual address 1b3f48d0
current->tss.cr3 = 01e98000, %cr3 = 01e98000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c012da80>]
EFLAGS: 00010206
eax: 1b3f48c0 ebx: 00000000 ecx: c07d7fc0 edx: c0d8c5d0
esi: c05ecc63 edi: c19ef3c0 ebp: 00000006 esp: c0ef7f10
ds: 0018 es: 0018 ss: 0018
Process dpkg (pid: 10142, process nr: 34, stackpage=c0ef7000)
Stack: c0d8c5a0 c19ef3e0 c19ef3c0 c012df86 c05ecc63 c2c89c00 c0ef7f90 c3e3c4c4
00000000 c012e1b9 00000008 c2c89c00 c0ef7f90 c3e3c4c4 00000000 00000016
c01290e3 c2c89c00 c0ef7f90 c0ef7f90 c2c89c00 c35be02c c0129398 c2c89c00
Call Trace: [<c012df86>] [<c012e1b9>] [<c01290e3>] [<c0129398>] [<c0129bec>] [<c01091fa>]
Code: 8b 40 10 85 c0 74 02 89 c3 85 db 74 0d 8b 43 08 85 c0 74 06
Segmentation fault
Using `/usr/src/linux/System.map' to map addresses to symbols.
>>EIP: c012da80 <iput+18/16c>
Trace: c012df86 <prune_dcache+5e/88>
Trace: c012e1b9 <d_alloc+21/15c>
Trace: c01290e3 <real_lookup+2f/70>
Trace: c0129398 <lookup_dentry+148/1bc>
Trace: c0129bec <sys_rmdir+30/188>
Trace: c01091fa <system_call+3a/40>
Code: c012da80 <iput+18/16c>
Code: c012da80 <iput+18/16c> 8b 40 10 movl 0x10(%eax),%eax
Code: c012da83 <iput+1b/16c> 85 c0 testl %eax,%eax
Code: c012da85 <iput+1d/16c> 74 02 je c012da89 <iput+21/16c>
Code: c012da87 <iput+1f/16c> 89 c3 movl %eax,%ebx
Code: c012da89 <iput+21/16c> 85 db testl %ebx,%ebx
Code: c012da91 <iput+29/16c> 74 0d je c012da9a <iput+32/16c>
Code: c012da93 <iput+2b/16c> 8b 43 08 movl 0x8(%ebx),%eax
Code: c012da96 <iput+2e/16c> 85 c0 testl %eax,%eax
Code: c012da98 <iput+30/16c> 74 06 je c012da9a <iput+32/16c>
(I think this is in linux/fs/inode.c:
void iput(struct inode *inode)
{
if (inode) {
struct super_operations *op = NULL;
if (inode->i_sb && inode->i_sb->s_op)
op = inode->i_sb->s_op;
if (op && op->put_inode)
op->put_inode(inode);
...etc, though I'm not quite sure.)
I don't think that this is reproducible (can't figure the conditions
under which the bug was triggered). My system is almost all-modules,
which of ppp, slhc and serial were loaded at the time of the oops.
Note though that the ppp link was down, only the module wasn't
autocleaned (yet). I have only ext2 built-in in the kernel, and all
disks in use are IDE.
The dpkg process was probably removing lotsa files/directories when
this happened, judging by the call trace and 'ext2_rmdir: d_count=x,
pruning' messages found in the logs before the oops.
Thank you for listening!
More info available on request,
Taneli <vahakang@cs.helsinki.fi>