Patch Name: PHKL_30690

Patch Description: s700_800 11.11 VxFS 3.5-ga15 Kernel Cumulative Patch 06

Creation Date: 04/06/04

Post Date: 04/08/24

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

Products:
	VxFS 3.5-ga15

Filesets:
	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=HP
	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=VERITAS

Automatic Reboot?: Yes

Status: General Release

Critical:
	Yes
	PHKL_30690: HANG CORRUPTION PANIC
	PHKL_29896: HANG CORRUPTION PANIC
	PHKL_29212: HANG
	PHKL_28785: HANG CORRUPTION PANIC
	PHKL_28503: HANG

Category Tags:
	defect_repair enhancement general_release critical panic
	halts_system corruption

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

Symptoms:
	PHKL_30690:
	(SR: 8606366078 CR : JAGaf26707)
	vxfs idle quota records are not freed.

	(SR: 8606366079  CR : JAGaf26708)
	Panic during logged write.

	(SR: 8606366080  CR : JAGaf26709)
	Data corruption on main fileset in presence
	of clones.

	(SR: 8606366082 CR : JAGaf26711)
	DPF in VX_CLUSTER_INODE while running
	KRT test.

	(SR: 8606366083 CR : JAGaf26712 )
	Large allocating write from CFS secondary on a
	fragmented file system can take a long time.

	(SR: 8606359937  CR : JAGaf20633)
	(SR: 8606366084  CR : JAGaf26713)
	The customers can see hang or panic because
	of this problem.

	(SR: 8606359941  CR : JAGaf20637)
	(SR: 8606366085  CR : JAGaf26714)
	This is a CFS specific problem. The secondary mount
	will hang (instead of exiting with error).

	(SR: 8606359942  CR : JAGaf20638)
	(SR: 8606366086  CR : JAGaf26715)
	Oracle RAC crashes with following error:
	ORA-00600: internal error code, arguments: [kcrfnl_3]
	The customers can see data corruption in files because
	of this problem. This is applicable only when VxFS
	is being used in a cluster along with ODM/QIO.

	(SR: 8606347755  CR : JAGaf08577)
	The customers can see a data page fault because
	of this problem.

	(SR: 8606344712  CR : JAGaf05562)
	The customers can see panic because of this problem.

	(SR: 8606343270 CR: JAGaf04164)
	Resizing an VxFS filesystem using fsadm
	sometimes leads to panic.

	(SR: 8606337509 CR: JAGae98516)
	Customers can see hung/unkillable processes
	because of this problem.

	(SR: 8606355334 CR: JAGaf16074)
	System panics with the panic string as:
	"mp_b_sema_sleep:blocking on a semaphore we already own"

	(SR: 8606206142 CR: JAGad75317)
	System panics in kdm_k_get_nextevent.

	PHKL_29896:
	(SR: 8606351775  CR : JAGaf12580)
	Because of a bug in the way free blocks in snapshot
	are calculated, incorrect free block count can be seen
	in a snapshot, when df(1M) command is used.

	(SR: 8606304072  CR: JAGae67420)
	Excessive spinlock contention on
	"FS:vxfs:inode spin for sleep lock" in
	VXFS 3.5 is causing approximately
	15% performance loss compared to VXFS 3.3.

	(SR: 8606338973  CR: JAGae99919)
	When clones (used by netbackup) are enabled,
	allocation of typed extents may fail with error value
	ENOTSUP, which can result in failure of system
	calls like write() which require allocation.

	(SR: 8606338978  CR: JAGae99924)
	Performance loss in HSM products that utilize
	the VxFS file system's DMAPI.

	(SR: 8606338975 CR: JAGae99921)
	System panics when there is a request
	to reorg multiple structural files.

	(SR: 8606331825  CR: JAGae92945)
	If multiple threads are reading from the same
	file, then read performance suffers.

	(SR: 8606331826  CR:  JAGae92946 )
	Customer would see a successful write system call
	even though the write(2) incorrectly returns
	success when it actually returns ENOSPC.

	(SR:  8606331827 CR: JAGae92947 )
	System panics at boot time with following
	assertion failure:
	assertion failed (Spinunlock of a lock we do not own)
	at line 1288 in /ux/core/kern/pa/sync/spinlock.c

	(SR: 8606331828  CR: JAGae92948 )
	With cached Quick-IO feature enabled for Quick-IO
	files, performance degrades instead of improving.
	This problem can be seen when running the TPC-C
	benchmark using  Quick-IO database files with
	cached Quick-IO enabled.

	(SR: 8606331830 CR: JAGae92950)
	ACL information is lost until a directory is created
	at which time subsequent files created have
	the correct ACL specification. This is intermittent
	behaviour and does not happen each time a
	sub-directory is created.

	(SR: 8606331831 CR: JAGae92951)
	On a heavily fragmented file system,
	writing to a hole in a sparse file may
	fail with ENOSPC even though enough
	space is available.

	(SR: 8606331833 CR: JAGae92953)
	If a file has shared writable mapping and
	read/write is done on that file using kernel buffers,
	read/write fail with error EFAULT.

	(SR: 8606331835 CR: JAGae92955 )
	If a sparse file is created and mmapped
	immediately afterwards, pages in the hole
	regions are not zero-filled but contain junk data.

	(SR: 8606331836 CR: JAGae92956 )
	System panics in vx_remount() while remounting
	the file system.

	(SR: 8606331838 CR:JAGae92958 )
	(SR: 8606284882 CR:JAGae48824 )
	Element v_pgpgin of vmmeter structure
	intermittently and temporarily decrements
	in value (by one) for one data collection and
	then returns to the same or slightly larger value
	in subsequent queries.  This temporary decrease
	in value causes inconsistent behaviour in
	OVPA/GlancePlus products.

	(SR:  8606331839 CR: JAGae92959)
	Poor read performance while doing unaligned reads.

	(SR: 8606331840 CR: JAGae92960)
	VxFS inode cache hogs up memory.

	(SR: 8606331843 CR: JAGae92963)
	If user issues a write request of 8K and
	only 4K of free space is available and if it is
	the first write to the file from offset 0 ,
	the write request returns success but in reality
	a 4k hole is created in the beginning and
	data is written only in the next 4K.
	This causes data corruption.

	(SR:  8606331844  CR: JAGae92964)
	When multiple threads of a single process
	issues pstat_getstatic() simultaneously,
	system panics with the following stack trace:

	q4> trace event 0
	 vx_cfsaioctl_cleanup+0x40
	 vxportal_close+0x34
	 call_open_close+0x1458
	 closed+0xfc
	 spec_close+0x12c
	 vn_close+0x54
	 get_fsinfo+0x108
	 pstat_static+0x180
	 pstat+0x94
	 syscall+0x8a8
	 $syscallrtn+0x0

	(SR:  8606331845  CR: JAGae92965)
	A user within a group that matches a file's
	owning group cannot properly access the file
	if the file was created in a directory that
	has default ACLs."

	(SR:  8606331847  CR: JAGae92967)
	(SR:  8606326970  CR: JAGae89234)
	Two NetBackup threads hanged due to a deadlock
	between vx_dio_iovec() and vx_read1().

	(SR: 8606331848 CR: JAGae92968)
	If Oracle is running on the node while
	uninstallDBAC is run to remove that node
	from cluster, system panics in
	vx_glmlock_refdeinit().

	Procedure to reproduce the panic is:
	1. Start Oracle (mainly its listener
	process 'gsd') from vxfs file-system
	mounted with cluster option.
	2. Force unmount this file-system.
	3. Deinit cfs (using cfsdeinit option of fsadm).

	System panics after some time.

	(SR: 8606331849 CR: JAGae92969)
	qlogchkd hangs and cannot be killed
	when it is started and deinited
	many (greater than max_thread_proc tunable) a times.

	(SR: 8606331851  CR: JAGae92971)
	On freshly rebooted machine having root
	vxfs file-system, buffer cache
	usage is unusually high (105 MB on machine
	having 1 GB RAM). It can
	be found by running command:

	# vxfsstat -b /

	On machine having 4 GB RAM, it uses
	350 MB for its meta-data buffer cache.

	(SR:  8606331852 CR: JAGae92972)
	After remounting a file system mounted with qlog,
	qlog is disabled.

	(SR: 8606331853 CR: JAGae92973)
	No external symptom will be visible to the
	customer except that the kernel 'vmunix'
	will be bigger without this fix.

	(SR: 8606331856 CR: JAGae92976)
	VxFS sets up an extended operation
	to shorten a file when such operation is
	not necessary. Systems which create many
	small files may observe a slight performance
	boost after applying this fix.

	(SR:  8606331857 CR: JAGae92977)
	File data retruned by read(2) may
	be corrupted for mmaped sparse files.

	PHKL_29688:
	(SR: 8606331829 CR: JAGae92949)
	Second re-read on files will be
	slower.

	PHKL_28785:
	( SR: 8606295939 CR: JAGae59576 )
	Reads on sparse files opened using a writable
	memory mapping, returned junk data.

	( SR: 8606277951 CR: JAGae42012 )
	vhand performance drastically goes
	down under memory pressure.

	( SR: 8606300118 CR: JAGae63586 )
	Adding support for handling i/o fencing.
	This includes a new feature of
	adding support for handling
	i/o fencing, to enhance jeopardy handling
	in Cluster File System. Without the
	support for i/o fencing, it leads to data
	corruption in split brain scenarios.

	Snapshot file system shows unexpected
	ENXIO errors.

	Low throughput and ultimately no I/O
	happening through fdd.

	The symptom of the bug is a hang.
	Many threads are stacked up
	waiting for locks held by a thread
	which is in turn blocked trying
	to get a buffer lock.
	The problem is noticed mostly on
	systems with 8 or more cpus.
	The customers who reported this
	problem were running database
	(non-dbed) when they noticed the hang.
	There is no definite way of
	saying that it will happen in a
	particular configuration or there
	are no known workarounds.

	VxFS threads hang or sleep.

	Uninstalling of GAB package wouldn't be smooth.
	The customer would require an extra reboot
	while uninstalling SPFS.

	Data page fault on split brain scenario
	or panic during uninstalldbac.

	PHKL_28503:

	( SR: 8606281794  CR: JAGae45737 )
	System under heavy activity on memory mapped
	files causing low memory condition and ultimately
	resulting in system hang.

	( SR: 8606291859  CR: JAGae55623 )
	VERITAS Quick I/O shows significant performance degradation
	on the TPC-C benchmark in the presence of
	Storage Checkpoints. The degradation can be as
	high as 70% in some cases.

	PHKL_29212:

	(SR:8606313751 CR:JAGae76543)
	VERITAS Incident number : 117663
	Force unmount command (vxumount -o force)
	hangs for cluster file-system. All
	commands/operations on that file-system
	will hang cluster-wide afterwards and such
	hung processes may not be killed even with SIGKILL.

	(SR:8606313752 CR:JAGae76544)
	VERITAS Incident number : 125630
	A command which causes file-system freeze
	(for e.g. sync/quotacheck/vxresize/fsckptadm etc.)
	hangs for cluster file-system, and such hung processes
	may not be killed even with SIGKILL.

	(SR:8606311410 CR:JAGae74247)
	VERITAS Incident number : 125027
	Two NetBackup threads running on VxFS3.5
	results into a deadlock.

Defect Description:
	PHKL_30690:
	(SR: 8606366078  CR : JAGaf26707)
	VERITAS Incident Number: 75688
	Problem Description:
	vxfs idle quota records are not freed.

	Reason:
	The vx_dq_sync() routine, which frees
	idle vx_dquot structures,
	was not being called.

	Resolution:
	Fixed by calling vx_dq_sync()
	periodically from the
	scheduler thread.

	(SR:8606366079 CR: JAGaf26708)
	VERITAS Incident Number: 141241
	Problem Description:
	Panic during logged write.

	Reason:
	iovp in vx_logonly_write() was not
	restored in tran_retry code path.

	Resolution:
	Fixed by restoring iovp in tran
	retry code path.

	(SR: 8606366080  CR : JAGaf26709)
	VERITAS Incident Number: 141300
	Problem Description:
	Data corruption on main fileset
	in presence of clones.

	Reason:
	In the case of a partial truncation of a file
	where the truncation point is in the middle of
	the extent,only the second half of the extent is
	pushed to the clone inode.For this we call vx_move()
	to move data to the clone inode.If the upstream
	inode contains a very large extent and clone inode
	contains a number of small extents throughout the
	range,then more number of free/pushes would be
	required which may not fit into a single
	transaction. vx_move() would return
	VX_EMAXTRUNC in this case.

	Resolution:
	Fixed by setting this modified extent correctly.

	(SR: 8606366082 CR : JAGaf26711)
	VERITAS Incident Number: 146224
	Problem Description:
	DPF in VX_CLUSTER_INODE while running KRT test

	Reason:
	In vx_root_iget(), in error path we
	were doing vx_iput() instead of
	vx_idrop() on the inode. The result was
	a corrupt inode lying in the icache and
	triggered this DPF.

	Resolution:
	Fixed by replacing vx_put() by vx_idrop().

	(SR: 8606366083 CR : JAGaf26712)
	VERITAS Incident Number: 146671
	Problem Description:
	Large allocating write from CFS
	secondary on a fragmented file
	system can take a long time.

	Reason:
	The bug is in vx_recv_prealloc()
	and vx_recv_prealloc_v1()which
	contain the following loop:
	while (offset < eoff) {
	  error = vx_write_alloc2_local(ip, offset,
	  eoff, &clrstart,&clrend, onlywrite,
	  numext,nsize, 1);
	if (error) {break;}
	if (error = vx_bmap(ip, offset,
		     &exoff, &myext, NULL, NULL,
		     VX_BNOOVERLAY)) {break;}
		     ...
	if (myext.ex_st != VX_HOLE) {
	offset = myext.ex_off + myext.ex_sz;

	On a fragmented filesystem, if there
	is a large allocation request,the
	initial call to vx_write_alloc2_local
	will allocate for most of
	the requested ranges.
	But "offset" will still move ahead only
	by an extent and vx_write_alloc2_local will
	do wasteful bmaps on all the allocated
	extents and skip through them.
	And this process will repeat as
	the above loop proceeds extent
	by extent resulting O(n^2) bmaps,
	where n is the number of extents
	allocated.

	There is also a small performance issue
	in this loop in vx_write_alloc()
	while (offset < eoff) {
	  if(error=vx_bmap(ip,offset,&exoff,
	   &myext,NULL,NULL,VX_BNOOVERLAY))
	   { goto badout; }
	   ...
	if (myext.ex_st != VX_HOLE) {
	offset = myext.ex_off + myext.ex_sz;
	 continue;}
	if (error = VX_EXTERNAL_ALLOC(ip,
	 offset, eoff, clrstartp,
	 clrendp, onlywrite, numext)){
	 goto badout;}}

	This loop makes a number of
	additional calls to vx_bmap(),
	to skip over the allocated extents.
	VX_EXTERNAL_ALLOC eventually
	ends up in a call to
	vx_write_alloc2_local().

	Resolution:
	vx_write_alloc2_local() now returns
	only after allocating the entire
	range,unless there is any error like
	ENOSPC,callers are now assured that.
	And hence they don't need to verify
	or retry the allocation.

	(SR: 8606359937  CR : JAGaf20633)
	(SR: 8606366084  CR : JAGaf26713)
	VERITAS Incident Number : 134156
	Problem Description:
	The problem is of the stack getting polluted
	because of doing large strcpy into a small buffer
	having insufficient space. vx_common_msgprint allocates
	a 512-byte array on the stack to hold the processed
	string and uses it as a destination of a strcpy
	which is unbounded and extremely unsafe.
	Any "%s" which expands to a really long string
	will smash the stack.

	The problem is easily reproducible by mounting
	a filesystem on a long path just short of PATH_MAX.
	Then irritate the filesystem by injecting
	I/O failures or something. When it prints fst_mntpt,
	vx_common_msgprint will overwrite the caller's stack frame,
	leading to the inevitable.

	
	Reason:
	The problem is occuring because of the stack
	getting polluted because of doing a large strcpy into
	a small buffer having insufficient space.

	
	Resolution:
	The problem is solved by replacing the static
	array on the stack by a dynamically allocated
	array having sufficient space to hold the source
	string during strcpy.

	(SR: 8606359941  CR : JAGaf20637)
	(SR: 8606366085  CR : JAGaf26714)
	VERITAS Incident Number : 141770
	Problem Description :
	The problem can be reproduced as follows:
	1. Mount a cluster filesystem on primary.
	2. On secondary node, set max_thread_proc to 64.
	max_thread_proc is a  kernel tunable and this step
	might need a reboot to take effect.
	3. Try cluster mounting the file system from secondary.

	If it succeeds then max_thread_proc needs to be
	reduced and the steps retried. If it bails out with
	error then the patch is installed and things
	are fine. If it hangs then you have successfully
	reproduced the problem and it requires the patch.

	Reason :
	The problem occurs because vxfs will not be able
	to create more than "max_thread_proc"
	number of threads, if max_thread_proc is set to
	a low value.In this case and if secondary has not
	created "vx_ctl_process_thread" then it wont be able
	to handle any GAB messages causing the mount to hang.

	Resolution :
	Modified the code so that if vxfs is unable to
	create vx_ctl_process_thread thread
	then it propagates the error to the upper
	layers failing the mount.

	(SR: 8606359942  CR : JAGaf20638)
	(SR: 8606366086  CR : JAGaf26715)
	VERITAS Incident Number : 144097(143564)
	Problem Description:
	This is cache coherency problem when a file is
	accessed using both the regular read(2) and write(2)
	operations and the ODM interface in a cluster
	environment. The basic principal is that if a file
	is opened via ODM anywhere in a cluster, the file
	should not be cached anywhere in the cluster.
	This was not being enforced in the write(2) case.

	Reason:
	The probem occurs because of cache coherency
	problem when a file is accessed using both the
	regular read and write operations and the ODM
	interface.

	Resolution:
	If a file is being accessed via ODM
	(on local node or anywhere in the cluster),
	VxFS invalidates the cache for every read/write
	operation via the regular file interface.
	This ensures that a read/write operation
	never uses a stale copy of the cache.

	(SR: 8606347755  CR : JAGaf08577)
	VERITAS Incident Number : 143393
	Problem Description:
	The problem occurs when the size of a file is
	increased (using truncate(2)) while it is being
	simultaneuosly accessed using shared
	writable mmap.

	This can be reproduced by doing the following:

	0. create a vxfs filesystem with bsize = 1024 and
	mount it on /mnt1

	1. touch /mnt1/file1    - create a file

	2. setext -e 1 /mnt/file1  - set fixed extent size
	to 1 so that only the desired number of
	blocks are allocated.

	3. write 100 bytes to /mnt/file1 - this will
	allocate one block to /mnt1/file1

	4. do a PROT_WRITE mmap(2) on /mnt1/file1 and
	write a byte into it using mmap-ed address.

	5. Now before doing an munmap or before the
	program exits in step 4, do a trunc up
	(using truncate(2) syscall in another
	program from another shell) on /mnt1/file1 to
	4096 bytes.

	Now /mnt1/file1 will be in a state as seen in the
	file in the dump, i.e. its size will be 4096 bytes
	but will have only one extent of size 1 block
	allocated to it.

	6. Now let the program in step 4 exit or do a munmap.
	This will trigger call to vx_pageout -> vx_do_pageout
	and now vx_do_pageout will try to flush a hole
	(between offset 1024 - 4096) resulting in the

	TED_ASSERT("f:vx_do_pageout:3a", ex.ex_st != VX_HOLE);

	to fail and panic.

	Reason:
	The problem is occuring because vx_do_pageout passes
	blkno as -1 (VX_HOLE) to asyncpageio in a certain case.

	Resolution:
	The problem is solved by skipping the holes
	(VX_HOLE extents) while doing the flushing
	in vx_do_pageout.

	
	(SR: 8606344712 CR : JAGaf05562)
	VERITAS Incident Number : 142639
	Problem Description:
	The problem occurs when invalidation (B_INVAL)
	of a dirty buffer (B_DELWRI) is attempted in brelse
	if there is an error in the vx_write_default
	during write(2).

	Reason:
	The problem occurs when invalidation (B_INVAL)
	of a dirty buffer (B_DELWRI) is attempted in brelse.

	Resolution:
	The problem is solved by not doing invalidation
	if the buffer is dirty.

	(SR: 8606343270 CR: JAGaf04164)
	VERITAS Incident Number : 144573
	Problem Description:
	fsadm resize can sometimes lead to panic
	due to stale fs pointer being passed to fsync.

	Reason:
	The panic is due to an old fs pointer being
	passed to fsync. This happens because of an evaluation of
	the pointer outside of active level of protection.

	Resolution:
	The fs pointer is now evaluated inside
	active level of protection.

	(SR: 8606337509 CR: JAGae98516)
	VERITAS Incident Number : 143085
	Problem Description:
	The problem occurs when vx_do_pageout,
	called to flush the mmap-ed writes, incorrectly
	changes the error reporting fields of buffers
	(viz.  vb_error and vb_flags) which are chained
	together for flushing. This is done to propagate
	an error during vx_do_pageout to pageiodone but the way
	it is done can cause problems. If the error on a buffer
	was such that the caller then retries the operation,
	then if this error is changed to something else,
	then the retry operation will not happen and could result
	in problems. One manifestation of this could be
	hung processes because they could not finish the operation.

	Reason:
	The problem occurs when vx_do_pageout,
	called to flush the mmap-ed writes,
	incorrectly changes the error reporting fields
	of buffers (viz.  vb_error and vb_flags).

	Resolution:
	The problem is solved by using some other field
	of the buffer, vx_fs_data, to propagate the error
	to pageiodone and not touching the
	vb_error and vb_flags fields.

	
	(SR: 8606355334 CR: JAGaf16074)
	VERITAS Incident Number : 144043
	Problem Description:
	When the user tries to read a file into shared
	writable mapped pages of the same file, he might
	get this fault. But its not necessary that you would
	get this panic. It also depends on the fact whether
	the TLB entry for translation of this page is present.
	It couldn't be reproduced.

	Reason:
	Panic occurred because OS's fault handler was invoked
	on pages which were already locked by vxfs.
	Ideally it shouldn't have faulted on locked pages
	because on PA we use PROBE instruction to check
	access permissions. As per the PA-RISC 2.0 instruction
	set reference PROBE just checks the TLB for validation
	permissions/protections on the passed addressed.
	If there's a TLB miss it invokes the operating system
	fault handler (which is then required to search its
	page-tables, insert an entry in TLB and
	restart the faulting instruction)

	Resolution:
	For locked pages, replaced uiomove() and
	copyin/copyout() by privlbcopy() to avoid possibility of
	faulting on those pages. This should fix the problem.
	privlbcopy() doesn't check for access permissions so we
	would not fault for locked pages with this change.

	(SR: 8606206142 CR: JAGad75317)
	VERITAS Incident Number :123276
	Problem Description:
	On systems running HSM applications that use VxFS DMAPI
	interfaces, there is a possibility of a race that
	causes an 'event' (a structure internally used by VxFS
	for representing HSM/DMAPI events) on some internal
	list to be accessed even after its freed up. This causes
	routines accessing the event from the internal list to
	access freed-up memory and hence system panic.
	The problem occurs due to inadequate serialization between
	the routine that frees up events and those that
	add events to internal lists.

	Reason:
	The problem occurs due to race between routines that free
	up event structures and those that add them to internal
	lists.

	Resolution:
	The fix involved serializing routines that add events to
	internal list to skip an event if its busy
	(a busy event means that its being processed by some
	other routine, and could eventually get freed up).

	PHKL_29896:

	(SR: 8606304072  CR: JAGae67420)
	(SR: 8606351775  CR : JAGaf12580)
	VERITAS Incident number: 139378
	Problem Description:
	In the function vx_snap_statefreeblk,
	where free blocks in a snapshot
	are calculated, the pointer "sump" is made to
	point to an AU (Allocation Unit) summary structure
	(struct vx_emapsum which holds the free block
	count), which is present at an offset in the buffer
	which is read from the
	summary file, in following manner:

	sump = (struct vx_emapsum *)
		(sumbp->vb_addr + sumex.ex_bufoff

	The bug in the above statement is that
	sumex.ex_bufoff gets initialized
	only when a buffer is read from the file
	and a buffer holds summaries for
	many AUs (Allocation Units), but the sump keeps
	pointing to the same first vx_emapsum entry in the
	buffer because sumex.ex_bufoff remains same for a
	buffer. The fix is to increment sump properly so
	that it points to the new AU's summary.

	Reason:
	The problem is occuring because of a bug in the way
	free blocks in a snapshot are calculated.

	Resolution:
	The problem is solved by replacing the buggy statement
	sump = (struct vx_emapsum *)
		(sumbp->vb_addr + sumex.ex_bufoff
	by

	sump = (struct vx_emapsum *)
		(sumbp->vb_addr + (sumoff - (sumex.ex_buflbno <<
					     fs->fs_bshift)));

	
	Since sumoff gets incremented for each AU,
	sump points to proper summary entry in the buffer.

	(SR: 8606304072  CR: JAGae67420)
	Problem Description:
	VERITAS Incident number: 124562
	Around 15% performance loss is observed
	on VxFS 3.5 compared to VxFS 3.3 during
	SDET performance benchmark used testing
	scalability.

	Reason:
	Excessive spinlock contention on
	"FS:vxfs:inode spin for sleep lock" was
	seen with VxFS 3.5.

	All inode locks i_ilock, i_plock & i_bmaplock
	are allocated from same arena and hence they are
	allocated from same page. Hash function
	VX_SPIN_HASH_INDEX() used by vx_spin_init()
	returns same hash index in the hashpool for all
	the locks allocated from same page, which results
	in increased lock contention.

	Resolution:
	Contention on ilock was reduced by increasing
	hashpool size for inode locks (VX_INODE_HASH_NLOCK)
	to 1024 from current value 256.
	Contention was further reduced by assigning locks
	in the hashpool sequentially for
	each call to vx_spin_init().

	(SR: 8606338973  CR: JAGae99919)
	Problem Description:
	VERITAS Incident number: 132088
	When clones are enabled, entering a new typed
	extent can causes ted assert f:vx_enter_typed:2
	in vx_enter_typed() and error ENOTSUP
	may be returned from allocation.

	Reason:
	vx_reorg_settype() is called by vx_extmap_reorg()
	which ends up creating two extents in the overlay inode:

		a. one at offset 0, size 0x7fffffff
		b. one at offset 0x7fffffff of size 1

	This may cause overlap with the last extent in the
	bmap of the reorg inode while entering new typed extent.

	Resolution:
	Modified function vx_make_overlay() to create
	extents of size 0x80000000 instead of size
	0x7fffffff.

	(SR: 8606338978  CR: JAGae99924)
	Problem Description:
	VERITAS Incident number: 134922
	Calling the dm_create_userevent() interface
	or any other DMAPI interface that can accept
	(and is passed) the token DM_NO_TOKEN will
	cause a delay of approximately
	half of a second per interface call.

	Reason:
	An unnecessary overhead was introduced
	in VxFS3.5 whereby the creation of a new kernel
	thread for the dm_create_userevent() interface was
	enqueued as a task on a background work list thread.
	The overhead was incurred whilst
	waiting for this task to be performed.

	Resolution:
	The task is no longer enqueued as a work list item
	and is now performed  directly.

	(SR: 8606338975 CR: JAGae99921)
	Problem Description:
	VERITAS Incident number: 136181
	During fsadm, if there are multiple
	structural files for which reorg request
	is sent in, then there will be a
	panic. Also in case we an error occurs
	in function vx_extmap_reorg while
	reorg is in progress, the system will panic.

	Reason:
	Bug in code vx_reorg_dostruct() where the pointer
	manipulation was incorrect. Trying to take
	the same lock twice in error
	code paths of vx_extmap_reorg().

	Resolution:
	Fixed the loop in function vx_reorg_dostruct().
	Fixed the error code paths of
	function vx_extmap_reorg().

	(SR: 8606331825  CR: JAGae92945)
	Problem Description:
	VERITAS Incident Number : 102162
	If multiple threads are reading from
	the same file, then read performance suffers.

	Reason:
	The read performance suffers because
	of contention on the inode ispinlock
	which is taken in the vx_read_ahead().

	Resolution:
	Fixed by changing vx_read_ahead() to acquire
	inode spinlock only when necessary.

	(SR: 8606331826  CR:  JAGae92946 )
	Problem Description:
	VERITAS Incident Number : 104349
	vx_rdwri() incorrectly returns success
	instead of returning ENOSPC error.

	Resolution:
	Fix vx_rdwr() to return ENOSPC correctly.

	(SR:  8606331827 CR: JAGae92947 )
	Problem Description:
	VERITAS Incident Number: 104761
	vxfsd tries to unlock a spinlock that it
	doesn't own.

	Reason:
	There is a race between vxfsd and its
	parent process. The parent process creates
	worker threads while vxfsd is closing open
	files as part of initialization. This
	race causes vxfsd to try to unlock a spinlock
	that it doesn't own.

	Resolution:
	The parent process waits for vxfsd to complete
	the initialization before creating worker
	threads, thus avoiding the race.

	(SR: 8606331828  CR: JAGae92948 )
	Problem Description :
	VERITAS Incident Number :  109284
	With cached Quick-IO feature, data read from
	a Quick-IO file is cached in the buffer cache.
	When writing to such file, the code incorrectly
	invalidate all buffers associated with the file
	where it should only invalidate those buffers
	within the write range. This nullifies the
	performance gain in data caching.

	In addition, read-ahead is not performed for such
	file to improve performance.

	Resolution :
	When writing to Quick-IO file with caching enabled,
	only invalidate buffers in the write range.

	Reads to a Quick-IO file having caching
	enabled attempts to detect read access patterns
	on the file and issues appropriate read-ahead
	if a pattern (eg. sequential) is detected.

	(SR: 8606331830 CR: JAGae92950)
	Problem Description:
	VERITAS Incident Number : 113367
	ACL information is lost until a directory
	is created at which time subsequent files
	created have the correct ACL specification.
	This is intermittent behaviour and does not
	happen each time a sub-directory is created.

	Reason:
	The reason for this problem is the
	uninitialized i_iaclcnt and not checking
	it during the inheritance of acl
	(at file creation).

	Resolution:
	The problem is resolved by:
	- properly initializing i_iaclcnt.
	- using i_iaclcnt to decide acl inheritance
	during file creation.

	(SR: 8606331831 CR: JAGae92951)
	Problem Description:
	VERITAS Incident Number :115533
	During allocation in a hole in a sparse file,
	a fixed size extent of the size equal to the size
	of the hole is tried and if such a extent
	is not available, because of the file system
	being fragmented, the allocation
	fails with ENOSPC thus finally failing the
	write(2) system call.

	Resolution:
	The problem is fixed by converting the inode
	from IORG_EXT4 to IORG_TYPED if a
	fixed size extent of desired size is not
	found while allocating in a hole.

	(SR: 8606331833 CR: JAGae92953)
	Problem Description:
	VERITAS Incident Number : 117566
	In vx_read1() and vx_write_default(), useracc()
	is called to check whether
	user has appropriate privilege on that buffer
	(write privilege in case of read and vice versa).
	If the read/write originates within the kernel,
	(e.g. when execve() calls read_elf_object() to read
	the ELF header of a file having writable mapping)
	useracc() simply fails since the
	user will never have privilege to
	write/read to kernel buffers.

	Resolution:
	Fixed vx_read1() and vx_write_default()
	so useracc() is not called for kernel buffers.

	
	(SR: 8606331835 CR: JAGae92955 )
	Problem Description :
	VERITAS Incident Number: 117634
	vx_mapbd() calls vx_alloc_clear()
	which creates delayed write buffers
	to zero out the extents allocated to the holes
	of the newly created sparse file.
	But these buffers are not flushed to disk
	immediately afterwards.
	A subsequent attempt to page in the holes
	may still read the uninitialized data on the disk.

	Resolution :
	Fixed by flushing dirty buffers in "vx_mapdbd()"
	after having called "vx_alloc_clear()" so that
	zeroed out buffers are written to the disk.

	(SR: 8606331836 CR: JAGae92956 )
	Problem Description:
	VERITAS Incident Number: 118086
	In function vx_remount(), during following check:

	if (!error && fs->fs_version == VX_VERSION4
	&& (fs->fs_flags & VX_UPGRADING)
	&& VX_CFS_MASTER(fs->fs_fsext))
	{
	fsext = fs->fs_fsext;

	at this point since vx_fs_reinit has already
	happenned, the fs pointer could be stale.
	Hence the check is not correct. it should again get
	the pointer as fs = fsext->fse_fs;
	before performing the check.

	Reason:
	The problem occurs because of a stale
	'fs' pointer in function vx_remount.

	Resolution:
	The problem is resolved by reinitializing
	'fs' pointer in function vx_remount
	after a vx_fs_reinit.

	(SR: 8606331838 CR:JAGae92958 )
	(SR: 8606284882 CR:JAGae48824 )
	Problem Description:
	VERITAS Incident Number: 119913
	When a memory mapped file (mmap) is read or
	written, then vx_pagein() returns 1
	while it should return -1, resulting in the
	pstat(2) reporting wrong counter for the
	number of pageins.

	Resolution:
	Fixed vx_pagein() to return the correct
	value (-1) if the page has already been faulted in.

	(SR:  8606331839 CR: JAGae92959)
	Problem Description:
	VERITAS Incident Number: 121107
	In the existing code, Direct I/O is not
	allowed for unaligned reads. Unaligned
	reads go through buffer cache, taking more
	time than direct I/O. For example, an application
	which reads data in chunks of slightly less
	than 256K, will get slowed down because of
	intermediate buffer cache.

	Reason:
	Direct I/O is not allowed for unaligned reads.

	Resolution:
	This patch now enables direct I/O for
	unaligned reads.

	(SR: 8606331840 CR: JAGae92960)
	VERITAS Incident Number: 121558
	Unused VxFS inodes are freed at a very slow rate
	because the code relinquishes CPU after freeing
	every single inode. This hogs up memory for
	that time period.

	Reason:
	The CPU is being relinquished after every
	inode is freed.

	Resolution:
	The resolution made is to relinquish CPU after
	freeing a bunch of inodes on the freelist,
	instead of every single inode.

	(SR: 8606331843 CR: JAGae92963)
	Problem Description:
	VERITAS Incident Number : 122411
	If user issues a write request of 8K when
	only 4K of free space is available,
	logonly_write will sucessfully allocate
	space for the first 4K and do uiomove()
	but vx_bmap() will fail with ENOSPC.

	Reason:
	In an attempt to write 8K data when only
	4K of free space is available,
	vx_logonly_write() successfully
	allocates space for the first 4K and
	copies over 4K data.  When it later
	fails with ENOSPC, it will undo the
	transaction by releasing the 4K space
	already allocated.  But the uio
	structure is not restored to
	reflect the undo operation.  A retry of
	the write request based on this improper
	uio structure returns success, giving
	the impression that the entire 8K was
	successfully written.

	Resolution:
	The uio structure is restored in case of any
	error in vx_logonly_write().

	(SR:  8606331844  CR: JAGae92964)
	Problem Description:
	VERITAS Incident Number : 123765
	In a multi-threaded application,
	if the function pstat_getstatic() is
	called from each thread (or more
	than one thread), then this problem can
	occur. Each thread will try to do a
	close() on vxportal device,
	i.e. vxportal_close() is called simultaneouly.
	If multiple threads call
	close() simultaneouly, they will get same
	state pointer sp if none of the
	threads has yet called vx_portal_state_free().
	Second thread which executes
	vx_cfsaioctl_cleanup() will cause above
	panic since first thread will free
	up the state.

	Reason:
	The panic occurs when multiple threads try
	to close the vxportal device
	simultaneously as the code doesn't keep track
	of the open counts on vxportal and simply
	close the device upon the first attempt to close it.
	Subsequent attempts to close the device
	will panic.

	Resolution:
	The problem is solved by maintaining a refcount
	for each open of the vxportal device and
	only close the device upon the last close.

	(SR:  8606331845  CR: JAGae92965)
	Problem Description:
	VERITAS Incident Number : 124581
	A user with a group that matches a file's
	owning group cannot properly access the file
	if the file was created in a directory that
	has default ACLs.

	Reason:
	There are two reasons for this failure:

	1. During setacl, there was a case where
	the GROUP_OBJ entry, which corresponds to
	the file's owner group, was not getting added
	to the file's acl thus disallowing users in
	that group access to the file.

	2. In vx_daccess(), non-default acl entries of
	files are not checked, thus denying permission
	which would otherwise have been allowed if those
	were checked.

	Resolution:
	The problem is resolved by fixing vx_setacl()
	and vx_daccess() to take care of the
	two problems mentioned above.

	(SR:  8606331847  CR: JAGae92967)
	(SR:  8606326970  CR: JAGae89234)
	Problem Description:
	VERITAS Incident Number : 125027
	Two NetBackup threads hanged due to a deadlock
	between vx_dio_iovec() and vx_read1().

	Reason :
	In normal read/write code path buffer is locked
	first and then pages. But in dio(direct i/o)
	code path pages are locked first and
	then the buffer. This locking disorder
	results in a deadlock.

	Resolution :
	Fixed by releasing the pages(in dio code path)
	if buffer is already locked, and following the
	usual read/write code path.
	This patch has a complete fix for this JAG
	and is also being partially fixed as part of
	PHKL_29212 patch which is superceded
	by this patch (PHKL_30690).

	(SR: 8606331848 CR: JAGae92968)
	Problem Description :
	VERITAS Incident Number : 128348
	If some vnode of a file system is still active
	when a forced unmount is performed, the file system's
	vx_fsext structure cannot be released. This structure
	is freed later during the
	inactive processing of the last active vnode.
	In so doing, we attempt to lock vx_mayfreezelock_list.
	and if this lock has been released earlier by an cfs-deinit
	operation, the system panics.

	Resolution :
	Fixed by incrementing vx_cfs_keepcount to block
	any cfs-definit operation if there
	are still active vnodes on the force-unmounted
	file system. During the inactive processing of
	the last active vnode, reduce vx_cfs_keepcount
	after finishing with vx_mayfreezelock_list."

	(SR: 8606331849 CR: JAGae92969)
	Problem Description :
	VERITAS Incident Number : 128435
	When qlogckd is started and then deinited
	(using deinit option of qlogclustadm) multiple
	times in a loop (greater than value of
	max_thread_proc tunable), qlogckd hangs.

	Reason :
	qlogckd loops forever inside the function
	ql_msg_thread_start() trying to create message
	processing thread, thread creation fails
	because qlogckd already has threads equal
	to max_thread_proc. qlog threads exit when
	they find ql_msg_thread_stopflag is set to
	1. But ql_msg_thread_stop() does not wake up
	threads after setting ql_msg_thread_stopflag
	to 1, as a result threads do not terminate
	even after deinit.

	Resolution :
	Fixed the problem in ql_msg_thread_stop()
	by waking up threads after
	setting ql_msg_thread_stopflag to 1.

	(SR: 8606331851  CR: JAGae92971)
	Problem Description :
	VERITAS Incident Number : 128925
	Invalid buffers are not reused immediately.
	Also, free buffers are not properly reused
	because their timestamps are not correctly set.
	Thus the meta-data buffer cache easily grows to
	its maximum, i.e. vx_bc_bufhwm.

	Resolution :
	Fixed by reusing invalid buffers immediately and
	properly setting the timestamp of free buffers.

	(SR:  8606331852 CR: JAGae92972)
	Problem Description:
	VERITAS Incident Number: 130108
	qlog information is not copied over
	during a remount.

	Resolution:
	Fixed vx_fs_reinit() to copy qlog information
	during a remount.

	(SR: 8606331853 CR: JAGae92973)
	Problem Description:
	VERITAS Incident Number : 130906
	Memory is wasted in VxFS
	due to missing typedef in declaration of
	vx_cbuf_t.

	Resolution:
	Fixed by adding typedef before struct vx_cbuf.

	(SR: 8606331856 CR: JAGae92976)
	Problem Description:
	VERITAS Incident Number : 133465
	Under certain condition which involves
	only simple opening and writing to a file,
	the extended operation to shorten the file
	is unnecessary and such overhead should be avoided.

	Resolution:
	Fixed by avoiding the shorten operation
	if the right condition is matched.

	(SR:  8606331857 CR: JAGae92977)
	Problem Description:
	VERITAS Incident Number: 94258
	read(2) on a sparse file (having holes) may
	return corrupt file data if the
	file is mmaped in writable mode.

	Reason:
	In vx_read1(), if we are reading a hole in
	a mmapped file, uiomove() is called to copy
	data over based on the information in a uio
	structure. It is found
	that the uio structure is not properly updated
	when reading from an allocated extent in the
	mmapped file. So if a hole is read afterwards,
	uiomove() will end up overwriting data read
	previously because of the incorrect fields
	(in particular iov_base) in the uio structure.

	Resolution:
	Fixed by updating uio_iov->iov_base & uio_iov->iov_len
	correctly for the case when uiomove() is not used
	in vx_read1() and vx_write_default().

	PHKL_29688:
	(SR: 8606331829 CR: JAGae92949)
	Problem Description :
	VERITAS Incident Number : 109815
	Read-ahead is sometimes not performed
	for re-reads after the first re-read.
	So second re-reads will not
	benefit from read-ahead.

	Resolution :
	Fixed by scheduling read-aheads appropriately
	after the first re-read.

	PHKL_28785:
	( SR: 8606295939 CR: JAGae59576 )
	Problem Description :
	VERITAS Incident number: 117634
	For page faults over holes in a sparse file
	(mmap'ed with a writable mapping),
	VxFS allocates extents to cover the area
	of the fault in the file. The allocated
	extent is zeroed, before it can be read
	by the pagein codepath. There was a
	race whereby the newly allocated extent
	could be read directly from disk,
	before it got zeroed out.

	Reason :
	Since the allocated
	extent was zeroed before it can be read
	by the pagein codepath, there was a
	race whereby the newly allocated extent
	could be read directly from disk,
	before it got zeroed out.

	Resolution :
	All dirty buffers of a file are synchronously
	flushed in the pagein codepath. This
	guarantees that newly allocated extents
	get zeroed, before they can be read
	during pagein.

	( SR: 8606277951 CR: JAGae42012 )
	Problem Description :
	VERITAS Incident number: 111671
	vx_pageout() calls vm_pageout_init() with
	incorrect start/end values, resulting
	into poor vhand performance under
	heavy memory pressure.

	Reason :
	This defect is narrowed down to
	code in vx_pageout():

	vxfs code is calling vm_pageout_init()
	with 0, 0 instead of start and end.
	This caused the vm_info fields to be set incorrectly,
	resulting in poor vhand performance under
	memory pressure.  The memory pressure was due to
	mmap'd pregions not being paged because,
	using the incorrect values from vm_info,
	p_stealhand was set to 1
	and p_agescan was set to 0.

	Resolution :
	Changing the call to vm_pageout_init()
	to pass start and end instead
	of 0, 0 corrected the paging problems.

	( SR: 8606300118 CR: JAGae63586 )
	Problem Description :
	VERITAS Incident number: 121195 116112
	Adding support for handling i/o fencing :

	Split brain is an issue faced by all cluster
	solutions. To provide high availability,
	the cluster must be capable of taking
	corrective action when a node fails.
	However, problems arise when the mechanism
	used to detect the failure of a node breaks
	down. The symptoms look identical
	to a failed node. This typically results in
	data corruption when both nodes attempt
	to take control of data storage in an
	uncoordinated manner. This feature is
	only for CFS but not for local mount
	VxFS.

	Reason :
	If a system in a two node cluster
	were to fail, it would stop sending
	heartbeats over the private
	interconnects and the remaining node
	would take corrective action.
	However, the failure of the private
	interconnects would present identical
	symptoms. In this case, both nodes would
	determine that their peer has departed
	and attempt to take corrective action.
	Other scenarios could be where a
	system were so busy as to appear hung,
	it would be declared dead.
	On systems were the hardware supports
	a "break" and "resume" function,
	dropping the system to firmware and
	subsequently resuming means that system
	could be declared dead, the cluster would
	reform and when the system returns,
	it could begin writing again.

	Resolution :
	I/O fencing technology removes the risk
	associated with split brain.
	I/O fencing blocks access to storage
	from specific nodes. This means even
	if the node is alive, it cannot cause damage.

	Problem Description :
	VERITAS Incident number: 105999
	Snapshot file system shows unexpected
	ENXIO errors :

	The problem is narrowed down to getblk()
	on snapshot file system returning without
	proper disk contents. vx_ivalidate() from
	vx_iread() fails on the directory inode
	which is being read. This is possible only
	if getblk() of ilist files returned garbage
	instead of valid ilist contents on the
	snapshot file system.

	Reason :
	This is a serious bug which got introduced
	through fixing another bug.

	In the following code fragment :

	naubase = (int)(stateoff >> VX_SMAPSHIFT);

	<snip>

	nauilim = stateextsz >> VX_SMAPSHIFT;

	 if ((naubase + nauilim) > dv->dv_nau) {
	     nauilim = dv->dv_nau - naubase;

	stateoff, stateextsz are byte offset and size
	of au state map file extent and its getting
	right shifted by VX_SMAPSHIFT
	instead of left shift. As a result of which
	naubase and naulim calculations are
	wrong and there is corruption of snapshot
	bitmap while marking free blocks.

	Another problem is in the `for' loop of
	vx_snap_statefreeblk() which iterates
	over range of AUs.

	     <snip>
	for (naui = 0; naui < nauilim; naui++) {
	 nbyte = (naubase + naui) >> VX_SMAPSHIFT;
	 bitoff = ((naubase + naui) & VX_SMAPMASK) << 1;

	For multi-extent SMAP files,
	((naubase + naui) >> VX_SMAPSHIFT)
	goes beyond the size of the SMAP
	buffer passed to this function.

	Resolution :
	Fixed at both the places by changing the
	RIGHT SHIFTS to LEFT SHIFTS.

	Problem Description :
	VERITAS Incident number: 117379 116429 117163
				 114721
	Low throughput and ultimately no I/O
	happening through fdd :

	fdd I/O happens by queuing buffers
	in work-lists and then fdd threads
	dequeue buffers from the list.
	If fdd threads are not created,
	these buffers will never be dequeued
	and I/O will not happen through fdd.
	If only small number of threads could
	be created, throughput will be very
	low.

	1.If EAGAIN or other error is returned
	by thread_create() (which might happen
	due to very heavy load or incorrectly
	set max_thread_proc tunable or
	low memory etc.), no fdd thread is ever
	created in future for that list and as a
	result no further I/O happens for the list.

	2.fdd thread creation does not succeed
	even after retrying for a very long time
	if VxFS was heavily loaded in the past.
	Number of alive VxFS flushing threads
	should have come down after
	VX_THR_DECR_TIMELAG interval (300 secs)
	if that many threads were not required,
	i.e., load on VxFS has decreased.
	But it was not happening and threads were
	not stopped after waiting for a very long time.

	3.fdd thread creation fails if there is
	heavy load on VxFS or in other terms,
	number of VxFS flushing threads present
	equals max number of allowed VxFS flushing
	threads (vx_maxworkthreads).

	4. VxFS may create new threads unnecessarily
	even when enough flushing threads are already
	present. It results in increased VxFS flushing
	threads which may block creation of
	fdd/DMAPI threads and
	increased CPU/memory consumption.

	Reason :
	1.Function fdd_thread_create() does not reset
	wlist->fwl_creating variable for the list if
	error is returned by thread_create(). The
	function does not attempt to create threads
	if fwl_creating is set for the list assuming that
	some other thread is currently creating threads.
	Thus no thread can be created in future
	for that list once error is returned
	by thread_create().

	2. Function vx_sched_thread() decreases number
	of required flushing threads after
	VX_THR_DECR_TIMELAG interval by calling
	vx_workthread_set() which reduces vx_nworkthreads.
	VxFS thread stops it it sees that its thread-id is
	greater than vx_nworkthreads but this logic requires
	all threads to be woken up which was missing.

	3.VxFS limits number of threads for vxfsd
	process by calling VX_KTHREADS_MAX()
	(kthread_daemon_max_thread_proc) in function
	vx_postinit() to vx_maxworkthreads but that
	many flushing threads can be created under heavy
	load and fdd thread creation fails because of this
	limit. The limit does not take fdd or DMAPI
	threads into account.

	4. Function vx_workthread_set() creates more
	threads every-time it is called with nthreads
	greater than vx_nworkthreads. This happens
	because of following piece of code:

	STATIC void
	vx_workthread_set(nthreads)
		int             nthreads;
	{
	<snip>

	vx_nworkthreads = nthreads;
	  VX_CACHE_WRITE_SYNC();
	   while (old_nthreads < nthreads) {
	   VX_THREAD_LOCK(&ipl);
	   if (vx_flushing_threads > vx_maxworkthreads) {
	    VX_THREAD_UNLOCK(ipl);
	    old_nthreads++;
	    continue;
	    }
	    vx_flushing_threads++;
	    VX_THREAD_UNLOCK(ipl);
	    err = vx_workthread_create(old_nthreads++);

	<snip>
	}

	Here if above condition is not serving any purpose
	because function vx_sched_thread() ensures
	that vx_workthread_set() is never called with
	a value which is greater than vx_maxworkthreads
	and as a result vx_flushing_threads should be
	less than vx_maxworkthreads. It should
	rather check for old_nthreads.

	Resolution :
	1.Fixed function fdd_thread_create() by
	retrying creation of thread if thread_create()
	returns EAGAIN and resetting wlist->fwl_creating
	before returning other errors.

	2.Fixed by waking up all the flushing threads
	when vx_nworkthreads is reduced after
	VX_THR_DECR_TIMELAG interval in
	function vx_sched_thread.

	3.Raised the max thread limit for VxFS
	to vx_maxworkthreads + 64.
	This allows upto 64 extra threads
	for fdd and DMAPI even when max
	flushing threads are present.

	4.Fixed the if condition in function
	vx_workthread_set() to :
	if (vx_flushing_threads > old_nthreads)
	So now new threads will be created only
	when that many flushing threads
	do not exist.

	Problem Description :
	VERITAS Incident number: 120439
	The problem occurs when a chunk (128k)
	of buffer is freed from a
	buffer subfreelist. A chunk of buffer
	can be freed in 2 circumstances,
	periodically when the buffers in the
	chunk have aged sufficiently and
	when the memory is stealed from a
	subfreelist that meets some criteria.
	As part of releasing the buffer,
	threads are determined which are
	waiting for the buffer in the buffer's
	hash chain derived on the hash
	chain field of the buffer.Any waiters are
	woken up by issuing a broadcast.

	Because of the bug, wrong locks are held
	while certain fields are manipulated
	in the hash chain structure that is used to
	indicate if there are any waiters.
	And also the waiters are woken up
	spuriously even when the buffer it is
	waiting for is actualy not free.
	This can result in a race leading to
	missed wakeups.

	Reason :
	The bug is that clearing of the
	buffer's hash chain fails, when it is pulled
	off of the hash chain. This will result
	in holding the wrong buffer
	freelist lock when the buffer is
	released and all the problems
	described above.

	Resolution :
	The fix is simply to clear the buffer's
	hash chain when it is pulled off
	of the hash chain.

	Problem Description :
	VERITAS Incident number: 116699
	While debugging problems in VxFS 3.5,
	there is no  clue as to
	which thread is holding a given
	buffer in exclusive  mode.

	Reason :
	Prior to VxFS3.5, the owner information
	which will assist debugging problems
	was stored. But in VxFS3.5, the code
	for storing the above information has been
	removed .

	Resolution :
	Re-introduced the code to store
	the owner  information.

	Problem Description :
	VERITAS Incident number: 104036 120116
	VxFS(CFS) and Qlog register with GAB
	and they never unregister. Since VxFS and Qlog
	are not dlkm's the customer would require
	an extra reboot when trying to deinstall SPFS.

	Reason :
	There was no mechanism by which CFS
	and Qlog can deregister from GAB.

	Resolution :
	The 'fsclustadm' and the 'qlogclustadm commands
	have been enhanced with a new option
	which will deregister VxFS and Qlog
	from gab ports. The vx_admin_ioctl
	has been enhanced to accept a new
	ioctl command VX_CFS_DEINIT and similarly,
	the ql_clust_ioctl has been enhanced to accept
	a new ioctl command QL_CLUST_DEINIT.
	With the help of these new cli's and ioctls
	VxFS and Qlog are capable of deregistering
	from GAB port 'f' and 'q' respectively.

	Problem Description:
	VERITAS Incident number: 124065
	While uninstalling DBED/AC nodes in the
	cluster panic. Data page fault occurs on
	cluster nodes, incase of split brain
	scenario.

	Reason:
	VOP_IOCTL() call in vx_vxfen_ping()
	expects a pointer to a pointer of
	vxfen_node_stat_t wheras currently
	it takes only a vxfen_node_stat_e pointer.

	Resolution:
	Fixed the inconsistency in the arguments
	VOP_IOCTL() call in vx_vxfen_ping() takes.

	PHKL_28503:

	( SR: 8606281794  CR: JAGae45737 )
	Problem Description :
	VERITAS Incident number: 109514
	The problem arises because of the deadlock between threads
	simultaneously involved in activity on a memory mapped
	file or deadlock between threads involved in activity on a
	memory mapped file and another thread involved in
	file-system freezing activity
	(for example, while creating a snapshot).
	The deadlocked threads do not allow vhand to reclaim
	pages from the memory mapped file and drive the system
	into low memory condition.

	Reason :
	The read and write code paths violated the locking
	hierarchy between page lock and getpage lock and the
	pagein and pageout code paths violated the
	region lock and active level acquisition hierarchy.

	Resolution :
	Corrected the locking hierarchy in
	concerned code paths.

	( SR: 8606291859  CR: JAGae55623 )
	Problem Description :
	VERITAS Incident number: 109889
	VERITAS Quick I/O matches the throughput of raw devices
	on the TPC-C benchmark. However, if a storage
	checkpoint is created on the file-system holding
	the database files then the TPC-C
	transaction throughput drops drastically.

	Reason :
	In the presence of a storage checkpoint, a write
	to the database quick i/o file would require
	copying the old data to the storage checkpoint,
	if it is not already copied. VxFS acheives this through
	a file system transaction that is logged in the intent log.
	The intent log is then flushed to disk.
	Each asynchronous write to
	the database quick i/o file would
	result in a synchronous
	flush to copy the old data to the storage
	checkpoint. This can cause a severe
	performance degradation due to overhead of
	flushing the intent log for each write.

	Resolution :
	For asynchronous io, it is possible to delay flushing of
	the intent log to disk till we can batch several other
	transactions written to the intent log. This amortizes
	teh overhead of the intent log write over several
	asynchronous io and thus improves performance.

	PHKL_29212:

	(SR:8606313751 CR:JAGae76543)

	Problem Description :
	VERITAS Incident number : 117663
	This problem is seen only when any file in the
	cluster file-system was mmapped in read-write
	mode and had dirty pages at the time of
	force unmount. Problem can be reproduced by
	mmaping a file in read-write mode and then
	issuing force unmounting just after the page
	is written.

	Reason :
	Force unmount first freezes the file-system
	and tries to de-init inodes via vx_idrop_nofree().
	Glock revoke happens when glock
	in the cluster inode is deinited by glm,
	which triggers pageouts if dirty pages are present
	but pageout can not take active levels till
	file-system is frozen. This results in deadlock
	in force unmount while file-system is frozen.
	Resolution :
	Now pages are not flushed/invalidated/purged
	during glm revoke (in vx_glock_putdata())
	if file-system is being force unmounted.

	(SR :8606313752 CR:JAGae76544 )
	Problem Description :
	Veritas Incident number : 125630
	This problem is seen only when a file in the
	cluster file-system was mmapped on two nodes
	and pages on one nodes were being read when
	freeze is in progress while dirty pages were
	present on the second node. In short, this may
	be reproduced when there is a race between
	freeze and pageout (happening on other node
	due to pagein of one node).

	Reason :
	Both vx_pagein() and vx_pageout() take active
	level 4 on HP. Suppose freeze-level was
	3 (cluster-wide) when pagein happened on node 1;
	node 2 had dirty pages for same file so
	vx_pageout() was called on node 2
	during glock revoke processing.
	But by that time, active level 4 was
	blocked by ongoing freeze on node 2,
	so pageout on node 2 can not proceed
	till file-system is completely frozen and
	then thawed. Thus there is a deadlock between
	freeze and pageout due to pagein on other node.

	Resolution :
	vx_pageout() now takes active level 5
	(one higher than vx_pagein()).

	(SR:8606311410 CR:JAGae74247)
	Problem Description :
	VERITAS Incident number : 125027
	Two NetBackup threads running on VxFS3.5
	result in a deadlock. One of them owns a
	buffer but want a pfdat lock.
	The other has pfdat lock but want the buffer.
	This problem cannot be reproduced easily.

	Reason :
	In normal read/write code path buffer is locked
	first and then pages. But in dio code path
	pages are locked first and then the buffer.
	This locking disorder results in a deadlock.

	Resolution :
	Fixed by releasing the pages(in dio code path)
	if buffer is already locked, and following the
	usual read/write code path.

Enhancement:
	No (superseded patches contained enhancements)
	PHKL_28785:
		This patch includes a new feature
		by providing support
		for handling i/ofencing, to enhance
		jeopardy handling in Cluster File System.
		This is an enhancement which
		affects only CFS and NOT local mount VxFS.

SR:
	8606331825 8606331826 8606331827 8606331828 8606331829
	8606331830 8606331831 8606331833 8606331835 8606331836
	8606331838 8606331839 8606331840 8606331843 8606331844
	8606331845 8606331847 8606331848 8606331849 8606331851
	8606331852 8606331853 8606331856 8606331857 8606295939
	8606277951 8606300118 8606281794 8606291859 8606313751
	8606313752 8606311410 8606326970 8606284882 8606304072
	8606338973 8606338975 8606338978 8606351775 8606359937
	8606359941 8606359942 8606347755 8606344712 8606343270
	8606355334 8606206142 8606366078 8606366079 8606366080
	8606366082 8606366083 8606366084 8606366085 8606366086
	8606337509

Patch Files:
	
	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=HP:

	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=VERITAS:
	/usr/conf/lib/libvxfs35.a(kdm_core.o)
	/usr/conf/lib/libvxfs35.a(vx_attr.o)
	/usr/conf/lib/libvxfs35.a(kdm_osdep.o)
	/usr/conf/lib/libvxfs35.a(vx_locks.o)
	/usr/conf/lib/libvxfs35.a(vx_fsetsubr.o)
	/usr/conf/lib/libvxfs35.a(vx_reorg.o)
	/usr/conf/lib/libvxfs35.a(vx_vm.o)
	/usr/conf/lib/libvxfs35.a(vx_io.o)
	/usr/conf/lib/libvxfs35.a(vx_acl.o)
	/usr/conf/lib/libvxfs35.a(vx_portal.o)
	/usr/conf/lib/libvxfs35.a(vx_lwrite.o)
	/usr/conf/lib/libvxfs35.a(vx_dnlc.o)
	/usr/conf/lib/libvxfs35.a(vx_bmapext4.o)
	/usr/conf/lib/libvxfs35.a(vx_itrunc.o)
	/usr/conf/lib/libvxfs35.a(vx_inode.o)
	/usr/conf/lib/libvxfs35.a(vx_osvnops.o)
	/usr/conf/lib/libvxfs35.a(fdd_common.o)
	/usr/conf/lib/libvxfs35.a(fdd_io.o)
	/usr/conf/lib/libvxfs35.a(fdd_osdep.o)
	/usr/conf/lib/libvxfs35.a(fdd_thread.o)
	/usr/conf/lib/libvxfs35.a(vx_iflush.o)
	/usr/conf/lib/libvxfs35.a(vx_osdep.o)
	/usr/conf/lib/libvxfs35.a(vx_rdwri.o)
	/usr/conf/lib/libvxfs35.a(vx_snap.o)
	/usr/conf/lib/libvxfs35.a(vx_bcache.o)
	/usr/conf/lib/libvxfs35.a(vx_config.o)
	/usr/conf/lib/libvxfs35.a(vx_glm.o)
	/usr/conf/lib/libvxfs35.a(vx_cfsaioctl.o)
	/usr/conf/lib/libvxfs35.a(vx_cvmres.o)
	/usr/conf/lib/libvxfs35.a(vx_cfsmsg.o)
	/usr/conf/lib/libvxfs35.a(vx_vfsops.o)
	/usr/conf/lib/libvxfs35.a(ql_cluster.o)
	/usr/conf/lib/libvxfs35.a(ql_admin.o)
	/usr/conf/lib/libvxfs35.a(ql_msg.o)
	/usr/conf/lib/libvxfs35.a(ql_osdep.o)
	/usr/conf/lib/libvxfs35.a(vx_cfsinode.o)
	/usr/conf/lib/libvxfs35.a(vx_bio1.o)
	/usr/conf/lib/libvxfs35.a(vx_dio.o)
	/usr/conf/lib/libvxfs35.a(vx_mount.o)
	/usr/conf/lib/libvxfs35.a(vx_cview.o)
	/usr/conf/lib/libvxfs35.a(vx_bsdquota.o)
	/usr/conf/lib/libvxfs35.a(vx_bmaptyped.o)
	/usr/conf/lib/libvxfs35.a(vx_crdwri.o)
	/usr/conf/lib/libvxfs35.a(vx_identstrings.o)

what(1) Output:
	
	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=HP:
	/usr/conf/lib/libvxfs35.a(kdm_core.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_attr.o):
		None
	/usr/conf/lib/libvxfs35.a(kdm_osdep.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_locks.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_fsetsubr.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_reorg.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_vm.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_io.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_identstrings.o):
		vxfs:src/common/kernel/fdd/fdd_ted.h 3.2
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_prot
			o.h $Date: 11/29/02 02:57:24 $Revision: 3.28
			.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_osde
			p.h $Date: 11/29/02 03:02:45 $Revision: 3.32
			.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/fdd/fdd_iotrace.h 3.9
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_io.h
			 3.3
		vxfs:src/common/kernel/fdd/fdd_common.h 3.21
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_aioc
			tl.h 3.5
		vxfs:src/unix/bufcache/hp/11.11/kernel/fdd/fdd.h 3.3
		vxfs:src/unix/bufcache/hp/common/kernel/qlog/ql_tedl
			ocal.h 3.3
		vxfs:src/common/kernel/qlog/ql_ted.h 3.8
		vxfs:src/unix/bufcache/hp/common/kernel/base/qlog.h 
			3.4
		gfs:src/common/kernel/base/vx_kioctl.h 3.3
		vxfs:src/unix/bufcache/hp/common/kernel/base/vxio.h 
			3.5
		vxfs:src/unix/bufcache/hp/11.11/kernel/base/vxfs.h $
			Date: 02/24/03 13:23:32 $Revision: 3.33.53.1
			 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_vrt.h 3.31
		vxfs:src/common/kernel/base/vx_vnopsmsg.h 3.26
		vxfs:src/common/kernel/base/vx_types.h 3.16
		vxfs:src/common/kernel/base/vx_tran.h 3.61
		vxfs:src/common/kernel/base/vx_tioctl.h 3.51
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_tedl
			ocal.h 3.22.53.2
		vxfs:src/common/kernel/base/vx_ted.h 3.228.53.1
		vxfs:src/common/kernel/base/vx_sysmacros.h 3.22
		vxfs:src/common/kernel/base/vx_stubs.h 3.6
		vxfs:src/common/kernel/base/vx_rpcmsg.h 3.32
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_quot
			a.h 3.4
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_prot
			o.h $Date: 06/03/04 05:52:31 $Revision: 3.33
			1.53.8 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_param.h $Date: 04/12/
			04 08:02:24 $Revision: 3.93.53.2 PATCH_11.11
			 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/11.11/kernel/base/vx_osrel
			.h 3.14
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_osde
			p.h $Date: 05/12/04 04:04:25 $Revision: 3.12
			6.53.3 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_name
			space.h 3.5
		vxfs:src/common/kernel/base/vx_mlink.h 3.21
		vxfs:src/common/kernel/base/vx_mfl.h 3.3
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_mach
			dep.h 3.6.53.2
		vxfs:src/common/kernel/qlog/ql_msg.h 3.11
		vxfs:src/common/kernel/qlog/ql_admin.h $Date: 04/08/
			03 03:26:57 $Revision: 3.5.53.1 PATCH_11.11 
			(PHKL_30690)
		vxfs:src/common/kernel/qlog/ql_cluster.h $Date: 04/0
			8/03 03:26:35 $Revision: 3.14.53.1 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/qlog/ql_ioct
			l.h 3.8
		vxfs:src/common/kernel/qlog/ql_kcommon.h 3.11
		vxfs:src/common/kernel/qlog/ql_common.h 3.29
		vxfs:src/unix/bufcache/hp/common/kernel/qlog/ql_osde
			p.h 3.20
		vxfs:src/common/kernel/base/vx_logbuf.h 3.12
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_lock
			s.h 3.27.53.2
		vxfs:src/common/kernel/base/vx_license.h 3.16
		vxfs:src/common/kernel/base/vx_layout.h 3.87
		vxfs:src/common/kernel/base/vx_kdmi.h 3.9
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_ioct
			l.h 3.19
		vxfs:src/common/kernel/base/vx_inode.h 3.165
		vxfs:src/common/kernel/base/vx_info.h 3.55
		vxfs:src/common/kernel/base/vx_glmlockcache.h 3.2
		vxfs:src/common/kernel/base/vx_glm.h 3.17
		vxfs:src/common/kernel/base/vx_genlock.h 3.11
		vxfs:src/unix/bufcache/hp/common/kernel/base/glmosde
			p.h 3.8
		glm:src/common/kernel/base/glmkrlapi.h 3.12
		glm:src/common/kernel/base/glmhdr.h 3.14
		vxfs:src/unix/bufcache/hp/common/kernel/base/gabosde
			p.h 3.7
		vxfs:src/common/kernel/base/gabkrl.h 3.4
		vxfs:src/common/kernel/base/gabhdr.h 3.4
		vxfs:src/common/kernel/base/gaberrno.h 3.3
		vxfs:src/common/kernel/base/vx_fs.h $Date: 06/30/03 
			03:20:29 $Revision: 3.200.53.1 PATCH_11.11 (
			PHKL_30690)
		vxfs:src/common/kernel/base/vx_extern.h $Date: 05/12
			/04 04:04:20 $Revision: 3.108.53.3 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_ext.h 3.17
		vxfs:src/common/kernel/base/vx_dnlc.h 3.7
		vxfs:src/common/kernel/base/vx_dll.h 3.2
		vxfs:src/common/kernel/base/vx_disklog.h 3.34
		vxfs:src/common/kernel/base/vx_cwfa.h 3.11
		vxfs:src/common/kernel/base/vx_csm.h 3.6
		vxfs:src/common/kernel/base/vx_cque.h 3.2
		vxfs:src/common/kernel/base/vx_copy.h 3.40
		vxfs:src/common/kernel/base/vx_const.h 3.28
		vxfs:src/common/kernel/base/vx_cfsupgrade.h 3.4
		vxfs:src/common/kernel/base/vx_cfssnap.h 3.3
		vxfs:src/unix/common/kernel/base/vx_cfsrdwri.h 3.10
		vxfs:src/unix/common/kernel/base/vx_cfsops.h 3.29
		vxfs:src/common/kernel/base/vx_cfsmsg.h 3.33
		vxfs:src/common/kernel/base/vx_cfsmount.h 3.27
		vxfs:src/common/kernel/base/vx_cfslocks.h 3.12
		vxfs:src/common/kernel/base/vx_cfsinode.h 3.40
		vxfs:src/common/kernel/base/vx_cfsiclone.h 3.18
		vxfs:src/common/kernel/base/vx_cfsfset.h 3.15
		vxfs:src/common/kernel/base/vx_cfsaioctl.h $Date: 04
			/08/03 03:25:26 $Revision: 3.15.53.1 PATCH_1
			1.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cfs.h 3.47
		vxfs:src/common/kernel/base/vx_cbdnlc.h 3.4
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_buf.
			h 3.28
		vxfs:src/common/kernel/base/vx_bsdquota.h 3.22
		vxfs:src/common/kernel/base/vx_bmap.h 3.13
		vxfs:src/common/kernel/base/vx_bitmaps.h 3.16
		vxfs:src/common/kernel/base/vx_assumption.h 3.6
		vxfs:src/common/kernel/base/vx_alert.h 3.7
		vxfs:src/common/kernel/base/vx_aioctl.h 3.113
		vxfs:src/common/kernel/dmapi/kdm_vnode.h 3.13
		vxfs:src/unix/bufcache/hp/common/kernel/dmapi/kdm_pr
			oto_osdep.h 3.2
		vxfs:src/common/kernel/dmapi/kdm_proto.h 3.24
		vxfs:src/unix/bufcache/hp/common/kernel/dmapi/kdm_os
			dep.h 3.2
		vxfs:src/common/kernel/dmapi/kdm_hsm.h 3.29
		vxfs:src/common/kernel/dmapi/kdm_dmi.h 3.21
		vxfs:src/common/kernel/dmapi/kdm_dll.h 3.7
		vxfs:src/common/kernel/dmapi/kdm_copy.h 3.13
		vxfs:src/unix/bufcache/hp/11.11/kernel/dmapi/dmattr_
			drv.h 3.7
		vxfs:src/unix/bufcache/hp/11.11/kernel/dmapi/dmapiki
			nc.h 3.2
		vxfs:src/unix/bufcache/hp/11.11/kernel/dmapi/dmapiin
			c.h 3.2
		vxfs:src/unix/bufcache/hp/common/kernel/dmapi/dmapi_
			size.h 3.2
		vxfs:src/common/kernel/dmapi/dmapi.h 3.19
		vxfs:src/common/kernel/dmsample/dm_sample_dmattr.h 3
			.4
		vxfs:src/common/kernel/fdd/fdd_ted.c 3.3
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_vnop
			s.c 3.19
		vxfs:src/common/kernel/fdd/fdd_thread.c $Date: 02/20
			/03 22:30:14 $Revision: 3.25.53.1 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_osde
			p.c $Date: 11/29/02 02:47:07 $Revision: 3.68
			.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/fdd/fdd_odm.c 3.11
		vxfs:src/common/kernel/fdd/fdd_iotrace.c 3.24
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd_io.c
			 $Date: 12/10/03 04:52:41 $Revision: 3.60.53
			.6 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/fdd/fdd_common.c $Date: 09/18
			/03 04:48:58 $Revision: 3.86.53.2 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/fdd/fdd.c 3.
			2
		vxfs:src/common/kernel/qlog/ql_msg.c $Date: 06/30/03
			 07:02:47 $Revision: 3.42.53.2 PATCH_11.11 (
			PHKL_30690)
		vxfs:src/common/kernel/qlog/ql_admin.c $Date: 04/08/
			03 03:26:46 $Revision: 3.45.53.1 PATCH_11.11
			 (PHKL_30690)
		vxfs:src/common/kernel/qlog/ql_cluster.c $Date: 04/0
			8/03 03:26:25 $Revision: 3.23.53.1 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/common/kernel/qlog/ql_lock.c 3.6
		vxfs:src/common/kernel/qlog/ql_ted.c 3.15
		vxfs:src/common/kernel/qlog/ql_cls.c 3.15
		vxfs:src/common/kernel/qlog/ql_map.c 3.10
		vxfs:src/common/kernel/qlog/ql_vxfs.c 3.24
		vxfs:src/common/kernel/qlog/ql_wrk.c 3.20
		vxfs:src/common/kernel/qlog/ql_sup.c 3.15
		vxfs:src/common/kernel/qlog/ql_cfg.c 3.41
		vxfs:src/common/kernel/qlog/ql_log.c 3.26
		vxfs:src/common/kernel/qlog/ql_dbg.c 3.7
		vxfs:src/common/kernel/qlog/ql_trc.c 3.8
		vxfs:src/common/kernel/qlog/ql_copy.c 3.14
		vxfs:src/unix/bufcache/hp/common/kernel/qlog/ql_osde
			p.c $Date: 04/08/03 03:27:32 $Revision: 3.35
			.53.2 PATCH_11.11 (PHKL_30690)
		gfs:src/common/kernel/base/vx_kioctl.c 3.10
		vxfs:src/common/kernel/base/vx_vrt.c 3.94
		vxfs:src/common/kernel/base/vx_vnopsmsg.c 3.122
		vxfs:src/unix/common/kernel/base/vx_vnops.c 3.52
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_vm.c
			 $Date: 05/06/04 03:39:44 $Revision: 3.41.53
			.10 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_vfso
			ps.c $Date: 04/08/03 03:26:14 $Revision: 3.1
			10.53.4 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_upgr
			ade3.c 3.17
		vxfs:src/common/kernel/base/vx_upgrade2.c 3.69
		vxfs:src/common/kernel/base/vx_upgrade1.c 3.47
		vxfs:src/common/kernel/base/vx_uioctl.c 3.69
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_tune
			.c 3.23
		vxfs:src/common/kernel/base/vx_tran.c 3.169
		vxfs:src/common/kernel/base/vx_tioctl.c 3.104
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_swap
			.c 3.10
		vxfs:src/common/kernel/base/vx_cfsstubs.c 3.5
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_stra
			tegy.c 3.27
		vxfs:src/unix/common/kernel/base/vx_snap_mount.c 3.3
			6
		vxfs:src/common/kernel/base/vx_snap.c $Date: 12/30/0
			3 00:00:59 $Revision: 3.102.53.3 PATCH_11.11
			 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_sar.c 3.21
		vxfs:src/common/kernel/base/vx_resize.c 3.67
		vxfs:src/common/kernel/base/vx_reorg.c $Date: 11/04/
			03 22:31:09 $Revision: 3.157.53.1 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_rdwr
			i.c $Date: 06/03/04 05:52:48 $Revision: 3.11
			3.53.13 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_rcfgmount.c 3.50
		vxfs:src/common/kernel/base/vx_quota.c 3.47
		vxfs:src/common/kernel/base/vx_qlog.c 3.12
		vxfs:src/unix/bufcache/hp/common/kernel/vxportal/vx_
			portal.c $Date: 09/19/03 01:35:13 $Revision:
			 3.24.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_osvn
			ops.c $Date: 04/23/04 01:27:02 $Revision: 3.
			114.53.6 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/11.11/kernel/base/vx_osrel
			.c 3.11
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_osde
			p.c $Date: 05/12/04 04:04:24 $Revision: 3.11
			4.53.10 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_oltmount.c 3.149
		vxfs:src/common/kernel/base/vx_odmioctl.c 3.3
		vxfs:src/common/kernel/base/vx_odm.c 3.22
		vxfs:src/common/kernel/base/vx_namespace.c 3.15
		vxfs:src/unix/common/kernel/base/vx_multifs.c 3.26
		vxfs:src/common/kernel/base/vx_mount.c $Date: 09/18/
			03 04:32:37 $Revision: 3.391.53.6 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_mfl.c 3.7
		vxfs:src/common/kernel/base/vx_message.c 3.57
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_mach
			dep.c 3.2
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_lwri
			te.c $Date: 06/03/04 00:04:00 $Revision: 3.3
			2.53.3 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_log.c 3.69
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_lock
			s.c $Date: 11/05/03 00:58:03 $Revision: 3.10
			.53.3 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_lite.c 3.45
		vxfs:src/common/kernel/base/vx_lct.c 3.40
		vxfs:src/common/kernel/base/vx_kernrdwri.c 3.36
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_kdmi
			_osdep.c 3.12
		vxfs:src/common/kernel/base/vx_kdmi.c 3.112
		vxfs:src/common/kernel/base/vx_itrunc.c $Date: 09/17
			/03 06:39:54 $Revision: 3.130.53.1 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_io.c $Date: 06/03/04 
			05:52:00 $Revision: 3.6.53.4 PATCH_11.11 (PH
			KL_30690)
		vxfs:src/common/kernel/base/vx_inode.c $Date: 05/24/
			04 03:59:53 $Revision: 3.446.53.8 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_iflush.c $Date: 05/12
			/04 04:04:21 $Revision: 3.272.53.3 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_iclone.c 3.288
		vxfs:src/common/kernel/base/vx_ialloc.c 3.77
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_hsm_
			vnops.c 3.8
		vxfs:src/common/kernel/base/vx_glmlockcache.c 3.5
		vxfs:src/common/kernel/base/vx_glm.c $Date: 02/11/04
			 23:34:04 $Revision: 3.57.53.2 PATCH_11.11 (
			PHKL_30690)
		vxfs:src/common/kernel/base/vx_genlock.c 3.16
		vxfs:src/common/kernel/base/vx_full.c 3.179
		vxfs:src/common/kernel/base/vx_fsetsubr.c $Date: 11/
			05/03 01:46:37 $Revision: 3.232.53.2 PATCH_1
			1.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_fset.c 3.257
		vxfs:src/common/kernel/base/vx_freeze.c 3.210.53.1
		vxfs:src/common/kernel/base/vx_doextop.c 3.86
		vxfs:src/common/kernel/base/vx_dnlc.c $Date: 09/16/0
			3 04:17:35 $Revision: 3.11.53.1 PATCH_11.11 
			(PHKL_30690)
		vxfs:src/common/kernel/base/vx_dmattr.c 3.17
		vxfs:src/common/kernel/base/vx_dirsort.c 3.60
		vxfs:src/common/kernel/base/vx_dirop.c 3.89
		vxfs:src/common/kernel/base/vx_dirl.c 3.59
		vxfs:src/common/kernel/base/vx_dira.c 3.73
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_dio.
			c $Date: 04/23/04 04:45:09 $Revision: 3.31.5
			3.4 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cwfreeze.c 3.48
		vxfs:src/common/kernel/base/vx_cwfa.c 3.38
		vxfs:src/common/kernel/base/vx_cvmres.c $Date: 04/08
			/03 03:25:36 $Revision: 3.4.53.1 PATCH_11.11
			 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_cvie
			w.c $Date: 06/30/03 03:18:11 $Revision: 3.19
			.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cut.c 3.52
		vxfs:src/common/kernel/base/vx_csm.c 3.13
		vxfs:src/unix/common/kernel/base/vx_crdwri.c $Date: 
			06/01/04 02:49:09 $Revision: 3.5.53.1 PATCH_
			11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_copy.c 3.91
		vxfs:src/common/kernel/base/vx_config.c $Date: 09/16
			/03 20:00:07 $Revision: 3.140.53.4 PATCH_11.
			11 $Date: 09/16/03 20:00:07 $Revision: (PHKL
			_30690) PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_chai
			n.c 3.17
		vxfs:src/common/kernel/base/vx_cfsupgrade.c 3.4
		vxfs:src/common/kernel/base/vx_cfssubr.c 3.16
		vxfs:src/common/kernel/base/vx_cfssnap.c 3.13
		vxfs:src/common/kernel/base/vx_cfsmsg.c $Date: 02/11
			/04 23:31:44 $Revision: 3.125.53.2 PATCH_11.
			11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cfsmount.c 3.131
		vxfs:src/unix/common/kernel/base/vx_cfsops.c 3.43
		vxfs:src/common/kernel/base/vx_cfsinode.c $Date: 05/
			24/03 01:45:48 $Revision: 3.254.53.1 PATCH_1
			1.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cfsiflush.c 3.70
		vxfs:src/common/kernel/base/vx_cfsiclone.c 3.63
		vxfs:src/common/kernel/base/vx_cfsfset.c 3.60
		vxfs:src/common/kernel/base/vx_cfsfilelock.c 3.15
		vxfs:src/common/kernel/base/vx_cfsaioctl.c $Date: 04
			/08/03 03:25:14 $Revision: 3.38.53.1 PATCH_1
			1.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_cbuf.c 3.24
		vxfs:src/common/kernel/base/vx_cbdnlc.c 3.11
		vxfs:src/common/kernel/base/vx_vfms.c 3.25
		vxfs:src/common/kernel/base/vx_bsdquota.c $Date: 05/
			12/04 04:04:18 $Revision: 3.139.53.1 PATCH_1
			1.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_bsdq
			subr.c 3.15
		vxfs:src/common/kernel/base/vx_bmaptyped.c $Date: 05
			/20/04 03:53:07 $Revision: 3.123.53.1 PATCH_
			11.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_bmaptops.c 3.17
		vxfs:src/common/kernel/base/vx_bmapext4.c $Date: 09/
			18/03 03:14:51 $Revision: 3.56.53.1 PATCH_11
			.11 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_bmap.c 3.43
		vxfs:src/common/kernel/base/vx_bitmaps.c 3.57
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_bio1
			.c $Date: 06/06/03 11:32:39 $Revision: 3.21.
			53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_file
			bio.c 3.17
		vxfs:src/common/kernel/base/vx_bio.c 3.33
		vxfs:src/common/kernel/base/vx_bcache.c $Date: 07/07
			/03 00:49:12 $Revision: 3.23.53.3 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_ausum.c 3.45
		vxfs:src/common/kernel/base/vx_attr.c $Date: 04/23/0
			4 04:44:14 $Revision: 3.144.53.1 PATCH_11.11
			 (PHKL_30690)
		vxfs:src/common/kernel/base/vx_assumption.c 3.121
		vxfs:src/common/kernel/base/vx_alloc.c 3.65
		vxfs:src/common/kernel/base/vx_alert.c 3.18
		vxfs:src/common/kernel/base/vx_aioctl.c 3.141
		vxfs:src/unix/bufcache/hp/common/kernel/base/vx_acl.
			c $Date: 09/22/03 22:40:23 $Revision: 3.34.5
			3.2 PATCH_11.11 (PHKL_30690)
		vxfs:src/unix/bufcache/hp/common/kernel/dmapi/kdm_os
			dep.c $Date: 10/01/03 08:26:36 $Revision: 3.
			6.53.1 PATCH_11.11 (PHKL_30690)
		vxfs:src/common/kernel/dmapi/kdm_core.c $Date: 04/22
			/04 22:46:10 $Revision: 3.67.53.1 PATCH_11.1
			1 (PHKL_30690)
		vxfs:src/common/kernel/dmapi/kdm_copy.c 3.15
		vxfs:src/unix/bufcache/hp/common/kernel/dmsample/dm_
			sample_osdep.c 3.8
		vxfs:src/common/kernel/dmsample/dm_sample_dmattr.c 3
			.12
		VxFS 3.5 for HP-UX 11.11 libvxfs35.a
	/usr/conf/lib/libvxfs35.a(vx_inode.o):
		None
	/usr/conf/lib/libvxfs35.a(fdd_thread.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_iflush.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_osdep.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_snap.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_bcache.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_rdwri.o):
		None
	/usr/conf/lib/libvxfs35.a(fdd_common.o):
		None
	/usr/conf/lib/libvxfs35.a(fdd_io.o):
		None
	/usr/conf/lib/libvxfs35.a(fdd_osdep.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_config.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_itrunc.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_bmapext4.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_glm.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_cfsaioctl.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_cvmres.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_cfsmsg.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_vfsops.o):
		None
	/usr/conf/lib/libvxfs35.a(ql_cluster.o):
		None
	/usr/conf/lib/libvxfs35.a(ql_admin.o):
		None
	/usr/conf/lib/libvxfs35.a(ql_msg.o):
		None
	/usr/conf/lib/libvxfs35.a(ql_osdep.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_cfsinode.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_bio1.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_dio.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_dnlc.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_mount.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_cview.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_osvnops.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_lwrite.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_portal.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_acl.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_bsdquota.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_bmaptyped.o):
		None
	/usr/conf/lib/libvxfs35.a(vx_crdwri.o):
		None

cksum(1) Output:
	
	VRTSvxfs.VXFS-KRN,fr=3.5-ga15,fa=HP-UX_B.11.11_64,v=HP:
	3373721469 34696 /usr/conf/lib/libvxfs35.a(fdd_common.o)
	359952100 24536 /usr/conf/lib/libvxfs35.a(fdd_io.o)
	243872468 36400 /usr/conf/lib/libvxfs35.a(fdd_osdep.o)
	3844221152 22776 /usr/conf/lib/libvxfs35.a(fdd_thread.o)
	2190113543 122704 /usr/conf/lib/libvxfs35.a(kdm_core.o)
	3274018214 10512 /usr/conf/lib/libvxfs35.a(kdm_osdep.o)
	2018219904 56312 /usr/conf/lib/libvxfs35.a(ql_admin.o)
	3233524 22432 /usr/conf/lib/libvxfs35.a(ql_cluster.o)
	3324125693 79496 /usr/conf/lib/libvxfs35.a(ql_msg.o)
	862292550 45720 /usr/conf/lib/libvxfs35.a(ql_osdep.o)
	896949302 22552 /usr/conf/lib/libvxfs35.a(vx_acl.o)
	3584807560 97280 /usr/conf/lib/libvxfs35.a(vx_attr.o)
	1440723446 39896 /usr/conf/lib/libvxfs35.a(vx_bcache.o)
	247223009 13512 /usr/conf/lib/libvxfs35.a(vx_bio1.o)
	1568375 28264 /usr/conf/lib/libvxfs35.a(vx_bmapext4.o)
	1228066698 32736 /usr/conf/lib/libvxfs35.a(vx_bmaptyped.o)
	1502281124 72328 /usr/conf/lib/libvxfs35.a(vx_bsdquota.o)
	2220349622 24656 /usr/conf/lib/libvxfs35.a(vx_cfsaioctl.o)
	524181447 107056 /usr/conf/lib/libvxfs35.a(vx_cfsinode.o)
	2710740515 93840 /usr/conf/lib/libvxfs35.a(vx_cfsmsg.o)
	2476218506 49008 /usr/conf/lib/libvxfs35.a(vx_config.o)
	2444613915 35648 /usr/conf/lib/libvxfs35.a(vx_crdwri.o)
	2315160343 25544 /usr/conf/lib/libvxfs35.a(vx_cview.o)
	236915479 7384 /usr/conf/lib/libvxfs35.a(vx_cvmres.o)
	2638539580 17392 /usr/conf/lib/libvxfs35.a(vx_dio.o)
	662745052 19120 /usr/conf/lib/libvxfs35.a(vx_dnlc.o)
	1457442912 76792 /usr/conf/lib/libvxfs35.a(vx_fsetsubr.o)
	3123767532 33312 /usr/conf/lib/libvxfs35.a(vx_glm.o)
	2230434586 28440 /usr/conf/lib/
		libvxfs35.a(vx_identstrings.o)
	1824693411 101448 /usr/conf/lib/libvxfs35.a(vx_iflush.o)
	1176253116 171952 /usr/conf/lib/libvxfs35.a(vx_inode.o)
	382956850 13040 /usr/conf/lib/libvxfs35.a(vx_io.o)
	2301127954 19392 /usr/conf/lib/libvxfs35.a(vx_itrunc.o)
	2486592906 21008 /usr/conf/lib/libvxfs35.a(vx_locks.o)
	2614482023 31544 /usr/conf/lib/libvxfs35.a(vx_lwrite.o)
	3346823254 83208 /usr/conf/lib/libvxfs35.a(vx_mount.o)
	2901620154 86832 /usr/conf/lib/libvxfs35.a(vx_osdep.o)
	2423830716 64536 /usr/conf/lib/libvxfs35.a(vx_osvnops.o)
	3744815067 13944 /usr/conf/lib/libvxfs35.a(vx_portal.o)
	582727361 67488 /usr/conf/lib/libvxfs35.a(vx_rdwri.o)
	3328546407 48752 /usr/conf/lib/libvxfs35.a(vx_reorg.o)
	4173966689 33432 /usr/conf/lib/libvxfs35.a(vx_snap.o)
	1834118350 45960 /usr/conf/lib/libvxfs35.a(vx_vfsops.o)
	2057537804 26872 /usr/conf/lib/libvxfs35.a(vx_vm.o)

Patch Conflicts: None

Patch Dependencies:
	s700: 11.11: PHKL_23337 PHCO_29897
	s800: 11.11: PHKL_23337 PHCO_29897

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHKL_28503 PHKL_29212 PHKL_28785 PHKL_29688 PHKL_29896

Equivalent Patches: None

Patch Package Size: 810 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_30690

	5. Run swinstall to install the patch:

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

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHKL_30690.  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_30690.text file is 
	available in the product readme:

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

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

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

Special Installation Instructions: None