ZCOM Kernel Data

NCARD

NCARD (Number of Mux interface cards installed in the system) is a counter used to indicate the number of Mux interface cards in the host computer. It is updated by the DAM when the Mux interface cards are bound to the DAM during system boot-up.

HPA Table

The Hard Physical Address (HPA) table is built by the DAM; for HP-PB standard systems it provides a cross reference between the hardware address and software tables and addresses. The DAM creates a row in this table for each interface card that is bound by the system at bootup or reconfiguration. When the ZCOM subsystem is initialized, the LDM uses the information provided by TTGEN in the ZCOM interface table (INHPA field) to match the actual HPA value. If the LDM is able to find the matching HPA, it inserts the ZCOM interface table address in the HPA table.

Each row in the table has entries of the form (zhpa_type) shown in Table 3-44 “HPA Table Entries”.

Note that for EISA ACC the slot number is assigned to PDA variable in the DAM.

HPANO - HPA value of I/F card (zhpano_type)

The HPA value is setup by the DAM when HP-UX creates an instance of the DAM for a particular Mux interface card. This field is used by the LDM to match the Mux interface cards defined in the TTGEN configuration file, to those actually configured in the hardware. The format of the field is shown in Table 3-45 “HPA value of I/F card (HPANO)”.

In the 32-bit kernel, the HPA value is a 32-bit value. Only the lower 32-bit are kept in this field. This field will also become a 32-bit field, followed by a 32-bit padding.

RESRVD1 - Reserved for future use.

RESRVD2 - Reserved for future use.

HLMPDA - Pointer to DAM PDA for I/F card

This is the address of the PDA for this Mux interface card and is setup by the DAM when it initializes a row for an interface card.

HPAIFT - Pointer to ZCOM Interface table for this interface

This field is initialized to NULL during bootup. It is set up by the LDM during ZCOM subsystem startup. It is used to retrieve the responsible IFT from the HPA value.

HSTATUS - Status of this entry

This field contains the status indicators for the HPA entry. The DAM sets up the status after the drivers recognize the hardware during HP-UX system boot-up. Currently, only one bit is used (bit 15, ZCOM_HSTATUS_ALIVE). Bit ZCOM_HSTATUS_ALIVE indicates that the Mux card is physically present and usable.

The LDM checks this status before it communicates with the DAM. If this bit is not set, the LDM will ignore the card. This feature is intended for the implementation of dynamic hardware reconfiguration in HP-UX.

HACTIVE - Number of active requests

This field contains the number of pending inter-driver requests from the LDM to DAM. A non-zero value indicates some LDM requests are being processed by the DAM, hence deallocation of the driver resources is not allowed (i.e., driver unbinding). This feature is intended for the implementation of dynamic hardware reconfiguration in HP-UX.

SX25_BRDN - Streams X.25 board number

This field is used internally by the driver for keeping track of the J2793A Streams X.25 assigned board number, used for this card in the SNID.

DVR - Call entry for the interface driver

This is a kernel function pointer to the DAM's primary entry point. It is for the LDM to request the DAM's services. It is set up by the DAM during system bootup.

BUS1_NUM - Bus converter position (U2) of the interface card

BUS_NUM - Bus number of the interface card

SLOT_NUM - Slot number of the card

These 3 fields are set up by the DAM during system bootup. It contains the hardware path of the associated interface card.

HW_ADDRESS - A string containing the hardware path to the card.

HLOCK - IFT spinlock

It is allocated by the DAM during system bootup. It is used to allow sharing resources in a Multi-Processor system. When a module requires exclusive access to a IFT, it must obtain this lock first.

SYS

The SYS structure (ZCOM system global information, zsys_type) contains software status information about the ZCOM subsystem. For example, it indicates whether ZCOM is running and when it was last started up. It is updated by the LDM based on requests from ZMON.

STIME - Time when status last changed

This field contains the time (in Epoch format) when the ZCOM subsystem changed to the current state. For example, in a running ZCOM subsystem, this field contains the time when the ZCOM subsystem became operative.

In addition to providing time information, this field is also used in the LDM sleeping mechanism. When a ZCOM application is awoken after waiting in the sleep state, it checks this field to determine whether the ZCOM subsystem has changed state (for example, from READY to RESET state). If so, an error will be returned to the application program. This mechanism allows all sleeping ZCOM programs to be notified when the operational state of the ZCOM subsystem has changed.

STATUS - Current ZCOM system status

This field contains the current state of the ZCOM subsystem. The defined values are shown in Table 3-47 “Current ZCOM system status”.

The LDM uses the high order bits of this field as individual indicator to determine the status of the system as listed in Table 3-48 “Current ZCOM system status (Higher Order Bits)”.

DEBUG - Debug level

This field is used by the LDM to produce driver debug logs for its processing. Some LDM modules have embedded debug codes, which check this field to log debug messages. The format of this field is shown in Table 3-49 “Debug Level Field Format”. The values of the bits in the field are described in Table 3-50 “Debug Level Field Values”.

This field is maintained by the zmon debug and zmon nodebug commands. Because the debug logging increases the LDM overhead and is mainly for internal use, these commands are not recommended for users.

MEMPTR, MEMSIZE -Kernel memory size pointers

These are pointers to the size of kernel memory allocated by the LDM. The memory is used to hold ZCOM subsystem Memory Tables. In the current implementation, there is a fixed amount of memory defined in the kernel for use by the ZCOM subsystem, determined by the kernel zcom_mem_size tunable parameter defined at kernel build time. Hence, these fields are assigned to that part of memory.

SYSPTR, SYSSIZE - ZCOM system size (adjusted) and pointer.

These are the pointers to the size of the kernel memory to be used by the ZCOM subsystem. The ZCOM subsystem memory requires 64-byte alignment, and the system may not use up all allocated memory. These two fields indicate the actual location and size of the ZCOM memory.

NREQUEST - Number of active requests

This field contains the number of ZCOM application requests in progress. The LDM increments content in this field when it receives a new request, and decrements it when a request completes. During ZCOM subsystem shutdown, the LDM checks this value for pending application requests. If there is any pending requests, the LDM waits (for 5 seconds) to give the requests time to complete before forcing the ZCOM subsystem down.

This field is intended for the implementation of a smooth (i.e., graceful) ZCOM subsystem shutdown mechanism.

RTIMER - Reset request timer

This is the timer used by the LDM to wait during a ZCOM subsystem shutdown. The LDM will not shutdown the ZCOM subsystem immediately if there are pending application requests. Instead, it sets this timer to a non-zero value and goes dormant. When the LDM timer module is activated, it decrements this field and wakes up the waiting LDM when it reaches zero.

This field is used with NREQUEST to provide a waiting deferred shutdown mechanism.

NSLOW - Number of slowdown processes (* obsolete *)

This field is obsolete. Not used.

ZSINFO - ZCOM system information buffer

This is a data structure set up by the LDM when ZCOM subsystem is started up. It contains information to be passed back to an application via zinit. Refer to the definition of zsinfo_type for its layout.

HP

The HP (Pointer to ZCOM system header) structure is a pointer to ZCOM subsystem header. It is set up by the LDM during ZCOM subsystem startup. The ZCOM subsystem memory tables are accessed through this pointer.

LINFO

The LINFO structure (Lock Information, struct zlinfo) contains the ZCOM locks used globally in the ZCOM subsystem. It is initialized by the LDM during system bootup. The locks are used to provide exclusive access to the sharable data structures in the ZCOM subsystem. The fields are described in Table 3-51 “LINFO Structure Fields”.

ZC_GLOCK - Global spinlock

This is the highest lock order in the ZCOM subsystem. It protects the ZCOM system header zheader_type in global memory (with some exception, see ZC_RLOCK below), and the LDM static data such as the interface request queue and ZCOM message log buffer.

ZC_MLOCK - Memory pool spinlock

This protects the ZCOM buffer pool. Used in buffer management routines, such as buffer allocation and buffer freeing.

ZC_RLOCK - Remote ZLU spinlock

This lock protects the following ZCOM system header data fields. They are connected with remote nodes or remote API processing:

hrdataq, hpntbl, hndpid, hndsig, hndmax, hnidle, hnhigh, hnlow, hnwait

ZC_SLOCK - Super IFT spinlock

This lock protects against deadlock situations while multiple IFTs need to be access simultaneously. A piece of code must obtain this lock first if it is going to lock multiple IFTs.

Each of the above fields is a data structure (zlock_t) with the data fields shown in Table 3-52 “Super IFT spinlock (ZC_SLOCK) Data Structure”.

LOCKP - Pointer to kernel spinlock structure

This is a pointer to the spinlock structure allocated dynamically from the kernel. It is used for the locking mechanism in the kernel.

REFCOUNT - Lock reference count

This is to support locks that could be acquired recursively in the ZCOM subsystem. Every time when the ZCOM lock is acquired, this count is incremented. When the ZCOM lock is released, this count is decremented. Only when this count reaches zero, the kernel lock (via the LOCKP pointer) is released.