 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHKL_30158
Patch Description: s700_800 11.11 Cumulative VM patch
Creation Date: 04/01/18
Post Date: 04/02/02
Warning: 04/05/18 - This Critical Warning has been issued by HP.
- PHKL_26386 introduced behavior that in rare circumstances
can cause a system panic. When the behavior occurs, the
mmap(2) system call may panic with a stack trace similar to
the following:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
shrinkvfd+0x70
growreg+0x1e8
mapvnode+0x1e0
mmap_file_object+0x128
smmap_common+0x2e8
smmap+0x50
syscall+0xaec
syscallinit+0x554
- The same behavior is exhibited by superseding patches
PHKL_26744, PHKL_27278, PHKL_28267, PHKL_28428, PHKL_28990,
PHKL_30158, and PHKL_30616.
- Since this change was implemented in February 2002, if a
system has been successfully running with any of these
patches installed it is unlikely that the behavior will be
observed in the future. However, to avoid this behavior, HP
recommends removing these patches from any systems
experiencing system panics with a stack trace similar to the
one described above.
- Additional information on this behavior may be found in
Service Request 8606354805 (JAGaf15561).
- The superseded patch, PHKL_26233, does not exhibit the
same behavior. If you choose to remove these patches, HP
recommends that PHKL_26233 be installed after the patches
are removed to ensure as many known issues as possible are
addressed. If PHKL_26233 was installed prior to these
patches, it will automatically be restored when the patches
are removed and it will not need to be reinstalled.
- This behavior will be corrected in a new patch as soon as
possible.
Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11
Products: N/A
Filesets:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP
Automatic Reboot?: Yes
Status: General Superseded With Warnings
Critical:
Yes
PHKL_30158: HANG
PHKL_28990: ABORT CORRUPTION HANG
The defect described in JAGae67573 can result in
seemingly random application failures for those
applications that call mprotect(2) with the
PROT_CHECK flag.
PHKL_28428: PANIC CORRUPTION
PHKL_28267: PANIC CORRUPTION
PHKL_27278: PANIC CORRUPTION
PHKL_26744: PANIC
PHKL_26233: PANIC
PHKL_25614: CORRUPTION PANIC ABORT
JAGad62420: a process with a private 3rd quadrant
can obtain an erroneous address when calling mmap(2)
for a large mapping ( size > 1 GB). The erroneous
address can match an already existing address for
that process. If this is the case, subsequent use
of this address could lead to corruption of data
already at that address, as now 2 pointers with
different meaning refer to the same block of data.
The corruption is limited to the own address space
of the process, and possibly files mapped by the
process.
The corruption is limited to the calling process
address space, and will not affect system or other
process memory.
PHKL_25129: CORRUPTION
PHKL_24073: HANG
Category Tags:
defect_repair enhancement general_release critical panic
halts_system corruption
Path Name: /hp-ux_patches/s700_800/11.X/PHKL_30158
Symptoms:
PHKL_30158:
( SR:8606335008 CR:JAGae96085 )
System may hang when fork(2) fails due to unavailable
protection or space ids. The following is the stack
trace when the hang is TOC'ed.
su_waiters+0x10
call_su_waiters+0x1c
lock_write+0xfc
findpreg+0x150
pfault+0xe4
trap+0xa1c
nokgdb+0x8
b_eight_word_loop+0x4
long_copyin+0xb4
long_uiomove+0xfc
vx_write_default+0xab0
vx_write1+0x878
vx_rdwr+0x144
vn_rdwr+0x84
write_to_core+0xe0
write_prp_core+0x3c
pa32_write_prp_seg+0x7c
pa32_walkpregions+0x50
pa32_core+0x134
core+0x1b8
psig+0x4fc
syscall+0xb38
$syscallrtn+0x0
syscall+0xb38
$syscallrtn+0x0
PHKL_28990:
( SR:8606304228 CR:JAGae67573 )
Applications that use the mprotect(2) system call with the
PROT_CHECK flag may fail randomly due to an incorrect
result returned from mprotect(2).
( SR:8606283720 CR:JAGae47665 )
This patch is required for systems running Hyper Messaging
Protocol(HMP)/Message Passing Interface (MPI)
applications. The MPI applications hang after some time
as they receive corrupt data. This problem can be seen on
systems running MPI or HMP applications with the
hyperfabric cards.
When the parent forks and the child exits before the parent
(MPI/HMP application) sends/receives data, there could be
data corruption. The behavior is evident when using a
popen(), pclose() call and immediately starting data
transfer via HMP.
PHKL_28428:
( SR:8606267409 CR:JAGae31651 )
System panic when removing an iomap range from a child
process of a fork() system call when the parent process
has already removed the range.
Trap Type 15 (Data page fault):
Instruction Address (pcsq.pcoq) = 0x0.0x1256c4
Instruction (iir) = 0x4134002e (load/store)
Target Address (isr.ior) = 0x0.0x0000000000000017
Base Register (gr9) = 0x0000000000000000
Savestate Ptr (ssp) = 0xe57bc00.0x400003ffffff1378
Savestate Return Pointer (ss_rp) = 0x00000000001256c0
panic: Data page fault
A typical stack trace for this problem is:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xef4
nokgdb+0x8
pddpage+0xc4
io_unmap+0x25c
iomap_nuke+0x24
iomap_exit+0xa4
exit+0xf30
rexit+0x24
syscall+0x20c
$syscallrtn+0x0
( SR:8606267454 CR:JAGae31696 )
This problem was found in HP internal analysis and
has not been encountered on customer systems. If
the problem occurs, the system may panic or experience
system memory corruption (which may in turn cause user
memory corruption). Because the exact behavior depends
entirely on the state of the system, a typical stack
trace for such a panic is not possible.
PHKL_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
Under certain conditions of a process fork/exit, the system
may panic with the panic string: "freevas: vas cnt 0, but
still pointing to pregions".
The stack trace may be similar to:
panic+0x14
freevas+0x164
freeproc+0x22c
wait1+0x25c
waitpid+0x38
syscall+0x394
$syscallrtn+0x0
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
Using glance, or any tools based on pstat, to report memory
information about a single-threaded process, can cause a
panic.
The panic will occur in psl_search(). Before the panic
occurs, corruption is possible as the process address space
is corrupted.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
A data page fault panic may occur as the result of running
mmap(2) more than 65535 times on a file. The resulting
stack trace may look similar to the following:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xa9c
nokgdb+0x8
skl_deletevalue+0x4
remove_pregion_from_region+0xc8
detachreg+0xa4
dispreg+0x164
exit+0xb3c
rexit+0x24
syscall+0x724
$syscallrtn+0x0
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update provides pre-enablement of extensions
to mmap to allow mapping of I/O registers or address
ranges.
This product update will have no impact on your system
until the extensions to mmap are fully enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
System panic with the following stack trace.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
hdl_vfault+0x80
vfault+0x12c
trap+0x234
thandler+0xd20
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
A 32 bit process with the 3rd quadrant private (obtained
with the command chattr +q3 enable) can obtain an incorrect
address when requesting a large (~1 GB) mapping with the
mmap(2) call.
Observed symptoms are :
-process aborted because of a memory fault
(signals SIGBUS or SIGSEGV).
-corruption of the memory for the calling process,
including files that are mapped in memory by the process.
System memory and memory from other processes are not
impacted.
( SR:8606212954 CR:JAGad82141 )
When a 32 bit process uses mmap64(2) to mmap(2) a large file
on a 64 bit kernel, if the offset is bigger than 4 GB, the
call returns EINVAL.
( SR:8606188767 CR:JAGad57983 )
Applications requiring large amounts of private memory
address space (greater than 2GB) may use shared memory space
to offset their private memory space needs. This is done by
using the mmap(2) flags:
MAP_ANONYMOUS|MAP_GLOBAL|MAP_SHARED.
Even with this effort to conserve private memory space,
these applications are running out of private memory space.
A close examination shows that allocations intended for
shared space were put into private memory space in error.
( SR:8606205797 CR:JAGad74972 )
A panic "Returning ID that is already free" may occur as a
result of a process (proc A) calling mmap(2) with MAP_FIXED
and an address that overlaps with an existing text mapping.
This will result in a panic in one of the following ways:
(1) Panic occurs when process proc A exits.
(2) The process proc A does a munmap(2) of the previous
mmap(2) (as mentioned above) and subsequent mmap(2)
calls from any process (proc X) get assigned the same
address. When process proc X exits (case 1) the panic
occurs.
A stack trace may look similar to the following:
panic+0x6c
hdl_return_id+0xb8
hdl_free_protid+0x1c
hdl_detach+0x17c
attachreg+0x228
mmap_anon_object+0xc4
smmap_common+0x35c
smmap+0x50
syscall+0x750
$syscallrtn+0x0
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
Memory corruption may occur after the installation of
PHKL_24679.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
The system takes a lot of time in creating a large number of
threads. The cost of creating threads increases
exponentially as the number of threads increases and so the
system appears to be very slow when one tries to create a
lot of threads.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
Narrow mode (32bit) HP-UX 11.11 programs cannot mmap64() any
part of a large file beyond the first 2GB.
PHKL_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Decreased performance for mmap() operations has occasionally
been observed in superdome systems with more than 32 cpus.
These symptoms are not specific to superdomes, but could
possibly occur on other high end systems as well.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
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.
Defect Description:
PHKL_30158:
( SR:8606335008 CR:JAGae96085 )
When a process having called mprotect(PROT_NONE) on
private region(s) calls fork(2) system call and if
fork(2) does not succeed due to unavailability of
protection or space ids, it may result in hang.
This is due to freeing the parent process' resources
incorrectly in the fork(2) cleanup path.
Resolution:
Incorrect logic in the fork(2) cleanup path is corrected.
PHKL_28990:
( SR:8606304228 CR:JAGae67573 )
mprotect(2), when called with the PROT_CHECK flag, was
checking access rights on pages from the beginning of the
specified pregion instead of from the pregion offset that
is passed in.
Resolution:
Corrected the access protection checking code to begin at
the given offset instead of at the beginning of the
pregion.
( SR:8606283720 CR:JAGae47665 )
When MPI/HMP applications fork a child process and
make the child exit, the child - which shares the parent's
address space because of the Copy On Write feature of
fork - clears bits incorrectly in the shared pages.
This action leads to data corruption for the parent.
Since the bit is incorrectly cleared, the HMP call
back function is not called when the parent does a
copy-on-write. So, the lowfat code writes new data
to the old page causing data corruption. This defect
exists in the large page (> 4k) code only.
Resolution:
Corrected the code to disallow the child from
incorrectly clearing bits in the shared address space.
PHKL_28428:
( SR:8606267409 CR:JAGae31651 )
The fork() system call does not add the child process
address space to the iomap control structures as intended
when the parent of the fork() has performed an iomap.
Resolution:
Revised the fork() system call to add the child address
space as intended.
( SR:8606267454 CR:JAGae31696 )
The exec() system call re-uses the address space of the
calling process for the target process. If the calling
process had performed an iomap operation (via a device
driver), the mapping is removed from the address space.
However, the address space is not being removed from
the iomap control structures. When the target process
exits, the kernel memory address of this address space
remains in the control structures. This address may now
reference a new kernel structure, kernel data, or memory
which is not in use. Since the use of this reference in
the control structures involves memory reads and writes,
using the invalid reference may cause a kernel panic
or may overwrite kernel or user data.
Resolution:
Perform the removal of such a mapping in the exec()
system call in the same way as an explicit unmap,
ensuring that the address space reference is also
removed.
PHKL_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
The reference count for the process' Virtual Address Space
(vas) is not protected from multiple concurrent accesses
by any lock. This results in a race condition and possible
ambiguous value in the reference count. If the reference
count is decremented to zero but the vas is still pointing
to valid pregions that are still in use, the freevas panic
will occur when attempting to free the vas.
Resolution:
The resolution is to lock the vas whenever the reference
count is incremented/decremented, thereby serializing
any changes and maintaining coherency of the reference
count.
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
There is a race condition between pstat and a function
managing a process address space. This causes the corruption
of the list representing a process address space, leading
to a panic.
Resolution:
The fix consists of enforcing locking even for
single-threaded processes, to protect them from
external pstat requests.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
The variable holding the mmap reference count is not checked
for overflow. When the variable resets to zero, the system
panics with a data page fault.
Resolution:
The overflow condition is now detected. The panic is
avoided by returning ENOMEM when the mmap(2) reference count
variable overflows.
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update contains minor enhancements required to
enable extensions to mmap to allow mapping of I/O registers
or address ranges.
Resolution:
Extended mmap to recognize MAP_IO flag and perform mapping
if functionality is enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
Kernel incorrectly handles some of the parameters to
setrlimit.
Resolution:
The kernel is fixed to handle the particular parameters
correctly.
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
On 64 bit systems, calls to mmap(2) by 32 bit processes with
sizes in the range of 1 GB or greater cause the allocation
algorithm to allocate a segment in the 64 bit address space
instead of the 32 bit address space. The 64 bit address is
truncated to 32 bits on return to the 32 bit calling
process. The cause of this error is an incorrect boundaries
checking in the allocation algorithm. When using a
debugger, one can observe a 64 bit segment in the process
address space.
Resolution:
The allocation algorithm now checks boundary conditions
correctly, producing a correct memory address.
( SR:8606212954 CR:JAGad82141 )
One kernel structure associated with the mapped file is
based on the type of the process address space. Thus a 32
bit process creates a 32 bit mapped file kernel structure.
The kernel structure should be independent from the type of
the calling process.
Resolution:
The creation of the kernel structure associated with a mmap
file has been made independent from the type of the process.
( SR:8606188767 CR:JAGad57983 )
The mmap(2) system call ignores the MAP_GLOBAL flag when
used in combination with the MAP_SHARED and MAP_ANONYMOUS
flags.
Resolution:
Checking for the MAP_GLOBAL option in mmap(2) when the
MAP_ANONYMOUS and MAP_SHARED flags are used. The allocation
is then made from the appropriate quadrant.
( SR:8606205797 CR:JAGad74972 )
This panic results from trying to free the same ID twice as
a result of the system allowing a mapping that overlaps with
an existing mapping of text.
Resolution:
mmap(2) calls with addresses that overlap with existing text
mappings will now fail.
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
In one corner case the fix for "PHKL_24679" overwrites some
memory beyond the allocated limit for an internal data
structure.
Resolution:
Overwriting of memory is fixed by checking for a corner
case.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
When ever a range of virtual address space is allocated for
a thread the OS always searches for a hole from the highest
possible address so as to give maximum possible space for
the heap to grow. When large number of threads are created
and all space in the proximity of the highest address is
occupied it takes a while before the search could get a
hole of required size, which slows down the thread creation
process.
Resolution:
The fix to the problem is to keep a hint for starting the
search next time so we do not have to start always from the
highest address.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
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_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Unnecessary acquisition and release of region locks in
common execution paths can cause unpredictable performance
degradation.
Resolution:
ltered code path to minimize frequency of region
lock/release in procedures mmap_file_pieces() and
mmap_file_object(). Note that this is only one of the
causes for unpredictable performance degradation in mmap.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
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.
Enhancement:
No (superseded patches contained enhancements)
PHKL_28428:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
SR:
8606186482 8606188435 8606188767 8606189205 8606193208
8606201639 8606202772 8606204858 8606205558 8606205797
8606212954 8606215349 8606220721 8606227157 8606230627
8606262338 8606267409 8606267454 8606283720 8606304228
8606335008
Patch Files:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm.a(vm_vas.o)
what(1) Output:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r
11.11/3 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2003/04/30 16:15:57 $Revision: r11.
11/7 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r
11.11/6 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2004/01/15 21:24:49 $Revision: r11.1
1/6 PATCH_11.11 (PHKL_30158)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r
11.11/3 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2003/04/30 16:15:57 $Revision: r11.
11/7 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2003/04/11 12:42:27 $Revision: r
11.11/6 PATCH_11.11 (PHKL_28990)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2004/01/15 21:24:49 $Revision: r11.1
1/6 PATCH_11.11 (PHKL_30158)
cksum(1) Output:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
3311638838 18940 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
1100962443 8576 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
3926868510 32604 /usr/conf/lib/libvm.a(vm_mmap.o)
2080795126 16404 /usr/conf/lib/libvm.a(vm_pregion.o)
1045261532 15684 /usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
2833422939 42680 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
617116363 17144 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
3218804588 71024 /usr/conf/lib/libvm.a(vm_mmap.o)
4189893640 33320 /usr/conf/lib/libvm.a(vm_pregion.o)
2001844405 36440 /usr/conf/lib/libvm.a(vm_vas.o)
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_28990 PHKL_28428 PHKL_28267 PHKL_27278 PHKL_26744 PHKL_26386
PHKL_26233 PHKL_25614 PHKL_25227 PHKL_25129 PHKL_24743 PHKL_24679
PHKL_24073
Equivalent Patches: None
Patch Package Size: 170 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_30158
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_30158.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_30158. 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_30158.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_30158.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_30158.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
|
Printable version
