Content-type: text/html Man page of vb

vb

Section: Environments, Tables, and Troff Macros (7)
Index Return to Main Contents
 

NAME

vb, sys_attrs_vme_vba - VME backplane Ethernet interface  

SYNOPSIS

controller vb0 at vba0  

DESCRIPTION

The VME backplane (vb) interface provides access to an Ethernet network through the VME backplane driver, which acts as an Ethernet Datalink Layer driver. This interface allows VME-based systems to communicate directly over the VMEbus to other VME-based systems on the same backplane, or on other Ethernet connected systems outside the backplane through a gateway node on the backplane.

Both the Compaq Tru64 UNIX and VxWorks for Alpha (Version 3.1 or higher) software support the vb driver as well as communication between these systems on the same backplane. The Tru64 UNIX vb driver is supported on DIGITAL AXPvme and Alpha VME SBCs and DIGITAL Alpha VME 2100 systems.

The VME backplane interface requires you to modify the /etc/sysconfigtab file on your AXPvme or Alpha VME system in order to configure the vb driver and to map VMEbus windows for the system. Mapping the VMEbus windows on one node requires knowledge about every node in the vb network.

Note

Do not modify any vme_vba kernel subsystem attributes. To configure a vb network node, you modify attributes of the vb driver (vb:) and the system's VMEbus adapter (vba_vipvic: or vba_univ:).

This reference page addresses the following topics relating to the use of the vb interface on Alpha VME systems: vb network overview Configuring vb network nodes Modifying vb driver attributes Modifying vba_vipvic adapter attributes Modifying vba_univ adapter attributes Examples Related ioctl commands Diagnostic messages Errors  

vb Network Overview

Tru64 UNIX provides a VMEbus backplane (vb) driver that allows systems to communicate over a VMEbus backplane using Ethernet protocols.

The backplane driver is compatible with the other parts of the network subsystem; that is, all higher-level network protocols are immediately available over the backplane, just as they are over the Ethernet. Socket communication, remote login, remote file access, NFS, and remote procedure calls are all simultaneously available to and from any processor on the backplane. Using these network facilities over the backplane is indistinguishable from using any other network medium.

By default, the vb driver is not configured to run when the system is booted and must be explicitly turned on for the node to participate in the backplane network.

Configuring nodes in a vb network can be simple or complex, depending on the specific system needs. At a minimum, the vb driver must be configured to be turned on and the Ethernet hardware address of the target system must be specified. By default, an unconfigured driver will not start up.

You can use all other default vb characteristics without change, as long as you configure the necessary system VMEbus window space correctly. You can also tailor several backplane node characteristics to meet specific system and application needs.

VMEbus addresses are used in two ways in the vb driver: To map local memory onto the VMEbus for client message queues To interrupt nodes on the vb network when data is sent

The following subsections describe how VMEbus addresses are used for client communication and for interrupting nodes on the vb network.  

VMEbus Addresses Used for Client Communication

A vb network is made up of two or more nodes in a VMEbus backplane cage that communicate by way of local memory mapped onto the VMEbus. Nodes that participate in the vb network provide local memory for client message queues. Other backplane nodes map to this memory over the VMEbus and write data to this local memory; this is what is meant by "sending" messages to a node on the backplane network.

The VMEbus has three different basic address spaces to which system VMEbus windows may be mapped: A16, A24, and A32. Each system in a VMEbus backplane must configure a client-communication VMEbus window (and a mailbox-interrupt VMEbus window, discussed later) in a unique manner, such that the windows do not overlap across the backplane. See vme_manual_setup(7) (VIP/VIC-based Alpha VME systems) or vme_univ_manual_setup(7) (UNIVERSE-II-based Alpha VME systems) for more information on configuring VMEbus address spaces.

The vb driver uses either A24 or A32 space to map its client-communication queues (data) to the VMEbus. The specific address within the A24 or A32 space is specified by an offset from the base of the particular window. The size of the queue data is also specified by the user.

Specify the following information regarding the queues for each backplane node: The address space in which to map the queues (A24 or A32) as well as other address space modifiers (supervisory/user, program/data) The total size of the area used to map the communication queues The VMEbus address where the queues will be mapped to the VMEbus, as specified by an offset from the base of the queues' chosen system VMEbus window

Default values are defined for these items, but you can reconfigure your vb and VMEbus characteristics by adding or modifying values in the /etc/sysconfigtab file, as described in the section Configuring vb Network Nodes.

Whatever you configure the values to be, you must modify the client-communication window to accommodate the chosen values. The window (A24 or A32) base and size specified must be unique across the backplane, and its size must be big enough to fit the queue size specified, starting at the offset specified.

You can configure VMEbus windows on a per-system basis by adding or modifying values for each window's VMEbus base address and size in the /etc/sysconfigtab file. See vme_manual_setup(7) (VIP/VIC-based Alpha VME systems) or vme_univ_manual_setup(7) (UNIVERSE-II-based Alpha VME systems) for more information on modifying the base address and size of VMEbus windows.

Note

If you do not uniquely configure the client-communication VMEbus windows for the backplane nodes on the vb network, unpredictable behavior may occur. An error message similar to the following prints to the console of a node whose client-communication VMEbus window overlaps that of a node that has mapped the window and is actively communicating through it, even if it is with a device other than the vb driver: vba0 errors_inter: VIP/VIC errors detected
        VIC BESR 0x50 - VIP BESR 0x40400 VIC DMASR 0x8
        VMEbus timeout
        local bus error - LBERR* asserted to VIC
        Inbound error - invalid s/g or VMEbus slave access error  

VMEbus Addresses Used for Interrupting

Module switch (mailbox interrupt) settings regulate interrupt activity in the vb backplane network. When a node sends data to another node, the sending node generates an interrupt on the receiving node by using module switches.

An interrupt is generated by writing to a particular offset from the base of a mailbox-interrupt window, which is an A16 (VIP/VIC) or A16/A24/A32 (UNIVERSE II) VMEbus window on the node to be interrupted. The offset determines the particular module switch to use for interrupting a node.

You must configure each node's mailbox-interrupt window to be unique across the nodes in the VMEbus backplane. You can configure VMEbus windows on a per-system basis by adding or modifying values for each window's VMEbus base address and associated attributes in the /etc/sysconfigtab file. See vme_manual_setup(7) (VIP/VIC-based Alpha VME systems) or vme_univ_manual_setup(7) (UNIVERSE-II-based Alpha VME systems) for more information on modifying the base address and size of VMEbus windows.

There are four module switches associated with each node's mailbox-interrupt window. You specify the module switch to use for interrupting by adding or modifying values for the following driver attributes in /etc/sysconfigtab: A module-switch offset value in VB_Mailbox_Offset A module-switch vector number in the Vector field of the VBA_Option entry For UNIVERSE-II-based Alpha VME systems, VMEbus address modifiers for the mailbox-interrupt window in VB_Mailbox_Addr_Type Verify that VB_Interrupt_Interface is set to 1 to select interrupt mode over polling mode

If you prefer, you can use the default module-switch offset and vector values, which select module switch 1. Adapter-specific offset and vector values are listed in the section Modifying vb Driver Attributes.

Whatever you configure the values to be, you must modify the A16 (VIP/VIC) or A16/A24/A32 (UNIVERSE II) mailbox-interrupt window base address to be unique among the nodes in the VMEbus backplane for interrupting to work. (Only one node in the backplane can use the default mailbox-interrupt window base address.)

However, the module switch used to interrupt a particular node can be individually configured on a per-node basis (not necessarily uniquely).  

Box Manager Node

Because a vb network is made up of two or more nodes in a VMEbus backplane cage that communicate via local memory mapped onto the VMEbus, information about which nodes are participating in the network must be stored so that all nodes can access this information. The information is stored in the local memory of a single backplane node called the box manager.

The box manager node is a special client in that it maps this global information onto the VMEbus in addition to mapping its client communication queues.

The box manager maps the global information onto the VMEbus at an address that is known to all other nodes in the backplane network (the well-known address). When non-box-manager nodes boot, they read information from the well-known address to see what other nodes are in the network. The well-known address must reside in the particular system VMEbus window (A24 or A32) with modifiers (supervisory/user, program/data) that are also well known to other nodes in the vb network. The combination of the address and its modifier uniquely specifies where the box manager global data resides on the VMEbus for all nodes to see.

The well-known address is configurable through /etc/sysconfigtab and defaults to 0xBC0000. The address space that it is mapped to (A24 or A32) is also configurable and defaults to A24 address space, supervisory mode, and data space. (For more information on configuring the well-known address and modifiers, see the section Modifying Per-Network vb Attributes.)

The network manager must configure only one node to be the box manager node. A node is a box manager if the well-known address is contained within the node's system VMEbus window (either A24 or A32, depending on the configured value of the box manager address modifier). There is no other switch or value to specify to identify a box manager. Note that you do not have to set the base VMEbus window address to the well-known address; the well-known address must simply be contained within a valid VMEbus system window.

When a node boots, it determines whether or not it is the box manager node by comparing the well-known address to its configured system VMEbus window range. A node that is not the box manager node is called a client node.

The box manager node is also just another network client, and it has local communication queues mapped to the VMEbus just like any other client. The difference is in the placement of those queues mapped onto the VMEbus. The box manager has two sets of data that must be mapped to the VMEbus: the box manager global data and the client communication queues.

By default, box manager global data and client communication queues are mapped to the same address space, A24. In the default case: The offset of the communication queues from the base window specified in /etc/sysconfigtab for the queues is ignored. The communication queues are mapped directly following the global data starting at the well-known address.

In addition, the combined size of the global data and the communication queues is adjusted to be equal to the configured size of the communication queues (the default for which is 0x40000, or 256 KB). You do not need to deal with the size of the box manager global data when you determine what your system VMEbus window size should be for the box manager node.

However, you can configure the global data and the communication queues to be mapped to different spaces (A24 and A32). In this case, the communication queues are mapped like any other client node. They are mapped at the configured offset from the base of its configured window. The global data is mapped to the well-known address, for a size of 0x6000 bytes. You must be sure that both system windows, A24 and A32, will accommodate either the well-known address or the communication queues.

The box manager node must be the first node in the backplane to boot so that the global memory is mapped to the well-known address before other nodes attempt to read from it.

You must boot the VMEbus system controller for the VMEbus crate (set by the appropriate jumper on the module) before any other node that is participating in the vb backplane or any other node that is using the VMEbus. This is because when the system controller is booted, it can reset the VMEbus registers of all other nodes. If the VMEbus system controller is not the box manager, ensure that the system controller boots before the box manager node, or that the system controller is not booted while the vb network is up and running. Note that if the the system controller is not the box manager, the system controller cannot participate in the vb network.  

Network Participation

Nodes in a backplane network communicate via memory mapped onto the VMEbus. If this memory becomes unmapped, or the VMEbus is reset for any reason, the mapping is no longer valid. Any read or write operations to a remote node that uses the invalid mapping could cause a panic or machine check on the system performing the read or write. To reduce the possibility of this occurring, the nodes in the vb network keep "liveness" with the rest of the network.

Once a node enters the vb network, it begins continually updating a counter in the global memory called its "heartbeat"; In addition, all nodes on the network continually check the vb heartbeat of other nodes, including the box manager node, to see if they are still alive and able to participate in the network in a timely manner.

If the heartbeat of a remote node is no longer being updated, communication to that node must stop in anticipation of the remote node's VMEbus mapping becoming invalid. For example, if a node is rebooted, its heartbeat ceases to be updated and the rest of the backplane nodes eventually lose liveness with that node and stop communicating with it.

When a node is shut down in a controlled manner (using /usr/sbin/shutdown), the vb driver notifies the other vb nodes that it is shutting down, so that they can stop communicating. If a node is shut down in an uncontrolled manner (panic or halt), the current VMEbus mappings remain valid until you reinitialize the system. This allows time for other vb network nodes to lose liveness with the node before an invalid mapping reference occurs.

Once you fully reboot the shutdown node, it can reenter the vb network, and is seen by the other vb network nodes again.

Once node A loses liveness with node B, node B cannot reenter the vb network without rebooting. You cannot restart the vb driver without rebooting. This restriction is due to the need for the restarting node to probe the well-known address to see if a box manager memory is mapped to the well-known address. This probing is supported only during the booting stage.

Response time is an important aspect of liveness. Even if a node is not shut down, it may respond too slowly to vb network traffic to be considered alive. In these cases, it may be in the best interest of the rest of the vb network to cease communication with that node. For example, a node may have a realtime application running at a realtime priority above that of the vb network driver, and in fact higher than many system functions. Without network traffic being processed in a timely manner, backups or message loss could occur on any node attempting to send data to the node.

The liveness feature of the drivers allows remote nodes to notice that the node's heartbeat is not being updated (because the node is devoted to the realtime application) and stop attempting to communicate with it. In addition, you could use a long liveness interval in a stable network configuration (one that does not expect frequent shutdowns) to allow a light load on the vb network to continue in the midst of expectedly high realtime priority usage.  

Configuring vb Network Nodes

To configure a vb network node, you perform the following steps: Examine the default or current configuration attributes of the vb driver (vb:) and of the system's VMEbus adapter (vba_vipvic: or vba_univ:).

If an existing vba_vipvic: or vba_univ: entry in /etc/sysconfigtab indicates that adapter defaults have already been modified for other VMEbus device drivers in the system, you must factor the needs of other drivers into any changes you make for the vb driver. As needed, modify the /etc/sysconfigtab file to add or modify values for vb driver and VMEbus adapter attributes. The vb driver must be turned on to be started up and the node's Ethernet hardware address must be specified. Also, as part of modifying VMEbus adapter attributes, you will need to configure each node's VMEbus system windows with the other participating nodes' VMEbus window configurations in mind. Sections that follow describe these tasks in detail.
Note
You should not directly edit /etc/sysconfigtab. Instead you should use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. Compaq recommends that you maintain private sysconfigtab file fragments for vb and VMEbus adapter attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) attribute values for a particular subsystem. The Examples section illustrates this approach. Reboot the vb node. You must always reboot after modifying driver or adapter subsystem attributes. Once a configured vb node boots, you must use the netsetup command to register the vb driver as a new network driver. Assign each vb node a unique IP address that is a subnet used exclusively by the vb network, to differentiate between the Ethernet network and the vb network. The participating nodes must be specified in the /etc/hosts file. For information on setting up a new network, see the Network Administration guide.

You must configure and boot the box manager node before configuring and booting any other nodes. Also, if the box manager is not the VMEbus system controller, the VMEbus system controller module must boot before the box manager. Otherwise, when the system controller is booted, it may reset the entire VMEbus backplane network.

When you boot each configured node, the VMEbus backplane driver becomes available. During the boot, the console will display diagnostic messages prefixed with the string VB:. The box manager displays the following message at startup: VB: This is the box manager node A client (non-box-manager) node displays the following message at startup: VB: Box mgr address space is not configured for this system,
    thus this node is not the box manager node (OK).  Be sure
    that there is a box manager in the network.

Caution

Make sure that only one node comes up as the box manager. If more than one node comes up as the box manager, it means that the system VMEbus address window has been configured to contain the well-known address (whose default is 0xBC0000) on more than one node. This results in unpredictable behavior and, at a minimum, causes the vb network to fail.  

Modifying vb Driver Attributes

The vb driver attributes are configurable on a per-node or per-vb-network basis, as described in detail in this section.

First you examine the default or current configuration attributes of the vb driver, as well as the system's VMEbus adapter. If the existing vb: entry in /etc/sysconfigtab indicates that vb driver defaults have already been modified, you may need to factor the previous changes into your new changes. If an existing vba_vipvic: or vba_univ: entry in /etc/sysconfigtab indicates that adapter defaults have already been modified for other VMEbus device drivers in the system, you must factor the needs of other drivers into any changes you make for the vb driver.

If you wish to change a vb driver attribute from its default or current value, you enter the attribute and its new value after the label vb: in the /etc/sysconfigtab file or in a sysconfigtab file fragment.

Note

You should not directly edit /etc/sysconfigtab. Instead you should use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. Compaq recommends that you maintain a private sysconfigtab file fragment for vb attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) vb attribute values. The Examples section illustrates this approach. You must always reboot after changing vb driver attributes.

You must also add or modify vba_vipvic: or vba_univ: adapter attribute values to map unique VMEbus windows for client communication and mailbox interrupts, as described in the sections Modifying vba_vipvic Adapter Attributes and Modifying vba_vipvic Adapter Attributes.

The following code example shows a sample vb: entry in the /etc/sysconfigtab file or in a sysconfigtab file fragment, including the associated VBA_Option bus configuration structure. Line breaks have been added to the VBA_Option entry for clarity.

In this example, only the VB_Startup_State and VB_Netid parameters have been modified from their defaults. These modifications enable the vb driver to start up and participate in a vb network. After you complete your vb driver and VMEbus adapter modifications, you must reboot the system. vb: # # %%%VB #
   VB_Startup_State = 1
   VB_Netid = 08-00-2b-e2-48-48
   VBA_Option = Manufact_Name - 'Compaq',
                Product_Name - 'VME Backplane Network Driver',
                Bus_Instance - 0, Driver_Name - vb, Driver_Instance - 0,
                Csr1 - 0, Csr2 - 0, Vector - 0x1150, Bus_Priority - 7,
                Type - C, Adpt_Config - N  

Modifying Per-Node vb Attributes

The following vb driver attributes are configurable on a per-node basis in sysconfigtab; values can differ on each node: Specifies the driver name as an unquoted ASCII string. The default value is vb. Specifies the startup state of this driver. The default value is 0 (off). You must change this value to 1 (on) to start up the vb network. Specifies address modifiers for the VMEbus address space used for the client node's message queues. You must specify the numerical equivalent of the desired set of address modifier (AM_) flags, among the following: AM_A24 (0x1), AM_SUPER (0x2), and AM_DATA (0x4).
You can map a node's client-communication queue memory to the VMEbus in either the A24 or A32 address space (AM_A24 set or clear), either in supervisory mode or user mode (AM_SUPER set or clear), and either in data or program space (AM_DATA set or clear). The default is AM_A24|AM_SUPER|AM_DATA, which equals 0x7. A32 program space in user mode would be represented as 0x0 (no flags set). Specifies the size (in bytes) of an area within the client-communication window (as characterized by VB_Client_Addr_Type) to be used by the vb driver for its communication queues. The bigger the size, the greater the number of message packets that will be preallocated for communication.
The default size is 0x40000 (256 KB), which is enough for 150 packets to be reserved for the queues. If there are 10 nodes in the network, this default allows for 15 packets to be devoted exclusively to communication between the local node and each of the other nodes. Specifies an interface for determining whether messages have been sent to the vb driver's queues: interrupt (1) or polled (0). You should use the default value of 1 for better performance. The vb driver uses module switch interrupts.
If you use the interrupt interface, you must ensure that the base address for the VMEbus window that maps the inbound mailbox interrupts is unique among the nodes in the backplane, as configured in sysconfigtab. Specifies the milliseconds interval between remote node liveness tests. By default, a node checks whether a remote node is still alive every 10000 milliseconds (10 seconds).
Be careful if you modify this value. An interval that is too short could cause nodes to lose liveness with each other too easily, and a lost node must be rebooted to resume communication. An interval that is too long (or 0, which specifies no liveness checking) could cause delays in determining that a remote node has gone down. The node could attempt to communicate with a shut down node after the VMEbus mapping is no longer valid. For UNIVERSE-II-based Alpha VME systems only, specifies address modifiers for the VMEbus address space used to map the client node's inbound mailbox interrupts. You must specify the numerical equivalent of the desired set of address modifier (AM_) flags, among the following: AM_A24 (0x1), AM_SUPER (0x2), AM_DATA (0x4), and AM_A16 (0x8).
On UNIVERSE-II-based nodes, you can map a node's mailbox interrupts to the VMEbus in A16, A24, or A32 address space. Specifying AM_A16 set and AM_A24 clear selects A16; specifying AM_A24 set and AM_A16 clear selects A24; and specifying both AM_A16 and AM_A24 clear selects A32. You also can map the mailbox interrupts either in supervisory mode or user mode (AM_SUPER set or clear), and either in data or program space (AM_DATA set or clear). The default is AM_A16|AM_SUPER|AM_DATA, which equals 0xE. A32 program space in user mode would be represented as 0x0 (no flags set).
For UNIVERSE-II-based nodes, the VMEbus address modifiers you specify for this attribute must match the adapter's CSR window attributes. See the descriptions of the CSR_AM_Space, CSR_AM_Usr_Sprvsr, and CSR_AM_Data_Prg attributes in the vme_univ_manual_setup(7) reference page.
For VIP/VIC-based Alpha VME systems, do not specify this attribute; the VMEbus window that maps inbound mailbox interrupts is always A16 data space in supervisory mode. Selects a mailbox for inbound interrupts by specifying an offset from the mailbox-interrupt window base address.
You use module switches to create vb driver interrupts on the backplane. You can use any of four module switches for interrupts in each mailbox-interrupt window. For each module switch, a particular offset value must be specified for VB_Mailbox_Offset and a particular vector number must be specified in the Vector field of the VBA_Option entry.
For VIP/VIC-based Alpha VME systems, the offset and vector values are: A16 offset 0x21, VBA_Option vector 0x1140 A16 offset 0x23, VBA_Option vector 0x1150 A16 offset 0x25, VBA_Option vector 0x1160 A16 offset 0x27, VBA_Option vector 0x1170
For UNIVERSE-II-based Alpha VME systems, the offset and vector values are: Offset 0x348, VBA_Option vector 0x1140 Offset 0x34C, VBA_Option vector 0x1150 Offset 0x350, VBA_Option vector 0x1160 Offset 0x354, VBA_Option vector 0x1170
The default in each case is module switch 1. If the mailbox-interrupt window base address for a given node A is 0x300 (A16), remote nodes can use offset 0x23 (VIP/VIC) or offset 0x34C (UNIVERSE II) added to 0x300 to cause an interrupt on node A when the vb driver writes to the address. The mailbox-interrupt window base address must be unique among all nodes in the backplane. However, the offset need not be unique.
If you change the module switch from the default of 1, this change must be reflected in both the VB_Mailbox_Offset attribute and the Vector field of the VBA_Option entry for interrupts to work on the system. Specifies the maximum number of nodes allowed in the vb network. The default value is 10. The maximum you specify cannot exceed 32. This value is examined by the vb box manager only, and determines the maximum number of nodes that may enter the vb network while the box manager is booted.
All other client nodes adjust their maximum-nodes value according to the box manager's value and do not have to know the box manager's value ahead of time. Specifies the offset from the client-communication window base address (A24 or A32, as characterized by VB_Client_Addr_Type) at which to map client queues for other nodes to see. The default is 0x0, which maps the queues at the beginning of the base address.
You must be able to adjust queue mappings because, if other VMEbus drivers in the system map memory to specific VMEbus addresses, there may be conflicts. In the event of a conflict, you can either adjust a system VMEbus window base address or modify the offset value such that the queues start at a different VMEbus address.
Although the default offset of 0x0 works well, you should consider changing the offset to a value equal to the A24 or A32 window size minus the size of the client communication queues (VB_Client_Vme_Window_Size defaults to 256 KB, 0x40000). For example, in a 2 MB (0x200000) A24 window, specify an offset of 0x1C0000. This moves the client communication queues to the top of the window, which reduces fragmentation within the window and minimizes potential conflict with the memory needs of other VMEbus drivers.
If you change the offset, make sure the value is on a page boundary (0x2000 bytes). Specifies the Ethernet hardware address of the node as an unquoted ASCII string; for example, 08-00-2b-e2-48-48. You must fill in this field with the correct Ethernet hardware address. The vb network address is derived from the unique Ethernet hardware address and is the shadow Ethernet address. If this value is not filled in, the vb driver does not start up and an error message is displayed.
One way to obtain the Ethernet hardware address of a running system is netstat -I ln0 (or tu0 or other Ethernet device). You can also obtain the Ethernet address at the console prompt of a nonbooted system as follows: >>> show dev Specifies whether the vb driver's probing of the box manager's well-known address should time out after the number of minutes specified in VB_Probe_Period or continue until the box manager comes up. The default is to time out (1). You can modify the value to continue probing indefinitely (0). Specifies the number of minutes to probe the box manager's well-known address before timing out and exiting the driver. The default value is 1 minute. This value is ignored if VB_Give_Up is set to 0. Specifies whether to display information whenever the driver maps to a new node or unmaps from a node. The default is not to display state changes (0). If the vb driver starts up with this value set to 1, you can track state changes beginning at startup. Reserved for future use
 

Modifying Per-Network vb Attributes

The following vb driver attributes are configurable on a per-network basis in sysconfigtab; values must match exactly on every node that participates in the vb network: Specifies the well-known VMEbus address of the box manager, to which the box manager maps 256 KB of global VMEbus data. This address and its associated 256 KB size must fit within the adapter's configured inbound VMEbus address space. The default is 0xBC0000. Be careful when modifying this value, as it must match on every node in the vb network for communication to occur.
Note
The VB_Box_Mgr_WK_Addr default of 0xBC0000 differs from the default used in previous vb driver versions, 0xA40000. The new default places the vb box manager well-known address near the top of what is assumed to be a 2 MB A24 or A32 window: 0xC00000 (window top) minus 0x040000 (256 KB size) equals 0xBC0000. This reduces fragmentation within the window and minimizes potential conflict with other VMEbus drivers on the same node allocating memory in the same window.
UNIVERSE II Restriction
The VB_Box_Mgr_WK_Addr default of 0xBC0000 does not fit into the UNIVERSE II adapter's default special A24/A16 outbound window, due to the allocation of the A24/A16 window's top 64 KB for A16 space. UNIVERSE II vb nodes should either adjust the box manager well-known address down by 64 KB (x10000) to 0xBB0000 to allow use of the A24/A16 window, or use an outbound PCI-to-VME 64 KB window to map the 0xBC0000 default. Note that doing the latter can boost performance by allowing use of BLTs, at the cost of the added PCI resources used to map the window. Specifies address modifiers for the box manager's well-known VMEbus address. You must specify the numerical equivalent of the desired set of address modifier (AM_) flags, among the following: AM_A24 (0x1), AM_SUPER (0x2), and AM_DATA (0x4).
You can map the box manager's global data to the VMEbus in either the A24 or A32 address space (AM_A24 set or clear), either in supervisory mode or user mode (AM_SUPER set or clear), and either in data or program space (AM_DATA set or clear). The default is AM_A24|AM_SUPER|AM_DATA, which equals 0x7. Be careful when modifying this value, as it must match on every node in the vb network. If you modify this value, make sure the address is on a page boundary (0x2000 bytes). Specifies the maximum transmit unit (mtu) size. Do not modify this value; it is not currently configurable.
 

Modifying vba_vipvic Adapter Attributes

On each node in a vb network, you must modify VMEbus adapter attributes in /etc/sysconfigtab to configure unique system VMEbus windows for client communication and mailbox interrupts. If the node is VIP/VIC-based, you add or modify values for vba_vipvic kernel subsystem attributes such as A32_Base, A32_Size, A24_Base, A24_Size, and A16_Base. These attributes are described in the vme_manual_setup(7) reference page.

Note

You should not directly edit /etc/sysconfigtab. Instead you should use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. Compaq recommends that you maintain private sysconfigtab file fragments for vba_vipvic attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) vba_vipvic attribute values. The Examples section illustrates this approach.

Each system participating in the vb network must map its client communication queues to either A24 or A32 space in a unique manner. Thus, there must be at least enough system VMEbus window space to accommodate the size devoted to the communication queues. In addition, the system VMEbus window of the box manager node must encompass the well-known address (default of 0xBC0000).

Although the address modifiers of the box manager well-known address and of the client communication queues are the same by default (A24/Supervisor/Data), they need not be the same. If they are not the same, configure the box manager node so that its system windows accommodate both sets of data. If they are the same, configure the box manager node so that the chosen system VMEbus window accommodates both sets of data, starting at the well-known address, for a size equal to the size of the communication queues.

For interrupting, the A16 system VMEbus window base address must also be unique for all nodes in the backplane, but the size is always 0x100.

The VMEbus address space parameters you can modify in /etc/sysconfigtab, and their defaults, are listed below: Parameter Default Meaning ------------------------------------------------------------------- A32_Base 0x08000000 A32 inbound DMA window base address

A32_Size 0x8000000 A32 window size (128 MB)

A24_Base 0x00C00000 A24 inbound DMA window base address

A24_Size 0x400000 A24 window size (4 MB)

A16_Base 0x00000100 A16 interprocessor communication
                                base address (size is always 0x100) See the Examples section for examples of how to modify /etc/sysconfigtab for VIP/VIC-based nodes in a vb network.

Note

The size of the system VMEbus window for a node should be larger than what the vb driver needs. If the vb driver uses the entire system VMEbus window, there will be no space in the VMEbus window left for other VMEbus devices on the system to use.

A system manager must carefully configure all nodes on the backplane to have large enough system VMEbus windows to accommodate the needs of each, but not so much that there is little room left for other nodes. The system manager should make a roadmap of each system's VMEbus device addresses and sizes and fit the vb needs around the needs of the other devices because the vb characteristics are user configurable.  

Modifying vba_univ Adapter Attributes

On each node in a vb network, you must modify VMEbus adapter attributes in /etc/sysconfigtab to configure unique system VMEbus windows for client communication and mailbox interrupts. If the node is UNIVERSE-II-based, you add or modify values for vba_univ kernel subsystem attributes that configure VMEbus windows. These attributes are described in the vme_univ_manual_setup(7) reference page.

Note

You should not directly edit /etc/sysconfigtab. Instead you should use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. Compaq recommends that you maintain private sysconfigtab file fragments for vba_univ attributes and use sysconfigdb switches to add (-a -f), delete (-d), or merge (-m -f) vba_univ attribute values. The Examples section illustrates this approach.

Each system participating in the vb network must map its client communication queues to either A24 or A32 space in a unique manner. Thus, there must be at least enough system VMEbus window space to accommodate the size devoted to the communication queues. In addition, the system VMEbus window of the box manager node must encompass the well-known address (default of 0xBC0000).

Although the address modifiers of the box manager well-known address and of the client communication queues are the same by default (A24/Supervisor/Data), they need not be the same. If they are not the same, configure the box manager node so that its system windows accommodate both sets of data. If they are the same, configure the box manager node so that the chosen system VMEbus window accommodates both sets of data, starting at the well-known address, for a size equal to the size of the communication queues.

For interrupting, you must map the node's VMEbus adapter CSRs, including mailbox-interrupt CSRs, to a VMEbus systems window. On UNIVERSE-II-based nodes, extra work is required to also map the VME adapter CSRs (including mailbox interrupt CSRs) of each vb partner node. On UNIVERSE-II-based nodes, VME device CSRs are not constrained to A16/Supervisor/Data space and potentially could vary widely in address space and characteristics from node to node. For mapping purposes, you should organize the VMEbus device CSRs for all nodes in the vb network into a carefully architected region of VMEbus space, such that each UNIVERSE-II-based node can map them using a dedicated window with consistent VMEbus attributes. You then modify vba_univ adapter attributes on each UNIVERSE II node to map partner-node CSRs with a dedicated window.

Note

The size of the system VMEbus window for a node should be larger than what the vb driver needs. If the vb driver uses the entire system VMEbus window, there will be no space in the VMEbus window left for other VMEbus devices on the system to use.

A system manager must carefully configure all nodes on the backplane to have large enough system VMEbus windows to accommodate the needs of each, but not so much that there is little room left for other nodes. The system manager should make a roadmap of each system's VMEbus device addresses and sizes and fit the vb needs around the needs of the other devices because the vb characteristics are user configurable.  

EXAMPLES

The following steps show the easiest way to configure two VIP/VIC nodes to run in the backplane network: Node 0 and Node 1.

For both nodes, default values in /etc/sysconfigtab are used (for example, interrupt mode versus polling), except for the A24 base address and size, the A16 base address, the startup state, the node's Ethernet hardware address, and the client queues offset from the base of the node's A24 system VMEbus window.

Configure the box manager node first. Make sure that it is either the VMEbus system controller node or that the system controller node is already up.

To configure Node 0, perform the following steps: On Node 0, create a sysconfigtab file fragment in a private directory; for example, /mypath/vipvic_sysconfigtab. Insert the label vba_vipvic: at the beginning of the file. After the label, you construct an indented list of the vba_vipvic attributes you wish to modify and their values.

This example assumes /etc/sysconfigtab contains no previous vba_vipvic entry. If such an entry exists, you can either remove the old entry (sysconfigdb -d) before adding the new, or merge the new attributes in with the old (sysconfigdb -m -f). You may need to factor the earlier vba_vipvic attribute values into your new modifications. Change the A24 base address (vba_vipvic parameter A24_Base) from the default of 0xC00000 to something that encompasses the box manager data well-known address of 0xBC0000. For example, set the A24 base address to 0xA00000, and change the A24 size (parameter A24_Size) to 2 MB (value 0x200000), which brings the window to just below the default window address of 0xC00000. The box manager node now has an A24 window of 0xA00000 to 0xBFFFFF. Change the A16 base address (parameter A16_Base) to something other than the default of 0x100; for example, 0x000. The /mypath/vipvic_sysconfigtab file fragment now contains the following text: vba_vipvic:
        A24_Base = 0x00A00000
        A24_Size = 0x200000
        A16_Base = 0x00000000
Close the file, then add its contents to /etc/sysconfigtab by issuing the following command: sysconfigdb -a -f /mypath/vipvic_sysconfigtab vba_vipvic Create a sysconfigtab file fragment for vb attributes; for example, /mypath/vb_sysconfigtab. (If you want to use the default vb: entry provided by /etc/sysconfigtab as a starting point, you can copy the existing entry into the file fragment using the command sysconfigdb -l vb > /mypath/vb_sysconfigtab.)
Insert the label vb: at the beginning of the file, if it is not already present. After the label, construct an indented list of the vb attributes you wish to modify and their values. Change the VB startup state (vb parameter VB_Startup_State) from 0 (off) to 1 (on). Specify the VB node's Ethernet hardware address (vb parameter VB_Netid). For example, if the node's Ethernet address is 08-00-26-E2-48-47, you would specify that address as an unquoted ASCII string. Modify the client-communication queues offset, VB_Client_Vme_Window_Offset, to map client queues at the top of the A24 window, as previously configured with the vba_vipvic attributes A24_Base and A24_Size. Doing so reduces window fragmentation and minimizes potential conflicts with the memory needs of other VMEbus drivers. Specify the value 0x1C0000, which equals the A24 window size (0x200000) minus the 256 KB needed for client queues (0x040000). The /mypath/vb_sysconfigtab file fragment now contains the following text: vb:
   VB_Startup_State = 1
   VB_Netid = 08-00-26-e2-48-47
   VB_Client_Vme_Window_Offset = 0x1C0000
Close the file, then merge its contents into /etc/sysconfigtab by issuing the following sysconfigdb command: sysconfigdb -m -f /mypath/vb_sysconfigtab vb Reboot the vb box manager node. During the boot, the vb driver becomes available and prints VB: messages on the console, including the following message: VB: This is the box manager node

When you configure Node 1, do not modify any VMEbus A24 or A16 window attributes in /etc/sysconfigtab, except for the A24 client-communication queues offset. For A24_Base, A24_Size, and A16_Base, use the defaults, which do not overlap with the values reconfigured for the box manager node. This will produce the following setup for the two nodes:
                    Client
                    queues A24
        A24 base    address     A24 end          A16 base --------------------------------------------------------------- Node 0: 0xA00000 0xBC0000 0xBFFFFF (2 MB) 0x000 Node 1: 0xC00000 0xFC0000 0xFFFFFF (4 MB) 0x100 To configure Node 1, perform the following steps: Create a vb_sysconfigtab file fragment, corresponding to Node 0's, for Node 1, changing the VB startup state (vb parameter VB_Startup_State) from 0 (off) to 1 (on). Specify the VB node's Ethernet hardware address (vb parameter VB_Netid). For example, if the node's Ethernet address is 08-00-26-E2-24-50, you would specify that address as an unquoted ASCII string. Modify the client-communication queues offset, VB_Client_Vme_Window_Offset, to map client queues at the top of the A24 window, based on Node 1's A24 window size. Specify the value 0x3C0000, which equals the default A24 window size (0x400000) minus the 256 KB needed for client queues (0x040000). The /mypath/vb_sysconfigtab file fragment for Node 1 now contains the following text: vb:
   VB_Startup_State = 1
   VB_Netid = 08-00-26-e2-24-50
   VB_Client_Vme_Window_Offset = 0x3C0000

Close the file, then merge its contents into /etc/sysconfigtab by issuing the following sysconfigdb command: sysconfigdb -m -f /mypath/vb_sysconfigtab vb Reboot Node 1. You should see VB: messages printed on the console, including the following message: VB: Box mgr address space is not configured for this system,
    thus this node is not the box manager node (OK).  Be sure
    that there is a box manager in the network.

Note

Because Node 1 is using the system defaults for the VMEbus A24 window, you must make sure that if you bring up an additional node (Node 2), you modify the addresses such that the defaults are not used. Even if Node 2 does not turn on the backplane driver at all, its inbound window overlaps with Node 1. Accesses to the window will cause error messages to be printed to the screen of Node 2 because Node 2 is getting inbound VMEbus accesses from other nodes on addresses to which it has not mapped inbound.

In summary, you should always reconfigure the VMEbus addresses to be unique, no matter how you plan to use the VMEbus.  

Related ioctl Commands

The host's Internet address is specified at boot time with an SIOCSIFADDR ioctl. The vb interface employs the address resolution protocol described in arp(7) to map dynamically between Internet and Ethernet addresses on the local network.

The SIOCRPHYSADDR ioctl can be used to read the physical address of the VME backplane node. The SIOCSPHYSADDR ioctl can not be used to change the physical address of the VME backplane node. The VME backplane network does not support DECnet.

The SIOCADDMULTI and SIOCDELMULTI ioctls can be used to add or delete multicast addresses. The VME backplane driver recognizes a maximum of 64 multicast addresses.

The SIOCRDCTRS and SIOCRDZCTRS ioctls can be used to read or "read and clear" the Ethernet driver counters. The argument to these two ioctls is a pointer to a counter structure, ctrreq, found in <net/if.h>.

The SIOCENABLBACK and SIOCDISABLBACK ioctls can be used to enable and disable the interface loopback mode respectively.

To obtain the physical address of the adapter, use the SIOCRPHYSADDR ioctl as in the following program example: #include <stdio.h> /* standard I/O */ #include <errno.h> /* error numbers */ #include <sys/socket.h> /* socket definitions */ #include <sys/ioctl.h> /* ioctls */ #include <net/if.h> /* generic interface structures */

main() {
  int s,i;
  static   struct  ifdevea  devea;
  /* Get a socket */
  s = socket(AF_INET,SOCK_DGRAM,0);
  if (s < 0) {
     perror("socket");
     exit(1);
  }
  strcpy(devea.ifr_name,"vb0");
  if (ioctl(s,SIOCRPHYSADDR,&devea) < 0) {
     perror(&devea.ifr_name[0]);
     exit(1);
  }
  printf("Address is ");
  for (i = 0; i < 6; i++)
     printf("%X ", devea.default_pa[i] & 0xff);
  printf("\n");
  close(s); }  

Diagnostic Messages

The following diagnostic messages contain relevant information provided by the VME backplane driver, and are not errors:

VB: VME Backplane Driver The backplane driver is not configured to run. Reconfigure the VB_Startup_State attribute to 1 in the vb: backplane driver subsystem in sysconfigtab. Driver exiting.... The VME backplane driver is not configured on this system. This is the default state of the VME driver, since it must be configured, by setting VB_Startup_State to 1, in order to run. This message is not an error.

VB: VME Backplane Driver Mailbox interrupts are configured to use A24 space AND A16 space, which is illegal. Defaulting to A16 SUPER DATA space for mailbox interrupts. The vb driver attributes specified in /etc/sysconfigtab use an illegal combination of address modifiers for the VMEbus window that maps mailbox interrupts. The driver has reverted to a default set of address modifiers: A16 address space, supervisory mode, and data space. This node's VME address space contains the user-configured address for the box manager node as specified in the sysconfigtab file. Therefore, this is the box manager node. One and only one node in a backplane network should have this message appear at startup. This message will appear on a node that has succesfully entered the backplane network. This message will appear when a node in the VME backplane network is shutdown. This is a normal diagnostic message.  

ERRORS

The following error messages may appear at system startup: The backplane driver has been configured to be turned on, but the Ethernet address in the file sysconfigtab has not been changed to reflect the Ethernet hardware address of the node. This information must be supplied in order for the node to be entered in the VME Backplane network. Another device is mapped to the address specified as the box manager well known address in the sysconfigtab file. Be sure to reconfigure the box manager address such that it does not overlap another devices's CSR address range.

VB: VME Backplane Driver Doorbell interrupts are configured to use A16 space, which is not the case on this system. Reconfigure the VB_Mailbox_Addr_Type attribute in sysconfigtab to use the correct address space according to this system's setup. Driver exiting....

The following error messages may appear after system startup: These messages indicate that the vb driver was unable to allocate memory for internal data structures. The vb driver was unable to get VME slave window mapping information. These VME mapping errors are generally caused by misconfigured systems on the backplane network. The vb driver was unable to initialize the network interface. Too many multicast requests have been made.  

RELATED INFORMATION

Interfaces: vme_manual_setup(7), vme_univ_manual_setup(7), sysconfigdb(8)

Network Administration guide delim off


 

Index

NAME
SYNOPSIS
DESCRIPTION
vb Network Overview
VMEbus Addresses Used for Client Communication
VMEbus Addresses Used for Interrupting
Box Manager Node
Network Participation
Configuring vb Network Nodes
Modifying vb Driver Attributes
Modifying Per-Node vb Attributes
Modifying Per-Network vb Attributes
Modifying vba_vipvic Adapter Attributes
Modifying vba_univ Adapter Attributes
EXAMPLES
Related ioctl Commands
Diagnostic Messages
ERRORS
RELATED INFORMATION

This document was created by man2html, using the manual pages.
Time: 02:40:19 GMT, October 02, 2010