Patch Name: PHKL_24971

Patch Description: s700_800 11.00 Probe,sysproc,IDDS,PM,VM,PA-8700,asyncio

Creation Date: 01/08/29

Post Date: 01/08/29

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

Products: N/A

Filesets:
	OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP
	OS-Core.CORE2-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_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical:
	No (superseded patches were critical)
	PHKL_24612: ABORT
	PHKL_24457: PANIC
	PHKL_24273: PANIC
		The system panics when r_refcnt overflows
	PHKL_24116: OTHER
		Hung, Unkillable Process
	PHKL_24015: PANIC
	PHKL_23857: CORRUPTION
	PHKL_23813: PANIC
	PHKL_23812: HANG
	PHKL_23406: OTHER
		Hung, Unkillable Process
	PHKL_23183: OTHER
		A program that uses probe instruction will cause
		signal handler to be removed. It will cause a
		non-access reference to an invalid virtual memory
		address causing SIGSEGV handler to be removed.
		So, the application's signal handler is not
		invoked and it does not know what to do.
	PHKL_22493: PANIC
	PHKL_21775: HANG
	PHKL_21507: PANIC
	PHKL_20439: PANIC MEMORY_LEAK
	PHKL_22744: PANIC
	PHKL_22549: PANIC
	PHKL_22380: PANIC HANG
	PHKL_22126: PANIC
	PHKL_21781: PANIC CORRUPTION
	PHKL_21624: HANG
	PHKL_21600: PANIC
	PHKL_20647: HANG
	PHKL_20449: PANIC
	PHKL_20223: PANIC
	PHKL_21354: PANIC
	PHKL_20335: CORRUPTION
	PHKL_20222: MEMORY_LEAK
	PHKL_20017: OTHER
		Causing degradation in I/O performance of the
		system.
	PHKL_19314: HANG
	PHKL_19201: HANG
	PHKL_20836: PANIC
	PHKL_20515: PANIC

Category Tags:
	defect_repair hardware_enablement enhancement
	general_release critical panic halts_system corruption
	memory_leak

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

Symptoms:
	PHKL_24971:
	( SR:8606195331 CR:JAGad64535 )
	Doing memory management activities on a large memory segment
	which was registered using asynchronous I/O driver, would
	take higher number of CPU cycles.

	PHKL_24826:
	( SR: 8606185728 CR: JAGad54930 )
	Narrow mode (32bit) HP-UX 11.00 programs cannot mmap64() any
	part of a large file beyond the first 2GB.

	PHKL_24612:
	( SR: 8606198933 CR: JAGad68122 )
	Random process core dumps.

	PHKL_24457:
	( SR: 8606180059, CR: JAGad49281 )
	When using the asyncio driver, applications may exhibit slow
	startup time.

	( SR: 8606179580, CR: JAGad48804 )
	A system panic occurs on process termination, if the process
	had registered private memory segment with asyncio driver.
	The stack trace will appear as follows:

		crash event was a panic
	        panic+0x14
	        report_trap_or_int_and_panic+0x84
	        trap+0xd9c
	        nokgdb+0x8
	        asyncdsk_close+0x94
	        call_open_close+0x1f8
	        closed+0xb0
	        spec_close+0x54
	        vn_close+0x48
	        vno_close+0x20
	        closef+0x64
	        exit+0x1108
	        psig+0x244
	        syscall+0x810
	        $syscallrtn+0x0

	( SR: 8606195629, CR: JAGad64833 )
	Slow application startup when using asyncio driver

	( SR: 8606199485, CR: JAGad68671 )
	On systems experiencing low memory conditions, applications
	registering memory segments with asyncio driver may get
	"Not owner" (EPERM) error.

	PHKL_24273:
	( SR:8606199847 CR:JAGad69033 )
	A user creates a 64-bit program which mmaps a file
	65536 times, then exists.  It caused data page fault
	in freereg() when referencing the region whose
	r_refcnt overflowed since it's already freed and
	its fields are not valid any more.
	Stack trace looks like:
	panic+0x14
	report_trap_or_int_and_panic+0x84
	trap+0xd9c
	nokgdb+0x8
	hdl_vfault+0x50
	vfault+0xf8
	trap+0x2a0
	nokgdb+0x8

	PHKL_24116:
	( SR: 8606192498 DTS: JAGad61711 )
	When the debugger is killed or sent a signal when trying to
	attach to a process, that process will be left in a hung
	state.

	PHKL_24015:
	( SR: 8606192072 DTS: JAGad61280 )
	When using memory windows and shared memory (IPC_SHARE32)
	between 32 and 64bit processes, the system may panic with
	an "hdl_pfault: invalid DBD for intransit page" panic.  The
	stack trace may look like:

		panic+0x14
		hdl_pfault+0x638
		pfault+0x104
		trap+0x724
		thandler+0xd20

	PHKL_23857:
	( SR: 8606178349 DTS: JAGad47576 )
	Data corruption can occur when Hyperfabric networking
	interface or async I/O driver is being used in the system.

	PHKL_23813:
	( SR: 8606188675 DTS: JAGad57891 )
	When booting 11.00 on a PA-8700 system, the system panics
	with the following message :

	panic: set_machine_parameters_64: Unidentified cpu type
	returned from PDC_MODEL

	Panic stack trace:
	PC-Offset Stack Trace (read down, top of stack is 1st):
	   panic+0x54
	   set_machine_parameters_64+0x1f8
	   rm_setmachineparams_64+0x40
	   DoCalllist+0x50
	   RDB_patch_int_trap+0xb0
	End Of Stack
	WARNING: Space ID hashing is disabled

	PHKL_23812:
	(SR: 8606183443 CR: JAGad52656)
	A multi-threaded process hangs and cannot be killed.  This
	process will have been repeatedly mmap()ing parts of the
	same file, while at the same time reading or writing to it
	with the read(), write(), readv(), or writev() system calls
	from a different thread.  That file must also be on a JFS
	file system.

	The Netscape Messaging Server's smtpd process is the only
	application we've seen do the particular combination of
	operations required to get into this state.

	PHKL_23628:
	(SR: 8606146888  CR: JAGad16231)
	If the process core file's size limit has been set to 0 in
	setrlimit(), when the process aborts, the core processing
	is incorrect.

	PHKL_23406:
	(SR: 8606103740  CR: JAGab70789)
	(SR: 8606159451  CR: JAGad28779)
	A multi-threaded process being executed over NFS can become
	hung and unkillable while performing either a fork, core,
	setrlimit, SIGSTOP, or debugger operations.

	PHKL_23183:
	(SR: 8606169539   CR: JAGad38814)
	An application trying to do a PROBE instruction
	results in non-access reference to an invalid
	virtual memory address that causes the SIGSEGV
	handler to be removed.
	This makes an application program's own
	error-recovery useless and results in database
	crashes.

	PHKL_22843:
	(SR: 8606162188 CR: JAGad31504)
	The output of "ps -f" shows the name of the script being
	runs instead of the name of the '#!' interpreter.

	(SR: 8606168950 CR: JAGad38228)
	When the user exec a script w/o providing the arguments,
	the kernel does not exec the shell as it should be
	expected to do.

	For example,

	execve("./t.sh", 0) will not work.

	t.sh:
	~~~
	#!/bin/ksh
	echo t.sh script executed OK.

	PHKL_22493:
	(SR: 8606141875 CR: JAGad11229)
	When not running as root, adb will panic the system when
	an attempt is made to debug a kernel-threaded application
	in which the first thread is in a ZOMBIE state.

	panic: Data page fault

	stack trace for event 0
	crash event was a panic
	panic+0x14
	report_trap_or_int_and_panic+0x80
	trap+0xdb8
	nokgdb+0x8
	handle_ooc_requests+0x2bc
	perform_trace_request+0x260
	ttrace1+0x13c
	ptrace+0x78
	syscall+0x480
	$syscallrtn+0x0

	PHKL_22032:
	(SR: 8606146888 CR: JAGad16231)
	Once-setuid/setgid processes could create corefiles or be
	attached to with a debugger.

	(SR: 8606146889 CR: JAGad16232)
	IDDS generated incorrect records in certain cases

	PHKL_21775:
	Some processes (eg .  created by Shared LVM) never get
	reaped leading to proc table being filled and leading
	to a system hang.

	PHKL_21507:
	( SR: 8606113684 CR: JAGac07198 )
	system panics when doing crfree

	panic: crfree: freeing free credential struct

	Stack trace for crash event was :
	q4> trace event 0
	stack trace for event 0
	crash event was a panic
	panic+0x14
	crfree+0xc4
	kthread_shared_objects_update+0x30
	syscall+0x594
	$syscallrtn+0x0

	PHKL_21358:
	( SR: 8606132621 CR: JAGad01770 )
	The Praesidium IDS/9000 product requires this patch in order
	to run.  This patch has no impact on systems without the
	Praesidium IDS/9000 product installed and enabled.

	PHKL_21350:
	( SR: 8606132613 CR: JAGad01762 )
	The Praesidium IDS/9000 product requires this patch in order
	to run.  This patch has no impact on systems without the
	Praesidium IDS/9000 product installed and enabled.

	PHKL_20439:
	( SR: 8606109770 DTS: JAGaa45170 )
	While running an MPI-based program, the system panics with a
	"Data page fault" or other memory-related fault.

	PHKL_20226:
	( SR: 8606107525 DTS: JAGab77768 )
	This patch is one of 8 patches necessary to add support
	for the 3 Gb private address space feature.

	PHKL_21535:
	( SR: 8606100830 CR: JAGab39185 )
	Application core files do not include the process' attached
	shared memory segments.

	PHKL_21357:
	( SR: 8606132620 CR: JAGad01769 )
	The Praesidium IDS/9000 product requires this patch in order
	to run.  This patch has no impact on systems without the
	Praesidium IDS/9000 product installed and enabled.

	PHKL_22744:
	( SR: 8606161365  CR: JAGad30681 )
	A system may experience a data page fault panic with the
	following stack trace:

		panic+0x14
		report_trap_or_int_and_panic+0x80
		trap+0xdb8
		nokgdb+0x8
		thread_pcb_reinit+0x30
		thread_alloc+0xe8
		thread_create+0x2ac
		_lwp_create+0xdc
		syscall+0x480
		$syscallrtn+0x0

	PHKL_22549:
	( SR: 8606128066 DTS: JAGab24436 )
	Data page fault when trying to flush buffers
	which have already been invalidated:

		bwrite+0x44
		bxwrite+0x44
		syncip_flush_cache+01x1dc
		vx_flushdev+0x14
		vx_fsync+0x248
		spec_fsync+0x254.

	PHKL_22440:
	( SR: 8606154274 CR: JAGad23592 )
	When trying to attach to a process that has been swapped
	out, both the tracing process and traced process hang and
	remain in an unkillable state.

	PHKL_22380:
	(SR: 8606130240 DTS: JAGac95111)
	Kernel paniced with data memory protection fault. This
	could happen when using direct I/O on JFS version 3.3
	or in other situations.

	(SR:8606139945 DTS: JAGad09268)
	MP System hang under heavy I/O load.

	PHKL_22126:
	( SR: 8606155209 DTS: JAGad24526 )
	This patch is a replacement for the recalled patch
	PHKL_21624 which addressed a system hang caused by memory
	scrubber operating on shared memory segment used by the
	async I/O driver. The following problems were introduced by
	PHKL_21624 and are resolved by this patch.

	1.  System panic when both Hyperfabric networking interface
	and async I/O driver are used on the same system with
	PHKL_21624 installed.

	2.  Applications fail when trying to register shared
	segments with async I/O driver. On failure errno is set to
	EPERM.

	( SR: 8606143996 DTS: JAGad13329 )
	Excessive delay in database connect time for database user
	processes.

	PHKL_21781:
	(SR: 8606137220  DTS: JAGad06338)
	when a user application makes a large number (over 65535)
	of mprotect(2) calls, it fails with ENOSPC - No space left
	on device.

	(SR: 8606136222  DTS: JAGad05348)
	When sendfile_max is configured to be > 0, and when using
	ftp or rcp to transfer data, we encounter a spinlock
	deadlock panic in sendfile_hold().

	A stack trace will look similar to:

	  panic
	  spin_deadlock_failure
	  deadlock_check
	  sl_pre_check
	  spinlock
	  sendfile_hold
	  sosendfile
	  sendfile
	  syscall

	PHKL_21624:
	(SR: 8606124290 DTS: JAGac39673)
	Memory scrubber (memlogd) causes system hang while scrubbing
	pages locked by async driver.  The async driver is typically
	used by database applications.

	( SR:            CR: JAGab16247 )
	HP-UX does not support an interface that allows a driver to
	lock user space memory on behalf of a user process in such
	a way that prevents the user process from unlocking the
	memory.  Such a mechanism is required to enable DMA to user
	space memory by the operating system (a driver).

	PHKL_21600:
	(SR: 8606134430 DTS: JAGad03565)
	When using mmap with a negative offset or an offset greater
	than 2^43, the system panics.

	PHKL_20647:
	(SR: 8606107024 DTS: JAGab76631)
	System hang in b_sema_get_queue() when doing an munmap().

	PHKL_20449:
	(SR: 8606106816 DTS: JAGab76230)
	Incorrect implementation of mmap(2) can cause system panics.

	PHKL_20223:
	( SR: 8606103245 DTS: JAGab69733)
	The system will panic with the following message:

	    panic: Returning ID that is already free.

	( SR: 8606107525 DTS: JAGab77768)
	This patch is one of 8 patches necessary to add support
	for the 3 Gb private address space feature.

	PHKL_21532:
	( SR: 8606131990 CR: JAGad01139 )
	Approximately every 22 minutes, the system, or one cpu of a
	multi-processor system, appears to hang for several minutes.
	Then the problem goes away.  This primarily affects larger
	memory systems.

	PHKL_21354:
	( SR: 8606132598 CR: JAGad01747 )
	After PHKL_21003 is installed on a V2500 or V2600 with at
	least 24 CPUs and at least 24 GB of memory, the system fails
	to boot.  One symptom that has been observed is the
	following message displayed during the boot process:

	Error found :
	    - mem_toc zero error encountered.

	( SR: 8606132617 CR: JAGad01766 )
	The Praesidium IDS/9000 product requires this patch in order
	to run.  This change has no impact on systems without the
	Praesidium IDS/9000 product installed and enabled.

	PHKL_21024:
	( SR: 8606112164 DTS: JAGab84450 )
	Enhancement:  Performance changes for corner case in RTSCHED
	scheduling.  This patch has no impact on most systems.

	PHKL_21003:
	( SR: 8606112473 CR: JAGab84822 )
	V2500 with more than 24GB of memory and more than 24
	processors takes a long time (>30min) to boot.

	PHKL_20335:
	( SR: 8606106466 DTS: JAGab75600)
	Unlinked files within NFS filesystems sometimes leave behind
	.nfsXXX files which are unremovable until after the system
	is rebooted.

	( SR: 8606107384 DTS: JAGab77587)
	Panic or data corruption due to buffer cache buffers being
	released multiple times.

	( SR: 8606108724 DTS: JAGab78191)
	Memory corruption after copying growing files over the
	network multiple times.

	PHKL_20222:
	( SR: 8606107507 DTS: JAGab77743)
	This patch adds support for the PA-8600 processor.

	( SR: 8606107525 DTS: JAGab77768)
	This patch is one of 8 patches necessary to add support for
	the 3 Gb private address space feature.

	PHKL_20102:
	( SR: 8606106969 DTS: JAGaa45096 )
	On systems with 5GB of memory or more, the system will
	allocate memory for a static table that it does not use.
	This affects 64-bit systems only.

	PHKL_20017:
	( SR: 8606104415 DTS: JAGab71916)
	After installing PHKL_19314, I/O performance of the system
	drops substantially.

	( SR: 8606103778 CR: JAGab70853 )
	64bit systems with large amount of memory (e.g.  32Gb) and
	having large buffer cache (e.g.  8Gb) configured find the
	syslog is flooded with the following error message:

	vmunix :  bufmap :  rmap :  ovflo, lost [xx..)(xx..]

	PHKL_19314:
	( SR: 4701426775 DTS: JAGab17440 )
	On a system with a large number of processors (more than 14)
	a hang can occur during boot and after displaying the
	following messages:

	Starting the STREAMS daemons-phase1
	Checking root filesystem
	log replay in progress
	replay complete - marking super-block clean
	Root check done
	Create STCP device files

	( SR: 8606101604 DTS: JAGab15954)
	Attempting to resume from a breakpoint when running a
	program under a debugger will cause the program to get a
	segmentation violation.  This has been seen on G-class
	systems but it can occur on any system with block-tlb.

	PHKL_19201:
	SR: 8606100898 DTS: JAGab39707
	A user sees a hang while using snapshot file systems.

	Stack trace:

	 _swtch+0xd4
	 _sleep_one+0x538
	 vx_sleep_lock+0xd0
	 vx_snap_bpcopy+0xf4
	 vx_snap_copyblk+0x144
	 vx_snap_copy+0x50
	 vx_snap_strategy+0x280
	 vx_buf_strategy+0x24
	 bwrite+0xe0
	 getnewbuf+0x918
	 allocbuf1+0x234
	 brealloc1+0x5c
	 getblk1+0x2fc
	 vx_snap_getblk+0x2c
	 vx_snap_getblkbp+0x140
	 vx_snap_lookup+0x1c
	 vx_snap_bpcopy+0x110
	 vx_snap_copyblk+0x144
	 vx_snap_copy+0x50
	 vx_snap_strategy+0x280
	 vx_buf_strategy+0x24
	 bwrite+0xe0
	 getnewbuf+0x918
	 ogetblk+0x110
	 getblk1+0x290
	 vx_getblk+0x50
	 vx_bread+0x68
	 vx_iread+0x88
	 vx_real_iget+0x398
	 vx_iget+0x3c
	 vx_dirlook+0x23c
	 vx_lookup+0x120
	 locallookuppn+0xd4
	 lookuppn+0xf8
	 lookupname+0x40
	 vn_open+0x68
	 copen+0xd0
	 open+0x3c
	 syscall+0x480
	 $syscallrtn+0x0

	PHKL_17038:
	The system will trap 15 data page fault when tracing for
	leaks without also tracing for corruption.

	PHKL_20945:
	( SR: 8606112164 DTS: JAGab84450 )
	Enhancement:  Performance changes for corner case in RTSCHED
	scheduling.  This patch has no impact on most systems.

	PHKL_20995:
	( SR: 8606127692 CR: JAGac78494 )
	Programs using "memory windows" (started via setmemwindow)
	will not be able to allocate more than 1 Gb of shared memory
	(1 Gb total for all memory windows processes, i.e. this is
	not a per process limit). This patch is a replacement for
	PHKL_20227, which introduced the bug that this patch
	fixes.

	PHKL_20836:
	( SR: 8606106781 CR: JAGab76169 )
	Application issuing large amount of mmap calls to
	map multiple virtual addresses to the same physical
	page (using flags MAP_SHARED|MAP_FILE|MAP_FIXED)
	may cause system panic with the follow stack trace:

	panic: hdl_zero_page: page not mapped

	panic+0x14
	hdl_zero_page+0xc8
	virtual_fault+0x418
	vfault+0x118
	trap+0x280
	nokgdb+0x8

	Trace on other processor shows:

	panic+0x14
	report_trap_or_int_and_panic+0x80
	trap+0xde8
	nokgdb+0x8
	allocpfd_from_pond+0x134
	allocate_page+0x68
	lgpg_vfdfill+0x4c
	virtual_fault+0xc3c
	vfault+0x118
	trap+0x280
	nokgdb+0x8

	PHKL_20227:
	( SR: 8606107525 CR: JAGab77768 )
	This patch is one of 8 patches necessary to add support
	for the 3 Gb private address space feature.

	PHKL_20224:
	( SR: 8606107525 CR: JAGab77768 )
	This patch is one of 8 patches necessary to add support
	for the 3 Gb private address space feature.

	PHKL_20515:

	(SR: 8606101315, CR: JAGab46368)
	System hang while using async I/O module through database
	applications with new large block I/O feature when system
	is low on memory resources.

	(SR: 8606100970, CR: JAGab39977)
	Data pagefault during async I/O operations when an I/O is
	being done to an unregistered (private) memory.

	(SR:8606103126, CR: JAGab69473)
	System hang can occur during async I/O operations when an
	IO is being done to an unregistered (private) memory
	 segment designated by the user's IO buffer.

	(SR: 8606102862, CR: JAGab68892)
	Async driver can hang during async IO with requests larger
	than MAXPHYS (allowing async I/O larger than MAXPHYS is a
	new feature available in this patch, where MAXPHYS = 256KB).

	(SR: 8606108814, CR: JAGab81517)
	Async driver I/O completion notifications don't work when
	used in conjunction with select(2) system call.

	PHKL_20426:
	When a multithreaded process does file I/O concurrently with
	mmap() or munmap() on the same file, it can result in a
	single process deadlock.  This process is not killable.

Defect Description:
	PHKL_24971:
	( SR:8606195331 CR:JAGad64535 )
	Upon removing the last process reference to a shared memory
	segment on a memory unlock, the segment is demoted from
	64MB pages to 4K pages. Any subsequent attempts to manage
	this segment take considerable amount of time as the
	number of page management structures has now been increased
	by 16K times.

	Resolution:
	Do not demote the largepages on doing a memory unlock.

	PHKL_24826:
	( SR: 8606185728 CR: JAGad54930 )
	The kernel code was limited by design to allow narrow
	mode mmap64() to 2GB or less only.

	Resolution:
	The kernel was enhanced to remove this limitation. Narrow
	mode mmap64() can now map up to 4GB.

	PHKL_24612:
	( SR: 8606198933 CR: JAGad68122 )
	The VM subsystem was not correctly handling self-modifying
	code pages that were not initially mapped with execute
	access.  There was a possibility that execute access could
	be removed, leaving stale data in the instruction cache.
	When the page was subsequently reused by another process,
	it would fault on the stale instruction cache data.

	Resolution:
	If a page has execute access, retain the execute access
	when adding a new translation.  This ensures the data is
	flushed from the instruction cache upon page deallocation.

	PHKL_24457:
	( SR: 8606180059, CR: JAGad49281 )
	Before starting I/O's through the asyncio driver,
	applications must register shared memory segments with the
	driver. As part of the registration, the driver locks the
	memory. If this operation needs to be done for a very
	large memory segment, the locking may take a significant
	amount of time, resulting in slow application startup.

	Resolution:
	The async driver now supports a new device file minor number
	256. If an application uses the async device file with this
	new minor number, the driver will defer locking the memory
	until I/O's are issued. This avoids the overhead of memory
	setup time and thus reduces the application startup time.

	Note: This minor number should only be used on systems that
	have enough physical memory so that paging is avoided.
	Paging can cause serious performance degradation with this
	new enhancement.  On systems where paging is an issue, this
	minor number should not be used.

	( SR: 8606179580, CR: JAGad48804 )
	When process that registered private memory with asyncio
	driver terminates, the memory management subsystem cleans
	the associated data structure. The asyncio driver tries to
	dereference a pointer to one of these data structures that
	has already been freed causing the system to panic.

	Resolution:
	The driver returns bad address (EFAULT) if any application
	tries to register a private memory segment.

	( SR: 8606195629, CR: JAGad64833 )
	The asyncio driver checks for the user access rights
	twice. This duplication of access rights check
	contributes to slow application startup.

	Resolution:
	The redundant access rights check is removed.

	( SR: 8606199485, CR: JAGad68671 )
	The asyncio driver propagates the wrong error code to the
	application when a memory locking function fails due to
	low memory conditions.

	Resolution
	The appropriate error code is returned to the application.

	PHKL_24273:
	( SR:8606199847 CR:JAGad69033 )
	The system panic's while trying to mmap() more than
	the maximum allowed limit of pregions to a shared
	region.  (limited by r_refcnt, which is of type
	ushort). This was caused by r_refcnt overflow which
	caused it to reset.  If a program mmap's more than
	this limit, the counter r_refcnt overflow which
	causes the system to panic.
	Resolution:
	The fix is to check for the overflow and return ENOMEM.

	PHKL_24116:
	( SR: 8606192498 DTS: JAGad61711 )
	If the debugger is interrupted while trying to attach to a
	single threaded process that is sleeping uninterruptibly,
	it will return to the user without unsuspending the
	debuggee so the debuggee's suspend count is not decremented
	and the debuggee will be suspended forever.

	Resolution:
	ttrace_prepare_attach() now checks the return from the
	sleep of the debugger. If the sleep returns an error, we
	know that the debugger has been interrupted by someone
	else other than the debuggee so we decrement the suspend
	count of the debuggee.

	PHKL_24015:
	( SR: 8606192072 DTS: JAGad61280 )
	A 64bit process cannot map into a private memory window -
	it can only map into the global memory window of the
	32bit virtual space.  A 32bit process needing to share
	with a 64bit process must either be mapped into the
	global memory window or the object to be shared must
	be marked IPC_GLOBAL.  These rules were not being
	enforced, resulting in incorrect space id assignment
	for shared memory (IPC_SHARE32) allocated in a private
	memory window.

	Resolution:
	Shared memory (IPC_SHARE32) allocated in a private memory
	window is now remapped into the global memory window when
	sharing with a 64bit process.

	PHKL_23857:
	( SR: 8606178349 DTS: JAGad47576 )
	Kernel sub-systems such as Hyperfabric networking
	interface and async I/O expect to be notified when a
	translation for a page changes that they are using
	for DMA. The virtual memory system uses the
	cluster-interconnect flag to determine if such sub-systems
	should be notified when the translation changes. If there
	are two different kernel-locked ranges in the same
	largepage, the unlocking of first locked range causes the
	cluster-interconnect flag for that page to be cleared, even
	though there is another locked range in the same page. This
	could cause a DMA operation to occur on the wrong page,
	resulting in data corruption, if sub-systems continued to
	do DMA on that page.

	Resolution:
	A check is added to see if there are other kernel-locked
	ranges in the same largepage before clearing the
	cluster-interconnect flag.

	PHKL_23813:
	( SR: 8606188675 DTS: JAGad57891 )
	11.00 does not recognize the PA-8700 processor.
	Additionally, the PA-8700 processor is not IO-PDIR coherent.

	Resolution:
	This patch, PHKL_23813,  is one of three 11.00 PA-8700
	enablement patches.  The other 11.00 PA-8700 enablement
	patches are PHKL_23814 & PHKL_23815.  To support 11.00 on
	PA-8700, the following changes were made :

	- Added code to recognize the PA-8700 processor.
	- Added code to check if non-coherent IO-PDIR is set and
	  performed flushes and syncs whenever IO-PDIR is changed.
	- Fixed inverted space hash mask to enable the PA-8700
	processor.

	PHKL_23812:
	(SR: 8606183443 CR: JAGad52656)
	This problem was caused by a lock ordering problem between
	VM and JFS.  JFS can call VM while holding an inode lock;
	the routines called may require a vas lock.  VM can call JFS
	while holding a vas lock; the routines called may require an
	inode lock.  If we get unlucky, we hit the same vas/inode
	lock combination from both directions, and the threads
	deadlock.  Because the vas lock potentially held by VM is a
	per process resource, this situation can only be encountered
	by a multithreaded process.

	Resolution:
	The fix is to have the VM routine drop the vas lock before
	calling the file system code; fortunately, the VM routine
	can safely drop and reacquire the lock around the call ...
	it was mostly holding it to avoid dropping and reacquiring
	it repeatedly in a loop.

	PHKL_23628:
	(SR: 8606146888  CR: JAGad16231)
	If the process core file's size limit has been set to 0 in
	setrlimit(), when the process aborts, the core processing
	is incorrect.

	Resolution:
	If the process core file size limit has been set to zero,
	don't create a core file.

	PHKL_23406:
	(SR: 8606103740  CR: JAGab70789)
	(SR: 8606159451  CR: JAGad28779)
	A thread acquires a lock and then sleeps interruptibly.  The
	interruptible sleep permits the thread to be stopped.  Any
	other thread attempting to acquire this lock will sleep
	uninterruptably until the lock is available.  This
	uninterruptable thread is also unkillable.  This introduces
	a deadlock potential in multi-threaded processes:  when a
	thread holding the lock, a thread desiring the lock, and a
	third thread doing one of fork, setrlimit, core, SIGSTOP, or
	debugger optionations, all occur at the same time in the
	same process, the deadlock is reached.  The only way to
	resolve the deadlock is to reboot the system.

	This patch is part of a set of four patches (PHKL_23406,
	PHKL_23407,PHKL_23408,PHKL_23409) that enable P_NOSTOP, a
	new feature that prevents a process from being unkillable.
	Each patch is independantly installable.  Without all four
	installed, P_NOSTOP will be unavailable.

	In order to prevent the process executed over NFS from
	becoming unkillable, NFS must use the P_NOSTOP feature.  An
	NFS patch using P_NOSTOP, PHNE_23249, will be released in
	Spring of 2001.

	Resolution:
	If a thread acquires a lock and then sleeps interruptably,
	it is not permitted to be stopped if P_NOSTOP is set.  This
	prevents this thread from becoming unkillable and prevents
	the deadlock.

	PHKL_23183:
	(SR: 8606169539   CR: JAGad38814)
	The check to unblock the signal handler was being done
	too early inside grow(). This resulted in removal of the
	signal handler specified by the application program.

	Resolution:
	The fix is to move the unblock signal out of grow() into
	hdl_vfault() which then calls grow() at a later stage.

	PHKL_22843:
	(SR: 8606162188 CR: JAGad31504)

	When an interpreter is invoked via a shell script, the
	script name is mistakenly passed to the kernel as the first
	argument (argv[0) instead of the interpreter name.

	Resolution:
	When an interpreter was being invoked via a shell script,
	we passed the interpreter to the kernel as the first
	argument instead of passing user's argv[0], which is
	the script name.

	(SR: 8606168950 CR: JAGad38228)
	When user exec a shell script w/o supplying arguments
	at all, the kernel failed to account for the extra
	argument for the name of the script into the number
	of arguments to be passed to the kernel.  Also,
	it failed to pass the interpreter to the kernel as
	the first argument to be executed.

	Resolution:
	When user exec a shell script w/o supplying arguments
	at all, the kernel bumps up argc by 1, to account for
	the extra argument that we will be adding later via
	via the function setup_shell_argv().  It also passes
	the shell name to the kernel as the first argument,
	instead of the script name.

	PHKL_22493:
	(SR: 8606141875 CR: JAGad11229)
	When the debugged process initializes each thread's
	data pointer, if the thread is in a ZOMBIE state,
	that thead is not initialized, leaving the data
	pointer NULL.  Later, adb attempts to dereference
	the NULL pointer, causing a data page fault panic.

	Resolution:
	Initialize the data pointer for all debugged threads,
	including those in a ZOMBIE state.

	PHKL_22032:
	(SR: 8606146888 CR: JAGad16231)
	If a setuid/setgid process completely dropped privileges,
	it could create a core file on a subsequent error, and could
	be attached to with a debugger.

	(SR: 8606146889 CR: JAGad16232)
	Some process management system calls generated incorrect
	IDDS records.

	Resolution:

	(SR: 8606146888 CR: JAGad16231)
	Remember that the process was once setuid/setgid, and
	disallow corefiles and debugger attaches.

	(SR: 8606146889 CR: JAGad16232)
	Fix the generated records.

	PHKL_21775:
	Resolution :PM internal function prepare_to_reap_proc in
	kern_exit.c changed to reap system processes correctly .

	PHKL_21507:
	( SR: 8606113684 CR: JAGac07198 )
	Analysis of dump showed that we are attempting to free a
	credential structure but credential refrence count
	is already 0 indicating it was already freed.

	Resolution:
	Locking of credentials operations were protected by
	sched_lock so that credential operations are done properly.

	PHKL_21358:
	( SR: 8606132621 CR: JAGad01770 )
	This patch is one of 16 patches (PHKL_21348-PHKL_21363)
	required by the Praesidium IDS/9000 product.  These patches
	enable the collection and tracking of information from
	various system calls.  Unless all of the enabling patches
	(or their successors) and the product are installed, and the
	product is enabled, this patch has no impact on the system.

	Resolution:
	This patch enables the gathering of information from the
	various uid and gid related system calls.

	PHKL_21350:
	( SR: 8606132613 CR: JAGad01762 )
	This patch is one of 16 patches (PHKL_21348-PHKL_21363)
	required by the Praesidium IDS/9000 product.  These patches
	enable the collection and tracking of information from
	various system calls.  Unless all of the enabling patches
	(or their successors) and the product are installed, and the
	product is enabled, this patch has no impact on the system.

	Resolution:
	This patch enables the gathering of information from the
	exec*() and exit() system calls.

	PHKL_20439:
	( SR: 8606109770 DTS: JAGaa45170 )
	In the process to process memory copy routines, there were a
	number of race conditions and memory leaks.  These led to
	system panics.

	Resolution:
	Made structural changes to locking logic to avoid these
	race conditions and fixed the memory leaks.

	PHKL_20226:
	( SR: 8606107525 DTS: JAGab77768 )
	This is one of 8 patches necessary to add support for the
	3 Gb private address space feature. This feature allows a
	process to have a private 3rd quadrant (normally the 3rd
	quadrant, which is a 1 Gb range of address space from
	0x80000000 to 0xC0000000, is used for shared objects). The
	chatr command must be used to enable this feature for an
	executable (chatr +q3p enable <a.out>). Note that this
	feature is only enabled for 32 bit processes running on the
	64 bit version of HP-UX.

	The other 7 patches necessary to enable this feature are
	PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20227,
	PHKL_20228 and PHKL_20229.  Each patch may be installed
	independently of the others - if enabling the 3 Gb private
	address space feature is not desired.  If fewer than all 8
	patches are installed, the 3 Gb private address space
	feature will not be enabled.  The code in this patch that is
	part of this feature will not have any impact on the system
	until all 8 patches are installed.

	Resolution:
	A subset of the code to support the 3 Gb private address
	space feature was added. When all 8 patches are installed
	the following code changes to support this feature will
	have been added:

	    1) Code to recognize the request for a private 3rd
	       quadrant (Q3) during exec() of an executable.
	       An executable that requests a private 3rd
	       quadrant will be referred to as a q3p process
	       below.
	    2) Code to prevent allocation of shared objects
	       in q3p processes.
	    3) Code to allow data to extend over the 2nd/3rd
	       quadrant boundary for q3p processes.
	    4) Code to put the stack for the primary thread
	       in the 3rd quadrant for q3p processes.
	    5) Code to map a shared library into the private
	       address space if there is no more room in the
	       4th shared quadrant for q3p processes.

	PHKL_21535:
	( SR: 8606100830 CR: JAGab39185 )
	This patch corrects application core dump behavior by
	allowing dumping of a process' attached shared memory
	segments to the application core file.  This patch has no
	impact on the system unless shared memory dumping is
	enabled. See the Special Installation Instructions section
	for details on how to enable shared memory dumping after
	installing this patch.

	A word of caution:
	After shared memory dumping is enabled, the new system-wide
	core dump behavior for applications will be to include
	attached shared memory segments to application core files.
	This may not be the desired behavior if you have
	applications that use large shared memory segments running
	on the system.  (eg database applications).  If those
	applications core dump, the core files will include their
	attached shared memory segments.  Thus, they can be very
	large files.  Do not enable shared memory dumping after
	installing this patch if you do not want this behavior.

	Resolution:
	This patch enables shared memory dumping in the coredump
	generation code when kernel global variables
	core_addshmem_read and/or core_addshmem_write are set to 1.
	If both of these variables are set to 0, their default
	value, this patch has no impact on the system.

	PHKL_21357:
	( SR: 8606132620 CR: JAGad01769 )
	This patch is one of 16 patches (PHKL_21348-PHKL_21363)
	required by the Praesidium IDS/9000 product.  These patches
	enable the collection and tracking of information from
	various system calls.  Unless all of the enabling patches
	(or their successors) and the product are installed, and the
	product is enabled, this patch has no impact on the system.

	Resolution:
	This patch enables the gathering of information from the
	corefile generation code.

	PHKL_22744:
	( SR: 8606161365  CR: JAGad30681 )
	A pregion lookup is done based on the thread id.  Thread
	id's are cached, so on systems with many threads configured
	and running, the thread id may be stale, i.e. reused by
	another thread.  In this case, the wrong pregion is
	returned.

	Resolution:
	Use the thread pregion pointer to access the pregion
	instead of the thread id.

	PHKL_22549:
	( SR: 8606128066 DTS: JAGab24436 )
	When syncing buffers for a particular device the routine
	that scans the cache for dirty buffers was not checking
	whether the buffers were valid. Those buffers that were
	invalid would no longer have a vnode pointer associated
	with them which in turn would cause a data page fault when
	they were passed to bwrite().

	Resolution:
	The routine responsible for flushing buffers corresponding
	to an individual inode will now ensure that only valid
	buffers are attempted to be flushed.

	PHKL_22440:
	( SR: 8606154274 CR: JAGad23592 )
	The kernel debug thread is responsible for receiving and
	executing the debugger commands. This is a daemon thread
	which is invisible to the user application and is not part
	of the thread list of the proc stucuture. Hence while the
	process is being swapped this thread is not put on the run
	queue even if it were in run state. Since the debug thread
	is not reactivated when the procces it is attached to is
	swapped back in, both it and the attached process hang.

	Resolution:
	Explicitly start the debug thread (if it has been created)
	when the process is swapped in.

	PHKL_22380:
	(SR: 8606130240 CR: JAGac95111)
	The kernel driver creates an anonymous private mapping
	with read-only protection and calls mprotect() to change
	the access right to 'read-write'.

	Before the dirver tries to write, it calls vaslockpages
	to lock those pages down. vaslockpages did not set the
	correct access right for the mprotected pages.

	Resolution:
	Changed kernel to set up the translation with corrent
	access right.

	(SR:8606139945 DTS: JAGad09268)
	In the original design, when allocating/freeing a buffer,
	it only does a sleep/wakeup on the list for the current
	CPU. Processes sleeping from another CPU will not be
	awakened. The result, seen in the dump of a hang, is
	dozens of processes sleeping on an empty per-processor
	queue.

	Resolution:
	The design has been changed as follows:  When allocating
	a buffer, first try to allocate from the cpu's own list,
	if fail, allocate from global list, if still fail, steal
	from each processor's list back to global list, then
	try allocate from global list; if still fail, sleep on
	global list.  When freeing the buffer, if my cpu list's
	number of free buffers is smaller than global list's,
	free it to my list, else free it to global list, and
	wakes up sleepers on the global list.

	PHKL_22126:
	( SR: 8606155209 DTS: JAGad24526 )
	1.  The problem was tied to the use of the global variables
	used by legacy HyperFabric driver, the driver assumed that
	they are kernel global function pointers owned by
	HyperFabric and were initialized to NULL in the driver init
	routine.

	PHKL_21624 initializes (at compile time) the same function
	pointers to the address of a new set of kernel funtions that
	VM uses for calling all registered callback functions.

	Resolution:
	Replace the references to the global function pointers in VM
	code with new symbol names, thus leaving the  original
	symbols initialized to NULL as the legacy HyperFabric driver
	expects.

	2.  PHKL_21624 addressed a problem of system hang caused by
	memory scrubber working on shared memory segments used by
	the async I/O driver. To fix this problem, the change
	required applications using async I/O driver to have MLOCK
	privilege. This fact was not documented in PHKL_21624 and
	caused application using async I/O driver to fail.

	Resolution:
	Applications that use the async I/O driver must belong to a
	group having MLOCK privilege. Refer to the section
	"Special Installation Instructions"  for details on how to
	check and set MLOCK privilege.

	( SR: 8606143996 DTS: JAGad13329
	During internal testing with PHKL_21624 using 8GB shared
	memory segment and 300 user processes that were tyring
	to connect to the database at the same time, we found that
	the database user processes had an excessive database
	connect delay. Each user process that connects to the
	database registers memory with the async I/O driver which in
	turn locks the memory so that if the address translation for
	that memory is ever changed by VM, the async I/O driver
	would be notified. To achieve this VM had to operate on each
	4K page that backs-up the memory being locked. If there are
	many users trying to register large memory segments almost
	at the same time the registration process would take a long
	time.

	Resolution:
	The VM code was modified to manage locking using superpages
	rather than 4K pages.

	PHKL_21781:
	(SR: 8606137220   CR: JAGad06338)
	The problem is due to the limitation of the protection
	ranges for memory mapped regions. The counter for the
	number of pregions that can be mprotected is defined as
	a u_short.  When an application uses a very large data
	segment and makes more than 64K-1 mprotect(2) calls,
	the system returns an ENOSPC.

	Resolution:
	Change the definition of mprotect range counters from
	u_short to long.

	(SR: 8606136222  CR: JAGad05348)
	The major lock order for sendfile_lock was incorrect.

	Resolution:
	Correct the lock ordering for sendfile_lock.

	PHKL_21624:
	(SR: 8606124290 DTS: JAGac39673)
	The following scenario would cause a deadlock (resulting in
	a system hang):  memlogd (using the dmem driver) was
	scrubbing the 4kB physical pages of a superpage locked by
	the async driver.  Prior to scrubbing, dmem invalidated the
	address translations for all the 4kB pages in the superpage.
	Before dmem finished processing the superpage, it was
	interrupted by an async I/O request.  The I/O transaction
	required accessing one of the 4kB pages in the superpage
	being scrubbed by dmem.  The interrupt handler would wait
	for the page to be marked valid; dmem could not mark it
	valid until the interrupt returned and it finished scrubbing
	the superpage.

	Resolution:
	Callback registration support has been added to enable the
	async driver to register a callback requirement against
	memory it has locked.  Whenever the address translation of a
	locked page is to be invalidated, the callback feature is
	invoked if the memory is registered as locked by async.
	Thus, the async driver is able to prevent dmem from
	scrubbing pages for which async I/Os are either active or
	pending.

	( SR:            CR: JAGab16247 )
	The mlock allows a user process to unlock memory locked by
	the operating system.  It does not allow for a persistant
	lock of user space memory by the operating system.

	Resolution:
	A new interface was added to the VM subsystem to allow
	persistant locking of user space memory by an operating
	system driver in such a way that a user can not unlock it.

	Both the persistant locking mechanism and the callback
	registration support are required to support DMA to user
	space by the operating system.

	PHKL_21600:
	(SR: 8606134430 DTS: JAGad03565)
	No check for overflow when casting mmap offset from 64 bits
	to 32 bits. And no check to prevent a negative value, from
	user space.

	Resolution:
	After casting from 64 to 32 bits, the offset is tested
	and if negative, mmap returns EINVAL.

	PHKL_20647:
	(SR: 8606107024 DTS: JAGab76631)
	When calling munmap() to unmap an area that ends within a
	superpage, the superpage lock was not properly released,
	resulting in a system hang upon a subsequent attempt to lock
	the superpage.

	Resolution:
	When calling munmap() to unmap an area that ends within a
	superpage, demote the end points before attempting to lock
	the superpage.

	PHKL_20449:
	(SR: 8606106816 DTS: JAGab76230)
	The kernel behaves incorrectly during some mmap(2)
	operations.

	Resolution:
	mmap(2) now returns an error if it can't honor the
	request.

	PHKL_20223:
	( SR: 8606103245 DTS: JAGab69733)
	This bug is caused by a race condition in the mmap(2) code
	which was using a recursive algorithm to map all of the
	file. A lock was being dropped and reacquired each time the
	algorithm recursed.

	Resolution:
	The mmap bug was fixed by changing the algorithm so that is
	no longer was recursive.  This allowed the lock to be held
	for the whole time.

	( SR: 8606107525 DTS: JAGab77768)
	This is one of 8 patches necessary to add support for the
	3 Gb private address space feature. This feature allows a
	process to have a private 3rd quadrant (normally the 3rd
	quadrant, which is a 1 Gb range of address space from
	0x80000000 to 0xC0000000, is used for shared objects). The
	chatr command must be used to enable this feature for an
	executable (chatr +q3p enable <a.out>). Note that this
	feature is only enabled for 32 bit processes running on the
	64 bit version of HP-UX.

	The other 7 patches necessary to enable this feature are
	PHKL_20222, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227,
	PHKL_20228 and PHKL_20229. Each patch may be installed
	independently of the others - if enabling the 3 Gb private
	address space feature is not desired. If fewer than all
	8 patches are installed, the 3 Gb private address space
	feature will not be enabled. The code in this patch that
	is part of this feature will not have any impact on the
	system until all 8 patches are installed.

	Resolution:
	A subset of the code to support the 3 Gb private address
	space feature was added. When all 8 patches are installed
	the following code changes to support this feature will
	have been added:

	    1) Code to recognize the request for a private 3rd
	       quadrant (Q3) during exec() of an executable.
	       An executable that requests a private 3rd
	       quadrant will be referred to as a q3p process
	       below.
	    2) Code to prevent allocation of shared objects
	       in q3p processes.
	    3) Code to allow data to extend over the 2nd/3rd
	       quadrant boundary for q3p processes.
	    4) Code to put the stack for the primary thread
	       in the 3rd quadrant for q3p processes.
	    5) Code to map a shared library into the private
	       address space if there is no more room in the
	       4th shared quadrant for q3p processes.

	PHKL_21532:
	( SR: 8606131990 CR: JAGad01139 )
	Approximately every 22 minutes, vhand monopolizes one cpu
	for a long period of time.  Every 22 minutes, vhand calls a
	routine which tries to free up kernel memory.  It tries to
	free up each memory bucket for all cpus on the system each
	time it is called.

	As memory is freed up, chunks of memory are coalesced into
	larger chunks of (contiguous) memory.  Each 4k page freed is
	added back into the superpage pool.

	Another related problem is that the superpage pool chain
	becomes long and fragmented (especially on large memory
	systems), which implies inefficiency in managing the pool.

	Resolution:
	The routine called by vhand to free up kernel memory will
	now work on one cpu at a time, and on only a few memory
	buckets at a time.  It will do less for each call, and be
	called more often, spreading the workload out in time.

	Use a better coalescing algorithm for the superpage pool
	list.

	PHKL_21354:
	( SR: 8606132598 CR: JAGad01747 )
	When mapping kernel pages to real memory, if the address
	falls beyond 1GB and cannot be found in the 32bit sysmap, we
	fail to check the return code and allocate it from the 64bit
	sysmap.

	Without PHKL_21003, which moved the 64bit sysmap to start at
	1GB instead of 4GB to cover an undefined 3GB gap, this has
	no effect since the address is not defined.  However, when
	the address is included in the 64bit sysmap and we do not
	remove it properly when the virtual address is being used,
	we end up using the same virtual address again because it is
	still available in the sysmap.  The init process fails when
	the vhand daemon starts paging.

	Resolution:
	Allocate the address from the 64bit sysmap when it is not
	found in the 32bit sysmap.

	( SR: 8606132617 CR: JAGad01766 )
	This patch is one of 16 patches (PHKL_21348-PHKL_21363)
	required by the Praesidium IDS/9000 product.  These patches
	enable the collection and tracking of information from
	various system calls.  Unless all of the enabling patches
	(or their successors) and the product are installed, and the
	product is enabled, this change has no impact on the system.

	Resolution:
	This patch causes the IDS/9000 pseudo-driver to be
	initialized at the right place during system boot.

	PHKL_21024:
	( SR: 8606112164 DTS: JAGab84450 )
	This is an enhancement for a corner case in RTSCHED
	scheduling.

	Resolution:
	Code added to fine tune RTSCHED thread scheduling code path.

	PHKL_21003:
	( SR: 8606112473 CR: JAGab84822 )
	In 11.00, the 32bit sysmap contains pages from 0 to 1GB and
	the 64bit sysmap contains pages from 4GB to 4TB, leaving a
	3GB gap between them.  Due to memory interleaving on V2500,
	there may not be enough physical memory below 1GB to satisfy
	the system initialization.  Therefore, memory above 1GB is
	used.  During system boot, the init process will try to
	allocate equivalently mapped virtual addresses from a sysmap
	for physical pages between 1GB to 4GB.  When it fails
	because none of these pages can be found in either sysmap,
	it loops through all pages sequentially until it exhausts
	all the memory within the 1-4GB range.  This may take a long
	time depending on the number of physical pages in the range.

	Resolution:
	Extend 64bit sysmap to start from 1GB to cover the 3GB gap.

	PHKL_20335:
	( SR: 8606106466 DTS: JAGab75600)
	The buffer cache was never releasing references it had on
	NFS files which had the side-effect of never allowing these
	files to be removed.

	Resolution:
	The buffer cache now ensures that it correctly releases all
	holds on vnodes after data is removed from the cache.  This
	ensures that NFS files become inactive and are therefore are
	removable.

	( SR: 8606107384 DTS: JAGab77587)
	The buffer cache has the potential to release buffers
	multiple times, which could lead to system panics or memory
	corruption.

	Resolution:
	The routine that was writing out dirty buffers then
	releasing the buffer will now write and return thereby
	ensuring that the buffer is released only once.

	( SR: 8606108724 DTS: JAGab78191)
	Files that grow in size and are copied over the network
	multiple times -- via rcp or ftp commands -- during this
	period may cause memory corruption to occur.  This happens
	because stale checksum data pointers within the buffer
	header are reused after the buffer increases in size.

	Resolution:
	The buffer cache routine responsible for increasing the size
	of buffers will now check whether a buffer contains a
	pointer to checksum data -- which is used by the networking
	code -- in which case it will free the data and clear the
	pointer.

	PHKL_20222:
	( SR: 8606107507 DTS: JAGab77743)
	This patch adds support for new machines that contain the
	PA-8600 processor.

	Resolution:
	Code to support the PA-8600 processor was added.

	( SR: 8606107525 DTS: JAGab77768)
	This is one of 8 patches necessary to add support for the 3
	Gb private address space feature.  This feature allows a
	process to have a private 3rd quadrant (normally the 3rd
	quadrant, which is a 1 Gb range of address space from
	0x80000000 to 0xC0000000, is used for shared objects).  The
	chatr command must be used to enable this feature for an
	executable (chatr +q3p enable <a.out>).  Note that this
	feature is only enabled for 32 bit processes running on the
	64 bit version of HP-UX.

	The other 7 patches necessary to enable this feature are
	PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226, PHKL_20227,
	PHKL_20228 and PHKL_20229.  Each patch may be installed
	independently of the others - if enabling the 3 Gb private
	address space feature is not desired.  If fewer than all 8
	patches are installed, the 3 Gb private address space
	feature will not be enabled.  The code in this patch that is
	part of this feature will not have any impact on the system
	until all 8 patches are installed.

	Resolution:
	A subset of the code to support the 3 Gb private address
	space feature was added.  When all 8 patches are installed
	the following code changes to support this feature will have
	been added:

	    1) Code to recognize the request for a private 3rd
	       quadrant (Q3) during exec() of an executable.
	       An executable that requests a private 3rd
	       quadrant will be referred to as a q3p process
	       below.
	    2) Code to prevent allocation of shared objects
	       in q3p processes.
	    3) Code to allow data to extend over the 2nd/3rd
	       quadrant boundary for q3p processes.
	    4) Code to put the stack for the primary thread
	       in the 3rd quadrant for q3p processes.
	    5) Code to map a shared library into the private
	       address space if there is no more room in the
	       4th shared quadrant for q3p processes.

	PHKL_20102:
	( SR: 8606106969 DTS: JAGaa45096 )
	On systems with 5GB of memory or more, the system allocates
	too much memory for the pdir hash table (32-224MB).  This
	additional memory is wasted.

	Resolution:
	Fixed boot time memory allocation algorithm to only allocate
	memory that is actually used.

	PHKL_20017:
	( SR: 8606104415 DTS: JAGab71916)
	The fix in PHKL_19314 for the "14-way boot hang" breaks the
	interrupt distribution code.  This results in all I/O
	interrupts being assigned to the monarch CPU, causing I/O
	performance degradation.

	Resolution:
	Add a new spu state SPU_INTR_ENABLED, so that pa_next_cpu
	will designate a spu to be an interrupt handler if its
	status is either SPU_INTR_ENABLED or SPU_ENABLED.  Each
	non-monarch CPU sets its state to be SPU_INTR_ENABLED at
	the point where it used to set SPU_ENABLED.

	( SR: 4701426775 DTS: JAGab17440 )
	Historically on a 32bit system, the maximum size in one
	quadrant is limited to 1Gb.  To handle more than 1Gb of
	buffer caches, we use two buffer cache resource maps, bufmap
	and bufmap2.  For 64bit systems, the maximum size of a
	quadrant is not limited to 1Gb anymore and we don't need a
	second bufmap to fulfill the buffer cache needs.  Therefore,
	bufmap2 is not used.  However, on 11.00, we still initialize
	two resource maps with the size of bufmap limited to 0.9Gb/2
	entries regardless of whether we have a 32bit or a 64bit
	system.  So for 64bit systems with large memory and large
	buffer cache defined the system can still run out of bufmap
	entries if the virtual address space for the buffer cache
	gets fragmented.

	Resolution:
	For 64bit systems, initialize bufmap to contain
	phys_mem_pages/2 entries.

	PHKL_19314:
	( SR: 4701426775 DTS: JAGab17440 )
	While the monarch processor is in MPCONFIG_PHASE2 during
	boot and before it gets a chance to tell all non-monarch
	processors to continue execution (set mp_sync_after_rendez
	to CONTINUE_EXECUTION), a clock interrupt comes in.  The
	clock interrupt handler will erroneously attempt an
	m_itmr_sync with all the processors (which are still waiting
	to continue).  This m_itmr_sync can take up to 13 msecs per
	processor.  When the number of processor is high enough,
	which is 14 in this case, another clock interrupt arrives
	before the current clock handler completes, causing the boot
	to hang in an infinite continuous series of servicing clock
	interrupts.

	Resolution:
	In the clock interrupt handling routine, we now make sure
	that no m_itmr_sync is attempted by the monarch processor
	until after the non-monarch processors are actually ready.
	As for the non-monarch processors, in the non_monarch_init
	routine, we now make sure that each non-monarch processor
	does not signal the monarch processor that it is ready for
	an m_itmr_sync until after the monarch sets
	mp_sync_after_rendez to CONTINUE_EXECUTION.

	( SR: 8606101604 DTS: JAGab15954)
	The root cause seems to be a double mapping of the
	break_page by both a block TLB entry and an ordinary one,
	which causes undefined results in the hardware.

	Resolution:
	Code has been added to main so that during initialization it
	looks at the machine being booted to see whether or not this
	machine has a block-tlb.  If the machine does not have one,
	then the page in the kernel is used for the break-page.  If
	the machine has a block-tlb, then instead of using the page
	in the kernel, a new page is allocated for the break-page.

	PHKL_19201:
	SR: 8606100898 DTS: JAGab39707
	The system hang is caused by jfs snap code trying to lock
	the same resource again when it already owns it.  A buffer
	that partially satisfies a request needs to be marked
	invalid when it can't be grown to fit the request.  This
	will prevent another thread from getting a hit on it and
	trying to grow it, which can cause a hang.

	Resolution:
	SR: 8606100898 DTS: JAGab39707
	Mark buffers invalid when the buffer can't be grown to fit
	the size of the request.

	PHKL_17038:
	An uninitialized variable may cause this data page fault
	when tracing for memory leaks.  The workaround is to also
	trace for corruption which will initialize the variable.
	The workaround isn't always feasible because tracing for
	corruption uses a lot more memory in some environments while
	tracing for leaks does not.

	PHKL_20945:
	( SR: 8606112164 DTS: JAGab84450 )
	This is an enhancement for a corner case in RTSCHED
	scheduling.

	Resolution:
	Code added to fine tune RTSCHED thread scheduling code path.

	PHKL_20995:
	( SR: 8606127692 CR: JAGac78494 )
	Code that initialized the space maps for the second and
	third quadrant for memory windows processes is not being
	run. This means that a memory windows process cannot
	allocate shared memory in the second (for SHMEM_MAGIC
	processes) or third quadrant, leaving only the fourth
	quadrant available, which is shared across all processes.
	This defect is only present if all 8 of the Large Data
	space patches are installed.

	Resolution:
	Code was changed to allow the space maps to be properly
	initialized for all configured memory windows.

	PHKL_20836:
	( SR: 8606106781 CR: JAGab76169 )
	HP-UX handles multiple virtual addresses mapping to the
	same physical page by using virtual address aliasing.
	Large number of overlapping exclusive mapping calls
	(mmap with MAP_SHARED|MAP_FIXED|MAP_FILE) create excessive
	number of virtual address aliases and can exhaust the alias
	entries for physical pages. The exhaustion of alias entries
	results in failed attempts to add a page translation.
	Improper handling of the translation failure results in
	corruption in the free memory list, thus causing an unmapped
	page to be returned from the free memory pond.

	Resolution:
	Handle application requested overlapping exclusive mapping
	without using aliases.

	PHKL_20227:
	( SR: 8606107525 CR: JAGab77768 )
	This is one of 8 patches necessary to add support for the
	3 Gb private address space feature. This feature allows a
	process to have a private 3rd quadrant (normally the 3rd
	quadrant, which is a 1 Gb range of address space from
	0x80000000 to 0xC0000000, is used for shared objects). The
	chatr command must be used to enable this feature for an
	executable (chatr +q3p enable <a.out>). Note that this
	feature is only enabled for 32 bit processes running on the
	64 bit version of HP-UX.

	The other 7 patches necessary to enable this feature are
	PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226,
	PHKL_20228 and PHKL_20229. Each patch may be installed
	independently of the others - if enabling the 3 Gb private
	address space feature is not desired. If fewer than all
	8 patches are installed, the 3 Gb private address space
	feature will not be enabled. The code in this patch that
	is part of this feature will not have any impact on the
	system until all 8 patches are installed.

	Resolution:
	A subset of the code to support the 3 Gb private address
	space feature was added. When all 8 patches are installed
	the following code changes to support this feature will
	have been added:

	    1) Code to recognize the request for a private 3rd
	       quadrant (Q3) during exec() of an executable.
	       An executable that requests a private 3rd
	       quadrant will be referred to as a q3p process
	       below.
	    2) Code to prevent allocation of shared objects
	       in q3p processes.
	    3) Code to allow data to extend over the 2nd/3rd
	       quadrant boundary for q3p processes.
	    4) Code to put the stack for the primary thread
	       in the 3rd quadrant for q3p processes.
	    5) Code to map a shared library into the private
	       address space if there is no more room in the
	       4th shared quadrant for q3p processes.

	PHKL_20224:
	( SR: 8606107525 CR: JAGab77768 )
	This is one of 8 patches necessary to add support for the
	3 Gb private address space feature. This feature allows a
	process to have a private 3rd quadrant (normally the 3rd
	quadrant, which is a 1 Gb range of address space from
	0x80000000 to 0xC0000000, is used for shared objects). The
	chatr command must be used to enable this feature for an
	executable (chatr +q3p enable <a.out>). Note that this
	feature is only enabled for 32 bit processes running on the
	64 bit version of HP-UX.

	The other 7 patches necessary to enable this feature are
	PHKL_20222, PHKL_20223, PHKL_20225, PHKL_20226, PHKL_20227,
	PHKL_20228 and PHKL_20229. Each patch may be installed
	independently of the others - if enabling the 3 Gb private
	address space feature is not desired. If fewer than all
	8 patches are installed, the 3 Gb private address space
	feature will not be enabled. The code in this patch that
	is part of this feature will not have any impact on the
	system until all 8 patches are installed.

	Resolution:
	A subset of the code to support the 3 Gb private address
	space feature was added. When all 8 patches are installed
	the following code changes to support this feature will
	have been added:

	    1) Code to recognize the request for a private 3rd
	       quadrant (Q3) during exec() of an executable.
	       An executable that requests a private 3rd
	       quadrant will be referred to as a q3p process
	       below.
	    2) Code to prevent allocation of shared objects
	       in q3p processes.
	    3) Code to allow data to extend over the 2nd/3rd
	       quadrant boundary for q3p processes.
	    4) Code to put the stack for the primary thread
	       in the 3rd quadrant for q3p processes.
	    5) Code to map a shared library into the private
	       address space if there is no more room in the
	       4th shared quadrant for q3p processes.

	PHKL_20515:

	(SR: 8606101315, CR: JAGab46368)
	Assertion failure occurs in 'kmalloc' someone called
	'kmalloc' holding the 'spinlock' which should not be
	done.
	Async driver allocated kernel memory while holding spinlock
	which causes driver to sleep until memory is available.

	Resolution:
	        Added No-Wait flag to memory allocation call when
	        spinlock is held.

	(SR: 8606100970, CR: JAGab39977)
	Async driver called subroutine with uninitialized variable.
	In the asyncdsk_dorequest() routine, the 1st argument to
	luseracc is tempseg.space -- however, tempseg.space doesn't
	get populated until & unless luseracc returns successfully.

	Resolution:
	        Initialize variable before using in subroutine call.

	(SR:8606103126, CR: JAGab69473)
	Spinlock was held in async driver during call to routine
	that did not need spinlock held, and which could take too
	long before returning.

	Resolution:
	        Released spinlock before call to the routine, then
	        reacquired after routine returned.

	(SR: 8606102862, CR: JAGab68892)
	Async driver should unmap buffers of same size as was
	originally mapped for the IO request, but instead it was
	unmapping the size based on the number of bytes transferred
	successfully in the async IO request.

	Resolution:
	        Unmapped IO request buffer size same as was mapped.

	(SR: 8606108814, CR: JAGab81517)
	Async driver's IO completion flag notification was checked
	in wrong sequence, when used in conjunction with select.

	Resolution:
	        Changed sequence to check for IO notification flag
	        before checking other types of IO completions.

	PHKL_20426:
	Violation of lock ordering by filesystem code.  The lock
	ordering that is safe from deadlock is:  vaslock, vnodelock,
	inodelock but filesystems are attempting the order:
	(vnodelock), inodelock, vaslock

	Resolution:
	The VM system will drop the vaslock around filesystem
	operations, and reacquire it afterwards. This completes
	PHKL_18531 that was partially solving the problem.

SR:
	1653301614 4701402461 4701426775 8606100830 8606100898
	8606100970 8606101315 8606101604 8606102862 8606103126
	8606103245 8606103740 8606103778 8606104415 8606106466
	8606106781 8606106816 8606106969 8606107024 8606107384
	8606107507 8606107525 8606108724 8606108814 8606109770
	8606112164 8606112473 8606113684 8606124290 8606127692
	8606128066 8606130240 8606131318 8606132598 8606132613
	8606132617 8606132620 8606132621 8606134430 8606134995
	8606136222 8606137220 8606139945 8606141875 8606143996
	8606146888 8606146889 8606154274 8606155209 8606161365
	8606162188 8606168950 8606169539 8606178349 8606179580
	8606180059 8606183443 8606185728 8606188675 8606192072
	8606192498 8606195331 8606195629 8606198933 8606199485
	8606199847

Patch Files:
	
	OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/conf/h/map.h
	/usr/conf/h/vm_mlock.h
	/usr/conf/machine/hdl_preg.h
	/usr/conf/machine/pdc_rqsts.h
	/usr/conf/sio/async.h

	ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/include/machine/hdl_preg.h
	/usr/include/machine/pdc_rqsts.h
	/usr/include/sio/async.h
	/usr/include/sys/map.h
	/usr/include/sys/vm_mlock.h

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/libhp-ux.a(async.o)
	/usr/conf/lib/libhp-ux.a(clic_stubs.o)
	/usr/conf/lib/libhp-ux.a(clock.o)
	/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
	/usr/conf/lib/libhp-ux.a(dmem.o)
	/usr/conf/lib/libhp-ux.a(hdl_fault.o)
	/usr/conf/lib/libhp-ux.a(hdl_init.o)
	/usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
	/usr/conf/lib/libhp-ux.a(hdl_policy.o)
	/usr/conf/lib/libhp-ux.a(hdl_trans.o)
	/usr/conf/lib/libhp-ux.a(init_main.o)
	/usr/conf/lib/libhp-ux.a(kern_exec.o)
	/usr/conf/lib/libhp-ux.a(kern_exit.o)
	/usr/conf/lib/libhp-ux.a(kern_mallo.o)
	/usr/conf/lib/libhp-ux.a(kern_mman.o)
	/usr/conf/lib/libhp-ux.a(kgdb_machine.o)
	/usr/conf/lib/libhp-ux.a(kmall_trace.o)
	/usr/conf/lib/libhp-ux.a(onyxe.o)
	/usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
	/usr/conf/lib/libhp-ux.a(pm_core.o)
	/usr/conf/lib/libhp-ux.a(pm_cred.o)
	/usr/conf/lib/libhp-ux.a(pm_prot.o)
	/usr/conf/lib/libhp-ux.a(pm_ptrace.o)
	/usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
	/usr/conf/lib/libhp-ux.a(vfs_bio.o)
	/usr/conf/lib/libhp-ux.a(vm_clic.o)
	/usr/conf/lib/libhp-ux.a(vm_kern.o)
	/usr/conf/lib/libhp-ux.a(vm_machdep.o)
	/usr/conf/lib/libhp-ux.a(vm_machreg.o)
	/usr/conf/lib/libhp-ux.a(vm_memlock.o)
	/usr/conf/lib/libhp-ux.a(vm_mlock.o)
	/usr/conf/lib/libhp-ux.a(vm_mmap.o)
	/usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
	/usr/conf/lib/libhp-ux.a(vm_pregion.o)
	/usr/conf/lib/libhp-ux.a(vm_realmain.o)
	/usr/conf/lib/libhp-ux.a(vm_remap.o)
	/usr/conf/lib/libhp-ux.a(vm_sched.o)
	/usr/conf/lib/libhp-ux.a(vm_vas.o)
	/usr/conf/lib/libhp-ux.a(vm_vfd.o)
	/usr/conf/lib/libhp-ux.a(vm_vhand.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/libhp-ux.a(async.o)
	/usr/conf/lib/libhp-ux.a(clic_stubs.o)
	/usr/conf/lib/libhp-ux.a(clock.o)
	/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
	/usr/conf/lib/libhp-ux.a(dmem.o)
	/usr/conf/lib/libhp-ux.a(hdl_fault.o)
	/usr/conf/lib/libhp-ux.a(hdl_init.o)
	/usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
	/usr/conf/lib/libhp-ux.a(hdl_policy.o)
	/usr/conf/lib/libhp-ux.a(hdl_trans.o)
	/usr/conf/lib/libhp-ux.a(init_main.o)
	/usr/conf/lib/libhp-ux.a(kern_exec.o)
	/usr/conf/lib/libhp-ux.a(kern_exit.o)
	/usr/conf/lib/libhp-ux.a(kern_mallo.o)
	/usr/conf/lib/libhp-ux.a(kern_mman.o)
	/usr/conf/lib/libhp-ux.a(kgdb_machine.o)
	/usr/conf/lib/libhp-ux.a(kmall_trace.o)
	/usr/conf/lib/libhp-ux.a(onyxe.o)
	/usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
	/usr/conf/lib/libhp-ux.a(pm_core.o)
	/usr/conf/lib/libhp-ux.a(pm_cred.o)
	/usr/conf/lib/libhp-ux.a(pm_prot.o)
	/usr/conf/lib/libhp-ux.a(pm_ptrace.o)
	/usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
	/usr/conf/lib/libhp-ux.a(vfs_bio.o)
	/usr/conf/lib/libhp-ux.a(vm_clic.o)
	/usr/conf/lib/libhp-ux.a(vm_kern.o)
	/usr/conf/lib/libhp-ux.a(vm_machdep.o)
	/usr/conf/lib/libhp-ux.a(vm_machreg.o)
	/usr/conf/lib/libhp-ux.a(vm_memlock.o)
	/usr/conf/lib/libhp-ux.a(vm_mlock.o)
	/usr/conf/lib/libhp-ux.a(vm_mmap.o)
	/usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
	/usr/conf/lib/libhp-ux.a(vm_pregion.o)
	/usr/conf/lib/libhp-ux.a(vm_realmain.o)
	/usr/conf/lib/libhp-ux.a(vm_remap.o)
	/usr/conf/lib/libhp-ux.a(vm_sched.o)
	/usr/conf/lib/libhp-ux.a(vm_vas.o)
	/usr/conf/lib/libhp-ux.a(vm_vfd.o)
	/usr/conf/lib/libhp-ux.a(vm_vhand.o)

what(1) Output:
	
	OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/conf/h/map.h:
		map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2
			 PATCH_11.00 (PHKL_21003)
	/usr/conf/h/vm_mlock.h:
		vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11
			ros/2 PATCH_11.00 (PHKL_23857)
	/usr/conf/machine/hdl_preg.h:
		hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11
			ros/1 PATCH_11.00 (PHKL_21781)
	/usr/conf/machine/pdc_rqsts.h:
		pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1
			1ros/3 PATCH_11.00 (PHKL_20222)
	/usr/conf/sio/async.h:
		async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros
			/5 PATCH_11.00 (PHKL_24457)

	ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	/usr/include/machine/hdl_preg.h:
		hdl_preg.h $Date: 2000/05/31 14:27:02 $Revision: r11
			ros/1 PATCH_11.00 (PHKL_21781)
	/usr/include/machine/pdc_rqsts.h:
		pdc_rqsts.h $Date: 1999/10/28 05:09:19 $Revision: r1
			1ros/3 PATCH_11.00 (PHKL_20222)
	/usr/include/sio/async.h:
		async.h $Date: 2001/06/26 14:43:30 $Revision: r11ros
			/5 PATCH_11.00 (PHKL_24457)
	/usr/include/sys/map.h:
		map.h $Date: 2000/02/02 11:49:37 $Revision: r11ros/2
			 PATCH_11.00 (PHKL_21003)
	/usr/include/sys/vm_mlock.h:
		vm_mlock.h $Date: 2001/04/23 13:03:40 $Revision: r11
			ros/2 PATCH_11.00 (PHKL_23857)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	/usr/conf/lib/libhp-ux.a(async.o):
		async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros
			/16 PATCH_11.00 (PHKL_24457)
	/usr/conf/lib/libhp-ux.a(clic_stubs.o):
		clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r
			11ros/3 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(clock.o):
		clock.c $Date: 1999/09/24 17:23:06 $Revision: r11ros
			/7 PATCH_11.00 (PHKL_20017)
	/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o):
		cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision
			: r11ros/7 PATCH_11.00 (PHKL_20439)
	/usr/conf/lib/libhp-ux.a(dmem.o):
		dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/
			6 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(hdl_fault.o):
		hdl_fault.c $Date: 2001/01/25 17:29:01 $Revision: r1
			1ros/13 PATCH_11.00 (PHKL_23183)
	/usr/conf/lib/libhp-ux.a(hdl_init.o):
		hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11
			ros/7 PATCH_11.00 (PHKL_20223)
	/usr/conf/lib/libhp-ux.a(hdl_mprotect.o):
		hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision:
			 r11ros/9 PATCH_11.00 (PHKL_21781)
	/usr/conf/lib/libhp-ux.a(hdl_policy.o):
		hdl_policy.c $Date: 2001/08/02 16:49:10 $Revision: r
			11ros/15 PATCH_11.00 (PHKL_24826)
	/usr/conf/lib/libhp-ux.a(hdl_trans.o):
		hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1
			1ros/18 PATCH_11.00 (PHKL_24612)
	/usr/conf/lib/libhp-ux.a(init_main.o):
		init_main.c $Date: 2000/03/17 11:52:05 $Revision: r1
			1ros/11 PATCH_11.00 (PHKL_21354)
	/usr/conf/lib/libhp-ux.a(kern_exec.o):
		kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1
			1ros/22 PATCH_11.00 (PHKL_24015)
	/usr/conf/lib/libhp-ux.a(kern_exit.o):
		kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1
			1ros/18 PATCH_11.00 (PHKL_23406)
	/usr/conf/lib/libhp-ux.a(kern_mallo.o):
		kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r
			11ros/7 PATCH_11.00 (PHKL_21532)
	/usr/conf/lib/libhp-ux.a(kern_mman.o):
		kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1
			1ros/4 PATCH_11.00 (PHKL_23183)
	/usr/conf/lib/libhp-ux.a(kgdb_machine.o):
		kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision:
			 r11ros/4 PATCH_11.00 (PHKL_20222)
	/usr/conf/lib/libhp-ux.a(kmall_trace.o):
		kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision: 
			r11ros/7 PATCH_11.00 (PHKL_21003)
	/usr/conf/lib/libhp-ux.a(onyxe.o):
		onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros
			/2 PATCH_11.00 (PHKL_20222)
		onyxe 1.0 (unsupported)
	/usr/conf/lib/libhp-ux.a(pa_generic_psm.o):
		pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio
			n: r11ros/2 PATCH_11.00 (PHKL_20017)
	/usr/conf/lib/libhp-ux.a(pm_core.o):
		pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r
			os/7 PATCH_11.00 (PHKL_23628)
	/usr/conf/lib/libhp-ux.a(pm_cred.o):
		pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r
			os/1 PATCH_11.00 (PHKL_21507)
	/usr/conf/lib/libhp-ux.a(pm_prot.o):
		pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22032)
	/usr/conf/lib/libhp-ux.a(pm_ptrace.o):
		ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio
			n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL
			_17205)
		pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1
			1ros/15 PATCH_11.00 (PHKL_24116)
	/usr/conf/lib/libhp-ux.a(ufs_mchdep.o):
		ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r
			11ros/6 PATCH_11.00 (PHKL_21781)
	/usr/conf/lib/libhp-ux.a(vfs_bio.o):
		vfs_bio.c $Date: 2000/10/20 06:59:31 $Revision: r11r
			os/21 PATCH_11.00 (PHKL_22549)
	/usr/conf/lib/libhp-ux.a(vm_clic.o):
		vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r
			os/4 PATCH_11.00 (PHKL_23857)
	/usr/conf/lib/libhp-ux.a(vm_kern.o):
		vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r
			os/4 PATCH_11.00 (PHKL_21532)
	/usr/conf/lib/libhp-ux.a(vm_machdep.o):
		vm_machdep.c $Date: 2001/04/17 14:38:30 $Revision: r
			11ros/35 PATCH_11.00 (PHKL_23813)
	/usr/conf/lib/libhp-ux.a(vm_machreg.o):
		vm_machreg.c $Date: 2000/09/11 14:14:58 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_22380)
	/usr/conf/lib/libhp-ux.a(vm_memlock.o):
		vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r
			11ros/5 PATCH_11.00 (PHKL_24971)
	/usr/conf/lib/libhp-ux.a(vm_mlock.o):
		vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_21624)
	/usr/conf/lib/libhp-ux.a(vm_mmap.o):
		vm_mmap.c $Date: 2001/08/02 16:42:17 $Revision: r11r
			os/21 PATCH_11.00 (PHKL_24826)
	/usr/conf/lib/libhp-ux.a(vm_pgalloc.o):
		vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r
			11ros/4 PATCH_11.00 (PHKL_21624)
	/usr/conf/lib/libhp-ux.a(vm_pregion.o):
		vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_24273)
	/usr/conf/lib/libhp-ux.a(vm_realmain.o):
		vm_realmain32.c $Date: 1999/10/28 05:09:19 $Revision
			: r11ros/5 PATCH_11.00 (PHKL_20222)
	/usr/conf/lib/libhp-ux.a(vm_remap.o):
		vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(vm_sched.o):
		vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11
			ros/8 PATCH_11.00 (PHKL_22440)
	/usr/conf/lib/libhp-ux.a(vm_vas.o):
		vm_vas.c $Date: 2000/11/14 06:37:13 $Revision: r11ro
			s/12 PATCH_11.00 (PHKL_22744)
	/usr/conf/lib/libhp-ux.a(vm_vfd.o):
		vm_vfd.c $Date: 2000/01/25 08:06:48 $Revision: r11ro
			s/7 PATCH_11.00 (PHKL_20945)
	/usr/conf/lib/libhp-ux.a(vm_vhand.o):
		vm_vhand.c $Date: 2000/04/12 03:18:15 $Revision: r11
			ros/6 PATCH_11.00 (PHKL_21532)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	/usr/conf/lib/libhp-ux.a(async.o):
		async.c $Date: 2001/06/26 12:54:22 $Revision: r11ros
			/16 PATCH_11.00 (PHKL_24457)
	/usr/conf/lib/libhp-ux.a(clic_stubs.o):
		clic_stubs.c $Date: 2000/08/14 11:40:53 $Revision: r
			11ros/3 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(clock.o):
		clock.c $Date: 1999/09/24 17:23:06 $Revision: r11ros
			/7 PATCH_11.00 (PHKL_20017)
	/usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o):
		cnx_p2p_bcopy.c $Date: 1999/11/09 15:03:19 $Revision
			: r11ros/7 PATCH_11.00 (PHKL_20439)
	/usr/conf/lib/libhp-ux.a(dmem.o):
		dmem.c $Date: 2000/08/14 11:40:53 $Revision: r11ros/
			6 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(hdl_fault.o):
		hdl_fault.c $Date: 2001/01/25 17:29:01 $Revision: r1
			1ros/13 PATCH_11.00 (PHKL_23183)
	/usr/conf/lib/libhp-ux.a(hdl_init.o):
		hdl_init.c $Date: 1999/10/31 21:44:19 $Revision: r11
			ros/7 PATCH_11.00 (PHKL_20223)
	/usr/conf/lib/libhp-ux.a(hdl_mprotect.o):
		hdl_mprotect.c $Date: 2000/05/31 14:25:46 $Revision:
			 r11ros/9 PATCH_11.00 (PHKL_21781)
	/usr/conf/lib/libhp-ux.a(hdl_policy.o):
		hdl_policy.c $Date: 2001/08/02 16:49:10 $Revision: r
			11ros/15 PATCH_11.00 (PHKL_24826)
	/usr/conf/lib/libhp-ux.a(hdl_trans.o):
		hdl_trans.c $Date: 2001/07/12 15:49:36 $Revision: r1
			1ros/18 PATCH_11.00 (PHKL_24612)
	/usr/conf/lib/libhp-ux.a(init_main.o):
		init_main.c $Date: 2000/03/17 11:52:05 $Revision: r1
			1ros/11 PATCH_11.00 (PHKL_21354)
	/usr/conf/lib/libhp-ux.a(kern_exec.o):
		kern_exec.c $Date: 2001/04/25 13:09:32 $Revision: r1
			1ros/22 PATCH_11.00 (PHKL_24015)
	/usr/conf/lib/libhp-ux.a(kern_exit.o):
		kern_exit.c $Date: 2001/02/15 11:36:33 $Revision: r1
			1ros/18 PATCH_11.00 (PHKL_23406)
	/usr/conf/lib/libhp-ux.a(kern_mallo.o):
		kern_mallo.c $Date: 2000/04/12 03:18:15 $Revision: r
			11ros/7 PATCH_11.00 (PHKL_21532)
	/usr/conf/lib/libhp-ux.a(kern_mman.o):
		kern_mman.c $Date: 2001/01/25 16:58:55 $Revision: r1
			1ros/4 PATCH_11.00 (PHKL_23183)
	/usr/conf/lib/libhp-ux.a(kgdb_machine.o):
		kgdb_machine.c $Date: 1999/10/28 05:09:19 $Revision:
			 r11ros/4 PATCH_11.00 (PHKL_20222)
	/usr/conf/lib/libhp-ux.a(kmall_trace.o):
		kmall_trace.c $Date: 2000/02/02 11:47:27 $Revision: 
			r11ros/7 PATCH_11.00 (PHKL_21003)
	/usr/conf/lib/libhp-ux.a(onyxe.o):
		onyxe 1.0 (unsupported)
		onyxe.c $Date: 1999/10/28 05:09:19 $Revision: r11ros
			/2 PATCH_11.00 (PHKL_20222)
	/usr/conf/lib/libhp-ux.a(pa_generic_psm.o):
		pa_generic_psm.c $Date: 1999/09/24 17:23:06 $Revisio
			n: r11ros/2 PATCH_11.00 (PHKL_20017)
	/usr/conf/lib/libhp-ux.a(pm_core.o):
		pm_core.c $Date: 2001/03/13 13:32:21 $Revision: r11r
			os/7 PATCH_11.00 (PHKL_23628)
	/usr/conf/lib/libhp-ux.a(pm_cred.o):
		pm_cred.c $Date: 2000/04/06 11:41:10 $Revision: r11r
			os/1 PATCH_11.00 (PHKL_21507)
	/usr/conf/lib/libhp-ux.a(pm_prot.o):
		pm_prot.c $Date: 2000/07/14 09:34:52 $Revision: r11r
			os/6 PATCH_11.00 (PHKL_22032)
	/usr/conf/lib/libhp-ux.a(pm_ptrace.o):
		ttrace_private.h $Date: 1998/12/15 09:21:36 $Revisio
			n: r11ros/cup_ros_ep1_pb/3 PATCH_11.00 (PHKL
			_17205)
		pm_ptrace.c $Date: 2001/05/14 14:45:15 $Revision: r1
			1ros/15 PATCH_11.00 (PHKL_24116)
	/usr/conf/lib/libhp-ux.a(ufs_mchdep.o):
		ufs_mchdep.c $Date: 2000/06/05 17:05:33 $Revision: r
			11ros/6 PATCH_11.00 (PHKL_21781)
	/usr/conf/lib/libhp-ux.a(vfs_bio.o):
		vfs_bio.c $Date: 2000/10/20 06:59:31 $Revision: r11r
			os/21 PATCH_11.00 (PHKL_22549)
	/usr/conf/lib/libhp-ux.a(vm_clic.o):
		vm_clic.c $Date: 2001/04/23 13:03:40 $Revision: r11r
			os/4 PATCH_11.00 (PHKL_23857)
	/usr/conf/lib/libhp-ux.a(vm_kern.o):
		vm_kern.c $Date: 2000/04/12 03:18:15 $Revision: r11r
			os/4 PATCH_11.00 (PHKL_21532)
	/usr/conf/lib/libhp-ux.a(vm_machdep.o):
		vm_machdep.c $Date: 2001/04/17 14:38:30 $Revision: r
			11ros/35 PATCH_11.00 (PHKL_23813)
	/usr/conf/lib/libhp-ux.a(vm_machreg.o):
		vm_machreg.c $Date: 2000/09/11 14:14:58 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_22380)
	/usr/conf/lib/libhp-ux.a(vm_memlock.o):
		vm_memlock.c $Date: 2001/08/17 14:43:30 $Revision: r
			11ros/5 PATCH_11.00 (PHKL_24971)
	/usr/conf/lib/libhp-ux.a(vm_mlock.o):
		vm_mlock.c $Date: 2000/05/03 15:11:15 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_21624)
	/usr/conf/lib/libhp-ux.a(vm_mmap.o):
		vm_mmap.c $Date: 2001/08/02 16:42:17 $Revision: r11r
			os/21 PATCH_11.00 (PHKL_24826)
	/usr/conf/lib/libhp-ux.a(vm_pgalloc.o):
		vm_pgalloc.c $Date: 2000/05/03 15:11:15 $Revision: r
			11ros/4 PATCH_11.00 (PHKL_21624)
	/usr/conf/lib/libhp-ux.a(vm_pregion.o):
		vm_pregion.c $Date: 2001/05/29 15:16:13 $Revision: r
			11ros/11 PATCH_11.00 (PHKL_24273)
	/usr/conf/lib/libhp-ux.a(vm_realmain.o):
		vm_realmain64.c $Date: 2001/04/17 14:38:30 $Revision
			: r11ros/9 PATCH_11.00 (PHKL_23813)
	/usr/conf/lib/libhp-ux.a(vm_remap.o):
		vm_remap.c $Date: 2000/08/14 11:40:53 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_22126)
	/usr/conf/lib/libhp-ux.a(vm_sched.o):
		vm_sched.c $Date: 2000/09/20 14:54:13 $Revision: r11
			ros/8 PATCH_11.00 (PHKL_22440)
	/usr/conf/lib/libhp-ux.a(vm_vas.o):
		vm_vas.c $Date: 2000/11/14 06:37:13 $Revision: r11ro
			s/12 PATCH_11.00 (PHKL_22744)
	/usr/conf/lib/libhp-ux.a(vm_vfd.o):
		vm_vfd.c $Date: 2000/01/25 08:06:48 $Revision: r11ro
			s/7 PATCH_11.00 (PHKL_20945)
	/usr/conf/lib/libhp-ux.a(vm_vhand.o):
		vm_vhand.c $Date: 2000/04/12 03:18:15 $Revision: r11
			ros/6 PATCH_11.00 (PHKL_21532)

cksum(1) Output:
	
	OS-Core.CORE-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	1807138169 5655 /usr/conf/h/map.h
	143359630 10831 /usr/conf/h/vm_mlock.h
	2017539801 2705 /usr/conf/machine/hdl_preg.h
	2704551415 54554 /usr/conf/machine/pdc_rqsts.h
	2001644049 11365 /usr/conf/sio/async.h

	ProgSupport.C-INC,fr=B.11.00,fa=HP-UX_B.11.00_32/64,v=HP:
	2017539801 2705 /usr/include/machine/hdl_preg.h
	2704551415 54554 /usr/include/machine/pdc_rqsts.h
	2001644049 11365 /usr/include/sio/async.h
	1807138169 5655 /usr/include/sys/map.h
	143359630 10831 /usr/include/sys/vm_mlock.h

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_32,v=HP:
	1165757719 22604 /usr/conf/lib/libhp-ux.a(async.o)
	2248021923 4184 /usr/conf/lib/libhp-ux.a(clic_stubs.o)
	3665843420 28992 /usr/conf/lib/libhp-ux.a(clock.o)
	4068629077 12468 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
	3676646299 14204 /usr/conf/lib/libhp-ux.a(dmem.o)
	3831526811 21028 /usr/conf/lib/libhp-ux.a(hdl_fault.o)
	1371839555 8208 /usr/conf/lib/libhp-ux.a(hdl_init.o)
	1842983883 19544 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
	1652933539 16880 /usr/conf/lib/libhp-ux.a(hdl_policy.o)
	922639598 13352 /usr/conf/lib/libhp-ux.a(hdl_trans.o)
	2046115620 23708 /usr/conf/lib/libhp-ux.a(init_main.o)
	3246280857 32016 /usr/conf/lib/libhp-ux.a(kern_exec.o)
	3281692625 27244 /usr/conf/lib/libhp-ux.a(kern_exit.o)
	21078018 16512 /usr/conf/lib/libhp-ux.a(kern_mallo.o)
	2757401471 3892 /usr/conf/lib/libhp-ux.a(kern_mman.o)
	242210559 23500 /usr/conf/lib/libhp-ux.a(kgdb_machine.o)
	2417393137 12052 /usr/conf/lib/libhp-ux.a(kmall_trace.o)
	1015401007 6688 /usr/conf/lib/libhp-ux.a(onyxe.o)
	437464505 24204 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
	3427014055 8424 /usr/conf/lib/libhp-ux.a(pm_core.o)
	533481460 3940 /usr/conf/lib/libhp-ux.a(pm_cred.o)
	3206193979 17348 /usr/conf/lib/libhp-ux.a(pm_prot.o)
	2031792614 55296 /usr/conf/lib/libhp-ux.a(pm_ptrace.o)
	1770547053 11480 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
	491545001 38384 /usr/conf/lib/libhp-ux.a(vfs_bio.o)
	2950872455 4616 /usr/conf/lib/libhp-ux.a(vm_clic.o)
	3153431302 14300 /usr/conf/lib/libhp-ux.a(vm_kern.o)
	1189989698 91060 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
	3370891229 23684 /usr/conf/lib/libhp-ux.a(vm_machreg.o)
	1745969010 13212 /usr/conf/lib/libhp-ux.a(vm_memlock.o)
	3819274536 5508 /usr/conf/lib/libhp-ux.a(vm_mlock.o)
	4057878370 30728 /usr/conf/lib/libhp-ux.a(vm_mmap.o)
	2032665462 18108 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
	1040416982 16056 /usr/conf/lib/libhp-ux.a(vm_pregion.o)
	2834688110 16212 /usr/conf/lib/libhp-ux.a(vm_realmain.o)
	617206859 9864 /usr/conf/lib/libhp-ux.a(vm_remap.o)
	2775488280 27896 /usr/conf/lib/libhp-ux.a(vm_sched.o)
	1870073525 14936 /usr/conf/lib/libhp-ux.a(vm_vas.o)
	2865378029 15312 /usr/conf/lib/libhp-ux.a(vm_vfd.o)
	3925871171 18564 /usr/conf/lib/libhp-ux.a(vm_vhand.o)

	OS-Core.CORE2-KRN,fr=B.11.00,fa=HP-UX_B.11.00_64,v=HP:
	2023403024 47088 /usr/conf/lib/libhp-ux.a(async.o)
	1726116097 11064 /usr/conf/lib/libhp-ux.a(clic_stubs.o)
	3940258843 69752 /usr/conf/lib/libhp-ux.a(clock.o)
	867340842 27976 /usr/conf/lib/libhp-ux.a(cnx_p2p_bcopy.o)
	4179883992 32600 /usr/conf/lib/libhp-ux.a(dmem.o)
	397048167 40400 /usr/conf/lib/libhp-ux.a(hdl_fault.o)
	3930614899 23664 /usr/conf/lib/libhp-ux.a(hdl_init.o)
	3803636533 40584 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o)
	1498538806 35688 /usr/conf/lib/libhp-ux.a(hdl_policy.o)
	2397291949 30128 /usr/conf/lib/libhp-ux.a(hdl_trans.o)
	3624897364 44960 /usr/conf/lib/libhp-ux.a(init_main.o)
	3910748425 73064 /usr/conf/lib/libhp-ux.a(kern_exec.o)
	3865257098 58008 /usr/conf/lib/libhp-ux.a(kern_exit.o)
	2106296386 40688 /usr/conf/lib/libhp-ux.a(kern_mallo.o)
	1485995480 9496 /usr/conf/lib/libhp-ux.a(kern_mman.o)
	3218363655 49456 /usr/conf/lib/libhp-ux.a(kgdb_machine.o)
	2315482884 28136 /usr/conf/lib/libhp-ux.a(kmall_trace.o)
	3954087531 16120 /usr/conf/lib/libhp-ux.a(onyxe.o)
	280788522 56256 /usr/conf/lib/libhp-ux.a(pa_generic_psm.o)
	3497115895 15600 /usr/conf/lib/libhp-ux.a(pm_core.o)
	1935319995 11120 /usr/conf/lib/libhp-ux.a(pm_cred.o)
	1706233712 38488 /usr/conf/lib/libhp-ux.a(pm_prot.o)
	1298300107 128424 /usr/conf/lib/libhp-ux.a(pm_ptrace.o)
	2381969701 26936 /usr/conf/lib/libhp-ux.a(ufs_mchdep.o)
	12735115 86832 /usr/conf/lib/libhp-ux.a(vfs_bio.o)
	3690125124 9736 /usr/conf/lib/libhp-ux.a(vm_clic.o)
	2977196837 62544 /usr/conf/lib/libhp-ux.a(vm_kern.o)
	71164995 181880 /usr/conf/lib/libhp-ux.a(vm_machdep.o)
	2821417790 51512 /usr/conf/lib/libhp-ux.a(vm_machreg.o)
	1899366477 32040 /usr/conf/lib/libhp-ux.a(vm_memlock.o)
	4276086089 12768 /usr/conf/lib/libhp-ux.a(vm_mlock.o)
	2994313186 68392 /usr/conf/lib/libhp-ux.a(vm_mmap.o)
	2937271311 40984 /usr/conf/lib/libhp-ux.a(vm_pgalloc.o)
	4235287590 32224 /usr/conf/lib/libhp-ux.a(vm_pregion.o)
	2565972548 23312 /usr/conf/lib/libhp-ux.a(vm_realmain.o)
	163951282 18552 /usr/conf/lib/libhp-ux.a(vm_remap.o)
	1419148136 75072 /usr/conf/lib/libhp-ux.a(vm_sched.o)
	3867637122 35248 /usr/conf/lib/libhp-ux.a(vm_vas.o)
	985640121 36512 /usr/conf/lib/libhp-ux.a(vm_vfd.o)
	1479621621 46296 /usr/conf/lib/libhp-ux.a(vm_vhand.o)

Patch Conflicts: None

Patch Dependencies:
	s700: 11.00: PHKL_18543
	s800: 11.00: PHKL_18543

Hardware Dependencies: None

Other Dependencies:
	PHKL_21549 is required when using the gang scheduler.
	Without PHKL_21549, the gang scheduler exhibits unacceptable
	performance after this patch is installed.

	PHKL_23406:  If NFS is installed on the system, all five
	patches (PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408,
	PHKL_23409) are required to resolve the process
	hang/deadlock due to unkillable processes executed over NFS.
	However, if NFS is not in use, none of these patches are
	required.

	PHKL_23813:  Two other patches work in conjuction with this
	patch to enable PA-8700 support.  These other two patches
	are PHKL_23814 and PHKL_23815.

Supersedes:
	PHKL_22843 PHKL_22493 PHKL_22032 PHKL_21775 PHKL_21600 PHKL_21535
	PHKL_21507 PHKL_21358 PHKL_21357 PHKL_21350 PHKL_20995 PHKL_20945
	PHKL_20836 PHKL_20647 PHKL_20515 PHKL_20449 PHKL_20439 PHKL_20426
	PHKL_20227 PHKL_20226 PHKL_20224 PHKL_20223 PHKL_20102 PHKL_20017
	PHKL_19314 PHKL_19201 PHKL_17038 PHKL_24826 PHKL_24612 PHKL_24457
	PHKL_24273 PHKL_24116 PHKL_24015 PHKL_23857 PHKL_23813 PHKL_23812
	PHKL_23628 PHKL_23406 PHKL_23183 PHKL_22744 PHKL_22549 PHKL_22440
	PHKL_22380 PHKL_22126 PHKL_21781 PHKL_21624 PHKL_21532 PHKL_21354
	PHKL_21024 PHKL_21003 PHKL_20335 PHKL_20222

Equivalent Patches: None

Patch Package Size: 2880 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_24971

	5. Run swinstall to install the patch:

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

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

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

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

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

Special Installation Instructions:
	To enable the asyncio enhancement that defers memory
	locking to improve application startup times, create the
	async device file with minor number 256 using the
	following commands. The user must have super-user rights
	to execute these commands.

	Delete the old device file.
	# rmsf -v /dev/async

	Create the new device file
	# mknod /dev/async c 101 256

	Note: This minor number should only be used on systems that
	have enough physical memory so that paging is avoided.
	Paging can cause serious performance degradation with this
	new enhancement.  On systems where paging is an issue, this
	minor number should not be used.

	PHKL_23813:
	This patch, PHKL_23813, is one of the three 11.00 PA-8700
	enablement patches. The other 11.00 PA-8700 enablement
	patches are PHKL_23814 & PHKL_23815. Installation of
	each patch individually will have no  effect on the system.

	PHKL_23406:
	If NFS is installed on the system, all five patches
	(PHNE_23249, PHKL_23406, PHKL_23407, PHKL_23408, PHKL_23409)
	are required to resolve the process hang/deadlock due to
	unkillable processes executed over NFS.  However, if NFS is
	not in use, none of these patches are required.  All five of
	these patches may be installed independently.  If fewer than
	four out of the four PHKL patches are installed, the
	P_NOSTOP feature will not be enabled.

	PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20226, PHKL_20227:
	This patch contains part of the enhancement to enable the 3
	Gb private address space feature.  It is one of 8 patches.
	The 8 patches necessary to enable this feature are
	PHKL_20222, PHKL_20223, PHKL_20224, PHKL_20225, PHKL_20226,
	PHKL_20227, PHKL_20228 and PHKL_20229.  Each patch may be
	installed independently of the others - if enabling the 3 Gb
	private address space feature is not desired.  If fewer than
	all 8 patches are installed, the 3 Gb private address space
	feature will not be enabled.  The code in this patch that is
	part of this feature will not have any impact on the system
	until all 8 patches are installed.

	In order to be able to use this feature you will need to
	reconfigure the kernel with a larger value for the kernel
	configurable variable "maxdsiz". In order to do this with
	SAM, you will also need to install patch PHKL_20174. Without
	PHKL_20174 installed SAM will not allow maxdsiz to exceed
	 ~1.9 Gb. Note that if PHKL_20174 is not installed it is
	still possible to manually configure a kernel with a larger
	value of maxdsiz (up to 3 Gb) using config(1M).

	PHKL_21535:
	To enable shared memory dumping to application core files,
	you must first install this patch. After the new vmunix
	has been built by the patch process you need to set some
	kernel variables in the new vmunix using adb.

	To do this, first invoke adb with write capabilities
	on the vmunix file (typically /stand/vmunix):
	adb -w /stand/vmunix
	You may get some error output "Not an Elf file: No Elf
	header". ignore those errors.

	Setting core_addshmem_read to 1 enables dumping of
	read-protected shared memory segments.
	To set core_addshmem_read to 1, the command in adb is:
	core_addshmem_read?W1
	adb should output:
	core_addshmem_read:	0 	 =  1

	Setting core_addshmem_write to 1 enables dumping of
	write-protected shared memory segments.
	To set core_addshmem_write to 1, the command in adb is:
	core_addshmem_write?W1
	adb should output:
	core_addshmem_write:	0  	 =  1

	exit adb by typing
	$q

	Now the vmunix file should be enabled for shared memory
	dumping.  You must reboot in order for the change to take
	effect.  Note:  if a new vmunix is generated in the future,
	such as after installing another kernel patch, you will need
	to repeat this procedure.  This mechanism is typically used
	in troubleshooting applications.

	The effective user ID of the process calling async driver,
	typically called by a process for database applications such
	as Oracle and Sybase, must be a superuser or the user must
	be a member of a group that has the MLOCK privilege.

	To check the privilege capabilities for a group, issue the
	command:

	          /usr/bin/getprivgrp <group-name>

	If the output of getprivgrp(1) does not indicate that the
	group has the MLOCK privilege, it can be set by issuing the
	following command as root:

	          /usr/bin/setprivgrp <group-name> MLOCK

	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.

