Patch Name: PHKL_24268

Patch Description: s700_800 11.00 pv_curxfs,lv_resyncpv cumulative patch

Creation Date: 01/05/31

Post Date: 01/06/13

Hardware Platforms - OS Releases:
	s700: 11.00
	s800: 11.00

Products: N/A

Filesets:
	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP
	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP
	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP
	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical:
	Yes
	PHKL_24268: PANIC HANG
	PHKL_23127: CORRUPTION
	PHKL_22266: HANG
	PHKL_22267: HANG
	PHKL_20419: PANIC CORRUPTION
	PHKL_20186: CORRUPTION
	PHKL_18542: PANIC HANG
	PHKL_18483: OTHER
		Performance problem
	PHKL_18189: HANG OTHER
		Hardware Detection Problem
	PHKL_17664: PANIC
	PHKL_15789: HANG
		Time to switch PVLinks can take several hours when
		100's of paths are involved.  During this time,
		these I/O paths (to disk devices) are unavailable.
		This may have the appearance of a hung system.
	PHKL_14689: PANIC
	PHKL_14252: PANIC HANG OTHER
		Cluster may not reconfigure after a node crash.

	PHKL_17045: PANIC
	PHKL_17042: PANIC
	PHKL_13346: CORRUPTION ABORT
	PHKL_16433: HANG
	PHKL_15956: ABORT
	PHKL_14861: HANG
	PHKL_20397: OTHER
		With patch PHKL_19367 installed, but not this
		patch, there can be cases where sleeping user
		threads cannot be awakened.

Category Tags:
	defect_repair hardware_enablement enhancement
	general_release critical panic halts_system corruption

Path Name: /hp-ux_patches/s700_800/11.X/PHKL_24268

Symptoms:
	PHKL_24268:
	( SR:8606194190 CR:JAGad63400 )
	I/O hang to the disk and LVM commands hanging.
	PV switching links with bad blocks. This causes
	the system also to hang.

	( SR:8606193747 CR:JAGad62959 )
	System hangs with all 6 lvmkd processes active

	( SR:8606161149 CR:JAGad30465 )
	In rare circumstances,A panic may occur when a Volume Group
	is deactivated and a disk in the volume group is offline or
	momentarily unavailable. The panic is characterized by a
	trap type 15 in lv_resyncpv().
	The panic message is:
	panic: data page fault on lv_resyncpv()

	( SR:8606186358 CR:JAGad55562)
	Like JAGad30465, in rare circumstances a panic may
	occur when a volume group is deactivated and a disk
	in the volume group is offline or momentarily
	unavailable.
	This panic is also characterized by a trap type 15
	in lv_resyncpv(). The difference is that it is less
	likely than JAGad30465 and the panic occurs in a
	different place in lv_resyncpv().

	( SR:8606193747 CR:JAGad64027)
	In rare circumstance, a panic may occur when a
	Volume Group is deactivated and a disk in the volume
	group is offline or momentarily unavailable. This panic
	is characterized by a trap type 15 in lv_resync_pfpv().
	This panic has never been detected in the field, the
	problem was discovered during a review of the code
	in this area.

	( SR:8606186346 CR:JAGad55551)
	In rare circumstances, in a Service Guard Cluster
	configuration, with Oracle Parallel Server accessing
	mirrored logical volumes in a shared volume group,
	disks may go offline and become available again without
	LVM ever detecting that they are working again. The
	result is that the devices will appear to be unavailable
	to LVM even when the disks have become available again
	and could potentially be resynced and used. This
	particular problem can only occur when the volume group
	cluster server and another node simultaneously detect
	that a disk is unavailable and both attempt to resync
	the device. The resyncs will both block and LVM will
	make no forward progress in restoring failed devices
	that are working again.

	PHKL_23127:
	( SR: 8606173900 CR: JAGad43153 )
	After a system crash, mirrored logical volumes might not be
	resynchronized correctly if the Mirror Write Cache is on
	(see lvchange(1M) for details). In some cases, the affected
	volume group cannot be activated and vgchange(1M) issues the
	following error message:

	 vgchange: Couldn't activate volume group "/dev/vgXXX":
	 I/O error while reading the VGDA.

	In other cases, the volume group can be activated, but the
	mirrored logical volumes are not fully resynchronized. This
	is a serious problem because any write in progress when the
	system crashed might have completed on one mirror but not
	on another.

	PHKL_22266:
	( SR: 5003437970 CR: JAGaa40887 )
	( SR: 8606106637 CR: JAGab75913 )
	When multiple physical volumes or paths to physical volumes
	are lost, it takes minutes to recover them. The current
	implementation to test for the failed devices still takes
	approximately 1-2 minutes regardless of the number of paths
	or devices to be recovered.

	( SR: 8606151870 CR: JAGad21209 )
	Degradation of performance in LVM regular I/O throughput.
	This problem is seen more frequently when out of bound
	requests like in Oracle 8.1.7 are sent to LVM.

	( SR: 8606108373 CR: JAGab78776 )
	Reads from a mirrored LV can take a very long time to
	complete if one of the mirrors is unavailable.

	( SR: 8606124005 CR: JAGac39365 )
	During heavy I/O stress system may panic because of a
	spinlock deadlock. The stack trace of the process causing
	the panic look similar to :
	        lv_unblock+0x118
	        lv_complete+0x5c
	        lv_terminate+0x330
	        lv_mwc_done+0x230
	        lv_finished+0x168
	        lv_parwrite_done+0x17c
	        lv_end+0x5f8
	        biodone+0xd8
	        scsi_iodone+0x290
	        scsi_cbfn+0x6a0
	        fcpdev_scsi_comp+0x44
	        fcpbh_scsi_comp+0x75c
	        fcpbh_fcp_cbfn+0x344
	        fcpbh_rcv_completer+0x580
	        fcT1_isr+0xdd8
	        mp_ext_interrupt+0x2a0
	        $RDB_int_patch+0x58
	        invoke_callouts+0x34
	        softclock+0x38
	        sw_service+0x154
	        mp_ext_interrupt+0x2a0
	        $RDB_int_patch+0x58
	        hdl_vpfn+0x10
	        kfree_unused+0x2f4
	        vhand+0x158
	        main+0x438
	        $vstart+0x34
	        $locore+0x74

	( SR: 8606141513 CR: JAGad10876 )
	The commands lvsplit, lvmerge, lvsync, lvdisplay or
	vgdisplay run in parallel will take a long time.

	( SR: 8606161019 CR: JAGad30337 )
	PHKL_20333 introduced a defect where pstat(2) always
	reports the number of open logical volumes (psd_openlv)
	and the number of open volume groups (psd_openvg) as
	zero. As a result, the GBL_NUM_VG metric in GlancePlus
	will remain zero.

	PHKL_22267:
	( SR:8606126246 DTS: JAGac56811 )
	Some process attempting to close an LVM logical volume
	sleep forever and are not killable.

	( SR:8606157504 DTS: JAGad26835 )
	On HP-UX version 10.20, we currently provide and support
	mirrored logical volumes which are part of a shared volume
	group.  This functionality was removed in HP-UX 11.00.
	This patch enables the functionality for HP-UX 11.00.

	PHKL_20419:
	( SR:8606113703 DTS: JAGac07217 )
	If a physical volume in an LVM mirrored disk configuration
	is replaced without deactivating the volume group it belongs
	to, an application might see spurious I/O errors, mirror
	resync failures, or data corruption.  (The I/O errors and
	resync failures may have been observed prior to replacing
	the disk.)

	( SR:8606128444 DTS: JAGac81735 )
	It might not be possible to activate a volume group in
	shared mode if any of its physical volumes are on an Optimus
	Prime Disk Array.

	( SR:8606106798 DTS: JAGab76189 )
	LVM performs a full resync every time a volume group is
	activated.  This symptom began occurring after patch
	PHKL_17045 (or a superseding patch) was installed.  While
	the resync is in progress, system performance may be
	degraded.  In addition, since LVM does not have two valid
	copies of all data during the resync, the system is
	vulnerable to a disk failure until the resync completes.

	( SR:8606106012 CR: JAGab74797 )
	It is possible for an I/O request to be accepted while a
	logical volume is being closed, causing the operating system
	to panic.  Typical actions that close a logical volume are
	unmounting a filesystem and closing a database [or other]
	application which uses raw logical volumes.  The panic would
	likely be a data page fault in an lvm ("lv_") routine.

	( SR: 8606128482 CR: JAGac84447 )
	LVM volume group fails to activate on a Cascade disk array
	with a block size of 2K.

	PHKL_20333:
	( SR: 8606107525 DTS: JAGab77768 )
	LVM IO throughput performance is affected by bottleneck
	caused during initiating the IO request on physical volumes.

	PHKL_20186:
	( SR: 8606106837 DTS: JAGab76286 )
	Patches PHKL_18542, PHKL_19060 and PHKL_19909 have been
	recalled because of a problem that was first introduced in
	PHKL_18542 and that remains in the two later patches.  This
	problem can only occur if the MirroDisk/UX product has been
	installed, and only on a volume group with mirrored logical
	volumes.  Under these circumstances, if a physical volume is
	replaced and its configuration restored using vgcfgrestore
	(1M), all of the data on that disk is marked "stale" so that
	the kernel will copy the correct data from another mirror
	onto the new disk.  However, with PHKL_18542, PHKL_19060 or
	PHKL_19909 on the system, the kernel does not recognize that
	the data on the new disk is stale and fails to copy over it,
	resulting in data corruption.

	PHKL_19909:
	1. Enhancement to LVM to allow striping in shared
	   logical volumes.

	2. When a disk goes down, sparing does not happen
	   automatically.

	PHKL_19060:
	( SR: 8606100412 DTS: JAGab31786 )
	With Optimus Disk Array, LVM incorrectly configures
	different luns with the same LUN id as alternate links.

	PHKL_18542:
	( SR: 4701424465 DTS: JAGab00194 )
	System panic (data page fault) in lv_validate_mwc() while
	trying to activate a volume group after a system reboot.

	( SR: 4701423426 DTS: JAGaa57312 )
	The system hangs when an LVM disk, configured as the swap
	volume, goes off line and system free memory (freemem) is
	low.  The system remains hung even if the LVM disk comes
	back online.

	( SR: 1653288373 DTS:  JAGaa45822 )
	Installing patch PHKL_17042 breaks access to sectioned
	disks.

	PHKL_18483:
	( SR: 5003435081 DTS: JAGab14452 )
	Performance degradation under Informix when massively
	parallel 1K reads are performed.

	PHKL_18189:
	( SR: 1653289132 DTS: JAGaa67952 )
	The system hangs when lvmkd is waiting for the lock obtained
	earlier by an application that performs a vg_create
	operation.  The hang does not happen unless there is a
	powerfailed disk.

	( SR: 4701233957 DTS: JAGab14455 )
	Optimus Disk Arrays (model number A5277A-HP) are not
	recognized as an ACTIVE/PASSIVE device and subsequently are
	not handled properly by the driver.

	PHKL_18134:
	( SR: 1653289553 DTS: JAGaa46305 )
	LVM's autoresync after disk powerfail can leave extents
	stale.

	PHKL_17664:
	( SR: 5003450635 DTS: JAGaa41477 )
	When an application uses sendfile() (i.e. rcp or ftp) and
	accesses files on an LVM volume, the system can panic with a
	Date Page Fault.  The panic stack trace will look similar
	to:
	    panic+0x14  report_trap_or_int_and_panic+0x4c
	    interrupt+0x1ec $ihndlr_rtn+0x0 ip_csuma+0xbc
	    ip_wput_ire+0x168 ip_wput+0x48c putnext+0x50
	    tcp_wput+0x980 tcp_rput+0x1d2c putnext+0x50
	    ip_rput_local+0x15e0 ip_rput+0x174 putnext+0x50 ...

	PHKL_17041:
	( SR: 1653229476 DTS: JAGaa10688 )
	( SR: 1653263434 DTS: JAGaa11044 )
	This patch addresses two problems:
	1. After lvsplit, fsck produces numerous errors
	"unreferenced inode #"
	2. lv_syncx :returning error : 126 when a 2nd powerfailed
	PV returns.

	( SR: 4701399519 DTS: GSY1604424 )
	LVM Disk Bandwidth Feature not present

	PHKL_16563:
	Debug kernel panics due to assertion failure at brelse().

	PHKL_16220:
	If the PVs are down then it will take lot of time to
	to comeout of any LVM related command which involves
	disk access.

	PHKL_15789:
	(SR: 4701396200 DTS: JAGaa12818/DSDe441605/DSDe442781)
	LVM PVLink switches with failed FibreChannel hubs can be
	very slow.  This patch is essential for FibreChannel hubs
	configurations.

	PHKL_15550:
	Added new compile-time optimizations to help eliminate
	excess I-cache pre-fetches, which improves performance.

	PHKL_14689:
	This patch fixes three problems:

	( SR: 1653247486 DTS: JAGaa01357 )
	   For a mirrored LVM root disk containing 2**n extents, if
	   the system is booted in maintenance mode (hpux -lm), it
	   will panic with trap 15 data page fault on the next
	   reboot.

	( SR: 1653239137 DTS: JAGaa01378 )
	   For a root volume group with two disks which are mirror
	   partners, if one disk becomes inaccessible, the system
	   panics on bootup with trap 15 data page fault.

	( SR: 1653248690 DTS: JAGaa01406 )
	   System panics in lv_end() with isr.ior=0.58 data page
	   fault when a bad block is detected on disk.  The console
	   message shows:
	lv_readvgdats: Could not read VGDA 1 header & trailer
	                    from disk H/W path x/x.x.0 (error = 5)
	lv_readvgdats: Could not read VGDA 2 header & trailer
	                    from disk H/W path x/x.x.0 (error = 5)

	PHKL_14252:
	The symptoms for the defects resolved are as follows:

	Alternate link not used for Nike devices in a cluster using
	MC/LockManager

	Cluster may not reconfigure after a node failure in a
	cluster using MC/LockManager.

	The command "vgchange -a s" may not succeed in a cluster
	using MC/LockManager.

	For a cluster using MC/ServiceGuard the command "vgchange -a
	e" may not succeed after a node failure when Fiber Channel
	devices are used.

	PHKL_17045:
	Corruption/stale data in disk based MCR can lead to system
	panic.

	PHKL_17042:
	System panics during boot into LVM maintenance mode after
	LIF LABEL file is removed with a "init died" message.

	PHKL_13346:
	If a boot disk is having i/o problems, it is not unusual
	for the system to fail to boot due to a boot configuration
	failure in either LVM or a mount failure in VFS_MOUNTROOT.
	In these cases, the system generally panics and reboots.

	The symptom to watch out for is having the next boot
	attempt fail with the error:

	IPL error: bad LIF magic.

	This could signify that the previous boot panic dumped
	to the wrong place, corrupting the boot disk (see
	problem statement).

	PHKL_16433:
	Corrupt or negative VGSA timestamp results in
	LVM commands hang.

	PHKL_15956:
	A failed device was not spared even when
	where was a reasonable spare device available for use.
	This would most often occur when other devices
	were being recovered or resynchronized during the
	sparing attempt for the device.

	PHKL_15520:
	io's passing through the LVM layer hang when the pv-link
	is broken (fc-cord is pulled off). The io's are hung even
	if the pv-link is restored.

	PHKL_14861:
	System Panic during lvm sparing

	PHKL_20397:
	( SR: 8606105384 DTS: JAGab73418 )
	In a corner case, usage of rw-lock synchronization can leave
	hung processes that do not respond to SIGKILL.  They are
	sleeping and will never be awakened.  This problem was
	introduced by PHKL_19367.

	PHKL_19367:
	(SR: 5003460279 DTS: JAGab15235)
	Significant performance degradation for an application that
	uses the RW-lock writer-locks as mutual-exclusion lock.
	This is sometimes called the 'thundering herd' problem.

Defect Description:
	PHKL_24268:
	( SR:8606194190 CR:JAGad63400 )
	This problem is due to this inconsistence in post
	processing after pv_curxfs decrement.
	Resolution:
	Whoever finishes (among the outstanding I/Os on this PV)
	has to complete the switch.

	( SR:8606193747 CR:JAGad62959 )
	To schedule an I/O request, LVM needs memory for a data
	structure called a "pbuf". If memory isn't available, LVM
	queues the request. Periodically, LVM tries to reschedule
	these queued requests. The catch is that we rely on LVM
	kernel daemons to do the rescheduling, but there are a
	limited number of these daemons and it's possible for all
	of them to be blocked waiting for I/O complete--I/O that is
	queued and won't complete until someone reschedules it!
	So we can have a deadlock.
	Resolution:
	A new daemon has been introduced, called lvmschedd. The
	daemon's only responsibility is to periodically reschedule
	I/O requests that were queued because no memory was
	available to allocate the necessary data structures.
	By having a dedicated daemon, we avoid deadlock.

	( SR:8606161149 CR:JAGad30465 )
	In a small timing window it is possible that LVM may
	attempt to perform a resync operation using a
	deallocated LVM physical volume data structure, in a
	deactivated volume group, when the volume group is
	deactivated just after LVM starts a resync operation
	on the PV.
	Resolution:
	lv_resyncpv() was redesigned for 11.11 to modify how
	different locks were acquired to prevent access to the
	deallocated data structures.

	( SR:8606186358 CR:JAGad55562)
	Similar to JAGad30465.
	Resolution:
	Similar to JAGad30465.

	( SR:8606193747 CR:JAGad64027)
	Code in lv_resyncpv() locks and unlocks volume group
	data structures which may be accessed in
	lv_resync_pfpv() immediately after they are unlocked.
	Resolution:
	The lv_resync_pfpv() routine was modified
	to hold the appropriate locks while accessing these
	data structures.

	( SR:8606186346 CR:JAGad55551)
	A deadlock can occur on the volume group server node
	between local and remote resync requests. This
	particular problem can only occur when the volume
	group server and another node on the cluster
	simultaneously detect that a disk is unavailable
	and both attempt to resync the device.
	Resolution:
	lv_resyncpv() was modified to avoid this deadlock as well.

	PHKL_23127:
	( SR: 8606173900 CR: JAGad43153 )
	On every disk, there are two MWC caches, each with its own
	timestamp. LVM should pick the latest, but instead, it
	always picks the first whether it's the latest or not. After
	a clean deactivation, there is no problem. But after a
	system crash, this is potentially very serious. The MWC
	cache records which logical track groups (LTGs) LVM was in
	the middle of writing. These LTGs are potentially out of
	sync: for each mirror, LVM doesn't know whether it had
	finished writing the data, was in the middle of writing it,
	or hadn't even started. As a result, the mirrors might not
	actually be mirrors. That is, they might not have the same
	data, so LVM needs to resync them. However, if LVM uses the
	wrong MWC cache (50% chance), it might neglect to resync
	some LTG that needed to be resynchronized, leading to silent
	data corruption. Now two reads in a row could go to
	different mirrors and return different data.

	The potential for silent data corruption is a long-standing
	problem. However, the error:

	 vgchange: Couldn't activate volume group "/dev/vgXXX":
	 I/O error while reading the VGDA.

	only occurs with the previous LVM patch, PHKL_22266.
	Although this error was supposed to protect the system from
	silent data corruption, it can occur even if the volume
	group was cleanly deactivated and even if there are no
	mirrored logical volumes. The most common scenario reported
	happens when a volume group is deactivated after splitting a
	mirrored logical volume (see lvsplit(1M) for details).

	Resolution:
	The timestamp comparisons have been corrected so that LVM
	will always select the latest MWC cache.

	PHKL_22266:
	( SR: 5003437970 CR: JAGaa40887 )
	( SR: 8606106637 CR: JAGab75913 )
	The problem was that some of the LVM device recovery was
	still a serial process.

	While working on this defect fix, a latent defect was found
	that can cause a LVM deadlock (hang) to occur. The problem
	was that an easily encountered deadlock condition was
	introduced while attempting to correct another relatively
	rare deadlock. The problem can be easily reproduced by
	running LVM commands which operate on existing logical
	volumes such as lvextend(1M), lvsplit(1M) or lvmerge(1M)
	along with commands that query logical volumes, such as
	glance(1).  The deadlock occurs roughly 10% of the time,
	but when it does happen there are severe consequences.
	The deadlock makes it impossible to complete the operations
	or to run any other LVM commands, without rebooting the
	system.

	Resolution:
	The LVM device recovery code was modified to cause all tests
	of devices and paths to be conducted in parallel.  Devices
	which are available are immediately brought online again,
	irrespective of other failed devices or paths.  The changes
	in this patch assure that devices recover within the time it
	takes to test the device/path and to update its data
	structures.  The volume group data structures and LVM
	operations that require them --LVM commands and opens and
	closes of logical volumes should be held off no more than
	35 seconds.

	The changes in this patch also reduce the time required to
	perform a switch from one PVLink to another when the active
	link fails. Previously, LVM would complete the switch within
	twice the I/O timeout plus 15 seconds (see pvchange(1M) for
	details about the I/O timeout). The default I/O timeout is
	30 seconds, so a PVLinks switch could take up to 75 seconds
	((2 * 30) + 15). With this patch, the time needed to switch
	has been reduced to just one I/O timeout plus 15 seconds (by
	default, a total of 45 seconds). Please note, this assumes
	that PHKL_19776 has been installed; without this SCSI patch,
	a PVLinks switch can take significantly longer. If you are
	using PVLinks, HP strongly recommends installing PHKL_19776
	or a later patch that supersedes it.

	The case that caused deadlock was resolved by reordering the
	volume group lock and other LVM locks and adding a new
	volume group data lock to allow device recovery operations
	to occur simultaneously with command operations.  Thus
	correcting the old and newly introduced deadlock defects.

	( SR: 8606151870 CR: JAGad21209 )
	When out of bound I/Os, that is the I/Os which span multiple
	Logical Track Groups(LTG), LVM is splitting the request
	into sub-requests per LTG and regroups them when they are
	done.  During the splitting of the request, it uses
	bufheader from a reserved pool of size 20. This is a very
	small resource and introduces heavy contention for it;
	Hence, the through put of the I/O degrades.

	Resolution:
	1.  The static reserved pool, which causes the contention,
	is not necessary. Instead, dynamically getting the buf
	header by mallocing removes the resource contention.

	2.  Removed the usage of one global lock to update the I/O
	requests buf structure which had a high contention and
	introduced a hashed pool of spinlocks for synchronization to
	reduce the contention.

	( SR: 8606108373 CR: JAGab78776 )
	When reading from a mirrored logical volume, LVM might try a
	disk that is known to be off line before it tries another
	disk which is still available.  The read is delayed while
	the first I/O times out.

	Resolution:
	In selecting the best mirror to read from, give preference
	to disks that are still available over disks that are known
	to be off line.

	( SR: 8606124005 CR: JAGac39365 )
	When an I/O completes, all the requests in the LVM work
	queues are analyzed to see if any requests can be unblocked,
	apart from unblocking the requests that were blocked because
	of the I/O that completed. Thus, we are trying to unblock
	all possible I/Os which can take a lot of time depending on
	the length of the work queues, since we are traversing
	through the list repeatedly causing heavy contention on the
	LV spinlock used to protect the list.

	Resolution:
	Instead of attempting to unblock all the requests, we now
	unblock only the requests that can be unblocked by
	completion of this I/O request.  Hence we are now avoiding
	multiple traversing through the lengthy queue and also
	reducing the contention on the lock protecting the queue.

	( SR: 8606141513 CR: JAGad10876 )
	During lvsplit or lvmerge VG lock is held in exclusive
	mode for consistency and these operations can take a very
	long time since it involves resyncing of logical volume(s).
	So commands like vgdisplay and lvdisplay which require
	the same lock in read mode have to wait for a very long
	time to acquire the lock, causing an unprecedented delay.

	Resolution:
	Since no modification to data structures are done vglock
	can be downgraded from exclusive access to read mode
	during resyncing of logical volumes. Hence other commands
	which require the vg lock in read mode will not block.

	( SR: 8606161019 CR: JAGad30337 )
	PHKL_20333 introduced a defect where pstat(2) always
	reports the number of open logical volumes (psd_openlv)
	and the number of open volume groups (psd_openvg) as
	zero.

	Resolution:
	pstat(2) now reports correct values for psd_openlv and
	psd_openvg.

	PHKL_22267:
	( SR:8606126246 DTS: JAGac56811 )
	During closing of a logical volume, lv_cache_clean() is
	called to cleanup all the cache entries for the lvol to be
	closed.

	There is a race condition in lv_cache_clean() which might
	prevent the cache entries for this lvol from being
	scrubbed.

	Moreover, a SUCCESS completion status will be incorrectly
	reported from lv_cache_clean(). Later, during the closing
	of this logical volume, the process which initiated the
	close will wait until all entries in the cache are
	scrubbed.

	Given that lv_cache_clean() did not scrub all cache
	entries for the lvol being closed, and given that those
	entries will never be scrubbed, the process initiating the
	close of the lvol will wait forever.

	Resolution:
	Closed the window in lv_cache_clean() to call
	lv_cache_scrub() by holding the appropriate spinlock. Also,
	in procedure lv_wait_mwc_clean(), if any of the requests
	for the lvol on which we are waiting are still in the cache,
	it will be synced.

	( SR:8606157504 DTS: JAGad26835 )
	A check was added to HP-UX 11.00 to reject activating any
	shared volume groups with mirrored logical volumes in it.
	This patch takes out that check and allows users to have
	mirrored logical volumes on shared volume groups.

	Resolution:
	This patch reenables the SLVM/LVM mirrored logical volumes
	on a shared volume group feature.

	Specifically, this patch enables SLVM/LVM to support
	logical volumes with mirrors on a shared volume group which
	is part of a cluster consisting of exactly 2 nodes.  This
	feature is not yet supported on clusters with more than 2
	nodes.

	PHKL_20419:
	( SR:8606113703 DTS: JAGac07217 )
	When a physical volume is replaced without deactivating the
	volume group it belongs to, the operating system does not
	read the bad block directory from the disk, but continues
	using the old one. This can cause spurious I/O errors or
	mirror resync failures if bad block relocation is disabled,
	or data corruption if bad block relocation is enabled.

	Resolution:
	Whenever a physical volume is replaced, the bad block
	directory from the new physical volume is read.

	( SR:8606128444 DTS: JAGac81735 )
	It might not be possible to activate a volume group in
	shared mode if any of its physical volumes are on an
	Optimus Prime Disk Array, because the serial numbers for
	these device are truncated when they're passed between
	nodes in a ServiceGuard cluster.

	Resolution:
	Do not truncate Optimus Prime serial numbers.

	( SR:8606106798 DTS: JAGab76189 )
	When a volume group is activated, LVM validates a data
	structure on each physical volume called the Mirror
	Consistency Record (MCR). If the MCR is not valid, LVM
	performs a full resync of the physical volume and should
	rewrite the MCR. But with PHKL_17045 and superseding
	patches, LVM does not rewrite the MCR.  Instead, if the
	MCR is invalid, LVM performs a full resync every time the
	volume group is activated, rather than just the first time.
	While the resync is in progress, system performance may be
	degraded.  In addition, since LVM does not have two valid
	copies of all data during the resync, the system is
	vulnerable to a disk failure until the resync completes.
	(This problem does not affect performance or availability
	of mirrored logical volumes after the resync has
	completed.)

	Resolution:
	If the MCR is not valid, rewrite it after performing a
	full resync. Also, add more validity checks.

	( SR:8606106012 CR: JAGab74797 )
	Because of a race condition in LVM, it is possible for an
	I/O request to be accepted when the logical volume is being
	closed. Eventually, a data structure that has already been
	freed (as a result of closing the logical volume) is
	referenced, causing the operating system to panic.

	Resolution:
	Eliminate the race condition so that I/O cannot proceed
	after a logical volume has been closed.

	( SR: 8606128482 CR: JAGac84447 )
	Whenever a volume group is activated, LVM attempts to read
	and compare the timestamps placed at the beginning and end
	of the metadata stored on each of the disks in the volume
	group.  On disk arrays/drives with a block size greater than
	1K, LVM miscalculates the location of these timestamps.  As
	a consequence it fails to find matching timestamps and
	reports the error back to the user.

	Resolution:
	Changed the calculation to take into consideration block
	sizes greater than 1K.

	PHKL_20333:
	( SR: 8606107525 DTS: JAGab77768 )
	LVM IO performance is affected with throttling the
	throughput to 700 MB/sec because of the following reasons :
	 - During scheduling of LVM I/O requests, we create physical
	   buffer headers (pbufs) for initiating I/O on physical
	   volumes.
	 - Currently, these pbufs are allocated from a static
	   reserved pool which is protected by a spin lock.
	Since this pool is heavily used it is hampering the
	performance of the I/O due to synchronization.  Also the
	spin lock used to protect the reserved pool is also used to
	protect the Scatter/Gather list of pbufs of a logical
	request, adding to the bottleneck.

	Resolution :
	Instead of using a statically allocated reserved pool
	we are dynamically allocating the memory for pbufs
	there by eleminating the need for spinlock.
	For scatter/gather list of pbufs for a logical request
	we are using a different hashed spin lock, there by
	eleminating the bottleneck.

	PHKL_20186:
	( SR: 8606106837 DTS: JAGab76286 )
	In function lv_readdats the parameter vghdr_flags was
	declared as int* instead of ushort_t*.  This caused a shift
	of 16 bits for the vghdr_flags and all the flag bits were
	lost.
	Resolution:
	Parameter vghdr_flags is changed to 'ushort *' from 'int *'

	PHKL_19909:
	1. Currently striping in shared logical volume is disabled
	though the LVM code is written to support it.

	Resolution:
	Removed the check for shared logical volume, to allow
	striping in shared logical volumes.

	2. Sparing is not triggered if a test I/O to a device
	fails during power fail test because currently we are
	not calling lv_io_error_processing() routine if a
	test I/O fails.

	Resolution:
	Added lv_io_error_processing() in lv_test_a_link(),
	to initiate sparing if a disk goes down.

	PHKL_19060:
	( SR: 8606100412 DTS: JAGab31786 )
	Generally, LVM treats multiple LUNs with the same LUN id as
	alternate links to the same disk.  With the Optimus disk
	array this assumption is incorrect.  Two different disks may
	have the same LUN id.  In order to uniquely identify a disk
	in an Optimus array, LVM needs both its LUN id and its
	target id.

	Resolution:
	Added a new macro TGT_AND_LUN_FROM_DEV_T to get the target
	id and LUN id for the device.

	PHKL_18542:
	( SR: 4701424465 DTS: JAGab00194 )
	The Mirror Write Consistency (MWC) cache was not cleaned
	correctly when more than one call to clean it occured and it
	was in flight (currently being written to disk,
	synchronizing in-core and on-disk copies).  Only the last
	call to clean was serviced correctly.  When the cache is not
	cleaned properly, invalid entries remain in it (in this
	particular case, entries referring to a logical volume that
	no longer exists).

	Resolution:
	First, the way the MWC cache gets cleaned has been corrected
	so that all calls to clean it are serviced, even when it's
	currently in flight.

	Second, when the MWC cache is read from the disk and
	validated, there are more checks to make sure the LV number
	in each entry is valid before using it.  This resolves a
	defect introduced by PHKL_17045.

	( SR: 4701423426 DTS: JAGaa57312 )
	When the swap volume goes off line, the powerfail check
	routine attempts to allocate a fairly large amount of kernel
	memory.  Because memory is low and the swap device is off
	line (so memory can not be freed up), the system hangs.

	Resolution:
	Powerfail routine avoids allocating memory.

	( SR: 1653288373 DTS:  JAGaa45822 )
	The fix in patch PHKL_17042 introduced an error condition
	for sectioned disks.  The fix returns dummy LIF information
	when there is no LIF information or when the LIF information
	is corrupted and the rootconf information on the disk is
	correct.  On a sectioned disk, the expected return value is
	NULL.  The dummy LIF information is treated as valid, which
	prevents the system from looking into the hard partition and
	from accessing the sectioned disk.

	Resolution:
	The dummy LIF label is now returned only when there is none,
	the rootconf information is valid, and the caller is LVM.
	If the caller is CPD (used for sectioned disks), a NULL
	value is returned.

	PHKL_18483:
	( SR: 5003435081 DTS: JAGab14452 )
	Informix issues massive ammounts of 1K reads in parallel.
	With 8K page structure with I/Os serialized within the
	page performance suffers.

	PHKL_18189:
	( SR: 1653289132 DTS: JAGaa67952 )
	If the holder of the vg_lock is waiting for I/O to finish,
	and if the I/O can't finish until we switch to another link,
	then we get into a deadlock.

	Resolution:
	To resolve the deadlock, the code now obtains the lock
	temporarily, in order to switch to the alternate link, then
	returns the lock to the original holder to finish the I/O.

	( SR: 4701233957 DTS: JAGab14455 )
	We need to recognize Optimus Array as an ACTIVE/PASSIVE
	device.

	Resolution:
	Added code to recognize the Optimus Array as an
	ACTIVE/PASSIVE device.

	PHKL_18134:
	( SR: 1653289553 DTS: JAGaa46305 )
	lv_syncx() may return with stale extents without
	actually syncing all the extents.

	Resolution:
	Added additional check to see if all the extents are synced;
	otherwise return error. lv_syncx() will return SUCCESS only
	when the syncing is completed.  Made changes in
	lv_resyncpv() to preserve error value.

	PHKL_17664:
	( SR: 5003450635 DTS: JAGaa41477 )
	The panic occurs in ip_csuma() due to a missing virtual
	address translation on a sendfile() physical buffer.  The
	b_sendcnt field in the logical buffer is set to prevent the
	disksort routines from merging the logical buffers.
	However, LVM fails to propagate the b_sendcnt field to the
	physical buffers, allowing the disksort routines to merge
	the physical buffers and remap them to different virtual
	addresses.

	Resolution:
	LVM now propagates the b_sendcnt field to the physical
	buffers.

	PHKL_17041:
	( SR: 1653229476 DTS: JAGaa10688 )
	( SR: 1653263434 DTS: JAGaa11044 )
	1.  Several "unreferred file inode#" errors appear when
	splitting a mounted logical volume and performing fsck.
	The fix is to freeze and then sync the file system if the
	logical volume is a mounted filesystem. This is done in a
	generic fashion independent of the file system type. The
	VFS layer routines freeze_and_sync_fs_dev(lv_dev)/
	unfreeze_fs_dev(lv_dev) is called for this purpose.
	2. When two PVs powerfail and only one returns, the mirror
	copy on the returned PV is not sync'd and it keeps getting
	the following errors in syslog/msgbuf:
	lv_syncx :returning error : 126
	The mirror copy syncs and message stops when both the PVs
	return from the powerfail.
	This is fixed by allowing to skip extents when all the
	extent mirrors to be resynced are not available.  If there
	are any stale extents after a resync operation, the resync
	is reported as failed.

	( SR: 4701399519 DTS: GSY1604424 )
	This enhancement will allow PRM users using the A.01.05
	version of PRM to report and regulate the amount of
	disk bandwidth user groups get.  All changes are
	visible only through PRM.

	PHKL_16563:
	Debug kernel panics at brelse() in lv_checkpvpath()
	because we are clearing all the preset flags of the
	buffer which we obtained from geteblk() and sending the
	buffer to brelse() to release it. At brelse() we check for
	B_BCACHE flag in buffer and since it is cleared the assert
	will fail.

	PHKL_16220:
	Changed the 'if' condition in lv_checkpvpath() to check
	the latest status of the PV to know whether it is up or
	down and depending on that we set the flag. This leads to
	preventing access to the disk later from LVM commands when
	the disk is down helping in saving the timeout period the
	command takes to come out of the disk access operation.

	PHKL_15789:
	(SR: 4701396200 DTS: JAGaa12818/DSDe441605/DSDe442781)
	LVM recovers PVLinks serially.  In situations where 100's
	of links can fail simultaneously (eg.  FibreChannel hubs)
	the time to switch all the links can be hours.
	The modifications allow LVM to pre-test all the links
	to the devices in parallel prior to performing the normal
	PV test.

	PHKL_15550:
	I-cache pre-fetching beyond the end of procedures creates
	unnecessary loads on the bus.  Adding new compile-time
	optimizations improves performance in this area.

	PHKL_14689:
	This patch fixes three defects:

	( SR: 1653247486 DTS: JAGaa01357 )
	After a maintenance mode reboot, if the root LV is mirrored,
	we make the copy of root on the boot device the only fresh
	copy. Before updating the VGSA with the new stale/fresh
	information, a structure used to pass physical extent info
	to the configuration is set up. In the case of a LV
	containing 2**n extents, memory allocated for the array of
	structures is exactly enough for the extents. The terminator
	of the array was written beyond the allocated memory.
	This corrupts the memory at the next address and causes
	system to panic when the next piece of memory is accessed.

	( SR: 1653239137 DTS: JAGaa01378 )
	When the root VG has a mirror PV missing with a lower PV
	index number than the boot disc, the PV's current physical
	link field is zero. The code attempts to dereference this
	null pointer in the bootup path and traps.

	( SR: 1653248690 DTS: JAGaa01378 )
	The problem is caused by a disc with bad blocks in the
	LVM structure area. This results the logical volume field
	in the physical request buffer to be zero. Deferencing this
	null pointer causes data page fault.

	PHKL_14252:
	The alternate link was not used for a Nike device in an
	MC/LockManager environment.  If the primary link failed then
	IOs were not switched to the alternate link.

	Use of time stamps for a volume group that suffered a device
	powerfail on a client node would sometimes lead to the
	cluster not reforming after a server node failure in an
	MC/LockManager cluster.

	In an MC/ServiceGuard environment, after a node crashed,
	activating the volume group would some times fail if the
	volume group was composed of fiber channel devices.
	Disabling of device resets on Fiber Channel devices allows
	for node failover in an MC/ServiceGuard environment.

	PHKL_17045:
	If the disk based MCR is corrupted it leads to a system
	panic. To avoid this we are making a validation on each MWC
	record on the disk to see if it is valid.  If any MWC
	record is bad on the disk then we mark all the extents on
	the disk as stale and do a full re-sync.  We are validating
	each MCR by checking for the validity of the logical volume
	number and validity of the logical extent.

	PHKL_17042:
	System panics with a "init died" message, during boot into
	LVM maintenance mode after LIF LABEL file is
	removed. Before this, the system displays:
	init died with return value 256
	Please check for init's execute permision
	init's location and root partitions location
	Problem can be reproduced by installing the OS, creating a
	separate file system for /stand, removing the LIF label
	through lifrm and rebooting in LVM maintenance mode.

	PHKL_13346:
	If i/o config succeeds for a given boot such that rootdev
	is not NODEV when LVM boot configuration is entered, and if
	the two opens of the rootdev to read lvmrec and BDRA then
	fail, and if the swapconf open of rootdev then succeeds, and
	if dumpconf open of rootdev then succeeds, the subsequent
	VFS_MOUNTROOT panic will corrupt the boot disk since swap
	and dump will get configured whole disk (i.e. corrupts
	the LVM boot disk).

	This has only been seen when boot disks are set to a low
	priority on a shared bus being saturated with i/o by other
	nodes on the bus (not a supported configuration).

	PHKL_16433:
	Corrupt or negative VGSA timestamp results in LVM commands
	hang. Because we need to always get strictly
	monotonically increasing latest timestamp and in this case
	we get a lesser value in timevaladd() because of adjusting
	of tv_usec by barrowing from tv_sec which results in a
	lesser timevalue hence system hangs. Avoided this by doing
	timevaladd() manually by incrimenting tv_sec by 1 and
	initialising tv_usec to 0 if tv_usec is negative.

	PHKL_15956:
	When a lock could not be obtained for a key data structure,
	the sparing code assumed that no spares were available.
	Instead the code should have later attempted to obtain the
	lock and retry the sparing operation again.

	PHKL_15520:
	io's passing through LVM layer in the process of being
	sent to the disk hang when the pv-link is broken by
	pulling the fc-cord. The io's wait on the wait queue as
	the primary lvm link is broken and also the disk is not
	accessible. But the lvm code was incorrectly setting
	the disk also not-accessible even after the link-switch,
	so after the alternate link is restored, the disk is still
	not accessible to those io's.

	PHKL_14861:

	Panic in lv_pv_attr_okay_for_sparing()
	The Panic was due to de-referencing an invalid (null)
	pv_lvmrec pointer. When a volume group is activated while
	a physical volume is down, it's pv_lvmrec pointer
	is set to null. Later when the lvm try to spare the down
	physical volume it accesses the pv_lvmrec to check if
	it is a boot disk. The fix (consulting with Jacques Hebert)
	is to remove the check since there is really now way to
	know if the down disk is boot or not and the fact the
	the boot restrictions are enforced at the time of creation.
	Also, fixed about five other places by checking if the
	pv_lvmrec is valid before accessed.

	PHKL_20397:
	( SR: 8606105384 DTS: JAGab73418 )
	In the case of a writer holding the lock and a reader
	requesting an upgrade, a later write lock attempt will
	cause an unwanted decrement to the write waiters count
	which eventually results in an illegal negative value.

	Resolution:
	Two lines of code that decrement the counter were removed.

	PHKL_19367:
	(SR: 5003460279 DTS: JAGab15235)
	Significant application performance degradation may be
	noticed by some customers when moving to a new release on a
	V2250.  The application uses many RW_lock writer-locks as
	mutual- exclusion locks.  When the lock-holder released the
	writer lock, ALL procs sleeping on that lock were awakened.
	This sleep-wakeup action causes the 'thundering herd'
	symptom of procs trying to grab the lock; only one can get
	it.  This functionality was changed to count the sleepers
	and to use sleep_one and wakeup_one thus reducing the wakeup
	cost.
	Resolution:
	The sleep-wakeup mechanism for the writer lock has been
	amended and shows significant performance improvement.

SR:
	1653229476 1653239137 1653245571 1653247486 1653248690
	1653254904 1653257279 1653258681 1653259408 1653263434
	1653264887 1653271148 1653288373 1653289132 1653289553
	4701233957 4701374942 4701374959 4701374967 4701375113
	4701375485 4701375915 4701394874 4701396200 4701399519
	4701402636 4701402818 4701423426 4701424465 5003410977
	5003435081 5003437970 5003450635 5003460279 8606100412
	8606105190 8606105285 8606105384 8606106012 8606106637
	8606106798 8606106837 8606107525 8606108373 8606113703
	8606124005 8606126246 8606128444 8606128482 8606141513
	8606151870 8606157504 8606161149 8606186358 8606193747
	8606186346 8606194190 8606194821 8606173900

Patch Files:
	
	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/liblvm.a(lv_block.o)
	/usr/conf/lib/liblvm.a(lv_cluster_lock.o)
	/usr/conf/lib/liblvm.a(lv_defect.o)
	/usr/conf/lib/liblvm.a(lv_hp.o)
	/usr/conf/lib/liblvm.a(lv_ioctls.o)
	/usr/conf/lib/liblvm.a(lv_lvsubr.o)
	/usr/conf/lib/liblvm.a(lv_malloc.o)
	/usr/conf/lib/liblvm.a(lv_mircons.o)
	/usr/conf/lib/liblvm.a(lv_pbuf.o)
	/usr/conf/lib/liblvm.a(lv_phys.o)
	/usr/conf/lib/liblvm.a(lv_schedule.o)
	/usr/conf/lib/liblvm.a(lv_spare.o)
	/usr/conf/lib/liblvm.a(lv_strategy.o)
	/usr/conf/lib/liblvm.a(lv_subr.o)
	/usr/conf/lib/liblvm.a(lv_syscalls.o)
	/usr/conf/lib/liblvm.a(lv_vgda.o)
	/usr/conf/lib/liblvm.a(lv_vgsa.o)
	/usr/conf/lib/liblvm.a(sh_vgsa.o)
	/usr/conf/lib/liblvm.a(slvm_comm.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/libhp-ux.a(dumpconf.o)
	/usr/conf/lib/libhp-ux.a(lv_config.o)
	/usr/conf/lib/libhp-ux.a(lv_lvm.o)
	/usr/conf/lib/libhp-ux.a(rw_lock.o)

	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/liblvm.a(lv_block.o)
	/usr/conf/lib/liblvm.a(lv_cluster_lock.o)
	/usr/conf/lib/liblvm.a(lv_defect.o)
	/usr/conf/lib/liblvm.a(lv_hp.o)
	/usr/conf/lib/liblvm.a(lv_ioctls.o)
	/usr/conf/lib/liblvm.a(lv_lvsubr.o)
	/usr/conf/lib/liblvm.a(lv_malloc.o)
	/usr/conf/lib/liblvm.a(lv_mircons.o)
	/usr/conf/lib/liblvm.a(lv_pbuf.o)
	/usr/conf/lib/liblvm.a(lv_phys.o)
	/usr/conf/lib/liblvm.a(lv_schedule.o)
	/usr/conf/lib/liblvm.a(lv_spare.o)
	/usr/conf/lib/liblvm.a(lv_strategy.o)
	/usr/conf/lib/liblvm.a(lv_subr.o)
	/usr/conf/lib/liblvm.a(lv_syscalls.o)
	/usr/conf/lib/liblvm.a(lv_vgda.o)
	/usr/conf/lib/liblvm.a(lv_vgsa.o)
	/usr/conf/lib/liblvm.a(sh_vgsa.o)
	/usr/conf/lib/liblvm.a(slvm_comm.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/libhp-ux.a(dumpconf.o)
	/usr/conf/lib/libhp-ux.a(lv_config.o)
	/usr/conf/lib/libhp-ux.a(lv_lvm.o)
	/usr/conf/lib/libhp-ux.a(rw_lock.o)

what(1) Output:
	
	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/liblvm.a(lv_block.o):
		lv_block.c $Date: 2000/10/27 16:51:29 $Revision: r11
			ros/7 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_cluster_lock.o):
		lv_cluster_lock.c $Date: 2000/10/27 16:51:29 $Revisi
			on: r11ros/5 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_defect.o):
		lv_defect.c $Date: 2001/05/29 13:28:36 $Revision: r1
			1ros/6 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_hp.o):
		lv_hp.c $Date: 2001/05/29 13:32:12 $Revision: r11ros
			/22 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_ioctls.o):
		lv_ioctls.c $Date: 2000/10/27 16:51:29 $Revision: r1
			1ros/14 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_lvsubr.o):
		lv_lvsubr.c $Date: 2001/05/29 13:35:18 $Revision: r1
			1ros/13 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_malloc.o):
		lv_malloc.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/2 PATCH_11.00 (PHKL_20333)
	/usr/conf/lib/liblvm.a(lv_mircons.o):
		lv_mircons.c $Date: 2001/01/25 11:57:36 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_23127)
	/usr/conf/lib/liblvm.a(lv_pbuf.o):
		lv_pbuf.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/5 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_phys.o):
		lv_phys.c $Date: 2001/05/29 13:36:48 $Revision: r11r
			os/11 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_schedule.o):
		lv_schedule.c $Date: 2001/05/29 13:37:10 $Revision: 
			r11ros/10 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_spare.o):
		lv_spare.c $Date: 2000/10/27 16:51:29 $Revision: r11
			ros/8 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_strategy.o):
		lv_strategy.c $Date: 2000/10/27 16:51:29 $Revision: 
			r11ros/9 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_subr.o):
		lv_subr.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_syscalls.o):
		lv_syscalls.c $Date: 2000/10/27 16:51:29 $Revision: 
			r11ros/11 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_vgda.o):
		lv_vgda.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_vgsa.o):
		lv_vgsa.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(sh_vgsa.o):
		sh_vgsa.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/11 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(slvm_comm.o):
		slvm_comm.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/7 PATCH_11.00 (PHKL_20333)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/libhp-ux.a(lv_lvm.o):
		lv_lvm.c $Date: 1998/06/24 16:28:30 $Revision: r11ro
			s/4 PATCH_11.00 (PHKL_15550)
	/usr/conf/lib/libhp-ux.a(lv_config.o):
		lv_config.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/5 PATCH_11.00 (PHKL_20333)
	/usr/conf/lib/libhp-ux.a(dumpconf.o):
		dumpconf.c $Date: 1998/12/15 07:46:00 $Revision: r11
			ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL_17042
			)
	/usr/conf/lib/libhp-ux.a(rw_lock.o):
		rw_lock.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/5 PATCH_11.00 (PHKL_22266)

	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/liblvm.a(lv_block.o):
		lv_block.c $Date: 2000/10/27 16:51:29 $Revision: r11
			ros/7 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_cluster_lock.o):
		lv_cluster_lock.c $Date: 2000/10/27 16:51:29 $Revisi
			on: r11ros/5 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_defect.o):
		lv_defect.c $Date: 2001/05/29 13:28:36 $Revision: r1
			1ros/6 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_hp.o):
		lv_hp.c $Date: 2001/05/29 13:32:12 $Revision: r11ros
			/22 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_ioctls.o):
		lv_ioctls.c $Date: 2000/10/27 16:51:29 $Revision: r1
			1ros/14 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_lvsubr.o):
		lv_lvsubr.c $Date: 2001/05/29 13:35:18 $Revision: r1
			1ros/13 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_malloc.o):
		lv_malloc.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/2 PATCH_11.00 (PHKL_20333)
	/usr/conf/lib/liblvm.a(lv_mircons.o):
		lv_mircons.c $Date: 2001/01/25 11:57:36 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_23127)
	/usr/conf/lib/liblvm.a(lv_pbuf.o):
		lv_pbuf.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/5 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_phys.o):
		lv_phys.c $Date: 2001/05/29 13:36:48 $Revision: r11r
			os/11 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_schedule.o):
		lv_schedule.c $Date: 2001/05/29 13:37:10 $Revision: 
			r11ros/10 PATCH_11.00 (PHKL_24268)
	/usr/conf/lib/liblvm.a(lv_spare.o):
		lv_spare.c $Date: 2000/10/27 16:51:29 $Revision: r11
			ros/8 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_strategy.o):
		lv_strategy.c $Date: 2000/10/27 16:51:29 $Revision: 
			r11ros/9 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_subr.o):
		lv_subr.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_syscalls.o):
		lv_syscalls.c $Date: 2000/10/27 16:51:29 $Revision: 
			r11ros/11 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_vgda.o):
		lv_vgda.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(lv_vgsa.o):
		lv_vgsa.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(sh_vgsa.o):
		sh_vgsa.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/11 PATCH_11.00 (PHKL_22266)
	/usr/conf/lib/liblvm.a(slvm_comm.o):
		slvm_comm.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/7 PATCH_11.00 (PHKL_20333)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/libhp-ux.a(lv_lvm.o):
		lv_lvm.c $Date: 1998/06/24 16:28:30 $Revision: r11ro
			s/4 PATCH_11.00 (PHKL_15550)
	/usr/conf/lib/libhp-ux.a(lv_config.o):
		lv_config.c $Date: 1999/10/27 11:49:40 $Revision: r1
			1ros/5 PATCH_11.00 (PHKL_20333)
	/usr/conf/lib/libhp-ux.a(dumpconf.o):
		dumpconf.c $Date: 1998/12/15 07:46:00 $Revision: r11
			ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL_17042
			)
	/usr/conf/lib/libhp-ux.a(rw_lock.o):
		rw_lock.c $Date: 2000/10/27 16:51:29 $Revision: r11r
			os/5 PATCH_11.00 (PHKL_22266)

cksum(1) Output:
	
	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	970758767 2756 /usr/conf/lib/liblvm.a(lv_block.o)
	2227254649 11904 /usr/conf/lib/liblvm.a(lv_cluster_lock.o)
	524875856 14324 /usr/conf/lib/liblvm.a(lv_defect.o)
	1451394110 100132 /usr/conf/lib/liblvm.a(lv_hp.o)
	1845134897 37684 /usr/conf/lib/liblvm.a(lv_ioctls.o)
	2984355735 41904 /usr/conf/lib/liblvm.a(lv_lvsubr.o)
	1178462308 2648 /usr/conf/lib/liblvm.a(lv_malloc.o)
	3093947490 18044 /usr/conf/lib/liblvm.a(lv_mircons.o)
	1945722684 2660 /usr/conf/lib/liblvm.a(lv_pbuf.o)
	3901953632 8252 /usr/conf/lib/liblvm.a(lv_phys.o)
	2998095158 34624 /usr/conf/lib/liblvm.a(lv_schedule.o)
	1390109986 53184 /usr/conf/lib/liblvm.a(lv_spare.o)
	1378896995 8132 /usr/conf/lib/liblvm.a(lv_strategy.o)
	4145743567 11216 /usr/conf/lib/liblvm.a(lv_subr.o)
	2626125543 15524 /usr/conf/lib/liblvm.a(lv_syscalls.o)
	788608253 8948 /usr/conf/lib/liblvm.a(lv_vgda.o)
	2456651972 13560 /usr/conf/lib/liblvm.a(lv_vgsa.o)
	1803344566 48540 /usr/conf/lib/liblvm.a(sh_vgsa.o)
	2636936538 35556 /usr/conf/lib/liblvm.a(slvm_comm.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	2028956042 216688 /usr/conf/lib/libhp-ux.a(lv_lvm.o)
	2306298751 28988 /usr/conf/lib/libhp-ux.a(lv_config.o)
	652388696 13636 /usr/conf/lib/libhp-ux.a(dumpconf.o)
	4032264185 7800 /usr/conf/lib/libhp-ux.a(rw_lock.o)

	LVM.LVM-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	1380544653 5248 /usr/conf/lib/liblvm.a(lv_block.o)
	2674850901 27200 /usr/conf/lib/liblvm.a(lv_cluster_lock.o)
	3817967140 27944 /usr/conf/lib/liblvm.a(lv_defect.o)
	3307731300 247616 /usr/conf/lib/liblvm.a(lv_hp.o)
	1179016473 82680 /usr/conf/lib/liblvm.a(lv_ioctls.o)
	1636179985 86992 /usr/conf/lib/liblvm.a(lv_lvsubr.o)
	1799921449 5024 /usr/conf/lib/liblvm.a(lv_malloc.o)
	233545878 37616 /usr/conf/lib/liblvm.a(lv_mircons.o)
	34742837 5520 /usr/conf/lib/liblvm.a(lv_pbuf.o)
	201036805 15320 /usr/conf/lib/liblvm.a(lv_phys.o)
	1968089571 71936 /usr/conf/lib/liblvm.a(lv_schedule.o)
	1210966354 122136 /usr/conf/lib/liblvm.a(lv_spare.o)
	3274875300 16832 /usr/conf/lib/liblvm.a(lv_strategy.o)
	3190545850 26040 /usr/conf/lib/liblvm.a(lv_subr.o)
	2163767878 28144 /usr/conf/lib/liblvm.a(lv_syscalls.o)
	2916295477 16352 /usr/conf/lib/liblvm.a(lv_vgda.o)
	722171592 26720 /usr/conf/lib/liblvm.a(lv_vgsa.o)
	2399440598 111568 /usr/conf/lib/liblvm.a(sh_vgsa.o)
	3299472637 77736 /usr/conf/lib/liblvm.a(slvm_comm.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	1108607914 271088 /usr/conf/lib/libhp-ux.a(lv_lvm.o)
	3411961794 72472 /usr/conf/lib/libhp-ux.a(lv_config.o)
	1712949615 26008 /usr/conf/lib/libhp-ux.a(dumpconf.o)
	2686207032 17752 /usr/conf/lib/libhp-ux.a(rw_lock.o)

Patch Conflicts: None

Patch Dependencies:
	s700: 11.00: PHCO_14124 PHKL_21775 PHKL_18543
	s800: 11.00: PHCO_14124 PHKL_21775 PHKL_18543

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHKL_20397 PHKL_19367 PHKL_17042 PHKL_13346 PHKL_23127 PHKL_22267
	PHKL_22266 PHKL_20419 PHKL_20333 PHKL_20186 PHKL_19909 PHKL_19060
	PHKL_18542 PHKL_18483 PHKL_18189 PHKL_18134 PHKL_17664 PHKL_17045
	PHKL_17041 PHKL_16563 PHKL_16433 PHKL_16220 PHKL_15956 PHKL_15789
	PHKL_15550 PHKL_15520 PHKL_14861 PHKL_14689 PHKL_14252

Equivalent Patches: None

Patch Package Size: 2250 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_24268

	5. Run swinstall to install the patch:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -s /tmp/PHKL_24268.depot

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHKL_24268.  If you do not wish to retain a
	copy of the original software, include the patch_save_files
	option in the swinstall command above:

		-x patch_save_files=false

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

	For future reference, the contents of the PHKL_24268.text file is 
	available in the product readme:

		swlist -l product -a readme -d @ /tmp/PHKL_24268.depot

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

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

Special Installation Instructions:
	This patch depends upon PHKL_21775.  The dependency is a
	result of a process management defect which this patch
	exposes.  If this patch is installed on a system without
	PHKL_21775, and the user then creates mirrored logical
	volumes on a shared volume group, over time the system
	proc table will be exhausted, thus causing the system to
	become unusable.  If you are not using mirrored logical
	volumes on shared volume groups, there is no dependency
	on PHKL_21775.

	This patch depends on base patch PHKL_18543.
	For successful installation please insure that PHKL_18543
	is already installed, or that PHKL_18543 is included
	in the same depot with this patch and PHKL_18543
	is selected for installation.

