PROBLEM: (MCPMA986D) (Patch ID: OSF375-061) ******** This patch is a kernel fix for network sockets left in FIN_WAIT_1 state forever. This patch contains a "tunable" kernel parameter. It is recommended that only experienced system administrators attempt to set this parameter from the default value. This patch is MANDATORY to install. How to recognize this problem. This is an example of the problem with tcpdump running in the background listening on the destination ip address shown in the netstat output. # netstat -An | grep 203.232.10.221 Active Internet connections PCB Proto Recv-Q Send-Q Local Address Foreign Address (state) 94276c00 tcp 0 759 192.86.154.82.80 203.232.10.221.162 FIN_WAIT_1 9418ef00 tcp 0 759 192.86.154.82.80 203.232.10.221.162 FIN_WAIT_1 13:28:03.472384 www-2.us.oracle.com.80 > 203.232.10.221.1626: . 0:1(1) ack 1 win 33232 13:28:12.973072 www-2.us.oracle.com.80 > 203.232.10.221.1623: . 0:1(1) ack 1 win 33232 What is observed here is the destination is clearly dead. The source is sending an ACK to the destination looking for his ACK of our FIN. This is commonly refered to as "persist mode". A socket in this state will never timeout and system resources associated with it will not be released. The new kernel modification to tcp_timer.o can be "tuned" by dbx'ing the tcp_keepidle parameter on the system. By default, this is set to 14400 1/2 seconds (2 hours). It can be easily set to any value appropriate for the system to "balance" the number of sockets in FIN_WAIT_1 state at any time. The system may always have some sockets in FIN_WAIT_1 as well as CLOSE_WAIT, this is NORMAL. What you don't want is a large number of sockets in FIN_WAIT_1 forever. It is not recommended that tcp_keepidle be set to less than 5 minutes on the system. Reference the man page to dbx for guidelines when using the dbx command. PROBLEM: (CLD MCSMB05F5, CLD MCPM60HH7) (Patch ID: OSF375-133) ******** This patch fixes a problem of memory corruption. A TCP control structure is illegally accessed after it is released. The corrupted memory buckets are the 256-byte size. If the crash tool command "kmem -v" is run on the dump to verify the integrity of the kernel buckets, the following message is printed indicating the memory corruption: kmembuckets[4]: invalid checksum in bucket element The symptom for this problem can take many forms. In one case, threads hung in wait_for_vxlock() with the following stack trace. 0 thread_block() 1 wait_for_vxlock() ["../../../../src/kernel/vfs/vfs_subr.c":802] 2 vgetm() ["../../../../src/kernel/vfs/vfs_subr.c":2142] 3 iget() ["../../../../src/kernel/ufs/ufs_inode.c":735] 4 scandir() ["../../../../src/kernel/ufs/ufs_lookup.c"] 5 ufs_lookup() ["../../../../src/kernel/ufs/ufs_lookup.c":386] 6 namei() ["../../../../src/kernel/vfs/vfs_lookup.c":593] 7 stat1() ["../../../../src/kernel/vfs/vfs_syscalls.c":2824] 8 lstat() ["../../../../src/kernel/vfs/vfs_syscalls.c":2808] 9 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":555] 10 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1209]