Unable to handle kernel paging request at virtual address 40008000
current->tss.cr3 = 013a3000, %cr3 = 013a3000
*pde = 02347067
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00157b45>]
EFLAGS: 00010216
eax: 0217fd04 ebx: 00000400 ecx: 00000100 edx: 02947800
esi: 40008000 edi: 02947800 ebp: 00000400 esp: 02994c08
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process tickle (pid: 30809, process nr: 17, stackpage=02994000)
Stack: 00001000 40008000 40008000 00040000 00000000 00000000 001d9148
00000000
00000000 00000014 00005000 00000000 0217fd04 ffffffe4 021b6d90
00ee3b6c
02994c94 01a8ad90 00008180 02994c94 01a8ad90 00008180 00123d52
00ee3b6c
Call Trace: [<00123d52>] [<0015ab26>] [<0012ef24>] [<0012f05b>] [<0012ef24>]
[<0012fa34>] [<00118dc3>]
[<00118e47>] [<00118cc0>] [<0010a42f>] [<0010a672>]
Code: 64 f3 a5 83 e3 03 89 d9 64 f3 a4 55 8b 54 24 34 8b 52 24 03
Using `/kernels/System.map-2.0.27-fdt-elf' to map addresses to symbols.
>>EIP: 157b45 <ext2_file_write+249/45c>
Trace: 123d52 <__brelse+22/44>
Trace: 15ab26 <ext2_create+152/168>
Trace: 12ef24 <dump_write+1c/2c>
Trace: 12f05b <writenote+a7/c8>
Trace: 12ef24 <dump_write+1c/2c>
Trace: 12fa34 <elf_core_dump+9b8/a50>
Trace: 118dc3 <do_no_page+103/328>
Trace: 118e47 <do_no_page+187/328>
Trace: 118e47 <do_no_page+187/328>
Trace: 10a42f <do_signal+1ef/280>
Trace: 10a672 <signal_return+12/40>
Code: 157b45 <ext2_file_write+249/45c> repz movsl %ds:(%esi),%es:(%edi)
Code: 157b48 <ext2_file_write+24c/45c> andl $0x3,%ebx
Code: 157b4b <ext2_file_write+24f/45c> movl %ebx,%ecx
Code: 157b4d <ext2_file_write+251/45c> repz movsb %ds:(%esi),%es:(%edi)
Code: 157b50 <ext2_file_write+254/45c> pushl %ebp
Code: 157b51 <ext2_file_write+255/45c> movl 0x34(%esp,1),%edx
Code: 157b55 <ext2_file_write+259/45c> movl 0x24(%edx),%edx
Code: 157b58 <ext2_file_write+25c/45c> addl (%eax),%eax
Code: 157b5a <ext2_file_write+25e/45c> nop
Code: 157b5b <ext2_file_write+25f/45c> nop
Code: 157b5c <ext2_file_write+260/45c> nop
I then ran it a second time, to see if I'd get identical results, and
instead I got a process eating 90% CPU that I cannot kill. Running it a
third time left the 3rd invocation in uninteruptable sleep.
fubar 30823 89.5 0.3 820 184 ? R 11:31 11:46 ./tickle
fubar 31312 0.1 1.1 1204 564 p5 S 11:42 0:00 -bash
fubar 31359 0.0 0.3 820 184 p5 D 11:44 0:00 ./tickle
Guess it's time to upgrade kernels and reboot.
On Mon, 24 Feb 1997, Bernd Schmidt wrote:
> > > eax: 00986bb0 ebx: 00000400 ecx: 00000100 edx: 016bd400
> > > esi: 40007000 edi: 016bd400 ebp: 00000400 esp: 01384c08
> >
> > Flipped 14th bit in esi, most likely. In other words, memory error.
>
> I'd like to agree, but I've seen another bug report like this, and I noticed
> that in both cases, the function elf_core_dump appeared in the stack trace.
> I even still have the original mail. The author (Johnny Stenback) claims the
> problem is reproducible with the following test program:
>
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <string.h>
> #include <errno.h>
>
> void main ()
> {
> int fd;
> void *p;
> char buf[1024];
> fd = open("test", O_RDONLY);
> p = mmap(NULL, 200, PROT_WRITE, MAP_PRIVATE, fd, 0);
> strncpy (buf, p, 100);
> printf ("%s\n", buf);
> munmap (p, 200);
> exit (0);
> }
>
> The "Oops" from the other post is mostly identical-looking.
> (I haven't tried this, so if it doesn't work, I apologize. I'll try today)
> Of course, you'll have to enable core dumps.
>
> Bernd
>
------------------------------------------------------------------
Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will
Network Administrator | be proof-read for $199/hr.
________Finger jlewis@inorganic5.fdt.net for PGP public key_______