 |
Index for Section 7 |
|
 |
Alphabetical listing for V |
|
vb(7)
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:
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. 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.
3. Reboot the vb node. You must always reboot after modifying driver or
adapter subsystem attributes.
4. 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:
Module_Config_Name
Specifies the driver name as an unquoted ASCII string. The default
value is vb.
VB_Startup_State
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.
VB_Client_Addr_Type
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).
VB_Client_Vme_Window_Size
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.
VB_Interrupt_Interface
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.
VB_Liveness_Timeout
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.
VB_Mailbox_Addr_Type (UNIVERSE II only)
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.
VB_Mailbox_Offset
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:
Module switch 0
A16 offset 0x21, VBA_Option vector 0x1140
Module switch 1 (default)
A16 offset 0x23, VBA_Option vector 0x1150
Module switch 2
A16 offset 0x25, VBA_Option vector 0x1160
Module switch 3
A16 offset 0x27, VBA_Option vector 0x1170
For UNIVERSE-II-based Alpha VME systems, the offset and vector values
are:
Module switch 0
Offset 0x348, VBA_Option vector 0x1140
Module switch 1 (default)
Offset 0x34C, VBA_Option vector 0x1150
Module switch 2
Offset 0x350, VBA_Option vector 0x1160
Module switch 3
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.
VB_Maxnodes
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.
VB_Client_Vme_Window_Offset
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).
VB_Netid
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
VB_Give_Up
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).
VB_Probe_Period
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.
VB_Census_Change
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.
VB_Developer_Debug
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:
VB_Box_Mgr_WK_Addr
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.
VB_Box_Mgr_WK_Addr_Type
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).
VB_Maxmtu
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:
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. 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.
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.)
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.
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. 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).
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 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:
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 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.
VB: This is the box manager node
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.
VB: network started
This message will appear on a node that has succesfully entered the
backplane network.
VB: shutdown
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:
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 VME
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 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:
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 get VME 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 VME 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.
RELATED INFORMATION
Interfaces: vme_manual_setup(7), vme_univ_manual_setup(7), sysconfigdb(8)
Network Administration guide