Unable to handle kernel paging request in 2.4.19-rc1

Hi,

I just experienced a paging request problem in 2.4.19-rc1 running on x86 (pIII 700 with 704MB ram. Motherboard, cpu, memory is very cool).

My kernel is tainted because I'm using the NAPI patch and tulip-NAPI driver (by Robert, Jamal, Alexey) and that driver doesn't set MODULE_LICENSE("GPL");
I have the same patches running in a few production systems/routers without any problems so I don't think they are the problem.

The process that caused it was wmnd which is a small X network monitor applet (much like wmnet) which I think accesses /proc/net/dev all the time to get stats.

Machine was still usable for a while after the failed paging request. But after a minute or so nmbd died aswell, probably a result of this first problem and then X segfaulted.

I was in X when it happened, using xmms, ssh, evolution, galeon, xchat and wmnd.

Hopefully someone can tell me what's going on or if it might be a hardware problem.

ksymoops 2.4.5 on i686 2.4.19-rc1. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.19-rc1/ (default)
-m /boot/System.map-2.4.19-rc1 (default)

Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options.

Reading Oops report from the terminal

Unable to handle kernel paging request at virtual address 89000000
c014a464
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c014a464>]    Tainted: P 

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210286
eax: 00000000 ebx: da190e40 ecx: 00000002 edx: 89000000
esi: da190e9d edi: ebda738d ebp: fffffffe esp: e4d6ded4
ds: 0018 es: 0018 ss: 0018
Process wmnd (pid: 743, stackpage=e4d6d000)

Stack: fffffff4 da190e40 e602c0a0 e602c108 c0139037 e602c0a0 da190e40 00000000 
       00000000 e4d6df8c e4d6df40 c0139753 da1902c0 e4d6df34 00000000 00000001 
       00000000 e4d6df8c e4d6df34 e4d6c000 e4d6c000 00000001 c1f5b00d 00000000 
Call Trace: [<c0139037>] [<c0139753>] [<c01399e2>] [<c0139ea4>] [<c0112b8e>] 
   [<c01301e3>] [<c013052a>] [<c0108bf7>] 
Code: 66 83 3a 00 74 16 0f b7 4a 02 3b 4b 40 75 0d 8b 73 3c 8b 7a 

Trace; c0139037 <real_lookup+53/c4>
Trace; c0139753 <link_path_walk+5bf/834>
Trace; c01399e2 <path_walk+1a/1c>
Trace; c0139ea4 <open_namei+88/534>
Trace; c0112b8e <schedule_timeout+7e/98>
Trace; c01301e3 <filp_open+3b/5c>
Trace; c013052a <sys_open+36/84>
Trace; c0108bf7 <system_call+33/38>

Code; c014a464 <proc_lookup+24/90>
00000000 <_EIP>:
Code; c014a464 <proc_lookup+24/90> <=====
0: 66 83 3a 00 cmpw $0x0,(%edx) <=====
Code; c014a468 <proc_lookup+28/90>
4: 74 16 je 1c <_EIP+0x1c> c014a480 <proc_lookup+40/90>
Code; c014a46a <proc_lookup+2a/90>
6: 0f b7 4a 02 movzwl 0x2(%edx),%ecx
Code; c014a46e <proc_lookup+2e/90>
a: 3b 4b 40 cmp 0x40(%ebx),%ecx
Code; c014a471 <proc_lookup+31/90>
d: 75 0d jne 1c <_EIP+0x1c> c014a480 <proc_lookup+40/90>
Code; c014a473 <proc_lookup+33/90>
f: 8b 73 3c mov 0x3c(%ebx),%esi
Code; c014a476 <proc_lookup+36/90>
12: 8b 7a 00 mov 0x0(%edx),%edi

/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.