|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: IT Resource Center (support_feedback
us-support-mail.external.hp.com)Date: Sun Jul 07 2002 - 07:35:10 CDT
HP Support Information Digests
===============================================================================
o IT Resource Center World Wide Web Service
---------------------------------------------------
If you subscribed through the IT Resource Center and would
like to be REMOVED from this mailing list, access the
IT Resource Center on the World Wide Web at:
http://www.itresourcecenter.hp.com/
Login using your IT Resource Center User ID and Password.
Then select Support Information Digests (located under
Maintenance and Support). You may then unsubscribe from the
appropriate digest.
To download a patch referenced below, access the
IT Resource Center on the World Wide Web at:
http://www.itresourcecenter.hp.com/
Login using your IT Resource Center User ID and Password.
Then select Individual Patches (under Maintenance and Support)
to access the patch. You may also download a patch via anonymous
ftp(1) from ftp.itrc.hp.com.
===============================================================================
Digest Name: weekly HP-UX series 800 10.X patch digest
Created: Sun Jul 7 3:05:02 PDT 2002
Table of Contents:
Document ID Title
--------------- -----------
PHSS_27365 s700_800 10.X Shared libF90 B.10.20.12 (post [10.20.19])
PHSS_27362 s700_800 10.X Fortran90 patch from B.10.20.40 to B.10.20.54
PHSS_27105 s700_800 10.20 LIBCL cumulative patch
PHKL_25439 s800 10.20 LVM cumulative patch, array controller hot-swap
PHCO_26962 s700_800 10.20 cumulative patch for shutdown(1M)
The documents are listed below.
-------------------------------------------------------------------------------
Document ID: PHSS_27365
Date Loaded: 20020702
Title: s700_800 10.X Shared libF90 B.10.20.12 (post [10.20.19])
Patch Name: PHSS_27365
Patch Description: s700_800 10.X Shared libF90 B.10.20.12 (post [10.20.19])
Creation Date: 02/06/26
Post Date: 02/07/02
Hardware Platforms - OS Releases:
s700: 10.00 10.01 10.10 10.20
s800: 10.00 10.01 10.10 10.20
Products: N/A
Filesets:
OS-Core.CORE-SHLIBS
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHSS_27365
Symptoms:
PHSS_27365:
JAGae13771: Add rsqrt (reciprocal square root) intrinsic
JAGad99133: present intrinsic does not always work.
JAGad99152: indirect common is in subprogram not working
JAGad28041: added MVBITS, HMVBITS, BMVBITS functions.
PHSS_25713:
JAGad48285: copy_out performs poorly for contiguous mem.
JAGad69903: zero sized arrays may cause unexpected results
NoJAG: ASM version of leadz, popcnt added needed.
JAGad99133: Customer reports present intrinsic does't work
PHSS_20852:
JAGab72608 Need shared libF90 on 10.X
Defect Description:
PHSS_27365:
JAGae13771: Add rsqrt (reciprocal square root) intrinsic
JAGad99133: present intrinsic does not always work
especially for arrays passed by dv.
JAGad99152: indirect common is in subprogram not working
JAGad28041: added MVBITS, HMVBITS, BMVBITS functions.
PHSS_25713:
JAGad48285: copy_out now checks for contiguous mem.
JAGad69903: Some intrinsics didn't expect zero sized arrays
NoJAG: Slow version of ASM leadz, popcnt added.
JAGad99133: Customer reports present intrinsic does't work
PHSS_20852:
JAGab72608 supplied a shared version of libF90 in /usr/lib
SR:
8606104852 8606179060 8606200727 8606230082 8606247331
8606247331 8606230101 8606158711
Patch Files:
/usr/lib/libF90.1
/usr/lib/libF90.sl
/usr/lib/nls/msg/C/libF90.cat
what(1) Output:
/usr/lib/libF90.1:
libF90 HP HPUX [ Release B.10.20.14 pa1.1 32bit ]
(hp700:hp/ux) Jun 24 2002
Copyright (c) 2001 Hewlett Packard.
/usr/lib/libF90.sl:
libF90 HP HPUX [ Release B.10.20.14 pa1.1 32bit ]
(hp700:hp/ux) Jun 24 2002
Copyright (c) 2001 Hewlett Packard.
/usr/lib/nls/msg/C/libF90.cat:
None
cksum(1) Output:
2411319331 3674112 /usr/lib/libF90.1
2411319331 3674112 /usr/lib/libF90.sl
2431138043 9677 /usr/lib/nls/msg/C/libF90.cat
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHSS_25713 PHSS_20852
Equivalent Patches:
PHSS_25714:
s700: 11.00 11.10
s800: 11.00 11.10
PHSS_25715:
s700: 11.11
s800: 11.11
PHSS_25716:
s700: 11.20
s800: 11.20
Patch Package Size: 3660 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 PHSS_27365
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHSS_27365.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHSS_27365. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
WARNING: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHSS_27365.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHSS_27365.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHSS_27365------------------------------------------
Document ID: PHSS_27362
Date Loaded: 20020702
Title: s700_800 10.X Fortran90 patch from B.10.20.40 to B.10.20.54
Patch Name: PHSS_27362
Patch Description: s700_800 10.X Fortran90 patch from B.10.20.40 to B.10.20.54
Creation Date: 02/06/24
Post Date: 02/07/02
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products:
FORTRAN90 B.10.20.40
FORTRAN90 B.10.20.42
Filesets:
FORTRAN90.FORT90-PRG,B.10.20.40
FORTRAN90.FORT90-PRG,B.10.20.42
FORTRAN90.FORT90-MAN,B.10.20.40
FORTRAN90.FORT90-MAN,B.10.20.42
FORTRAN90.F90-JPN-E-MAN,B.10.20.40
FORTRAN90.F90-JPN-E-MAN,B.10.20.42
FORTRAN90.F90-JPN-S-MAN,B.10.20.40
FORTRAN90.F90-JPN-S-MAN,B.10.20.42
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHSS_27362
Symptoms:
PHSS_27362:
01)JAGae30245: The compiler aborts when +i8 is used with
values greather than 2**31.
02)JAGae30374: The compiler issues an internal error
message when the first argument to an
elemental procedure is not an array.
PHSS_27071:
01)JAGae21542: The compiler aborts at +O3 in
replace_interval.
02)JAGae22867: The compiler aborts during compiling
rshift.
03)JAGae22891: Segmentation fault when executing
subroutines with a large number of
arguments.
04)JAGae23557: The compiler issues Error 215, Dummy
argument of a private procedure cannot have
a type that is private.
05)JAGae23902: Performance problem caused by extra
prefetches if using default cache line size.
06)JAGae24654: Poor performance with multiple memory
moves on some allocatable array types.
07)JAGae25135: Subscript range error not detected in I/O
implied DO.
08)JAGae25225: The compiled program aborts when named
parameters are used in some calls.
PHSS_26862:
01)JAGae14855: The compiler generates an error message
for read(f(),*) when f is a character
function.
02)JAGae16233: The compiler generates an error message
for a labelled ENDDO statement.
03)JAGae16582: Compiled programs encountered segmentation
violation in math intrinsic routines.
04)JAGae18265: Traceback information not always output
when compiler aborts.
05)JAGae18321: The compiler generates an error when a
statement function is used for a character
declared with a parameter.
06)JAGae19609: The compiler processes C$PAR directives
even when Open MP is used.
07)JAGae19504: The compiler aborts with interal error on
some codes at all optimization levels with
the -g option.
PHSS_26731:
01)JAGad31237: Inferior performance for automatic and
allocatable arrays.
02)JAGae07707: Compiling at +O3 results in the compiler
running out of memory in codes which
accumulate a result from a large number of
min or max expressions.
03)JAGae08269: f90 option -C - reports an error with
zero-sized array.
04)JAGae09212: Implement +A alignment option for backward
f77 compatibility.
05)JAGae09539: Wrong answers at +O2 +DA2.0W.
06)JAGae09734: The compiler aborts with internal error
10000.
07)JAGae09920: The compiler aborts with name table
overflow.
08)JAGae10093: The compiler gets wrong answers at +O3
with automatic arrays.
09)JAGae10762: The compiler issues an error message when
MIN1 and MAX1 are called with integer
arguments.
10)JAGae12200: $HP$ALIAS directive on interfaces are
not honored.
11)JAGae13356: The compiler was looking up constant
operands in the dictionary table.
12)JAGae13388: The compiler aborts on use of a format
label with OpenMP, legal code is rejected.
13)JAGae14315: The compiler gives wrong answers in 64
bit mode when using statement functions.
14)JAGae14622: The comiler aborts for +A compilation of
2 byte aligned common item.
PHSS_26376:
01)JAGae01864: When using allocatable arrays embedded
in a F90 record type, the program will
bus error or seg fault during the program
execution.
02)JAGae04245: Compiler aborts when -g is specified with
union map regions containing only one
component.
03)JAGae04558: The program gets wrong answers at +O2.
04)JAGae05471: GDB cannot stop at the end of a program
due to missing SLT entry.
05)JAGae05719: The executable gets wrong answers with
parmsoverlap at optimization level +O3.
06)JAGae06390: Customer wants O'400' and Z'400' treated
as 2 bytes for intrinsic calls.
07)JAGae07001: The compiler aborts when a PARAMETER
statement redefines a COMMON definition.
08)JAGae07078: The compiler rejects IAND(I4,i2const)
with +i2.
09)JAGae07262: IAND and IOR do not accept a mixture of
INTEGER*2 and INTEGER*4 arguments.
10)JAGae07652: The compiler mishandles the ORDERED clause
within nested parallel directives.
11)JAGae07658: The compiler does not honor f77 style
OPTIMIZE directives.
12)JAGae07660: The compiler does not honor f77 style
SAVE_LOCALS directives.
13)JAGae07707: Compiling at +O3 results in the compiler
running out of memory in codes which
accumulate a result from a large number of
min or max expressions.
14)JAGae07710: The compiler aborts with when an undeclared
function reference is used in a call.
15)JAGae07953: Intrinsic iint is not allowed with
type int.
16)JAGae08246: The compiler aborts with +i8 on
SIZE(array,dim) intrinsic.
17)JAGae08269: The compiler reports a subscript error when
using -C with a zero sized array.
18)JAGae09734: The compiler aborts on NASTRAN code.
19)JAGae09920: Compiler aborts on very large source file.
PHSS_26066:
01)JAGab70324: The compiler aborts with internal error
5172 with large real*8 arrays.
02)JAGad96334: Inefficient code generated in 64-bit mode
for loop indices.
03)JAGad97006: Wrong answer at optimization level +O2
due to use of EQUIVALENCE.
04)JAGad97103: Wrong answer at optimization level +O2
when using the LOC intrinsic.
05)JAGad98531: The compiler issues a bogus "No such entity
in module" error.
06)JAGad99000: The compiler generates wrong answers in
wide mode at optimization level +O3 when
using integer*8 induction variables.
07)JAGad99034: The debugger can't set breakpoints in
functions included via header files.
08)JAGad99133: The present intrinsic returns the wrong
result when an optional parameter is not
passed by the calling program.
09)JAGad99152: Incorrect code generated when an indirect
common block is used in a subroutine.
10)JAGad99350: The compiler generated incorrect names
for complex types for use by the debugger.
11)JAGae00880: F90 does not allow nnnnI and nnnJ notation
to express two byte and four byte integer
constants as f77 did. This is an f77
compatibility issue.
12)JAGae01113: The compiler generates an internal error
on call to getarg when using +getarg1.
13)JAGae01135: The compiler aborts with "Assertion is
not true at user line 22:
BP_is_field_memeber_of_union --".
14)JAGae01137: The compiler generated an error when values
greater than 127 were passed to the char
intrinsic in a PARAMETER statement.
15)JAGae02602: The compiler aborts on fstream with
integer*2 result assignment.
16)JAGae02631: Error compiling hollerith constants when
used with the IAND intrinsic.
17)JAGae03581: The compiler ignores +Onolibcalls at
optimization level +O2.
PHSS_25858:
01)JAGad96301: The compiler aborts in a segmentation
fault when compiling an incomplete type
at +O3.
02)JAGad96827: The compiler does not recognize the $SHORT
directive. This is needed for f77 backward
compatibility.
03)JAGad96964: The compiler aborts using +i8 when
compiling the index intrinsic.
04)JAGad96969: The compiler aborts in wide mode with the
+i8 switch when compiling OMP intrinsics.
05)JAGad97206: The compiler reports the wrong line number
in error messages when the -I include path
is used.
06)JAGad97500: The compiler aborts compiling
set_num_threads call using +autodbl in
64-bit mode.
07)JAGad97556: The compiler issues an error 300 message
when compiling a generic function.
08)JAGad97884: The compiler issues an error message for
a character array argument whose length is
different that a specific formal parameter
character array argument.
PHSS_25771:
01)JAGad96323: The compiler aborts during handling of a
CRAY pointer object.
02)JAGad96085: The compiler issues an error message when
defining a generic function using
an INTERFACE block when the function
specification contains a RESULT clause.
03)JAGad95772: The compiler asserts with -g on a program
with a hollerith constant.
04)JAGad95812: The compiler issues an error with +Oopenmp
and Sun's c$pragma directive.
05)JAGad95935: Bad compile-time evaluation of math
function calls with constant arguments.
06)JAGad93111: The compiler emits an "unable to privatize
compiler temp" warning for an OMP parallel
directive.
07)JAGad95189: The compiler emits an f95resolve.c assert
on operator in INTERFACE definition.
PHSS_25616:
01)JAGab14095: Debugger does not stop at the right line
number.
02)JAGab76571: Compiler gets an internal error with array
assignment.
03)JAGad06371: The compiler aborts with segmentation fault
after correctly reporting errors.
04)JAGad91856: Wrong answers for reentrant subroutines.
05)JAGad92916: Data size over 2**31 bytes is incorrectly
promoted to 64 bit
06)JAGad93080: Compiler issues error messages for
c$doacross, c$$, *$$ and !$$.
07)JAGad93165: The compiler aborts when a module is 'use'd
multiple times within the same source file.
08)JAGad93166: The compiler issues an error message for
c$$$.
09)JAGad93470: Line number information is incorrect when
compiling .F files or when +cpp=yes.
10)JAGad93578: The compiler generates an assertion
claiming "Missing LAB for label" on
Open MP code.
11)JAGad94515: The F90 compiler limits initialized DATA
to 42 megabytes, much smaller than F77.
PHSS_25520:
01)JAGad87638: Intermittant wrong answers using at
high optimization levels.
02)JAGad89871: Compiler error compiling a recursive
function, abnormal exit from bridge.
03)JAGad92123: Use of 300 continuation lines causes
internal compiler error.
04)JAGad92124: The label on a 'type' statement is lost.
PHSS_25413:
01)JAGad85737: The compiler does not correctly handle BOZ
constants in intrinsic function calls.
02)JAGad90122: The compiler does not accept the incremental
linking options +ild and +ildrelink.
03)JAGad90369: The compiler asserts on data statement which
uses rep and has another overlapping data
statement.
04)JAGad90394: The compiler aborts with f90: Signal 6.
05)JAGad90477: Use of the +Ofaster compile option causes
bus error.
PHSS_25175:
01)JAGab67472: A problem with strength reduction of 64
bit multiplication by unsigned consants
caused wrong answers.
02)JAGac86637: The compiler errantly reports "invalid arc
calculation" warning.
03)JAGad62170: The +U option needs to support multiple
arguments.
04)JAGad84653: The compiler does not accept 'type' as
a 'print' statement.
05)JAGad85160: Reference to omp_memcpy is unresolved.
06)JAGad85254: The compiler asserts on an OMP intrinsic.
07)JAGad85371: Customer reports need to have more than 256
continuation lines.
08)JAGad85372: Performance for guided scheduling does not
scale well beyond 2 threads.
09)JAGad86385: The compiler aborts with interanl error on
the pack intrinsic.
10)JAGad87340: Compiler aborts with TCG assertion in
in_descriptor.c.
11)JAGad87380: The compiler does not recognize the
+Onoopenmp command-line switch.
12)JAGad87416: Compiler aborts with TCG assertion.
13)JAGad87513: Using $HP$SHARED_COMMON within second
subroutine in a file Is ignored, causing
wrong answers.
14)JAGad88599: Bus error occurs when intrinsic function LOC
is called with a non-subscripted array.
15)JAGad88762: OMP directive is ignored.
16)JAGad89129: Error occurs when implicitly opening a file
with unit number greater than 99.
PHSS_24771:
01)JAGaa68246: Wrong answers with floating point
comparisons using +FPD.
02)JAGab73429: The compiler does not allow the !$ALIAS
directive.
03)JAGad03801: Compiler crashing on end do statements with
no matching do statements.
04)JAGad08183: Run time error with assigned gotos in 64bit
mode
05)JAGad15689: Failure on entry statement that returns a
quadword result.
06)JAGad62340: The +cat option at the end of the compile
line caused compile problems.
07)JAGad73062: Compiler aborts when parallelizing a loop
with an inlined routine.
08)JAGad73370: Wrong answers from libF90 cputime routine.
09)JAGad73465: Code sometimes generated wrong answers at
optimization level +O3.
10)JAGad73529: Garbled "Module not found" error messages.
11)JAGad74647: Open MP parallelization causes segmentation
fault.
12)JAGad77170: SAVE tags an automatic variable, a variable
type not eligible for SAVE causing bogus
compile-time errors.
13)JAGad77176: Compiler abort when an Open MP PRIVATE
variable is from a USEd module.
14)JAGad77883: Compiler abort on interface assignment.
15)JAGad79146: Gdb unable to show the correct f90 source
lines when stepping.
16)JAGad81039: Compiler aborts with "abnormal exit taken
from bridge" with nested routines and
modules.
17)JAGad81737: OMP variable trip count loops not always
correctly parallelized.
18)JAGad81738: Loops with induction variables of type
integer*8 were not transforming the
increment value to be an I*8 constant.
19)JAGad82866: Compiler aborts while generating code for
an array initialization in wide mode.
Defect Description:
PHSS_27362:
01)JAGae30245: The compiler did not detect the overflow
and emit an appropriate error message.
02)JAGae30374: The compiler did not look beyond the first
argument for the array.
PHSS_27071:
01)JAGae21542: There is an error in product tables
optimiziation.
02)JAGae22867: The compiler had an error in kind check
for extracting value prior to moving it to
a new kind, an integer*8 related problem.
03)JAGae22891: The compiler prematurely evaluated stack
arguments, allowing them to be overwritten.
04)JAGae23557: The compiler failed to check for the
private attribute before issuing an error
message.
05)JAGae23902: The default cache line size was
inefficient, changed to 64 bytes.
06)JAGae24654: Multiple memory moves was causing cache
thrashing.
07)JAGae25135: The compiler was turning the implied DO
into an array section, this can't be done
when bounds checking.
08)JAGae25225: Default(private) processing erroneously
privatized the named parameters and thus
created a temporary.
PHSS_26862:
01)JAGae14855: The compiler did not allow character
function results to be used as unit numbers.
02)JAGae16233: The compiler was generating a bogus error
message.
03)JAGae16582: The compiler failed to setup register
r29 correctly.
04)JAGae18265: The compiler did not call routines to
print context during assert.
05)JAGae18321: The compiler was performing an unnecessary
error check.
06)JAGae19609: The compiler was not ignoring C$Par when
+Oopenmp is used.
07)JAGae19504: The compiler was performing an illegal
check.
PHSS_26731:
01)JAGad31237: Improved alias analysis for allocatable
and automatic arrays.
02)JAGae07707: Fixed symbolic handling of min/max
expressions to avoid exponential expression
growth.
03)JAGae08269: Suppressed check when the array is null.
04)JAGae09212: Added implementation of +A option, aligning
to 2 byte boundary under +A.
05)JAGae09539: Fixed branch->skip conversion in wide mode.
06)JAGae09734: We needed a better check to autopromote
entity-type.
07)JAGae09920: Increased the nametable size from 128
to 1024.
08)JAGae10093: Prevent temporary copy of descriptor
base address.
09)JAGae10762: MIN1 and MAX1 calls are now coverted
internally to MIN0 and MAX0 when integer
arguments are specified.
10)JAGae12200: The compiler did not look for the alias
name for function and subroutine interfaces.
11)JAGae13356: The compiler aborts with redefinition of
macro type.
12)JAGae13388: Updated the compiler to accept label
formats.
13)JAGae14315: The compiler maintained context beyond
the statement function context.
14)JAGae14622: Emit subtype alignment of 16 bits for item.
PHSS_26376:
01)JAGae01864: The optimizer was hoisting a load without
hoisting the associated store instruction,
creating an uninitialized use of a
reference.
02)JAGae04245: The compiler was incorrectly calculating
map region offsets.
03)JAGae04558: The compiler was incorreclty optimizing
away a variable that was still in use.
04)JAGae05471: The compiler did not correctly output the
SLT entry before the exit.
05)JAGae05719: The compiler needed to extend array(1) to
the end of the commonblock for alias
purposes.
06)JAGae06390: The compiler did not default to the correct
type under the +i2 flag for BOZ constants.
07)JAGae07001: The compiler should have issued a meaningul
error diagnostic message.
08)JAGae07078: The compiler's type checking was too strict
and has been relaxed for IAND calls.
09)JAGae07262: The compiler's type checking was too strict
and has been relaxed for intrinsic calls.
10)JAGae07652: The mechanism for handling the Open MP
ORDERED directive needed to be enhanced.
11)JAGae07658: The compiler has been changed to handle
OPTIMIZE directives.
12)JAGae07660: The compiler has been changed to handle
SAVE_LOCALS directives.
13)JAGae07707: Fixed symbolic handling of min/max
expressions to avoid exponential expression
growth.
14)JAGae07710: The compiler did not issue a diagnostic
message for undeclared function reference
in a call.
15)JAGae07953: The compiler did not allow iint to
translate to int2 and int4 as appropriate.
16)JAGae08246: The compiler did not pass int4 dimension to
intrinsic.
17)JAGae08269: The compiler incorrectly flagged subscripts
to a zero-sized array as an error.
18)JAGae09734: The compiler incorrectly determined that a
variable equivalenced within a common block
could be type-size promoted to match the
size of address.
19)JAGae09920: The namespace table was not large enough to
handle the source file.
PHSS_26066:
01)JAGab70324: The compiler needed to check for valid
frame size before running with bad input.
02)JAGad96334: The compiler assumed loop indices to be
integer*4 regardless of the compilation
mode, causing unnecessary conversions
during rutime.
03)JAGad97006: An invalid but common idiom of
equivalencing length 1 array to the
beginning of a common block caused over
optimization.
04)JAGad97103: The compiler was incorrectly optimizing
addresses to the LOC function.
05)JAGad98531: The compiler did not correctly handle a
boundary condition when writing a symbol
across heaps.
06)JAGad99000: An error in optimization caused incorrect
code generation.
07)JAGad99034: The compiler was not correctly generating
line number references.
08)JAGad99133: The present intrinsic returned wrong
results.
09)JAGad99152: The compiler was not checking to see
if common blocks were indirect within
functions and subroutines.
10)JAGad99350: The compiler generated names incorrectly
by using the kind precision instead of the
type precision.
11)JAGae00880: The parser did not allow f77 notation for
2 byte and 4 byte integer constants.
12)JAGae01113: Error handing getarg and getarg1.
13)JAGae01135: The compiler generated an error on a valid
construct due to incorrect error checking.
14)JAGae01137: An error in bounds checking prevented
valid values as parameters to char.
15)JAGae02602: Needed to encode the fact that fstream on
typeint2 returns int4.
16)JAGae02631: The compiler had a problem converting
Holleriths to integers when using a
bit or logical intrinsic.
17)JAGae03581: The compiler turned on +Olibcalls even
though the user specified _Onolibcalls.
PHSS_25858:
01)JAGad96301: The compiler was stuck in an infinite
recursive call loop when compiling an
incomplete type.
02)JAGad96827: The compiler needed to recognize and
correctly handle the $SHORT directive.
03)JAGad96964: There was a bug coding the determination
of the index intrinsic parameter.
04)JAGad96969: The +i8 switch was not compatible with
some of the OMP internal intrinsics.
05)JAGad97206: The compiler incorrectly reported the hash
line number instead of the line number.
06)JAGad97500: The compiler failed to convert some types.
07)JAGad97556: The compiler did not allow dimension as
a function result attribute.
08)JAGad97884: The compiler should issue a warning rather
than an error.
PHSS_25771:
01)JAGad96323: The CRAY target object was not being
handled properly by intrinsics.
Resolution: Recompile with the new compiler.
02)JAGad96085: The function result type attributes were
not being checked correctly.
Resolution: Recompile with the new compiler.
03)JAGad95772: The compiler recognized a hollerith
field as an unnamed variable and issued
invalid debug information.
Resolution: Recompile with the new compiler.
04)JAGad95812: C$pragma was not recognized, the compiler
has been changed to ignore it.
Resolution: Recompile with the new compiler.
05)JAGad95935: The compiler was constant folding divides
by zero.
Resolution: Recompile with the new compiler.
06)JAGad93111: The compiler created temporary variables
but failed to privatize them in the parallel
region.
Resolution: Recompile with the new compiler.
07)JAGad95189: A USE statement of a module which exported
an operator definition within a nested
scope caused an abort due to failure to
clear the pushed operator count.
Resolution: Recompile with the new compiler.
PHSS_25616:
01)JAGab14095: Fixed problem with line number handling.
Resolution: Recompile with new compiler.
02)JAGab76571: Fixed problem with type conversion on array
constants.
Resolution: Recompile with new compiler.
03)JAGad06371: Fixed problem with graceful handling of
error situation.
Resolution: Recompile with new compiler.
04)JAGad91856: Fixed problem with more than one thread
saving the result.
Resolution: Recompile with the new compiler.
05)JAGad92916: The compiler stored subspace lengths as
integers. Changed them to use unsigned
integers.
Resolution: Recompile with the new compiler.
06)JAGad93080: Changed the compiler to suppress errors for
c$doacross, c$$, *$$, and !$$.
Resolution: Recompile with the new compiler.
07)JAGad93165: Multiple use statements caused a name
collision. This has been fixed.
Resolution: Recompile with the new compiler.
08)JAGad93166: Fixed the compiler to allow C$$$ to be a
comment.
Resolution: Recompile with the new compiler.
09)JAGad93470: Fixed problem with #line directives throwing
off the line countin the original source
file.
Resolution: Recompile with the new compiler.
10)JAGad93578: Fixed problem with missing label from
replicated nodes resulting from
parallelization.
Resolution: Recompile with the new compiler.
11)JAGad94515: The data limit was too small. Increased it
to 400 megabytes.
Resolution: Recompile with the new compiler.
PHSS_25520:
01)JAGad87638: Fixed uninitialized register problem causing
intermitant wrong answers at high
optimization levels.
Resolution: Recompile with the new compiler.
02)JAGad89871: Code to determine where the character length
is stored is aborting. Fixed this problem.
Resolution: Recompile with the new compiler.
03)JAGad92123: Over-writing memory due to overflow of 16
bit field describing debugger position.
Fixed field size.
Resolution: Recompile with the new compiler.
04)JAGad92124: Fixed handling of the 'type' form of the
print statement so that the label is
recognized.
Resolution: Recompile with the new compiler.
PHSS_25413:
01)JAGad85737: The compiler did not correctly infer data
type for BOZ (typeless) constants from
context. This has been fixed.
Resolution: Recompile with the new compiler.
02)JAGad90122: Implemented the +ild and +ildrelink compile
options.
Resolution: Recompile with the new compiler.
03)JAGad90369: Fixed bug in handling of the data statement.
Resolution: Recompile with the new compiler.
04)JAGad90394: Fixed the internal compiler assertion.
Resolution: Recompile with the new compiler.
05)JAGad90477: Fixed the bug in handling the +Ofaster
compile option.
Resolution: Recompile with the new compiler.
PHSS_25175:
01)JAGab67472: Fixed a problem with strength reduction
of 64 bit multiplication by unsigned
consants.
Resolution: Recompile with the new compiler.
02)JAGac86637: Removed an unused warning message
"invalid arc calculation".
Resolution: Recompile with the new compiler.
03)JAGad62170: Added support for multiple arguments to
the +U option.
Resolution: Recompile with the new compiler.
04)JAGad84653: To be consistent with f77, updated the
compiler to accept 'type' as a synonym
for 'print' when not within a declaration.
Resolution: Recompile with the new compiler.
05)JAGad85160: Fixed the compiler to resolve the
omp_memcpy reference.
Resolution: Recompile with the new compiler.
06)JAGad85254: Fixed the OMP intrinsic assertion problem
resulting from parameter mismatch.
Resolution: Recompile with the new compiler.
07)JAGad85371: Enhanced the compiler to allow up to 300
continuation lines.
Resolution: Recompile with the new compiler.
08)JAGad85372: Error in algorithm was causing the
compiler to use workload/2 to guide
scheduling. Changed this to use
workload/numthreads.
Resolution: Recompile with the new compiler.
09)JAGad86385: Fixed the internal compiler error
generated on a pack intrinsic.
Resolution: Recompile with the new compiler.
10)JAGad87340: Fixed the internal compiler error
resulting in TCG in_descriptor.c
assertion.
Resolution: Recompile with the new compiler.
11)JAGad87380: Implemented the +Onoopenmp
command-line switch.
Resolution: Recompile with the new compiler.
12)JAGad87416: Fixed the compiler internal error.
Resolution: Recompile with the new compiler.
13)JAGad87513: Placement of $HP$SHARED_COMMON
directive contrary to documentation
was permitted in F77. Upgraded the
f90 compiler to allow the f77 placement.
Resolution: Recompile with the new compiler.
14)JAGad88599: Fixed problem with intrinsic handling
of dope vector array, resulting in bus
error.
Resolution: Recompile with the new compiler.
15)JAGad88762: Fixed problem so that OMP directives
are not lost.
Resolution: Recompile with the new compiler.
16)JAGad89129: Fixed bug in compiler for implicit
open of file with unit number greater
than 99.
Resolution: Recompile with the new compiler.
PHSS_24771:
01)JAGaa68246: The compiler had a problem with using +FPD
combined with certain optimizations. This
has been fixed.
Resolution: Recompile with the new compiler.
02)JAGab73429: The compiler did not recognize the !$ALIAS
form of the $ALIAS directive. The compiler
has been changed to recognize !$ALIAS
Resolution: Recompile with new compiler.
03)JAGad03801: Compiler expected each end do statement to
have matching do statements. This has been
fixed so that an error message is generated.
Resolution: Recompile with new compiler.
04)JAGad08183: Compiler was incorrectly calculating the
destination address. This has been fixed.
Resolution: Recompile with the new compiler.
05)JAGad15689: Problem with quadword results for entry
statements has been fixed.
Resolution: Recompile with the new compiler.
06)JAGad62340: The compiler included the concatenated
file plus all of the individual files in
the compile and link. This has been fixed.
Resolution: Recompile with the new compiler.
07)JAGad73062: The compiler asserted under some cases
when parallelizing a loop with an inlined
routine. This has been fixed.
Resolution: Recompile with the new compiler.
08)JAGad73370: The cputime routine did not return the
correct value. This has been fixed.
Resolution: Recompile with the new compiler.
09)JAGad73465: The compiler incorrectly removed some code
assuming it was unreachable when it was in
fact needed. This has been fixed.
Resolution: Recompile with the new compiler.
10)JAGad73529: The compiler was built with the wrong version
of the error message file. This has been
fixed.
Resolution: Recompile with the new compiler.
11)JAGad74647: There was a problem with the variable step
transformation. This has been fixed.
Resolution: Recompile with the new compiler.
12)JAGad77170: The compiler generated SAVE tags for an
automatic variable. This has been fixed.
Resolution: Recompile with the new compiler.
13)JAGad77176: The compiler did not clear the USEASSOCIATED
bit for use variables which were privatized.
This has been fixed.
Resolution: Recompile with the new compiler.
14)JAGad77883: An INTERFACE Assignment definition prevented
the compiler from resolving an operator. This
has been fixed.
Resolution: Recompile with the new compiler.
15)JAGad79146: The compiler was using the incorrect variable
hashlinenumber which did not always track
line number. This has been fixed.
Resolution: Recompile with the new compiler.
16)JAGad81039: When propagating type tags from uplevel
imported module to the nested routine,
the compiler was not checking to see if
the type tags had already been set. This
has been fixed.
Resolution: Recompile with the new compiler.
17)JAGad81737: The compiler inadvertantly modified loops
not directly attached to OMP DO directives.
This has been fixed.
Resolution: Recompile with the new compiler.
18)JAGad81738: The compiler was not correctly typing
I*8 induction variables. This has been
fixed.
Resolution: Recompile with the new compiler.
19)JAGad82866: The compiler was incorrectly using the
address of the repetition count instead of
the repetition count. This has been fixed.
Resolution: Recompile with the new compiler.
SR:
1653237206 8606102064 8606105391 8606129091 8606134666
8606138917 8606146346 8606192958 8606193128 8606203884
8606204193 8606204286 8606204347 8606205472 8606207992
8606207998 8606208696 8606209960 8606211851 8606212551
8606212552 8606213675 8606215466 8606215988 8606216083
8606216201 8606216202 8606216568 8606217231 8606218190
8606218230 8606218266 8606218364 8606219457 8606219622
8606219988 8606220986 8606221235 8606221260 8606221343
8606218489 8606220735 8606223019 8606223020 8606106993
8606137253 8606222745 8606223819 8606223985 8606224069
8606224070 8606224378 8606224490 8606225428 8606224016
8606226117 8606226118 8606226709 8606226750 8606226873
8606227023 8606227262 8606227239 8606227765 8606227905
8606227912 8606228148 8606228443 8606228499 8606228831
8606229185 8606103499 8606225399 8606227273 8606227948
8606228045 8606228284 8606229185 8606229479 8606229949
8606229983 8606230082 8606230101 8606230298 8606230842
8606231642 8606231877 8606231899 8606231901 8606232417
8606233378 8606233407 8606234380 8606235463 8606232417
8606232629 8606235065 8606235221 8606235396 8606235856
8606236414 8606236666 8606237350 8606237956 8606237959
8606238036 8606238235 8606238627 8606238634 8606238636
8606238686 8606238932 8606239833 8606240317 8606239856
8606242154 8606242484 8606242685 8606133368 8606161921
8606218131 8606235531 8606238683 8606239856 8606241321
8606241957 8606242154 8606242287 8606242402 8606242484
8606242685 8606242858 8606243205 8606243236 8606244274
8606244596 8606245741 8606246386 8606246913 8606246945
8606247915 8606248024 8606248222 8606101202 8606247334
8606248457 8606249847 8606250201 8606253933 8606253989
8606255177 8606255282 8606257237 8606258567 8606258589
8606259239 8606259584 8606260331 8606260813 8606260903
8606265992 8606266122
Patch Files:
/opt/fortran90/bin/f90
/opt/fortran90/lbin/f90com32
/opt/fortran90/lbin/f90com64
/opt/fortran90/lib/libF90.a
/opt/fortran90/lib/pa2.0/libF90.a
/opt/fortran90/lib/nls/C/libF90.cat
/opt/fortran90/lib/nls/msg/C/f90.cat
/opt/fortran90/lib/nls/msg/C/f90com.cat
/opt/fortran90/share/man/man1.Z/f90.1
/opt/fortran90/share/man/ja_JP.eucJP/man1.Z/f90.1
/opt/fortran90/share/man/ja_JP.SJIS/man1.Z/f90.1
what(1) Output:
/opt/fortran90/bin/f90:
HP-UX f90 20020624 (164551) B3907DB/B3909DB PHSS_27
362 B.10.20.54
HP F90 v2.5.15
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lbin/f90com32:
HP F90 v2.5.15
HP-UX SLLIC/OPTIMIZER UX.11.01.96 (ROSE): 11/16/98
HP aC++ B3910B A.01.19.02 Classic Iostream Library
HP aC++ B3910B A.01.19.02 Language Support Library
Ucode Code Generator - UX11.01.04(GS IB4) (PACG - No
vember 16, 1998)
HP-UX f90com32 20020624 (161741) B3907DB/B3909DB PH
SS_27362 B.10.20.54
Copyright (c) 1993-2001 HP. All Rights Reserved.
HP Fortran-95 Version F95D4 HP:131200:080240
Ucode-2 Version 2-6
High Level Optimizer - 24-Jun-2002.16:10
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lbin/f90com64:
HP F90 v2.5.15
HP-UX SLLIC/OPTIMIZER UX.11.01.96 (ROSE): 11/16/98
HP aC++ B3910B A.01.19.02 Classic Iostream Library
HP aC++ B3910B A.01.19.02 Language Support Library
Ucode Code Generator - UX11.01.04(GS IB4) (PACG - No
vember 16, 1998)
HP-UX f90com64 20020624 (163235) B3907DB/B3909DB PH
SS_27362 B.10.20.54
Copyright (c) 1993-2001 HP. All Rights Reserved.
HP Fortran-95 Version F95D4 HP:131200:080240
Ucode-2 Version 2-6
High Level Optimizer - 24-Jun-2002.16:10
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lib/libF90.a:
libF90 HP HPUX [ Release B.10.20.14 pa1.1 32bit ]
(hp700:hp/ux) Jun 24 2002
Copyright (c) 2001 Hewlett Packard.
/opt/fortran90/lib/pa2.0/libF90.a:
libF90 HP HPUX [ Release B.10.20.14 pa2.0 32bit ]
(hp700:hp/ux) Jun 24 2002
Copyright (c) 2001 Hewlett Packard.
/opt/fortran90/lib/nls/C/libF90.cat:
None
/opt/fortran90/lib/nls/msg/C/f90.cat:
None
/opt/fortran90/lib/nls/msg/C/f90com.cat:
None
/opt/fortran90/share/man/man1.Z/f90.1:
None
/opt/fortran90/share/man/ja_JP.eucJP/man1.Z/f90.1:
None
/opt/fortran90/share/man/ja_JP.SJIS/man1.Z/f90.1:
None
cksum(1) Output:
759147862 557056 /opt/fortran90/bin/f90
1133433490 12230656 /opt/fortran90/lbin/f90com32
2464798836 12304384 /opt/fortran90/lbin/f90com64
2293426563 4115356 /opt/fortran90/lib/libF90.a
1981664445 4391928 /opt/fortran90/lib/pa2.0/libF90.a
1589122412 9505 /opt/fortran90/lib/nls/C/libF90.cat
2727162549 17117 /opt/fortran90/lib/nls/msg/C/f90.cat
4059747583 115530 /opt/fortran90/lib/nls/msg/C/f90com.cat
4119159773 28368 /opt/fortran90/share/man/man1.Z/f90.1
3609711377 32477 /opt/fortran90/share/man/ja_JP.eucJP/
man1.Z/f90.1
833327979 32600 /opt/fortran90/share/man/ja_JP.SJIS/man1.Z/
f90.1
Patch Conflicts: None
Patch Dependencies:
s700: 10.20: PHSS_27365
s800: 10.20: PHSS_27365
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHSS_27071 PHSS_26862 PHSS_26731 PHSS_26376 PHSS_26066 PHSS_25858
PHSS_25771 PHSS_25616 PHSS_25520 PHSS_25413 PHSS_25175 PHSS_24771
Equivalent Patches:
PHSS_27363:
s700: 11.00 11.11
s800: 11.00 11.11
Patch Package Size: 33110 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 PHSS_27362
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHSS_27362.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHSS_27362. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
WARNING: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHSS_27362.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHSS_27362.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
The baselines to which this patch applies are AR0901 or
AR1201. It will not install over patch PHSS_23952 or
earlier.
-----End of Document ID: PHSS_27362------------------------------------------
Document ID: PHSS_27105
Date Loaded: 20020702
Title: s700_800 10.20 LIBCL cumulative patch
Patch Name: PHSS_27105
Patch Description: s700_800 10.20 LIBCL cumulative patch
Creation Date: 02/06/06
Post Date: 02/07/02
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products: N/A
Filesets:
OS-Core.CORE-SHLIBS,B.10.20 ProgSupport.LANG-MIN,B.10.20
Automatic Reboot?: No
Status: General Release
Critical:
No (superseded patches were critical)
PHSS_14000: OTHER
Some simulation tools requires this patch
for locating their code (stored in $DATA$ space).
Path Name: /hp-ux_patches/s700_800/10.X/PHSS_27105
Symptoms:
PHSS_27105:
JAGad89129: Implicit write cannot open unit # > 99
JAGad92163: Bad Octal representation of numbers > 4294967295
JAGae05973: Wrong conversion of hex read of 0x80000000
PHSS_25717:
JAGad75314: writing to unit ID 26843546 causes crash.
JAGad54112: Intrinsic function NINT produces incorrect
results.
JAGad93863: cosd(90) should be 0.0, not 0.6123233996D-16
JAGad50860: I/O problem (-0.0000 instead of 0.0000)
PHSS_22652:
1. JAGaa93357: Calls to __F90_F_EXIT always had and exit
code of 0, even when not appropriate.
2. JAGad00306: large real constants not assigned properly
3. JAGad27408: Problem with numbers starting list
directed I/O streams.
PHSS_21951:
1. JAGab21216: U_STACK_TRACE only unwinds the frames
up to the sigreturn call, and does not display the
frame of the routine that was running when the signal
was caught.
2. JAGab71918: A throw or escape out of a signal handler
in aC++ will likely cause an abort when used in the catch
clause.
3. JAGab77879: Performance problems or hangs for F90
dynamic strings/arrays and Pascal's escapecode.
PHSS_17689:
1. Fortran treats letters T, F, t, f as valid input for
numeric items, instead of catching them as an error.
PHSS_16690:
1. Unwinding through an invalid stack frame may not
discontinue the unwinding process. The routine
which finds unwind entries in the unwind table,
"U_get_unwind_entry" has an "off by one" logic
error in its search algorithm and could return a
pointer to the address beyond the end of the unwind
table indicating that it found an unwind entry
instead of indicating that no entry was found.
2. The error message reported to the user when an alloca
frame is encountered by U_get_previous_frame() is
incorrect. "5613 Procedure entry sequence is too
long for Unwind. Contact HP Service." is displayed
rather than "5612 Old version data structures won't
restore r3 and r4 for Alloca Unwind." Reminder:
U_get_previous_frame_x() is the new 10.20 interface
which permits unwinding alloca() stack frames.
PHSS_15549:
1. PHSS_11658 causes FORTRAN to ignore format spec $
(newline suppression).
2. Fortran complex arithmetic is much slower with the
post-Fortran90 libcl.
3. For value 0.0, ES12.3 format displays 0.000E-01,
it should be 0.000E+0
4. FORTRAN I/O ERROR 979: VARIABLE NOT IN NAMELIST GROUP
for variables with embedded "$"
5. FORTRAN I/O ERROR 979: VARIABLE NOT IN NAMELIST GROUP
for f90 namelist IO which defines multiple array items
after a single array element is specified.
PHSS_15255:
1. Fortran formatted real output has a generic accuracy
problem caused by sometimes rounding a formatted value
twice. This can result in a formatted value that is
too large.
PHSS_14423:
1. If when handling an exception, the unwinder is
called to unwind a stack which contains alloca frames,
the stack unwind will often fail when crossing the
alloca() frame. (This affects Ansi C++ exception
handling which uses alloca() to allocate space for
temporary variables.)
2. The unwinder may dump core when unwinding through HP_UX
exception frames in shared libraries. The dumping of
core is likely to happen if the user has not followed
the procedure calling conventions in generating object
code (examples: A 3rd party compiler, assembly
functions which don't follow the HP procedure calling
conventions, simulator generated code.) The unwinder
dumps core rather than detecting the corrupt stack and
returning a "can't unwind" return value from
U_get_previous_frame().
PHSS_14000:
1. Applications which call stack unwind routines including
U_get_previous_frame() may receive different
description of stack frame upon reaching an invalid
frame in the stack. The behavior changed with
the introduction of patch PHSS_10766.
2. When using Ansi C++ exception handling support,
U_STACK_TRACE fails when called from signal
handler. The failure mode occures only if the
handler is responding to a signal which has
interrupted an HP_UX system call
3. Fortran 77 program is not terminated on the
first use of "kill -1."
PHSS_11658:
1. SR 16533218321 : In a Fortran program, sequential
unformatted write operations with empty I/O lists
results in a file that cannot be read back in.
2. In Fortran programs, the performance of formatted
floating point output is, in some instances, much
slower than with a 9.X release of Fortran 77.
PHSS_10766:
1. Unwind library fails to cross shared library
boundaries and signal frames.
PHSS_10743:
1. SR 5003363085, 1653198705 : In a Fortran program an
unformatted read of an unquoted character string may stop
before reaching the end of the string. This happens when
the string contains a quote or ':' character.
2. SR 5003360081 : A Fortran 77 program that tries to trap
INTEGER*4 overflow using "ON INTEGER*4 OVERFLOW ..." will
not in fact trap the overflow.
PHSS_9483:
1. SR 5003324855: Unwind library doesn't work if an
alloca call has been made.
PHSS_8967:
1. Fails to allow access to files larger than
2 Gigabytes in size.
PHSS_8966:
1. SR 5003340596 : There is a memory leak when closing
files that can cause a program to run out of memory
if it opens and closes files many times.
2. SR 1653187393 : A file auto-opened with a sequential
read or write statement will create a file whose
maximum record length is 256 bytes.
PHSS_8397:
1. Use of +Oparallel and shared libraries on HPUX 10.20
results in undefined externals __FTN_SET_AR and
__FTN_300CHARS.
2. Systems cannot compile Fortran 90 programs or run
Fortran 90 programs that were linked with a shared
libcl.
3. SR 5003330738 : Reading and writing may be much slower
under HP-UX 10.20 than on earlier releases.
PHSS_6986:
1. SR 5003298067 : Reading a record from an ISAM file may
cause the program to crash or exhibit other symptoms of
writing off the end of a dynamically allocated memory
block. Whether this problem will be observed depends on
exactly what other IO commands are executed both before
and after the ISAM file read.
2. SR 5003298075 : Programs may crash when using a REWRITE
statement to alter an existing ISAM record. The REWRITE
statement is used only with ISAM files. The occurrence of
this problem is highly sensitive to the pattern of
allocation and deallocation of memory blocks at run-time.
However, if the problem occurs it will almost certainly
result in a program crash while attempting to execute the
REWRITE statement; delayed symptoms or silent incorrect
behavior are very unlikely.
3. SR 5003290122 : If a program backspaces over an initial
64 byte record, the file pointer will be left in the
wrong position and the next access to the file will read
or write the wrong location in the file. This problem
only occurs with the initial record, and that record must
be exactly 64 bytes long.
4. SR 5003280859 : Arrays of 4-byte integers do not work
correctly with namelists if the +autodblpad compiler
switch is used. Only the first element of the array will
be correctly accessed via the namelist.
PHSS_5691:
1. SR 4701296160 : "Ada/unwind fails on 10.0" Users of Alsys
Ada will experience problems with exception handling on
HP-UX 10.0 without this patch. Exceptions may not be
caught by the program's handlers, or may cause core
dumps. This patch is essential for all Alsys Ada users.
2. SR 4701295998 : "C++ program compiled on 9.0 dumps core
on 10.0" Only affects C++ programs using exception
handling. Note that this fix is also included in HP-UX
release 10.01. It is mentioned here so that users of
HP-UX 10.00 may obtain the patch without updating their
whole system, should they so wish.
Defect Description:
PHSS_27105:
JAGad89129: Implicit write cannot open unit # > 99
JAGad92163: Bad Octal representation of numbers > 4294967295
JAGae05973: Wrong conversion of hex read of 0x80000000
PHSS_25717:
JAGad75314: Only works on large filesystems. Added a
clearer message to libIO77 when it fails at
exactly 2 GiG mark
JAGad54112: Increased precision of internal datatypes.
JAGad93863: added new intrinsic routines for cosd(90)
sin(0), and tand(180). Default behavior is
old imprecise values. Use f90 flag
+trigdacc (trig degree accurate) to get new
alternate intrinsics. No other Source change
needed.
JAGad50860: I/O problem (-0.0000 instead of 0.0000)
PHSS_22652:
1. JAGaa93357: Calls to __F90_F_EXIT always had and exit
code of 0, even when not appropriate.
2. JAGad00306: treat large real constants like F77.
3. JAGad27408: Problem with numbers starting list
directed I/O streams.
PHSS_21951:
1. JAGab21216: Error in U_STACK_TRACE unwinding past
64 bit _sigreturn
2. JAGab71918: If a throw or escape is done out of a
signal handler that interrupted a system call the values
of the callee save registers (at least R3 and R4) may be
invalid
3. JAGab77879: Performance problems or hangs for F90
dynamic strings/arrays and Pascal's escapecode.
PHSS_17689:
1. T, F, t, f are logicals and were incorrectly accepted
as integers.
PHSS_16690:
1. The off by one error in U_get_unwind_entry()
returns a bogus unwind descriptor for a pc
offset (the first argument) which is higher
than the highest executable pc offset in the
load module.
2. The message catalog for Unwind was missing
an entry. To reproduce this problem (and thus to
determin whether you need the patch on your system,)
use the following program. Note that this program
uses short cuts which are archive library specific.
It will not link shared. Just for reference, the
program also demonstrates use of the new
U_get_previous_frame_x interface for correct un-
winding through alloca frames.
#include <alloca.h>
#include <stdio.h>
typedef unsigned int address;
typedef unsigned int space;
main()
{
struct {
int curr_frame_size;
address curr_sp;
unsigned long curr_pcspace;
address curr_pcoffset;
address curr_dp;
address curr_rp;
address curr_mrp;
space curr_sr0, curr_sr4;
int r3;
address cur_r19; /* for PIC code */
int r4;
int reserved;
} cfi;
struct {
int prev_frame_size;
address prev_sp;
space prev_pcspace;
address prev_pcoffset;
int prev_dp;
unsigned int uw_descr[2];
address ustart;
address uend;
int uw_index;
address prev_r19; /* for PIC code */
int r3;
int r4;
} pfi;
#ifdef NEW_INTERFACE
#define UNWIND_STEP(cfi,pfi) \
U_get_previous_frame_x(&cfi,&pfi,sizeof(pfi));
#else
#define UNWIND_STEP(cfi,pfi) \
U_get_previous_frame(&cfi,&pfi);
#endif
void *mptr;
mptr = alloca(1000);
U_get_frame_info(&cfi);
UNWIND_STEP(cfi,pfi);
copy_frame_info(&cfi,&pfi);
UNWIND_STEP(cfi,pfi);
}
/* END */
Compile Line: cc -Ae test_alloca.c -Wl,-aarchive -lcl
$a.out will display, "Procedure entry sequence is too
long for Unwind. Contact HP Service." if patch
PHSS_16690 has not been installed on your system. It will
display "Old version data structures won't restore r3 and
r4 for Alloca Unwind." if the patch has been installed.
PHSS_15549:
1. SR1653242602: PHSS_11658, while fixing non-advancing
IO to conform to f90 standards, makes format spec $
stop working.
2. SR1653258798: Post-f90 libcl's complex arithmetic
routines were compiled without optimization.
3. SR5003407429: ES format descriptor incorrectly
handled 0.0, by decreasing the printed exponent
by one when it shouldn't.
4. SR5003390112: dollar signs ($) were not allowed in
namelist variable names, because of an earlier change
to make $end work correctly. Supporting $end is not
mutually exclusive with allowing $'s in variable
names as long as the $ is not the first character,
and the f77 and f90 compilers do not allow names to
begin with $.
5. SR5003421701: f90 uses namelist IO handling distinct
from f77, in order to handle new f90 features such as
array sections. The f90 implementation did not allow
more than one namelist value to follow a single
specified array element, which is sometimes used as
a starting position for a list of values.
PHSS_15255:
1. The Fortran IO library rounded the value to w+1 digits
during its initial conversion from floating point to
ascii, where w is the width requested in the format
string. It then proceeded to round the ascii result a
second time, to p digits, where p is the precision
requested in the format string. Rounding should have
been performed only once, to p digits, and never to
w+1 digits.
PHSS_14423:
1. The unwinder was not always obtaining the values of
gr3 and gr4 from the appropriate locations during
unwinding through exceptions which interrupted
HP_UX system calls. When encountering a stack frame
for an exception which interrupted the OS, the
values for r3 and r4 should be obtained from the user's
stack (which the unwind library tracks in it's
"state_vector" data structure.) The unwind library
was instead, getting these values from the signal
context saved when the interrupt occurred.
2. The unwinder dumps core when unwinding exception
frames in shared libraries upon getting a return
pointer in protected memory. Routines which
extract a return pointer from exception handler
code was not checking addresses for readability
prior to accessing the address triggering bus
errors.
PHSS_14000:
1. Applications calling U_get_previous_frame() on an
invalid stack frame received different results
because U_get_previous_frame() has been modified
to unwind inport and export stubs on the stack which
have been optimized by the linker (e.g. do not appear
in the stub unwind region tables in the SOM). After
U_get_previous_frame attempted to unwind a region of
the stack which was not listed in unwind tables or
stub unwind tables, the data structure which describes
the top frame of the stack has been filled with either
1) the description of the next stack frame on the stack
if the stack contained a "linker optimized" stub at its
top, or otherwise, 2) garbage values if the top of the
stack was an invalid frame. The original behaviour
of U_get_previous_frame was to not destroy the
information in the frame data structure in condition
(2).
2. The Ansi C++ exception handling support was failing
because the Stack Unwind routines (U_get_previous_frame)
were obtaining the gr3 and gr4 register values from
the signal context record, when instead it should have
picked them up from the "callee saves" register storage
area on the stack. The Unwind functions were not
correctly handling the difference between the state
saved by signals which interrupted user code from
signals which interrupted HP_UX system code.
3. Use the following f77 program to verify the "kill -1"
patch needs to be installed.
PROGRAM toto
X=0
DO WHILE (X .NE. 1000000)
WRITE (*,*) 'X = ',X
X = X + 1
END DO
END
Compile and execute the program. Issue
a "kill -1 <process id>" If a second "kill -1"
command is necessary, the patch is needed.
PHSS_11658:
1. In a Fortran program, sequential unformatted writes
with empty IO lists wrote nonsense records into
the file making the file unreadable. SR 1653218321
2. The slow performance of Fortran formatted floating point
output was due to the unnecessary use of quad precision
computation when double precision would have sufficed.
PHSS_10766:
1. The unwind library routine, "U_get_previous_frame()"
and it's associated routines such as "U_STACK_TRACE()"
fail to cross shared library boundaries and signal
stack frames.
PHSS_10743:
1. SR 5003363085, 1653198705 : The Fortran runtime library
did not handle correctly certain delimiter characters
when they occurred in an unquoted character string. The
read should terminate only when a blank, comma, slash, or
end of record is encountered.
2. SR 5003360081 : A defect in the Fortran runtime library
caused INTEGER*4 traps to be interpreted as INTEGER*8
traps. Note that INTEGER*8 is supported by F90 but not by
F77.
PHSS_9483:
1. Calls to the unwind library routine,
"U_get_previous_frame()" or it's associated
routines such as "U_STACK_TRACE()" do not unwind
through stacks which contain a frame in which
alloca() has been used to dynamically allocate
memory.
PHSS_8967:
1. libcl fails to allow access to files larger than
2 Gigabytes in size.
PHSS_8966:
1. Some memory was not freed when a file was closed.
2. The maximum record length was incorrectly being set
when a sequential file was auto-opened.
PHSS_8397:
1. The symbols __FTN_SET_AR and __FTN_300CHARS were not
exported from the shared version of libcl.
2. The complete set of Fortran 90 functionality was not
shipped with the 10.20 or earlier releases of HP-UX.
3. Changes were made to speed up the runtime IO system.
It may still not be as fast as in HP-UX 10.01 or 10.10
due to changes for Fortran 90 but it is faster then
the HP-UX 10.20 version.
PHSS_6986:
1. SR 5003298067 : The problem is caused by the runtime IO
library inappropriately reallocating a buffer to a
smaller size.
2. SR 5003298075 : The problem was caused by an
uninitialized variable in a dynamically allocated block.
3. SR 5003290122 : The defect was caused by incorrect
control logic in a Fortran run-time library routine.
4. SR 5003280859 : The +autodblpad option causes integer
arrays to be "padded" out to a length of 8 bytes for each
array element. But the runtime library routines that
implement access through a namelist treat the array as if
it had not been padded. This causes accesses to all
elements of the array, except to the first, to be
incorrect. Either the wrong element is accessed, or some
of the padding bytes are accessed.
PHSS_5691:
1. SR4701296160
(a) Ada compiler incorrectly used the "sr4export" bit of
unwind descriptors.
(b) Unwind library for HP-UX 10.0 incorrectly handled Ada
variable-sized frames and separate package bodies.
2. SR4701295998
An internal interface was changed at the 10.0 release
which led to incompatibilities with some C++ programs
that had been compiled on HP-UX 9.0. The problem was
solved by reverting to the original interface.
SR:
5003422808 1653281634 5003438473 4701380345 1653232181
5003324855 5003340596 5003330738 5003409466 1653253690
1653242602 1653258798 5003407429 5003421701 5003390112
5003415836 5003415752 8606104417 8606129759 8606145506
8606107614 8606131152 8606158078 8606200550 8606201661
8606206139 8606184910 8606224775 8606219352 8606221758
8606219988 8606223059 8606236924
Patch Files:
/usr/lib/libcl.1
/usr/lib/libcl.a
/usr/lib/pa1.1/libcl.1
/usr/lib/pa1.1/libcl.a
/usr/lib/nls/msg/C/libcl.cat
what(1) Output:
/usr/lib/libcl.1:
Unwind Library version UX.10.20.15 - 99/12/13
Trap Library version UX.10.20.15 - 99/12/13
libIO77 HP HPUX [ Release B.10.20.13 PA 32bit ]
(hp700:hp/ux) Jun 6 2002
Copyright (c) 2001 Hewlett Packard.
libcl.sl version B.10.29.16 - Jun 06, 2002
/usr/lib/libcl.a:
libcl.a version B.10.29.16 - Jun 06, 2002
libIO77 HP HPUX [ Release B.10.20.13 PA 32bit ]
(hp700:hp/ux) Jun 6 2002
Copyright (c) 2001 Hewlett Packard.
Unwind Library version UX.10.20.15 - 99/12/13
Trap Library version UX.10.20.15 - 99/12/13
/usr/lib/pa1.1/libcl.1:
Trap Library version UX.10.20.15 - 99/12/13
Unwind Library version UX.10.20.15 - 99/12/13
libIO77 HP HPUX [ Release B.10.20.13 PA 32bit ]
(hp700:hp/ux) Jun 6 2002
Copyright (c) 2001 Hewlett Packard.
fs_amod.s $Revision: 1.9.1.1 $
libcl.sl version B.10.29.16 - Jun 06, 2002
/usr/lib/pa1.1/libcl.a:
libcl.a version B.10.29.16 - Jun 06, 2002
fs_amod.s $Revision: 1.9.1.1 $
libIO77 HP HPUX [ Release B.10.20.13 PA 32bit ]
(hp700:hp/ux) Jun 6 2002
Copyright (c) 2001 Hewlett Packard.
Unwind Library version UX.10.20.15 - 99/12/13
Trap Library version UX.10.20.15 - 99/12/13
/usr/lib/nls/msg/C/libcl.cat:
None
cksum(1) Output:
375062849 1404544 /usr/lib/libcl.1
3451765743 1925724 /usr/lib/libcl.a
1421200257 1433216 /usr/lib/pa1.1/libcl.1
2147324722 1974292 /usr/lib/pa1.1/libcl.a
1905308540 28439 /usr/lib/nls/msg/C/libcl.cat
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHSS_25717 PHSS_22652 PHSS_21951 PHSS_5691 PHSS_6986 PHSS_8397
PHSS_8966 PHSS_8967 PHSS_9483 PHSS_10743 PHSS_10766 PHSS_11658
PHSS_14000 PHSS_14423 PHSS_15255 PHSS_15549 PHSS_16690 PHSS_17689
Equivalent Patches:
PHSS_27106:
s700: 11.00 11.10
s800: 11.00 11.10
PHSS_27107:
s700: 11.11
s800: 11.11
PHSS_27108:
s700: 11.20
s800: 11.20
Patch Package Size: 6670 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 PHSS_27105
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHSS_27105.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHSS_27105. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
WARNING: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHSS_27105.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHSS_27105.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHSS_27105------------------------------------------
Document ID: PHKL_25439
Date Loaded: 20020702
Title: s800 10.20 LVM cumulative patch, array controller hot-swap
Patch Name: PHKL_25439
Patch Description: s800 10.20 LVM cumulative patch, array controller hot-swap
Creation Date: 02/06/26
Post Date: 02/07/02
Hardware Platforms - OS Releases:
s800: 10.20
Products: N/A
Filesets:
LVM.LVM-KRN OS-Core.CORE-KRN
Automatic Reboot?: Yes
Status: General Release
Critical:
Yes
PHKL_25439: PANIC HANG CORRUPTION
PHKL_23481: PANIC HANG CORRUPTION
PHKL_19705: PANIC
PHKL_20964: HANG
PHKL_19697: PANIC
PHKL_19210: OTHER
This patch is essential to improve the recovery of
FC devices in large configurations.
PHKL_19167: HANG
Path Name: /hp-ux_patches/s800/10.X/PHKL_25439
Symptoms:
PHKL_25439:
(SR: 8606247854 CR: JAGae14254)
Under rare circumstances, with PHKL_23481 or a superseding
patch installed, LVM configuration information can be lost,
or data corruption can occur, when a volume group is
activated with one or more disks missing.
This problem can happen only when the following events
occur:
1) The volume group is activated with one or more disks
missing.
2) The volume group is used normally.
3) The volume group is deactivated.
4) The volume group is activated with the missing disk
present and this disk has not been restored with
vgcfgrestore(1M).
(SR:8606251516 CR:JAGae17581)
Although a different problem, the symptoms for this defect
are the same as those for JAGae14254.
(SR:8606251519 CR:JAGae17584)
Although a different problem, the symptoms for this defect
are the same as those for JAGae14254.
(SR:8606231449 CR:JAGae00687)
LVM configuration operations may hang after PHKL_23481 or
any superseding patch is installed. Any volume group
configuration operations performed on the volume group can
hang (e.g. lvcreate(1M), lvextend(1M), lvreduce(1M),
vgextend(1M)) and any subsequent LVM commands initiated will
hang behind these. The only way to break the hang is to
reboot the system. Subsequent volume group activations may
also hang.
(SR:8606224001 CR:JAGad93096)
LVM activation of a volume group can fail after PHKL_23481
or any superseding patch is installed. Activating a volume
group fails after all the disks in the volume group have
the LVM configuration information restored to them using the
vgcfgrestore(1M) command. The problem is not observed if at
least one of the disks does not have its configuration
restored. The message that results is: "Quorum not
present, or some physical volume(s) are missing."
(SR:8606264390 CR:JAGae28720)
On a Service Guard cluster node, while running the
cmapplyconf(1M) command, an unexpected error message may
result: "failed to release cluster lock disk". This can
occur unexpectedly when the cluster lock disk is part of a
read-only volume group, or if the volume group has less than
a quorum of its disks available. This fix eliminates only
one cause of this message, there are other possible reasons
for the message not addressed in this patch.
(SR:8606251547 CR:JAGae17612)
System with root device configured as three-way mirrored LVM
logical volume, could panic when the system is booted in LVM
normal mode after booting the system in LVM maintenance
mode. The data on mirrored volumes in the root VG could be
silently corrupted as well. The stack trace of the panic
would look something like this:
panic+0xA0
report_trap_or_int_and_panic+94
trap+0xED4$call_trap+38
kfree+24
lv_fixrootlv+3B0
lv_init_lvols+548
lv_activatevg_common+10C
lv_activatevg+4C
lv_vgconf+0xD8
lv_bootconf+14C
lvmconf+0xDC
im_lvmconf+1C
DoCalllist+3Cmain+28
$vstart+48
$locore+94
PHKL_23612:
(SR: 8606176439 CR: JAGad45677)
Various LVM commands coredump on systems where
any PV has more than 3 alternate links in addition
to the primary link.
PHKL_23481:
(SR: 8606142976 CR: JAGad12319)
LVM commands may hang forever in the kernel
lv_sa_config() routine (requiring a system reboot to
break the hang). Volume group activations may fail with
indications that the disks do not belong to the volume
group or some other obscure LVM error message. Although
it has never been reported from the field, there is also
a remote possibility of data corruption caused by LVM
using an older copy of the mirror consistency record (MCR)
or the volume group status (VGSA). These situations may
most likely happen on systems where the system time has
been advanced far into the future, then changed back to
the correct time again. The hangs can also occur if
a volume group is exported from one system and imported
to another with a system time behind the first.
Multiple volume groups on the system may be affected
simultaneously. Volume Groups that are most
likely to demonstrate the problem have timestamps on the
LVM disk VGSA, VGDA or MWC data structures which exceed
the current system time (although these timestamps are
themselves not bad).
(SR: 8606166039 CR: JAGad35326)
When media defects are encountered on LVM disks, i/o's may
panic while LVM is trying to map the defect to an alternate
block. The problem is characterized by an i/o path panic
"wait_for_lock_spinner: Already own this lock!", with a
thread deadlocked on a spinlock in the kernel
lv_defecthash() routine. This is similar to a
problem discovered on 11.00: JAGad30462.
(SR: 8606166971 CR: JAGad36258)
On ServiceGuard OPS clusters, A kernel hang can occur
in the lv_resyncpv() routine, when previously failed
devices are recovered and are being resynced by LVM.
This problem is characterized by a situation where a device
goes offline then returns, but LVM never recovers the
device and never starts using it again because LVM
has gotten stuck in lv_resyncpv().
(SR: 8606168136 CR: JAGad37418)
A kernel Data Page Fault (DPF) panic is possible in the
kernel lv_resyncpv() routine when a volume group is
deactivated while disks are offline and LVM is actively
trying to recover the disks. A similar DPF panic
is possible in lv_resyncpv() when vgreduce(1M) is used
to reduce PVs from a VG while a resync of the
logical volumes(s) containing the PV is in progress.
(SR: 8606173900 CR: JAGad43153)
After a system crash, mirrored logical volumes might not
be resynchronized correctly if the Mirror Write Cache is
enabled (see lvchange(1M) for details). The result is that
the data written at the time of a system crash might not
be made consistent across the mirrors. This is a form of
data corruption.
(SR: 8606161601 CR: JAGad30917)
Very poor read performance for HFS filesystems on LVM LVs
during an lvmerge(1M) operation. VxFS file systems are not
affected. Reads are held off for as long as 30 seconds.
(SR: 8606124005 CR: JAGac39365)
During heavy I/O stress system may panic in LVM
lv_unblock() due to a spinlock held too long.
PHKL_22529:
( SR:8606113703 DTS: JAGac07217 )
If a physical volume in an LVM mirrored disk configuration
is replaced without deactivating the volume group it belongs
to, an application might see spurious I/O errors, mirror
resync failures, or data corruption. (The I/O errors and
resync failures may have been observed prior to replacing
the disk.)
(SR: 8606138886 CR: JAGad08152)
A shared volume group has one or more LUNs on an active-
passive disk array (Nike, Galaxy or Optimus), and one of
the array's Service Processors is hot-swapped without
deactivating the volume group. Later, a node deactivates
the volume group (while it remains activated on other
nodes), and that node is not able to reactivate it.
(SR: 8606162303 CR: JAGad31619)
Read performance on HFS filesystems on LVM logical
volumes drops substantially when lvmerge operations
are in progress. VxFS file systems are unaffected.
Reads/writes from raw logical volumes are unaffected.
The problem occurs after installing patch PHKL_20964.
PHKL_21370:
(SR: 8606108373 CR: JAGab78776)
Reads from a mirrored LV can take a very long time to
complete if one of the mirrors is unavailable.
(SR: 8606106798 CR: JAGab76189)
With PHKL_20964 (recalled) installed, LVM may perform a
full resync every time a volume group is activated. While
the resync is in progress, system performance may be
degraded. In addition, since LVM does not have two valid
copies of all data during the resync, the system is
vulnerable to a disk failure until the resync completes.
PHKL_19705:
( SR: 1653305987 DTS: JAGab17773 )
If bad block relocation is enabled on a logical volume
with parallel read support, then any requests to a
block currently being relocated results in system panic.
PHKL_20964:
(SR: 8606128444 CR: JAGac81735)
It might not be possible to activate a volume group in
shared mode if any of its physical volumes are on an
Optimus Prime Disk Array.
(SR: 8606106637 CR: JAGab75913)
An LVM deadlock (hang) can occur when LVM commands which
operate on logical volumes are run at the same time as
device query operations. The result is that the LVM
commands and the query operations never complete (and
cannot be terminated), and it is not possible to run any
subsequent LVM commands. Furthermore, it is possible that
subsequent device recovery will be delayed indefinitely.
The only way to restore normal operation is to reboot the
system. For example, the lvmerge(1M), lvsplit(1M) commands
and glance(1) when run together could cause the commands
to deadlock, resulting in a situation where they make no
forward progress and cannot be interrupted or killed.
The same result could occur running lvchange(1M) or
lvextend(1M) and lvdisplay(1M) together.
The defect was introduced in PHKL_19210
which has since been recalled. This new patch supersedes
PHKL_19697, PHKL_19210, PHKL_20057 and PHKL_20808.
This patch contains all the fixes contained in these
patches. Customers with any of these superseded patches
installed should apply this new patch.
(SR: 8606106012 CR: JAGab74797)
It's possible for an I/O request to be accepted while a
logical volume is being closed, causing the operating system
to panic. Typical actions that close a logical volume are
unmounting a filesystem and closing a database (or other)
application which uses raw logical volumes. The panic would
likely be a data page fault in an lvm ("lv_") routine.
PHKL_20808:
( SR:8606100412 DTS: JAGab31786 )
This is an interim patch to support the Optimus disk array.
PHKL_20057:
( SR:8606100412 DTS: JAGab31786 )
LVM incorrectly treats two volumes within an Optimus disk
array as alternate paths to a single volume because they
have the same LUN ID, even though they are distinct volumes
and have different target IDs.
PHKL_19697:
( SR:8606101971 DTS: JAGab66231 )
If there is a problem with the physical volume to which the
logical volume is mapped, LVM returns EIO error for logical
requests, without retrying till the I/O timeout value
set on that logical volume.
PHKL_19210:
( SR:5003437970 DTS: JAGaa40887 )
When multiple physical volumes or paths to physical volumes
are lost, it can require minutes to recover them.
During the time the PVs for a given volume group are
tested, locks were held which delayed other LVM operations
and the opens and closes of logical volumes. Prior changes
to the device recovery code provided some benefit, assuring
that device recovery was 1-2 minutes regardless of the
number of paths or devices to be recovered, however this
still was not enough. The new device recovery code
in this patch reduces the recovery time to under 35 seconds,
again independent of the number of paths or devices offline.
PHKL_19167:
( SR: 8606100864 DTS: JAGab39559 )
( SR: 4701424846 DTS: JAGab14452 )
Performance degradation when massively parallel subpage
size (<8K) reads are performed (as with Informix).
( SR: 8606100864 DTS: JAGab39559 )
( SR: 1653289132 DTS: JAGaa67952 )
The system hangs when lvmkd is waiting for the lock obtained
earlier by an application that performs a vg_create
operation. The hang does not happen unless there is a
powerfailed disk.
( SR: 8606100864 DTS: JAGab39559 )
( SR: 4701424895 DTS: JAGab14455 )
Optimus Disk Arrays (model number A5277A-HP) are not
recognized as an ACTIVE/PASSIVE device and subsequently are
not handled properly by the driver.
PHKL_17547:
( SR: 1653289553 DTS: JAGaa46305 )
LVM's autoresync after disk powerfail can leave extents
stale.
Defect Description:
PHKL_25439:
(SR: 8606247854 CR: JAGae14254)
Timestamp roll-backs are initiated at activation time if at
least one of the disks in the volume group has a timestamp
which is sufficiently high to elicit one. This is a rare
occurrence.
This defect occurs as the result of a timestamp roll-back
taking place while one of the disks in the volume group is
unavailable. The timestamp for the missing disk will not be
rolled-back with the other disks in the same volume group,
and it will, therefore, have what appears to be a very high
(more recent) timestamp in relation to the other disks. If
the disk becomes available again at some future activation,
it will be assumed to have the latest data and configuration
information. Any changes made to data and configuration
information during the time the disk was unavailable will be
lost.
Resolution:
The code was changed to prevent the incorrect timestamp
roll-back when a disk is unavailable during activation.
(SR:8606251516 CR:JAGae17581)
Although similar and related to CR JAGae14254, this defect
has a different triggering mode, and a lesser probability
of occurring.
This defect can only occur if, during activation, a
timestamp roll-back has been initiated, and the system
crashes just as the timestamps are written to the disks.
If the ensuing activation of the volume group has a disk
missing, and that disk happens to be one that did not
get its new timestamp written, then we can get into the
same scenario as that described by JAGae14254. That is,
if the missing disk becomes available again at some future
activation, it can have a timestamp which is higher (more
recent) than those of the other disks in the volume group.
This disk will be assumed to have the latest data and
configuration information, thus, changes made during the
time the disk was unavailable will be lost.
Resolution:
The code was changed to detect failed timestamp roll-backs
and to start-off the volume group timestamp at the right
place afterward.
(SR:8606251519 CR:JAGae17584)
The timestamp algorithm introduced by patch PHKL_23481
replaces the system time based LVM timestamp with a
timestamp based upon a simple counter. At the time an LVM
volume group is activated, this new algorithm applies a
timestamp which uses the highest on-disk timestamp plus a
predetermined "leap" value. This is done to assure the new
timestamp will exceed the highest possible timestamp on a
disk not present.
However, during the first activation of a volume group after
PHKL_23481 is applied, a problem may arise if the highest
timestamp of the missing disk is greater than any of the
timestamps on an available disk, and this timestamp differs
from the others by more than the "leap" value. At a later
activation which includes the missing disk, this disk may be
assumed to have the latest information. Changes made during
the time the disk was unavailable will be lost.
This problem can not occur once all the disks are present
during any activation after PHKL_23481 is applied.
Resolution:
Changes were made to modify the timestamp algorithm to again
take into account the system time in generating the LVM
timestamps, the way it was done prior to PHKL_23481.
(SR:8606231449 CR:JAGae00687)
PHKL_23481 contained code to slow the advance of the LVM
timestamp and to assure that it advanced properly. For
volume groups with timestamps close to exceeding the bounds
of the timestamp counters, a roll-back routine was provided
to safely roll-back the timestamps on them. The roll-back
routine contained a flaw that caused any subsequent
configuration operations to hang. The roll-back only occurs
when one or more LVM timestamps exceed {0x7fffffff,0} so
this should be a rare occurrence. If prior to the
roll-back, all the timestamps exceed {0x7fffffff,0}, then
subsequently reactivating the volume group will work fine.
However, if some of the timestamps exceed {0x7fffffff,0} and
others are less, subsequent activations will hang. The
subsequent hang occurs because an unsigned comparison is
correctly done for determining the latest disk data
structures to use, but a signed comparison is incorrectly
used to generate the new timestamp starting point. When LVM
attempts to use the artificially low starting timestamp to
update LVM configuration data on the disks, the operation
never completes because it is presumed complete by LVM when
the written timestamp exceeds the last timestamp.
Resolution:
Added code to correct the roll-back function and to do the
proper comparison.
(SR:8606224001 CR:JAGad93096)
PHKL_23481 contained code only intended to reduce the
likelihood that LVM configuration information would be used
from recently replaced disks that had their configuration
information restored using vgcfgrestore(1M). Instead, the
code actually made it impossible to use the LVM
configuration information from these disks. So if all the
disks in a volume group were restored, LVM would not use the
configuration information from any of the disks, causing the
activation to fail.
Resolution:
The code incorrectly excluded the data from restored disks
by marking it internally with a zero timestamp. The
solution was to mark the data with the lowest legal
timestamp instead. This allows LVM to use the configuration
information from disks restored by vgcfgrestore(1M), but
only as a last resort (when all the disks have been
restored). Additional modifications were made to cause LVM
to disregard the Mirror Consistency Record (MCR) from
restored disks. Another change was made to no longer
require a full mirror consistency resynchronization of the
logical volumes on a given disk with old/bad MCR entries,
unless the disk could or does have an MCR recent enough to
be worth using. Formerly, an expensive full mirror
consistency resynchronization was done for all the logical
volumes residing on a disk even when the disk contained an
old MCR, which would not be used anyway.
(SR:8606264390 CR:JAGae28720)
The kernel LVM_REMOVEPV ioctl unnecessarily checks whether
the volume group is read-only or whether a proper quorum is
available. This can result in the unexpected failure of the
ioctl request, resulting in the error message indicated.
These checks are unnecessary because LVM on-disk volume
group data structures are not updated by the ioctl.
Resolution:
Modified the code for the LVM_PVREMOVE ioctl, eliminating
the unnecessary checks.
(SR:8606251547 CR:JAGae17612)
When a system boots normally from an LVM boot volume group,
after it had been booted previously in LVM maintenance mode,
prior to making the root logical volume available, LVM must
resynchronize all mirrors of the logical volume. This is
necessary so that any information written during the
maintenance mode boot to a single mirror of the logical
volume is propagated to all the mirror copies. During this
process, the copy of the root logical volume on the disk
previously used to boot in maintenance mode is marked fresh
and all the other mirrors are marked stale. The problem was
that the array data structure used for marking the stale
extents was only large enough to hold the extents in
one mirror, therefore if there were two stale mirrors, the
data structure overflowed causing either data corruption or
a system panic.
Resolution:
Increased the size of the array used for resynchronizing the
mirrors to handle the total number of stale extents possible
in multiple mirrors (not just one).
PHKL_23612:
(SR: 8606176439 CR: JAGad45677)
The maximum number of physical volumes, including links,
which LVM can support was used incorrectly in the code.
Resolution:
The problem have been fixed by the LVM command patch
PHCO_23437. Now LVM can support up to 8 links per
physical volume (1 primary, 7 alternates). In this
kernel patch, we added an error message to reject
any LVM command which tries to add the 8th alternate
link to any physical volume. In the future, LVM might
be able to support more than 8 links when the resources
are available.
PHKL_23481:
(SR: 8606142976 CR: JAGad12319)
The cause of the LVM command hang reported in the CR was
that the LVM in-memory timestamp had overflowed so that
a new timestamp had a value older (less) than the prior
one applied to the VGSA. The potential for data
corruption also exists due to the remote possibility
that latest LVM on-disk metadata may be stamped with
an old timestamp causing LVM not to use the latest
metadata upon a subsequent activation.
Resolution:
The fix in this patch is a redesign of the timestamp
algorithm to far reduce the possiblity of a timestamp
overflow by modifying how timestamps are generated.
The new timestamp algorithm generates timestamps
independent of the system time, and generates
independent timestamps for each volume group.
The new timestamp algorithm also corrects errors
in the code which could cause the timestamp to
advance faster than it should, and situations where
the timestamp could be truncated. The patch also
includes code to correct (roll-back) the
LVM VG timestamp in a safe way should the
timestamp on a VG pass a danger threshold
approaching the overflow point.
(SR: 8606166039 CR: JAGad35326)
The panic and potential i/o hang mentioned in the
CR was caused by a kernel spinlock deadlock in
lv_defecthash(). lv_defecthash() incorrectly
acquired a spinlock already held.
Resolution:
lv_defecthash() was corrected so it would not
acquire the unnecessary spinlock.
This problem was fixed in 11.0. Migrated the fix for
SR: 8606161146 CR: JAGad30462 to 10.20.
(SR: 8606166971 CR: JAGad36258)
The LVM resync hang is most definitively identified by
a deadlock between a resync process running on the VG
server node deadlocked with the processing of a resync
request from a client node. The server resync process
is holding the vg_lock waiting for the
slvm_resync_lock, and the client resync request process
is holding the slvm_resync_lock waiting for the
vg_lock. The deadlock was due to the order of
acquisition of locks in lv_resyncpv(). Another problem
within lv_resyncpv() was that a routine called during
the resync dropped locks held which kept the PV from
being removed or the VG from being deactivated.
So the physical volume or logical volume data structures
could be deallocated while they were still being used by
lv_resyncpv(), resulting in a Data Page Fault.
Resolution:
lv_resyncpv() was redesigned for 11.11 to modify how the
different locks were acquired and to avoid the deadlock
and DPF problems. The re-written routine was included
in this 10.20 patch.
(SR: 8606168136 CR: JAGad37418)
The description for this defect is similar to the one
for SR: 8606166971 CR: JAGad36258.
The kernel LVM lv_resyncpv() routine called during device
resync dropped locks held which kept the PV from
being removed or the VG from being deactivated.
So the physical volume or logical volume data structures
could be deallocated while they were still being used by
lv_resyncpv(), resulting in a Data Page Fault.
Resolution:
The resolution for this defect is similar to the one
for SR: 8606166971 CR: JAGad36258.
lv_resyncpv() was re-written for 11.11 to modify how the
different locks were acquired and to avoid the deadlock
and DPF problems. The re-written routine was included
in this 10.20 patch.
(SR: 8606173900 CR: JAGad43153)
There are two problems in the routine which synchronizes
extents from the MWC cache entries (lv_recover_ltg()):
One problem is an off-by-one bug which causes the last
mirror copy to not be considered when looking for a fresh
available copy of a given extent. To make matters worse,
if for a given extent there is no fresh data available
to read from to perform the MWC resync, the extent is
skipped, leaving the fresh mirror copies still fresh
even when their data is possibly inconsistent.
Resolution:
The fix for the off-by-one error from PHKL_23127 for
11.00 JAGad43153 was included in this patch to fix the
first problem. Additional code from 11.00 MR was
included in this 10.20 patch to assure that a failed
attempt to resynchronize an extent leaves only
synchronized copies of the extent fresh.
(SR: 8606161601 CR: JAGad30917)
The problem was that every HFS read makes a call to an
LVM lv_readahead_info() routine to determine the optimum
readahead (presumably to optimize readahead for striped
volumes). The LVM routine grabs the necessary locks
to assure consistency of the data structures it accesses,
competing for them with the LVM merge operation. Thus,
adversely affecting read performance.
Resolution:
This patch eliminates the locking in lv_readahead_info().
This works because LVM lv_readahead_info() routine cannot
be called with a closed logical volume and the stripe
factor cannot be changed once a logical volume is created.
(SR: 8606124005 CR: JAGac39365)
When an i/o completes, all the requests in the LVM work
queue containing the request are analyzed to see if any
requests can be unblocked, whether or not the request
could necessarily be unblocked by the completed i/o.
The LV spinlock must be held while traversing the queue,
and it is held a very long time. The algorithm is time
consuming because it requires traversing the queue up to
each request, for each request on the list.
The algorithm is wasteful because the only requests
which can be unblocked by the completed request are
those directed to the same LTG as the completed
request, and on the work queue after it.
Resolution:
The fix was migrated from 11.00 patch PHKL_22233.
Instead of traversing the list of all prior requests once
for each request in the list to determine whether any of
the requests can be unblocked, the new unblock algorithm
scans the list only once to attempt to unblock only the
requests that can be unblocked by completion of the i/o
request. Thus, reducing the length of time the lock
protecting the queue is held.
PHKL_22529:
( SR:8606113703 DTS: JAGac07217 )
When a physical volume is replaced without deactivating the
volume group it belongs to, the operating system does not
read the bad block directory from the disk, but continues
using the old one. This can cause spurious I/O errors or
mirror resync failures if bad block relocation is disabled,
or data corruption if bad block relocation is enabled.
Resolution:
Whenever a physical volume is replaced, the bad block
directory from the new physical volume is read.
(SR: 8606138886 CR: JAGad08152)
If a shared volume group has one or more LUNs on an
active-passive disk array (Nike, Galaxy or Optimus), and
if one of the array's Service Processors is hot-swapped
without deactivating the volume group, then there is no
guarantee that all the nodes in the cluster will be using
the same IDs to refer to those LUNs or to refer to
particular paths (i.e., PVLinks) to the LUNs. This is
because each Service Process has a unique "controller
signature" which is used to construct these IDs.
The LUN and path IDs are passed between nodes in PVLinks-
related messages. If the IDs do not match, the messages
will fail. This can lead to various symptoms, but the most
obvious is that if a node deactivates the volume group
(while it remains activated on other nodes), that node
will not be able to reactivate it.
Resolution:
The solution is to detect situations where the IDs might be
out of sync and reconstruct them, by reading the controller
signatures again. If necessary, messages are reprocessed (if
the receiver was using an old ID) or resent (if the sender
was using an old ID).
(SR: 8606162303 CR: JAGad31619)
Reads directed to HFS file systems on LVM logical volumes
can take substantially longer to complete during an lvmerge
operation. The cause is that the LVM lv_readahead_info()
interface called by HFS during each read is substantially
slower than it was prior to patch PHKL_20964 (in which
significant LVM locking improvements were made).
Resolution:
LVM lv_readahead_info() performance has been improved by
not being quite so strict with the locks acquired during
the lv_readahead_info() operation.
PHKL_21370:
(SR: 8606108373 CR: JAGab78776)
When reading from a mirrored logical volume, LVM might try
a disk that is known to be off line before it tries another
disk which is still available. The read is delayed while the
first I/O times out.
Resolution:
In selecting the best mirror to read from, give preference
to disks that are still available over disks that are known
to be off line.
(SR: 8606106798 CR: JAGab76189)
When a volume group is activated, LVM validates a data
structure on each physical volume called the Mirror
Consistency Record (MCR). If the MCR is not valid, LVM
performs a full resync of the physical volume and should
rewrite the MCR. But with PHKL_20964 installed, LVM does
not rewrite the MCR. Instead, if the MCR is invalid, LVM
performs a full resync every time the volume group is
activated, rather than just the first time. While the
resync is in progress, system performance may be degraded.
In addition, since LVM does not have two valid copies of
all data during the resync, the system is vulnerable to a
disk failure until the resync completes. (This problem
does not affect performance or availability of mirrored
logical volumes after the resync has completed.)
With PHKL_20964 installed, LVM might also display the
wrong physical volume (PV) number in certain diagnostic
messages. PHKL_21370 corrects this, as well.
Resolution:
If the MCR is not valid, rewrite it after performing a
full resync.
PHKL_19705:
( SR: 1653305987 DTS: JAGab17773 )
Currently, LVM does not allow bad block relocation with
parallel read operation for consistency in bad block
relocation. So when a bad block relocation is going on
and a new request comes on to the same block then
we panic.
As an enhancment, we enable bad block relocation with
parallel read operation if we notice that the block we
are accessing is being relocated, depending on the
state either initiate bad block relocation or wait till
the bad block relocation is completed. If REL_DESIRED
meaning a read noticed a bad block is set on a block
then we initiate the relocation for this block.
If REL_PENDING or REL_DEVICE meaning relocation is going
on, then we wait till the relocation is completed and
then we will do the I/O from the new location.
Resolution :
Modified lv_hwreloc() and lv_validblk() for taking
action appropriately for the above mentioned states.
PHKL_20964:
(SR: 8606128444 CR: JAGac81735)
It might not be possible to activate a volume group in
shared mode if any of its physical volumes are on an
Optimus Prime Disk Array, because the serial numbers for
these device are truncated when they're passed between
nodes in a ServiceGuard cluster.
Resolution:
Don't truncate Optimus Prime serial numbers.
[Although this defect was resolved in PHKL_20964, the
original documentation did not mention it.]
(SR: 8606106637 CR: JAGab75913)
The LVM deadlock (hang) occurs due to a defect introduced
in PHKL_19210 (recalled). In the bad
patch, the problem was that an easily encountered
deadlock condition was introduced while attempting
to correct another relatively rare deadlock.
The problem can be easily reproduced by running LVM
commands which operate on existing logical volumes
such as lvextend(1M), lvsplit(1M) or lvmerge(1M)
along with commands that query logical volumes, such as
glance(1). The deadlock occurs roughly 10% of the time,
but when it does happen there are severe consequences.
The deadlock makes it impossible to complete the operations
or to run any other LVM commands, without rebooting the
system.
Resolution:
The LVM kernel code was modified. The volume group lock and
other LVM locks were reordered and a new volume group data
lock was added to allow device recovery operations to occur
simultaneously with command operations. Thus correcting the
old and newly introduced deadlock defects.
This patch supersedes the interim PHKL_20808 patch.
It reintroduces the device recovery changes from PHKL_19210
and the bug fixes from PHKL_19697 which were purposely
excluded from PHKL_20808.
(SR: 8606106012 CR: JAGab74797)
Because of a race condition in LVM, it is possible for an
I/O request to be accepted when the logical volume is being
closed. Eventually, a data structure that has already been
freed (as a result of closing the logical volume) is
referenced, causing the operating system to panic.
Resolution:
Eliminate the race condition so that I/O cannot proceed
after a logical volume has been closed.
[Although this defect was resolved in PHKL_20964, the
original documentation did not mention it.]
PHKL_20808:
( SR:8606100412 DTS: JAGab31786 )
This is an interim patch to support the Optimus disk array.
PHKL_20057:
( SR:8606100412 DTS: JAGab31786 )
For some disk arrays, LVM treats all occurrences of the
same LUN ID as alternate paths to a single volume. This
assumption is not correct for the Optimus disk array: two
distinct volumes may have the same LUN ID, but different
target IDs.
Resolution:
To identify a unique volume in an Optimus array, LVM now
uses both its LUN ID and target ID.
PHKL_19697:
( SR:8606101971 DTS: JAGab66231 )
If the physical volume to which the logical volume is
mapped has problems, instead of retrying till the
lv_iotimeout value set on the logical volume, LVM
returns EIO for logical requests before lv_iotimeout.
This is because we are initializing the start time on the
request during scheduling of the request. If the PV to
which the request is to be scheduled is down then we
append the request to powerfail wait queue without
scheduling. When the PV comes back, we start resending
the buffers in the powerfail wait queue and at that
time we check the elapsed time (current time - initial
time set) of the request, since we had not initialized
the time on the request as we did not do the scheduling,
it will be set to zero resulting in a value higher
than the lv_iotimeout. Hence we bail out the request
without processing it, although the time elapsed will
be much less than the lv_iotimeout value.
Resolution :
Initializing logical buf start time in lv_strategy(),
at the time of processing the request instead of
setting it during scheduling in lv_schedule().
PHKL_19210:
( SR:5003437970 DTS: JAGaa40887 )
The problem was that some of the LVM device recovery was
still a serial process.
Resolution:
The LVM device recovery code was modified to cause all tests
of devices and paths to be conducted in parallel. Devices
which are available are immediately brought online again,
irrespective of other failed devices or paths. The changes
in this patch assure that devices recover within the time it
takes to test the device/path and to update its data
structures. The volume group data structures and LVM
operations that require them --LVM commands and opens and
closes of logical volumes should be held off no more than 35
seconds.
PHKL_19167:
( SR: 8606100864 DTS: JAGab39559 )
( SR: 4701424846 DTS: JAGab14452 )
Informix issues massive amounts of 1K reads in parallel.
With an 8K page size and I/Os serialized within the page,
performance suffers.
Resolution:
Logic was added to allow reads from the same 8K page to
proceed in parallel when bad block relocation is completely
disabled (lvchange -r N).
( SR: 8606100864 DTS: JAGab39559 )
( SR: 1653289132 DTS: JAGaa67952 )
If the holder of the vg_lock is waiting for I/O to finish,
and if the I/O can't finish until we switch to another link,
then we get into a deadlock.
Resolution:
To resolve the deadlock, the code now obtains the lock
temporarily, in order to switch to the alternate link, then
returns the lock to the original holder to finish the I/O.
( SR: 8606100864 DTS: JAGab39559 )
( SR: 4701424895 DTS: JAGab14455 )
We need to recognize Optimus Array as an ACTIVE/PASSIVE
device.
Resolution:
Added code to recognize the Optimus Array as an
ACTIVE/PASSIVE device.
PHKL_17547:
( SR: 1653289553 DTS: JAGaa46305 )
lv_syncx() may return with stale extents without actually
syncing all the extents.
Resolution:
Added additional check to see if all the extents are synced;
otherwise return error. lv_syncx() will return SUCCESS only
when the syncing is completed. Made changes in
lv_resyncpv() to preserve error value.
SR:
1653289132 1653289553 1653305987 4701424846 4701424895
5003437970 8606100412 8606100864 8606101971 8606106637
8606106798 8606108373 8606113703 8606124005 8606138886
8606142976 8606161601 8606162303 8606166039 8606166971
8606168136 8606173900 8606176439 8606247854 8606251516
8606251519 8606231449 8606224001 8606264390 8606251547
Patch Files:
/usr/conf/lib/libhp-ux.a(lv_lvm.o)
/usr/conf/lib/libhp-ux.a(rw_lock.o)
/usr/conf/lib/liblvm.a(lv_block.o)
/usr/conf/lib/liblvm.a(lv_cluster_lock.o)
/usr/conf/lib/liblvm.a(lv_defect.o)
/usr/conf/lib/liblvm.a(lv_hp.o)
/usr/conf/lib/liblvm.a(lv_ioctls.o)
/usr/conf/lib/liblvm.a(lv_lvsubr.o)
/usr/conf/lib/liblvm.a(lv_mircons.o)
/usr/conf/lib/liblvm.a(lv_phys.o)
/usr/conf/lib/liblvm.a(lv_schedule.o)
/usr/conf/lib/liblvm.a(lv_spare.o)
/usr/conf/lib/liblvm.a(lv_strategy.o)
/usr/conf/lib/liblvm.a(lv_subr.o)
/usr/conf/lib/liblvm.a(lv_syscalls.o)
/usr/conf/lib/liblvm.a(lv_vgda.o)
/usr/conf/lib/liblvm.a(lv_vgsa.o)
/usr/conf/lib/liblvm.a(sh_vgsa.o)
/usr/conf/lib/liblvm.a(slvm_comm.o)
what(1) Output:
/usr/conf/lib/libhp-ux.a(lv_lvm.o):
lv_lvm.c $Date: 2000/04/27 14:02:14 $ $Revision: 1.3
.98.5 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/libhp-ux.a(rw_lock.o):
rw_lock.c $Date: 2000/10/20 15:32:10 $ $Revision: 1.
8.98.7 $ PATCH_10.20 (PHKL_22529)
/usr/conf/lib/liblvm.a(lv_block.o):
lv_block.c $Date: 2001/03/10 14:56:42 $ $Revision: 1
.13.98.9 $ PATCH_10.20 (PHKL_23481)
/usr/conf/lib/liblvm.a(lv_cluster_lock.o):
lv_cluster_lock.c $Date: 2000/04/27 13:40:16 $ $Revi
sion: 1.10.98.9 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/liblvm.a(lv_defect.o):
lv_defect.c $Date: 2001/03/10 14:56:40 $ $Revision:
1.16.98.9 $ PATCH_10.20 (PHKL_23481)
/usr/conf/lib/liblvm.a(lv_hp.o):
lv_hp.c $Date: 2002/06/26 10:40:31 $ $Revision: 1.18
.98.42 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_ioctls.o):
lv_ioctls.c $Date: 2002/06/26 10:40:54 $ $Revision:
1.18.98.31 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_lvsubr.o):
lv_lvsubr.c $Date: 2001/03/10 14:56:29 $ $Revision:
1.15.98.27 $ PATCH_10.20 (PHKL_23481)
/usr/conf/lib/liblvm.a(lv_mircons.o):
lv_mircons.c $Date: 2002/06/26 10:41:01 $ $Revision:
1.14.98.12 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_phys.o):
lv_phys.c $Date: 2000/04/27 13:59:37 $ $Revision: 1.
14.98.21 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/liblvm.a(lv_schedule.o):
lv_schedule.c $Date: 2000/04/27 13:59:39 $ $Revision
: 1.18.98.16 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/liblvm.a(lv_spare.o):
lv_spare.c $Date: 2000/04/27 13:59:58 $ $Revision: 1
.3.98.12 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/liblvm.a(lv_strategy.o):
lv_strategy.c $Date: 2000/04/27 14:00:04 $ $Revision
: 1.14.98.18 $ PATCH_10.20 (PHKL_21370)
/usr/conf/lib/liblvm.a(lv_subr.o):
lv_subr.c $Date: 2002/06/26 10:35:14 $ $Revision: 1.
18.98.14 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_syscalls.o):
lv_syscalls.c $Date: 2002/06/26 10:40:22 $ $Revision
: 1.14.98.15 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_vgda.o):
lv_vgda.c $Date: 2002/06/26 10:40:47 $ $Revision: 1.
18.98.11 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(lv_vgsa.o):
lv_vgsa.c $Date: 2002/06/26 10:40:51 $ $Revision: 1.
14.98.11 $ PATCH_10.20 (PHKL_25439)
/usr/conf/lib/liblvm.a(sh_vgsa.o):
sh_vgsa.c $Date: 2001/03/10 14:56:21 $ $Revision: 1
.3.98.12 $ PATCH_10.20 (PHKL_23481)
/usr/conf/lib/liblvm.a(slvm_comm.o):
slvm_comm.c $Date: 2001/03/10 14:56:44 $ $Revision:
1.3.98.6 $ PATCH_10.20 (PHKL_23481)
cksum(1) Output:
3682845836 156624 /usr/conf/lib/libhp-ux.a(lv_lvm.o)
3753784657 7132 /usr/conf/lib/libhp-ux.a(rw_lock.o)
1887245431 2620 /usr/conf/lib/liblvm.a(lv_block.o)
2776493385 10592 /usr/conf/lib/liblvm.a(lv_cluster_lock.o)
3198851558 12788 /usr/conf/lib/liblvm.a(lv_defect.o)
611773878 92380 /usr/conf/lib/liblvm.a(lv_hp.o)
1065303547 35100 /usr/conf/lib/liblvm.a(lv_ioctls.o)
2163901249 39192 /usr/conf/lib/liblvm.a(lv_lvsubr.o)
3664749475 18800 /usr/conf/lib/liblvm.a(lv_mircons.o)
3498976193 8424 /usr/conf/lib/liblvm.a(lv_phys.o)
2206454939 26332 /usr/conf/lib/liblvm.a(lv_schedule.o)
723445810 38920 /usr/conf/lib/liblvm.a(lv_spare.o)
907693295 7476 /usr/conf/lib/liblvm.a(lv_strategy.o)
550220118 17952 /usr/conf/lib/liblvm.a(lv_subr.o)
580183395 14176 /usr/conf/lib/liblvm.a(lv_syscalls.o)
3660049477 9756 /usr/conf/lib/liblvm.a(lv_vgda.o)
2832949191 12532 /usr/conf/lib/liblvm.a(lv_vgsa.o)
1750144930 42624 /usr/conf/lib/liblvm.a(sh_vgsa.o)
45683920 27104 /usr/conf/lib/liblvm.a(slvm_comm.o)
Patch Conflicts: None
Patch Dependencies:
s800: 10.20: PHKL_16751
Hardware Dependencies: None
Other Dependencies:
PHKL_21085 should also be installed on systems using Nike,
Galaxy, or Optimus disk arrays in a Shared LVM configuration
to improve the recovery after the hot-swapping of array
Service Processors.
Supersedes:
PHKL_17547 PHKL_19167 PHKL_19210 PHKL_19697 PHKL_19705 PHKL_20057
PHKL_20808 PHKL_20964 PHKL_21370 PHKL_22529 PHKL_23481 PHKL_23612
Equivalent Patches:
PHKL_25438:
s700: 10.20
Patch Package Size: 650 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_25439
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHKL_25439.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHKL_25439. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
WARNING: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHKL_25439.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_25439.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
New tests run for the first time on this patch revealed a
preexisting problem with some LVM commands which will be
fixed in a separate commands patch. Commands that are run
independently work fine, but when a logical volume command
(lvchange, lvcreate, lvextend, lvreduce, lvremove, lvrmboot)
is run at the same time as a volume group command (vgchgid,
vgexport, vgreduce, vgremove, vgscan), it is possible that
the 'lvlnboot -R' and vgcfgbackup portions of the logical
volume command may fail. The best way to avoid the problem
is not to run the indicated LVM commands simultaneously.
If the 'lvlnboot -R' or vgcfgbackup operation fails, the
workaround is simply to repeat these manually. Similarly,
vgdisplay and lvdisplay might fail if they are run while
the LVM configuration is changing. If this happens, simply
repeat the vgdisplay or lvdisplay command.
There are no inconsistencies introduced into the LVM
configuration file or the on-disk LVM data structures by
this defect. However, it is important to run the failed
'lvlnboot -R' command when boot logical volumes are changed
and to perform configuration backups whenever the volume
group configuration is changed.
This patch depends on base patch PHKL_16751.
For successful installation, please ensure that PHKL_16751
is in the same depot with this patch, or PHKL_16751 is
already installed.
Due to the number of objects in this patch, the
customization phase of the update may take more than 10
minutes. During that time the system will not appear to
make forward progress, but it will actually be installing
the objects.
-----End of Document ID: PHKL_25439------------------------------------------
Document ID: PHCO_26962
Date Loaded: 20020702
Title: s700_800 10.20 cumulative patch for shutdown(1M)
Patch Name: PHCO_26962
Patch Description: s700_800 10.20 cumulative patch for shutdown(1M)
Creation Date: 02/05/02
Post Date: 02/07/02
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products: N/A
Filesets:
OS-Core.UX-CORE
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHCO_26962
Symptoms:
PHCO_26962:
shutdown(1m) exits with an error message if the
user id of the user who invoked shutdown is
greater than 60000.
PHCO_21574:
shutdown(1M) script replaced with compiled
program to correct basic functionality problem.
Defect Description:
PHCO_26962:
If shutdown(1m) is invoked by an user with user id
greater than 60000, the command exits with the error
message:
"getpwuid: No such file or directory
Unable to get username.
User not allowed to shut down this system --
exiting shutdown."
Resolution:
The current patch is built with a libc that supports
user ids upto 2147483647.
PHCO_21574:
Proper execution of the command is not assured
when considering input variables.
Resolution:
Input variable is now properly initialized.
SR:
8606219317 8606126826
Patch Files:
/sbin/shutdown
/usr/sbin/shutdown
what(1) Output:
/sbin/shutdown:
$Revision: 78.1.1.1 $
PATCH-PHCO_20441 for 10.20; for 10.30, 11.x compatib
ility libc.a_ID/main/r10dav/libc_dav/libc_
dav_cpe/9
/ux/core/libs/libc/archive_pa1/libc.a_ID
Nov 10 1999 10:43:44
PATCH_10_20: shutdown.o localDisk.o 02/05/02
/usr/sbin/shutdown:
$Revision: 78.1.1.1 $
PATCH-PHCO_20441 for 10.20; for 10.30, 11.x compatib
ility libc.a_ID/main/r10dav/libc_dav/libc_
dav_cpe/9
/ux/core/libs/libc/archive_pa1/libc.a_ID
Nov 10 1999 10:43:44
PATCH_10_20: shutdown.o localDisk.o 02/05/02
cksum(1) Output:
1760122220 339968 /sbin/shutdown
1760122220 339968 /usr/sbin/shutdown
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHCO_21574
Equivalent Patches:
PHCO_21534:
s700: 11.00
s800: 11.00
Patch Package Size: 390 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 PHCO_26962
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHCO_26962.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHCO_26962. If you do not wish to retain a
copy of the original software, you can create an empty file
named /var/adm/sw/patch/PATCH_NOSAVE.
WARNING: If this file exists when a patch is installed, the
patch cannot be deinstalled. Please be careful
when using this feature.
It is recommended that you move the PHCO_26962.text file to
/var/adm/sw/patch for future reference.
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHCO_26962.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHCO_26962------------------------------------------
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]