Messages in this thread | | | Date | Mon, 24 Aug 1998 11:38:30 +0200 (CEST) | From | Daniel Ryde <> | Subject | GPF: dcache_add in kernel 2.0.35 |
| |
Jum, these are odd:
general protection: 0000 CPU: 0 EIP: 0010:[<0012ebd1>] EFLAGS: 00010206 eax: 666b636f ebx: 03a6fe00 ecx: 001c8154 edx: 001c8084 esi: 001c8154 edi: 0002b801 ebp: 001c9b0c esp: 00437eb4 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process suexec (pid: 798, process nr: 32, stackpage=00437000) Stack: 03fa8c54 03a6fe00 0804bbb0 00000058 00000302 001c8154 00156bc7 03a6fe00 03fa8c54 00000003 0002b801 017a3000 00001000 0804bbb0 bfffde54 03fa8c4c 00000040 00000000 00158183 0162af00 00000000 00000000 0162af00 000041ed Call Trace: [<00156bc7>] [<00158183>] [<0019a191>] [<00122459>] [<0012cd03>] [<0012cbc8>] [<0010a705>] [<0018291e>] Code: 8b 50 30 89 41 2c 89 51 30 89 4a 2c 89 48 30 5b 5e 5f 5d 83 Unable to handle kernel paging request at virtual address f73073a3 current->tss.cr3 = 003cd000, %cr3 = 003cd000 *pde = 00000000
>>EIP: 12ebd1 <dcache_add+e9/194> Trace: 156bc7 <ext2_readdir+4af/620> Trace: 158183 <ext2_put_inode+b/68> Trace: 19a191 <sprint_dev_config+15/548> Trace: 122459 <do_open+59/124> Trace: 12cd03 <sys_getdents+97/c8> Trace: 12cbc8 <filldir> Trace: 10a705 <system_call+55/80> Trace: 18291e <con_get_trans_new+32/3c>
Code: 12ebd1 <dcache_add+e9/194> Code: 12ebd1 <dcache_add+e9/194> 8b 50 30 movl 0x30(%eax),%edx Code: 12ebd4 <dcache_add+ec/194> 89 41 2c movl %eax,0x2c(%ecx) Code: 12ebd7 <dcache_add+ef/194> 89 51 30 movl %edx,0x30(%ecx) Code: 12ebda <dcache_add+f2/194> 89 4a 2c movl %ecx,0x2c(%edx) Code: 12ebe3 <dcache_add+fb/194> 89 48 30 movl %ecx,0x30(%eax) Code: 12ebe6 <dcache_add+fe/194> 5b popl %ebx Code: 12ebe7 <dcache_add+ff/194> 5e popl %esi Code: 12ebe8 <dcache_add+100/194> 5f popl %edi Code: 12ebe9 <dcache_add+101/194> 5d popl %ebp Code: 12ebea <dcache_add+102/194> 83 00 90 addl $0xffffff90,(%eax) Code: 12ebf3 <dcache_add+10b/194> 90 nop Code: 12ebf4 <dcache_add+10c/194> 90 nop
Then a minute later or so:
Unable to handle kernel paging request at virtual address ee6673a3 current->tss.cr3 = 003b3000, %cr3 = 003b3000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<0012ebd1>] EFLAGS: 00010212 eax: 2e667373 ebx: 03a6fe00 ecx: 001c8154 edx: 001c8084 esi: 001c8154 edi: 0002b801 ebp: 001c9b0c esp: 003b4eb4 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process suexec (pid: 809, process nr: 33, stackpage=003b4000) Stack: 03fa8c54 03a6fe00 0804bbb0 00000058 00000302 001c8154 00156bc7 03a6fe00 03fa8c54 00000003 0002b801 03665374 00001000 0804bbb0 bfffddac 03fa8c4c 00000040 00000000 00158183 0162af00 00000000 00000000 0162af00 000041ed Call Trace: [<00156bc7>] [<00158183>] [<0019a191>] [<00122459>] [<0012cd03>] [<0012cbc8>] [<0010a705>] [<0018291e>] Code: 8b 50 30 89 41 2c 89 51 30 89 4a 2c 89 48 30 5b 5e 5f 5d 83
>>EIP: 12ebd1 <dcache_add+e9/194> Trace: 156bc7 <ext2_readdir+4af/620> Trace: 158183 <ext2_put_inode+b/68> Trace: 19a191 <sprint_dev_config+15/548> Trace: 122459 <do_open+59/124> Trace: 12cd03 <sys_getdents+97/c8> Trace: 12cbc8 <filldir> Trace: 10a705 <system_call+55/80> Trace: 18291e <con_get_trans_new+32/3c>
Code: 12ebd1 <dcache_add+e9/194> Code: 12ebd1 <dcache_add+e9/194> 8b 50 30 movl 0x30(%eax),%edx Code: 12ebd4 <dcache_add+ec/194> 89 41 2c movl %eax,0x2c(%ecx) Code: 12ebd7 <dcache_add+ef/194> 89 51 30 movl %edx,0x30(%ecx) Code: 12ebda <dcache_add+f2/194> 89 4a 2c movl %ecx,0x2c(%edx) Code: 12ebe3 <dcache_add+fb/194> 89 48 30 movl %ecx,0x30(%eax) Code: 12ebe6 <dcache_add+fe/194> 5b popl %ebx Code: 12ebe7 <dcache_add+ff/194> 5e popl %esi Code: 12ebe8 <dcache_add+100/194> 5f popl %edi Code: 12ebe9 <dcache_add+101/194> 5d popl %ebp Code: 12ebea <dcache_add+102/194> 83 00 90 addl $0xffffff90,(%eax) Code: 12ebf3 <dcache_add+10b/194> 90 nop Code: 12ebf4 <dcache_add+10c/194> 90 nop
This happens 10 minutes after boot for about 10 minutes, one GPF per minute or so. After that it continues normaly without any GPF. I have rebooted it twice with the same behaviour. This is a webserver with many (100 or so) virtual domains/ip alias. The load is about 0.1, no swapping. The suexec is the tiny cgi wrapper from apache, though modified to handle virtual domains more gracefully. This happens on only one of seven other very similar machines. And ofcourse It has Solar Designer security patch applied.
Can someone understand what is going on here?
CPU: P5/133, 64Mb of memory, 4.3Gb EIDE.
CONFIG_NET=y CONFIG_PCI=y CONFIG_SYSVIPC=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_KERNEL_ELF=y CONFIG_M586=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_TRITON=y CONFIG_NET_ALIAS=y CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_SYN_COOKIES=y CONFIG_IP_ALIAS=y CONFIG_IP_NOSR=y CONFIG_SKB_LARGE=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y CONFIG_PPP=y CONFIG_SLIP=y CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_NET_PCI=y CONFIG_DEC_ELCP=y CONFIG_EPIC=y CONFIG_NET_ISA=y CONFIG_NE2000=y CONFIG_MINIX_FS=y CONFIG_EXT2_FS=y CONFIG_NLS=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_PROC_FS=y CONFIG_SERIAL=y CONFIG_SECURE_STACK=y CONFIG_SECURE_LINK=y CONFIG_SECURE_PIPE=y
Best Regards
Daniel Ryde, System Administrator __________________________________________________________________________ Tripnet AB Visit Address: Telephone: +46 31 7252500 Box 5071 Avagen 42 Facsimile: +46 31 7252501 S-402 22 GOTEBORG GOTEBORG Email: ryde@tripnet.se Sweden Sweden
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |