Looks like page_launder is still causing problems. I was using
ReiserFS version 3.6.23. As far as I remember it was running
Seti@Home 3.03 and compile qt-2.2.3. I was able to run ksymoops
without rebooting.
ksymoops 2.3.5 on i686 2.4.0-test12. Options used
-v /boot/vmlinux-2.4.0-test12 (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12/ (default)
-m /boot/System.map-2.4.0-test12 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
c012cf63
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c012cf63>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000000 ebx: c1097d0c ecx: 000004ba edx: 00000002
esi: c1097cf0 edi: 00003a33 ebp: 00000000 esp: c1479fb4
ds: 0018 es: 0018 ss: 0018
Process bdflush (pid: 6, stackpage=c1479000)
Stack: c1478000 c027703c 00000000 0008e000 00000000 c1478000 00000000 00003a32
00000000 c01361bd 00000003 00000000 00010f00 c145ff8c c145ffd8 c0109043
c145ffc4 c145ffc4 c145ffc4
Call Trace: [<c01361bd>] [<c0109043>]
Code: 8b 40 0c 8b 10 85 d2 0f 84 85 04 00 00 83 7c 24 18 00 75 4e
>>EIP; c012cf63 <page_launder+1d3/800> <=====
Trace; c01361bd <bdflush+8d/120>
Trace; c0109043 <kernel_thread+23/30>
Code; c012cf63 <page_launder+1d3/800>
00000000 <_EIP>:
Code; c012cf63 <page_launder+1d3/800> <=====
0: 8b 40 0c mov 0xc(%eax),%eax <=====
Code; c012cf66 <page_launder+1d6/800>
3: 8b 10 mov (%eax),%edx
Code; c012cf68 <page_launder+1d8/800>
5: 85 d2 test %edx,%edx
Code; c012cf6a <page_launder+1da/800>
7: 0f 84 85 04 00 00 je 492 <_EIP+0x492> c012d3f5 <page_launder+665/800>
Code; c012cf70 <page_launder+1e0/800>
d: 83 7c 24 18 00 cmpl $0x0,0x18(%esp,1)
Code; c012cf75 <page_launder+1e5/800>
12: 75 4e jne 62 <_EIP+0x62> c012cfc5 <page_launder+235/800>
--
Ian.
I don't have a sig either!
On Thu, 21 Dec 2000, Ian Hastie wrote:
> Looks like page_launder is still causing problems. I was using
> ReiserFS version 3.6.23. As far as I remember it was running
> Seti@Home 3.03 and compile qt-2.2.3. I was able to run ksymoops
> without rebooting.
So, can you (or anyone) reproduce any oops/indication of a kernel
problem without having 'other' stuff in the kernel? If so, describe
please.. tis not of necessity an indicitation of problems with your
favorite application or driver if it is required to reproduce problem,
but _is_ much easier to diagnose the root if you can provide a formula
for failure [even obscure] which does not include 'foreign' material.
I've not seen a reproducable report yet.. but the reports which I've
seen ~jibe wrt 'there is something fairly odd going on'. (yes, I've
my share of oddities, and no, I don't have anything solid either;)
-Mike