I have upgraded one of our mailservers (P90, 32M RAM, 10GB IDE HDD)
to 2.2.14pre17, and it oopsed in two days (on Dec 31 :-). After going
back to 2.2.5 it is rock-solid again (the previous uptime was 212 days
and it went down just because of the UPS failure :-| ). The userland
is RedHat-5.2. Server runs qmail, MySQL and chrooted bind, nothing special.
I think the probability of HW failure is low (the previous uptime was so high).
The kernel was compiled on a generic RedHat 6.1 box
The version string of the kernel is the following:
Dec 29 16:08:14 arethusa kernel: Linux version 2.2.14pre17 (kas@pyrrha.fi.muni.cz) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Wed Dec 29 15:49:50 CET 1999
The kernel configuration is the following (no modules were loaded
at the time of kernel crash):
# grep =[ym] .config
CONFIG_EXPERIMENTAL=y
CONFIG_M586=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_1GB=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OPTIMIZE=y
CONFIG_PCI_OLD_PROC=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ALIAS=y
CONFIG_SKB_LARGE=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL3=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_CYCLADES=y
CONFIG_UNIX98_PTYS=y
CONFIG_PRINTER=m
CONFIG_PRINTER_READBACK=y
CONFIG_WATCHDOG=y
CONFIG_SOFT_WATCHDOG=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_NFS_FS=m
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MAGIC_SYSRQ=y
Here is the ksymoops output:
--------------------------------------------------------------------
Options used: -V (default)
-O (specified)
-K (specified)
-L (specified)
-m System.map-2.2.14pre17 (specified)
-c 1 (default)
Dec 31 02:15:50 arethusa kernel: Unable to handle kernel paging request at virtual address c422efc8
Dec 31 02:15:50 arethusa kernel: current->tss.cr3 = 00101000, pr3 = 00101000
Dec 31 02:15:50 arethusa kernel: *pde = 00000000
Dec 31 02:15:50 arethusa kernel: Oops: 0002
Dec 31 02:15:50 arethusa kernel: CPU: 0
Dec 31 02:15:50 arethusa kernel: EIP: 0010:[<c011a506>]
Dec 31 02:15:50 arethusa kernel: EFLAGS: 00010282
Dec 31 02:15:50 arethusa kernel: eax: c022bd48 ebx: c022bc58 ecx: c422efc4 edx: c022bc58
Dec 31 02:15:50 arethusa kernel: esi: 00000060 edi: 00000030 ebp: 000000a0 esp: c1fb3fbc
Dec 31 02:15:50 arethusa kernel: ds: 0018 es: 0018 ss: 0018
Dec 31 02:15:50 arethusa kernel: Process kswapd (pid: 5, process nr: 5, stackpage=c1fb3000)
Dec 31 02:15:50 arethusa kernel: Stack: 0000000d 00000006 c011f30a 00000006 00000030 c1fb2000 c019332e c1fb21c1
Dec 31 02:15:50 arethusa kernel: c011f3c3 00000030 00000f00 c1ff9fcc c0106000 c010651f 00000000 00000f00
Dec 31 02:15:50 arethusa kernel: c01bbfd8
Dec 31 02:15:50 arethusa kernel: Call Trace: [<c011f30a>] [<c019332e>] [<c011f3c3>] [<c0106000>] [<c010651f>]
Dec 31 02:15:50 arethusa kernel: Code: 89 41 04 8b 4a 04 85 c9 74 04 8b 02 89 01 c7 02 00 00 00 00
>>EIP: c011a506 <remove_inode_page+4a/70>
Trace: c011f30a <do_try_to_free_pages+26/78>
Trace: c019332e <tvecs+1b8e/3320>
Trace: c011f3c3 <kswapd+67/9c>
Trace: c0106000 <get_options+0/74>
Trace: c010651f <kernel_thread+23/30>
Code: c011a506 <remove_inode_page+4a/70> 00000000 <_EIP>: <===
Code: c011a506 <remove_inode_page+4a/70> 0: 89 41 04 movl %eax,0x4(%ecx) <===
Code: c011a509 <remove_inode_page+4d/70> 3: 8b 4a 04 movl 0x4(%edx),%ecx
Code: c011a50c <remove_inode_page+50/70> 6: 85 c9 testl %ecx,%ecx
Code: c011a50e <remove_inode_page+52/70> 8: 74 04 je c011a514 <remove_inode_page+58/70>
Code: c011a510 <remove_inode_page+54/70> a: 8b 02 movl (%edx),%eax
Code: c011a512 <remove_inode_page+56/70> c: 89 01 movl %eax,(%ecx)
Code: c011a514 <remove_inode_page+58/70> e: c7 02 00 00 00 00 movl $0x0,(%edx)
--------------------------------------------------------------------
More information on request.
-Yenya
-- \ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// Its purely bandwidth. If it was 40 instances of Miguel reading web pages flat out over 100baseT you would definitely be right. But its not... (Alan)- 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.tux.org/lkml/