A fix is available
APAR status
Closed as program error.
Error description
When the system is under extreme stress due to intense levels of HiperSockets network activity it is possible for device signals to be generated faster than some users can process them. If this situation persists, free storage can be flooded with CPEBKs stacked for entry point HCPVAIEV to process the signals.
Local fix
Apply PTF SXA004
Problem summary
**************************************************************** * USERS AFFECTED: Customers using HiperSockets Guest LAN for * * connectivity may be able to recreate this * * condition if network traffic is very high * * and the system has limited CPU resources for * * the guest processing inbound network data. * **************************************************************** * PROBLEM DESCRIPTION: * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** In an environment using HiperSockets Guest LAN connectivity for an unusually active network, the system failed with ABEND SXA004 (out of storage frames). The dump revealed that an unusual number of CP frames were filled with CPEBK structures representing stacked calls to HCPVAIEV. Each call to HCPVAIEV represents an update to a simulated HiperSockets input queue for a virtual NIC. The dump also revealed that multiple calls were stacked for the same input queue (suggesting that senders were adding network data to one receiver faster than that guest could process the input queue).
Problem conclusion
Research indicates that a receiver only needs one signal to initiate queue processing (no matter how many updates are made before it starts queue processing). This led to a new strategy for handling the call to HCPVAIEV. Entry point HCPVAIEV is updated to reset a new flag (VDEVAIF1) when the receiver is ready to process the input queue. Callers of HCPVAIEV are updated to set (using TS serialization) the new flag (VDEVAIF1) before stacking a call to HCPVAIEV. If TS fails, there is no need to stack a redundant call to HCPVAIEV. This eliminates the redundant CPEBK structures which could otherwise build up if multiple senders are feeding a single receiver faster than it can process the calls. It also saves CPU cycles which would be used in stacking and processing the unnecessary HCPVAIEV calls.
Temporary fix
********* * HIPER * ********* FOR RELEASE VM/ESA CP/ESA R540 : PREREQ: VM65283 VM65406 VM64651 CO-REQ: NONE IF-REQ: NONE FOR RELEASE VM/ESA CP/ESA R620 : PREREQ: VM65042 VM65406 CO-REQ: NONE IF-REQ: NONE FOR RELEASE VM/ESA CP/ESA R630 : PREREQ: VM65417 CO-REQ: NONE IF-REQ: NONE
Comments
APAR Information
APAR number
VM65626
Reported component name
VM CP
Reported component ID
568411202
Reported release
630
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-09-29
Closed date
2015-01-26
Last modified date
2016-03-30
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UM34523 UM34524 UM34525
Modules/Macros
HCPIQE HCPIQR HCPVAI HCPVDEV HCPVQA
Fix information
Fixed component name
VM CP
Fixed component ID
568411202
Applicable component levels
R540 PSY UM34523
UP15/01/26 P 1501
R620 PSY UM34524
UP15/01/27 P 1501
R630 PSY UM34525
UP15/01/26 P 1601
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG27M","label":"APARs - z\/VM environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"630","Edition":"","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]
Document Information
Modified date:
30 March 2016