3    Configuring a VMEbus Backplane (vb) Network

This chapter explains how to set up a VMEbus backplane-based network in which Alpha VME single-board computers (SBCs) operate as Ethernet nodes.

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

Both the 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 AXPvme and Alpha VME SBCs and on Alpha VME 2100 systems.

The VMEbus 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 chapter addresses the following topics relating to the use of the vb interface on Alpha VME systems:

3.1    VMEbus Backplane (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, you must configure the vb driver to be turned on and you must specify the Ethernet hardware address of the target system. 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:

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

3.1.1    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 Section 2.2 (VIP/VIC-based Alpha VME systems) or Section 2.3 (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. You specify the following information regarding the queues for each backplane node:

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 Section 3.2.

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 Section 2.2 (VIP/VIC-based Alpha VME systems) or Section 2.3 (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

3.1.2    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 Section 2.2 (VIP/VIC-based Alpha VME systems) or Section 2.3 (UNIVERSE II-based Alpha VME systems) for more information on modifying the base address and size of VMEbus windows.

Four module switches are 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:

Additionally, you must verify that the VB_Interrupt_Interface attribute 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 Section 3.3.

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, you can configure the module switch used to interrupt a particular node individually on a per-node basis (not necessarily uniquely).

3.1.3    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 Section 3.3.2.)

The network administrator 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). No other switch or value specification is needed 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:

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 and before 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.

3.1.4    Network Participation

Nodes in a backplane network communicate via memory mapped onto the VMEbus. If this memory becomes unmapped, or if 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 maintain liveness with the rest of the network.

To maintain liveness, when 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.

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

If 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.

3.2    Configuring vb Network Nodes

To configure a vb network node, you perform the following steps:

  1. 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.

  2. As needed, modify the /etc/sysconfigtab file to add or modify values for vb driver and VMEbus adapter attributes. You must turn on the vb driver and you must specify the node's Ethernet hardware address. Also, as part of modifying VMEbus adapter attributes, you 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

    Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended 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 in Section 3.6 and Section 3.7 illustrate this approach.

  3. Reboot the vb node. You must always reboot after modifying driver or adapter subsystem attributes.

  4. When 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 Network Administration.

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 displays 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.

3.3    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 and the system's VMEbus adapter. Table 3-1 lists the default values for vb driver parameters.

Table 3-1:  VMEbus Backplane (vb) Network Driver Defaults

Parameter Default Meaning
Per-node vb attributes:
Module_Config_Name vb Driver name is vb
VB_Startup_State 0 Driver is off
VB_Client_Addr_Type 0x7 Client communication window address modifiers: A24 space, supervisory mode, and data access
VB_Client_Vme_Window_Size 0x40000 Size of communication queues area is 256 KB
VB_Client_Vme_Window_Offset 0x0 Map client queues at offset 0x0 from the client communication window base address
VB_Interrupt_Interface 1 Message response is interrupt driven
VB_Liveness_Timeout 10000 Remote liveness tests are 10000 milliseconds (10 seconds) apart
VB_Mailbox_Addr_Type 0xE (UNIVERSE II only) Client mailbox-interrupt window address modifiers: A16 space, supervisory mode, and data access
VB_Mailbox_Offset 0x23 or 0x34C Module switch 1 is selected by offset 0x23 (VIP/VIC) or 0x34C (UNIVERSE II)
VB_Maxnodes 10 Maximum nodes allowed in the vb network is 10
VB_Netid -- Ethernet hardware address of the node must be supplied for the network to start up
VB_Give_Up 1 Time out if the VB_Probe_Period is exceeded
VB_Probe_Period 1 Number of minutes to probe the box manager's well-known address before exiting driver is 1
VB_Census_Change 0 Do not display node mapping state changes
VB_Transfer_Type 0 Use only programmed I/O (PIO) transfers over the bus
VB_DMA_Threshold 256 If VB_Transfer_Type equals 1, transfers equal to or exceeding 256 bytes will use direct memory access (DMA) rather than PIO
VB_DMA_Dwidth 0 If VB_Transfer_Type equals 1, the D16 data width will be used for DMA transfers over the bus
Per-network vb attributes:
VB_Box_Mgr_WK_Addr 0xBC0000 Box manager's well-known VMEbus address is 0xBC0000 (must match on every node)
VB_Box_Mgr_WK_Addr_Type 0x7 Box manager global data address modifiers: A24 space, supervisory mode, and data access (must match on every node)
VB_Maxmtu 1500 Maximum transfer unit (mtu) size is 1500 bytes (configurable on the box manager node only)

Table 2-1 and Table 2-4 list the parameter defaults for the VIP/VIC and UNIVERSE II VMEbus adapters, respectively.

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

Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended 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 in Section 3.6 and Section 3.7 illustrate 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 Section 3.4 and Section 3.5, respectively.

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

3.3.1    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:

3.3.2    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:

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

Section 3.7, UNIVERSE II Two-Node Network Example, uses the value 0xFC0000 for VB_Box_Mgr_WK_Addr. This suggested value 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 0xFB0000 to allow use of the A24/A16 window, or instead use an outbound PCI-to-VME 256 KB (or larger) window to map the 0xFC0000 value. Note that doing the latter can boost performance by allowing use of block transfers (BLTs) and a wider data path, at the cost of the added PCI resources used to map the window.

3.4    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. Section 2.2 describes these attributes.

Note

Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended 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 example in Section 3.6 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. Allocated system VMEbus window space must be sufficient 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.

Table 3-2 lists the VMEbus address space parameters you can modify in /etc/sysconfigtab and their defaults.

Table 3-2:  VIP/VIC VMEbus Address Space Defaults

Parameter Default Meaning
A32_Base 0x08000000 A32 inbound DMA window base address
A32_Size 0x08000000 A32 window size (128 MB)
A24_Base 0x00C00000 A24 inbound DMA window base address
A24_Size 0x00400000 A24 window size (4 MB)
A16_Base 0x00000100 A16 interprocessor communication base address (size is always 0x100)

See the VIP/VIC Two-Node Network Example in Section 3.6 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 exceed what the vb driver needs. If the vb driver uses the entire system VMEbus window, no window space remains for other VMEbus devices on the system to use.

A system administrator 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 administrator 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.

3.5    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. Section 2.3 describes these attributes.

Note

Do not directly edit /etc/sysconfigtab. Instead, use the sysconfigdb facility, as described in the sysconfigdb(8) reference page. It is recommended 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 example in Section 3.7 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. Allocated system VMEbus window space must be sufficient 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 system 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, VMEbus 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 designed 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.

See the UNIVERSE II Two-Node Network Example in Section 3.7 for examples of how to modify /etc/sysconfigtab for UNIVERSE II-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, no window space remains for other VMEbus devices on the system to use.

A system administrator 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 administrator 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.

3.6    VIP/VIC Two-Node Network Example

The following steps show an easy way to configure two VIP/VIC nodes to run in a VMEbus backplane (vb) network: Node 0 and Node 1.

For each node, most of the VIP/VIC and vb default values listed in Table 2-1 and Table 3-1 are retained. In particular, the well-known VMEbus address of the box manager remains at its 0xBC0000 default. You should examine the attribute defaults listed in Table 2-1 and Table 3-1, invoke sysconfigdb -l vba_vipvic and sysconfigdb -l vb on each node to uncover any previous changes to those defaults, and decide which attribute values require further modification.

In this example, VIP/VIC and vb parameters that must be modified include the following:

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:

  1. 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. In the next few steps, you will construct an indented list, immediately following the label, 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.

  2. 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.

  3. Change the A16 base address (parameter A16_Base) to something other than the default of 0x100; for example, 0x000.

  4. 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
 

  5. 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.)

    In the next few steps, you will construct an indented list, immediately following the label vb:, of the vb attributes you wish to modify and their values.

  6. Change the VB startup state (vb parameter VB_Startup_State) from 0 (off) to 1 (on).

  7. 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.

  8. 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. Mapping at the top of a window 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).

  9. 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

  10. 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 Node 0 and Node 1:

A24 Base Client Queues A24 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:

  1. 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).

  2. 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.

  3. 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).

  4. 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

  5. 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, its inbound window overlaps with Node 1. Accesses to the window could cause a system crash or could cause error messages to be printed to the screen of Node 2, because Node 2 is receiving 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.

3.7    UNIVERSE II Two-Node Network Example

The following steps show an easy way to configure two UNIVERSE II nodes to run in a VMEbus backplane (vb) network: Node 0, which is the box manager and the system controller, and Node 1.

For each node, most of the UNIVERSE II and vb defaults listed in Table 2-4 and Table 3-1 are retained, including most inbound and outbound window characteristics. You should examine the attribute defaults listed in Table 2-4 and Table 3-1, invoke sysconfigdb -l vba_univ and sysconfigdb -l vb on each node to uncover any previous changes to those defaults, and decide which attribute values require further modification.

In this example, UNIVERSE II and vb parameters that must be modified include the following:

Configure the box manager node first. This example assumes that the box manager node is the VMEbus system controller node.

To configure Node 0, perform the following steps:

  1. On Node 0, create a sysconfigtab file fragment in a private directory; for example, /mypath/univ_sysconfigtab. Insert the label vba_univ: at the beginning of the file. In the next few steps, you will construct an indented list, immediately following the label, of the vba_univ attributes you wish to modify and their values.

    This example assumes /etc/sysconfigtab contains no previous vba_univ 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_univ attribute values into your new modifications.

  2. Verify that inbound VME-to-PCI (VMEbus slave) windows 0 and 1 are configured at their default VMEbus base addresses, 0x00C00000 and 0x08000000. Node 1's corresponding windows will be relocated to different VMEbus addresses (0x00800000 and 0x10000000). For both Node 0 and Node 1, all other attributes of these windows are left at their defaults.

    In step 12, you will modify the box manager's well-known VMEbus address to map box manager data at the top of VME-to-PCI window 0.

  3. Relocate outbound PCI-to-VME (PCI slave) windows 0 through 3 to VMEbus base address 0x10000000, leaving all other window attributes at their defaults. You do this by entering the value 0x10000000 for the vba_univ parameters VME_Wnd0_VME_Address, VME_Wnd1_VME_Address, VME_Wnd2_VME_Address, and VME_Wnd3_VME_Address.

  4. Configure the outbound PCI-to-VME windows 4 and 5 to encompass all of A24 address space for user-data and supervisory-data accesses to other nodes in the system. Because the windows are set up by default for user data and supervisory data, respectively, you only need to specify a new base address, 0x00000000, and a new size, 16 MB, for each. Set VME_Wnd4_VME_Address and VME_Wnd5_VME_Address to the value 0x00000000, and set VME_Wnd4_Size and VME_Wnd5_Size to the value 0x01000000. In addition to providing a complete view of A24 address space for supervisory-data and user-data access, this mapping allows use of MBLTs and data widths up to D64.

  5. Configure the outbound PCI-to-VME window 6 as a mailbox-interrupt window. To do this, you design a region of VMEbus space that encompasses the UNIVERSE II adapter CSRs (4 KB per node), including mailbox-interrupt CSRs, for both Node 0 and the partner node, Node 1.

    In this case, the base address of the mailbox-interrupt window will be 0xFFFF0000, its size will be 64 KB, and Node 0 and Node 1 will map their adapter CSRs at 0xFFFF0000 and 0xFFFF1000, respectively. (If location monitors were in use, you could place adapter CSRs at 0xFFFF0000 and 0xFFFF2000, and location monitors at 0xFFFF1000.)

    Set VME_Wnd6_Ena to the value 1, set VME_Wnd6_VME_Address to the value 0xFFFF0000, and set the window size (parameter VME_Wnd6_Size) to 64 KB (value 0x00010000).

    Additionally, you must modify the mailbox-interrupt window's attributes to be compatible with the address modifier attributes of the node's CSR window, which will be mapped in the next step. Set the VME_Wnd6_AM_Space parameter to specify A32 space (value 2) and set the VME_Wnd6_AM_Usr_Sprvsr parameter to specify supervisory mode (value 2). Data access remains selected by default.

  6. Configure the node's CSR window in accordance with the design of the mailbox-interrupt window configured in the previous step. For node 0, retain all CSR window defaults, including the VMEbus base address of 0xFFFF0000, A32 space, supervisory mode, and both program and data access.

  7. The /mypath/univ_sysconfigtab file fragment now contains the following text: 

    vba_univ:
        PCI_Wnd0_VME_Address = 0x00C00000
        PCI_Wnd1_VME_Address = 0x08000000
        VME_Wnd0_VME_Address = 0x10000000
        VME_Wnd1_VME_Address = 0x10000000
        VME_Wnd2_VME_Address = 0x10000000
        VME_Wnd3_VME_Address = 0x10000000
        VME_Wnd4_VME_Address = 0x00000000
        VME_Wnd4_Size = 0x01000000
        VME_Wnd5_VME_Address = 0x00000000
        VME_Wnd5_Size = 0x01000000
        VME_Wnd6_Ena = 1
        VME_Wnd6_VME_Address = 0xFFFF0000
        VME_Wnd6_Size = 0x00010000
        VME_Wnd6_AM_Space = 2
        VME_Wnd6_AM_Usr_Sprvsr = 2

    Close the file, then add its contents to /etc/sysconfigtab by issuing the following command: 

    sysconfigdb -a -f /mypath/univ_sysconfigtab  vba_univ
 

  8. 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.)

    In the next few steps, you will construct an indented list, immediately following the label vb:, of the vb attributes you wish to modify and their values.

  9. Change the VB startup state (vb parameter VB_Startup_State) from 0 (off) to 1 (on).

  10. 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.

  11. Modify the client communication queues offset, VB_Client_Vme_Window_Offset, to map client queues at the top of a 4 MB window. Mapping at the top of a window reduces window fragmentation and minimizes potential conflicts with the memory needs of other VMEbus drivers. Specify the value 0x003C0000, which equals the window size (0x00400000) minus the 256 KB needed for client queues (0x00040000).

  12. Modify the box manager well-known address, VB_Box_Mgr_WK_Addr, to map box manager data at the top of VME-to-PCI window 0. In step 2, VME-to-PCI window 0 was configured to encompass the box manager well-known address that is shared among all nodes. Specify the value 0x00FC0000, which equals the VME-to-PCI window 0 base address (0x00C00000), plus its size (0x00400000), minus the 256 KB needed for the box manager's VMEbus global data (0x00040000).

  13. Mailboxes reside within the CSR window. You must modify the vb mailbox-interrupt address type parameter, VB_Mailbox_Addr_Type, to match the address modifier attributes associated with the CSR window you configured. Specify A32 address space, supervisory mode, and data access (value 0x6).

  14. 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 = 0x003C0000
   VB_Box_Mgr_WK_Addr = 0x00FC0000
   VB_Mailbox_Addr_Type = 0x6

    Close the file, then merge its contents into /etc/sysconfigtab by issuing the following sysconfigdb command: 

    sysconfigdb -m -f /mypath/vb_sysconfigtab  vb

  15. 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, you should specify UNIVERSE II and vb parameter values that you have carefully selected to fit well with the values specified for Node 0, and try to anticipate the needs of any additional nodes that might be added to the vb network later. For example, the values specified in this example produce the following setup for Node 0 and Node 1:

Parameter Node 0 Node 1
VME-to-PCI (inbound) window 0 address 0x00C00000 0x00800000
VME-to-PCI (inbound) window 1 address 0x08000000 0x10000000
PCI-to-VME (outbound) window 0 address 0x10000000 0x08000000
PCI-to-VME (outbound) window 1 address 0x10000000 0x08000000
PCI-to-VME (outbound) window 2 address 0x10000000 0x08000000
PCI-to-VME (outbound) window 3 address 0x10000000 0x08000000
PCI-to-VME (outbound) window 4 address 0x00000000 0x00000000
PCI-to-VME window 4 size 0x01000000 0x01000000
PCI-to-VME (outbound) window 5 address 0x00000000 0x00000000
PCI-to-VME window 5 size 0x01000000 0x01000000
PCI-to-VME (mailbox-interrupt) window 6 address 0xFFFF0000 0xFFFF0000
PCI-to-VME window 6 size 0x00010000 0x00010000
PCI-to-VME window 6 address modifiers 2 (A32), 2 (supervisory), 1 (data) 2 (A32), 2 (supervisory), 1 (data)
CSR window address 0xFFFF0000 0xFFFF1000
Box manager well-known address 0x00FC0000 0x00FC0000
Client queues offset (assumes a 4 MB window) 0x003C0000 0x003C0000

To configure Node 1, perform the following steps:

  1. On Node 1, create a sysconfigtab file fragment corresponding to Node 0's in a private directory; for example, /mypath/univ_sysconfigtab. Insert the label vba_univ: at the beginning of the file. In the next few steps, you will construct an indented list, immediately following the label, of the vba_univ attributes you wish to modify and their values.

  2. Relocate inbound VME-to-PCI (VMEbus slave) windows 0 and 1 to VMEbus locations that differ from those used by Node 0's corresponding windows, leaving all other window attributes at their defaults. Node 0 used the default VMEbus base addresses 0x00C00000 and 0x08000000 for its VME-to-PCI windows 0 and 1. For Node 1, enter the values 0x00800000 and 0x10000000 for the vba_univ parameters PCI_Wnd0_VME_Address and PCI_Wnd1_VME_Address.

  3. Relocate outbound PCI-to-VME (PCI slave) windows 0 through 3 to VMEbus base address 0x08000000, leaving all other window attributes at their defaults. Enter the value 0x08000000 for the parameters VME_Wnd0_VME_Address, VME_Wnd1_VME_Address, VME_Wnd2_VME_Address, and VME_Wnd3_VME_Address.

  4. As with Node 0, configure Node 1's outbound PCI-to-VME windows 4 and 5 to encompass all of A24 address space for user-data and supervisory-data accesses to other nodes in the system. Because the windows are set up by default for user data and supervisory data, respectively, you only need to specify a new base address, 0x00000000, and a new size, 16 MB, for each. Set VME_Wnd4_VME_Address and VME_Wnd5_VME_Address to the value 0x00000000, and set VME_Wnd4_Size and VME_Wnd5_Size to the value 0x01000000. In addition to providing a complete view of A24 address space for supervisory-data and user-data access, this mapping allows use of MBLTs and data widths up to D64.

  5. Configure the outbound PCI-to-VME window 6 as a mailbox-interrupt window, adhering to the design established during Node 0 configuration. As with Node 0, the base address of the mailbox-interrupt window will be 0xFFFF0000 and its size 64 KB. Node 0 and Node 1 will map their adapter CSRs at 0xFFFF0000 and 0xFFFF1000, respectively.

    Set VME_Wnd6_Ena to the value 1, set VME_Wnd6_VME_Address to the value 0xFFFF0000, and set the window size (parameter VME_Wnd6_Size) to 64 KB (value 0x00010000). As with Node 0, you must modify the mailbox-interrupt window's attributes to be compatible with the address modifier attributes of the node's CSR window, which will be mapped in the next step. Set the VME_Wnd6_AM_Space parameter to specify A32 space (value 2) and set the VME_Wnd6_AM_Usr_Sprvsr parameter to specify supervisory mode (value 2). Data access remains selected by default.

  6. Configure the node's CSR window in accordance with the design of the mailbox-interrupt window configured in the previous step. In this case, only the VMEbus base address needs modification; set CSR_VME_Address to the value 0xFFFF1000. Retain defaults for all other CSR window attributes, including A32 space, supervisory mode, and both program and data access.

  7. The /mypath/univ_sysconfigtab file fragment now contains the following text: 

    vba_univ:
        PCI_Wnd0_VME_Address = 0x00800000
        PCI_Wnd1_VME_Address = 0x10000000
        VME_Wnd0_VME_Address = 0x08000000
        VME_Wnd1_VME_Address = 0x08000000
        VME_Wnd2_VME_Address = 0x08000000
        VME_Wnd3_VME_Address = 0x08000000
        VME_Wnd4_VME_Address = 0x00000000
        VME_Wnd4_Size = 0x01000000
        VME_Wnd5_VME_Address = 0x00000000
        VME_Wnd5_Size = 0x01000000
        VME_Wnd6_Ena = 1
        VME_Wnd6_VME_Address = 0xFFFF0000
        VME_Wnd6_Size = 0x00010000
        VME_Wnd6_AM_Space = 2
        VME_Wnd6_AM_Usr_Sprvsr = 2
        CSR_VME_Address = 0xFFFF1000

    Close the file, then add its contents to /etc/sysconfigtab by issuing the following command: 

    sysconfigdb -a -f /mypath/univ_sysconfigtab  vba_univ
 

  8. Create a sysconfigtab file fragment corresponding to Node 0's 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.)

    In the next few steps, you will construct an indented list, immediately following the label vb:, of the vb attributes you wish to modify and their values.

  9. Change the VB startup state (vb parameter VB_Startup_State) from 0 (off) to 1 (on).

  10. 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.

  11. Modify the client communication queues offset, VB_Client_Vme_Window_Offset, to map client queues at the top of a 4 MB window. Mapping at the top of a window reduces window fragmentation and minimizes potential conflicts with the memory needs of other VMEbus drivers. Specify the value 0x003C0000, which equals the window size (0x00400000) minus the 256 KB needed for client queues (0x00040000).

  12. Modify the box manager well-known address, VB_Box_Mgr_WK_Addr, to map box manager data at the top of Node 0's VME-to-PCI window 0. Node 0's VME-to-PCI window 0 was configured to encompass the box manager well-known address that is shared among all nodes. Specify the value 0x00FC0000, which equals Node 0's VME-to-PCI window 0 base address (0x00C00000), plus its size (0x00400000), minus the 256 KB needed for the box manager's VMEbus global data (0x00040000).

  13. As with Node 0, you must modify the vb mailbox-interrupt address type parameter, VB_Mailbox_Addr_Type, to match the address modifier attributes associated with the CSR window you configured. Specify A32 address space, supervisory mode, and data access (value 0x6).

  14. The /mypath/vb_sysconfigtab file fragment now contains the following text: 

    vb:
   VB_Startup_State = 1
   VB_Netid = 08-00-26-e2-24-50
   VB_Client_Vme_Window_Offset = 0x003C0000
   VB_Box_Mgr_WK_Addr = 0x00FC0000
   VB_Mailbox_Addr_Type = 0x6

    Close the file, then merge its contents into /etc/sysconfigtab by issuing the following sysconfigdb command: 

    sysconfigdb -m -f /mypath/vb_sysconfigtab  vb

  15. 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.

3.8    Related ioctl Commands

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

Use the SIOCRPHYSADDR ioctl command to read the physical address of the VMEbus backplane node. The SIOCSPHYSADDR command cannot be used to change the physical address of the VMEbus backplane node. The VMEbus backplane network does not support DECnet.

Use the SIOCADDMULTI and SIOCDELMULTI ioctl commands to add or delete multicast addresses. The VMEbus backplane driver recognizes a maximum of 64 multicast addresses.

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

Use the SIOCENABLBACK and SIOCDISABLBACK ioctl commands to enable and disable the interface loopback mode.

To obtain the physical address of the adapter, use the SIOCRPHYSADDR command 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>          /* ioctl commands */
#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);
}

3.9    Diagnostic Messages

The following diagnostic messages contain relevant information provided by the VMEbus 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 VMEbus backplane driver is not configured on this system. This is the initial default state of the VMEbus driver, before you configure it to run by setting VB_Startup_State to 1. 

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. 

VB: VME Backplane Driver
VB_MAXMTU is outside the allowable range
Setting VB_MAXMTU = 1500

The value specified for the vb driver attribute VB_Maxmtu is less than 1500 or greater than 16K and has been reset to the default value, 1500. 

VB: VB_Maxmtu changed to match the Box manager's MTU n

This message is displayed during vb client registration if the vb driver attribute VB_Maxmtu on the client is not equal to VB_Maxmtu on the box manager node. The client value is reset to match the box manager value. 

VB: This is the box manager node

This node's VMEbus 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. 

VB: network started

This message will appear on a node that has successfully entered the backplane network. 

VB: shutdown

This message will appear when a node in the VMEbus backplane network is shut down. This is a normal diagnostic message.

3.10    Errors

This section lists and describes error messages displayed during and after system startup.

3.10.1    System Startup Error Messages

The following error messages may appear at system startup: 

VB: Ethernet address contains all zeroes!  DRIVER EXITING...

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 VMEbus backplane network. 

VB: Incorrect ident in box manager memory.

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 device'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....

Reconfigure mailbox interrupts as instructed.

3.10.2    Post-Startup Error Messages

The following error messages may appear after system startup: 

VB: MALLOC failure on box mgr memory
VB: MALLOC failure on l3 queues

These messages indicate that the vb driver was unable to allocate memory for internal data structures. 

VB: Error in dma_get_maps.

The vb driver was unable to obtain VMEbus slave window mapping information. 

VB: Error mapping box mgr memory inbound on the VME.
VB: Error mapping l3 queues inbound on VME.
VB: Error mapping outbound to box mgr
VB: Error mapping outbound to node %d

These VMEbus mapping errors are generally caused by misconfigured systems on the backplane network. 

vb%d: initialization error

The vb driver was unable to initialize the network interface. 

vb%d SIOCADDMULTI fail, multicast list full

Too many multicast requests have been made.