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