Patch Name: PHKL_20357

Patch Description: s700 10.20 Advanced VxFS B.10.20 cumulative patch

Creation Date: 99/11/04

Post Date:  99/11/12

Hardware Platforms - OS Releases:
	s700: 10.20

Products:
	HP OnLineJFS (Advanced VxFS) B.10.20

Filesets:
	AdvJournalFS.VXFS-ADV-KRN OMS.f_fs OS-Core.CORE-KRN

Automatic Reboot?: Yes

Status: General Release

Critical:
	Yes
	PHKL_20357: HANG
		VxFS snapshot may hang.  Only if OnLineJFS is
		installed.  Happens very rarely.
	PHKL_15134: PANIC
	PHKL_12767: HANG
	PHKL_11717: HANG

Path Name: /hp-ux_patches/s700/10.X/PHKL_20357

Symptoms:
	PHKL_20357:
	( SR: 8606100400 DTS: JAGab31753 )
	VxFS snapshot may hang.  This is an ancient bug in VERITAS
	code, no HPUX customer ever encountered this problem.
	Threads may hang sleeping on a busy reserved snapshot
	copy buffer.

	PHKL_15134:
	Non-access Data TLB miss panic when backing up a JFS
	snapshot filesystem.

	PHKL_12767:
	Vxdump hung while backing up a JFS snapshot file system,
	causing the system to hang eventually.

	PHKL_11717:
	The original problem was customer see deadlock when doing
	backup activity, or in other words, system hang.

Defect Description:
	PHKL_20357:
	( SR: 8606100400 DTS: JAGab31753 )

	This is a bug in the VERITAS snapshot code.  For copying
	blocks to the snapshot device, vx_getblk() is called to
	return a buffer without waiting.  If no buffer is returned,
	buffers from reserved copy buffer for the file system are
	used. If the reserved buffer is busy, the thread will be
	put on sleep on the buffer and never waken up. This is
	because the VX_COPYBUF_LOCK macro sets the b_wanted field
	of the reserved buffer while VX_COPYBUF_UNLOCK only tests
	the B_WANTED flag in b_flags. The two macros were not
	in sync.

	Resolution: Check buffer b_wanted also in
	VX_COPYBUF_UNLOCK.

	PHKL_15134:
	When multiple fragments of the buffer passed to
	vx_snap_bpcopy are written (rather than the entire buffer)
	vx_snap_bpcopy incorrectly calculates the offset into the
	buffer of the second and subsequent fragments.  The fix is
	to use the original buffer address and offset from that.

	PHKL_12767:
	SR: 4701368415  DTS: JAGaa00957
	When multiple processes read from the same JFS snapshot
	file system, a deadlock situation occured in
	vx_snap_read(), where one process holding a snapshot
	bitmap buffer was waiting for a snapshot structure lock
	while the process owning the snapshot structure lock was
	sleeping for the bitmap buffer. The fix was to release
	the snapshot bitmap buffer properly to avoid the deadlock.

	PHKL_11717:
	The problem was that stealbuffer will grab all the buffers
	it can before finishing the steal and if it hit a dirty
	buffer, it will try to flush that buffer out.  Unfortunately
	if that buffer is vxfs snapshot buffer, the flushing out of
	the content may sometime depend on getting other buffers
	that may in turn being grabbed by stealbuffer routine.
	Basically, the scenario looks like stealbuffer is sleeping
	on the same buffer it already has.

SR:
	1653213413 1653259630 4701368415 8606100400

Patch Files:
	/usr/conf/lib/libhp-ux.a(dbc_bio.o)
	/usr/conf/lib/libvxfs_adv.a(vx_snap.o)

what(1) Output:
	/usr/conf/lib/libhp-ux.a(dbc_bio.o):
		dbc_bio.c $Date: 97/07/09 15:09:41 $ $Revision: 1.6.
			98.5 $ PATCH_10.20 (PHKL_11717)
	/usr/conf/lib/libvxfs_adv.a(vx_snap.o):
		vx_snap.c $Date: 99/11/02 10:35:21 $ $Revision: 1.7.
			98.13 $ PATCH_10.20 (PHKL_20357)

cksum(1) Output:
	4289132443 5272 /usr/conf/lib/libhp-ux.a(dbc_bio.o)
	3787753970 12628 /usr/conf/lib/libvxfs_adv.a(vx_snap.o)

Patch Conflicts: None

Patch Dependencies: None

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHKL_11717 PHKL_12767 PHKL_15134

Equivalent Patches:
	PHKL_20358:
	s800: 10.20

Patch Package Size: 80 KBytes

Installation Instructions:
	Please review all instructions and the Hewlett-Packard
	SupportLine User Guide or your Hewlett-Packard support terms
	and conditions for precautions, scope of license,
	restrictions, and, limitation of liability and warranties,
	before installing this patch.
	------------------------------------------------------------
	1. Back up your system before installing a patch.

	2. Login as root.

	3. Copy the patch to the /tmp directory.

	4. Move to the /tmp directory and unshar the patch:

		cd /tmp
		sh PHKL_20357

	5a. For a standalone system, run swinstall to install the
	    patch:

		swinstall -x autoreboot=true -x match_target=true \
			-s /tmp/PHKL_20357.depot

	By default swinstall will archive the original software in
	/var/adm/sw/patch/PHKL_20357.  If you do not wish to retain a
	copy of the original software, you can create an empty file
	named /var/adm/sw/patch/PATCH_NOSAVE.

	WARNING: If this file exists when a patch is installed, the
	         patch cannot be deinstalled.  Please be careful
		 when using this feature.

	It is recommended that you move the PHKL_20357.text file to
	/var/adm/sw/patch for future reference.

	To put this patch on a magnetic tape and install from the
	tape drive, use the command:

		dd if=/tmp/PHKL_20357.depot of=/dev/rmt/0m bs=2k

Special Installation Instructions: None