Content-type: text/html
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.
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
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.
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.
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
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).
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.
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.
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:).
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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);
}
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.
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.
Interfaces: vme_manual_setup(7), vme_univ_manual_setup(7), sysconfigdb(8)
Network Administration guide delim off