[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | atm |
|
| Moderator: | NPSS::WATERS |
|
| Created: | Mon Oct 05 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 970 |
| Total number of notes: | 3630 |
Digital UNIX 4.0b AlphaServer 400/166
ATMworks 350 Gigaswitch 2.1.1
The Digital UNIX host is configured for lan emulation via the
Gigaswitch.
If the customer the public utility netperf to send a stream
of udp data to the Digital UNIX host for 10 seconds, the
system seems to just stop responding on both the atm AND the
ethernet interface. After the 10 sec., both are back to normal.
If he does netperf for about 30 sec., it will stop responding
as above, but then lane will go down before netperf is finished
running. netperf then returns the following:
netperf: receive_response: no response received. errno 0 counter 0
At this point, the ethernet interface comes back up, but lane has
been completely hosed.
Odd that it does not happen with a TCP stream.
Below is an excerpt from /var/adm/messages.
First, can someone help me out on what
cm_sap_xmt_vc - null conn_handle
implies, and if it could have any relevance to the problem?
Second, can anyone offer any trouble-shooting advice for
tracking down why this might happen?
I had them enable flow control (+vfc) but it did not effect
the problem. I tried to reproduce this here with the public
ttcp utility with no luck.
It is at 15:23 that the 30 sec. netperf occurred.
When this happens: (which is only a few seconds after it goes down)
Feb 26 15:23:49 weeble vmunix: ATM LANE - New PPA Bound to waiting
ELAN. ELAN coming up...
The elan0 interface does not actually come up for another 10 min
(and no log messages when it does.)
Feb 26 15:19:45 weeble vmunix: Alpha boot: available memory from 0x8fa000 to
0x7ffe000
Feb 26 15:19:45 weeble vmunix: Digital UNIX V4.0B (Rev. 564); Mon Feb 24
19:11:13 AST 1997
Feb 26 15:19:45 weeble vmunix: physical memory = 128.00 megabytes.
Feb 26 15:19:46 weeble vmunix: available memory = 119.03 megabytes.
Feb 26 15:19:46 weeble vmunix: using 484 buffers containing 3.78 megabytes
of memory
Feb 26 15:19:46 weeble vmunix: AlphaServer 400 4/166 system
Feb 26 15:19:46 weeble vmunix: DECchip 21071
Feb 26 15:19:46 weeble vmunix: 82378IB (SIO) PCI/ISA Bridge
Feb 26 15:19:46 weeble vmunix: Firmware revision: 6.3
Feb 26 15:19:46 weeble vmunix: PALcode: OSF version 1.46
Feb 26 15:19:46 weeble vmunix: pci0 at nexus
Feb 26 15:19:46 weeble vmunix: psiop0 at pci0 slot 6
Feb 26 15:19:46 weeble vmunix: Loading SIOP: script 800400, reg 82400000,
data 4063c370
Feb 26 15:19:46 weeble vmunix: scsi0 at psiop0 slot 0
Feb 26 15:19:46 weeble vmunix: rz0 at scsi0 target 0 lun 0 (LID=0) (DEC
RZ28 (C) DEC 442D)
Feb 26 15:19:46 weeble vmunix: rz4 at scsi0 target 4 lun 0 (LID=1) (DEC
RRD43 (C) DEC 1084)
Feb 26 15:19:46 weeble vmunix: tz5 at scsi0 target 5 lun 0 (LID=2) (DEC
TLZ06 (C)DEC 0491)
Feb 26 15:19:46 weeble vmunix: isa0 at pci0
Feb 26 15:19:46 weeble vmunix: gpc0 at isa0
Feb 26 15:19:47 weeble vmunix: ace0 at isa0
Feb 26 15:19:47 weeble vmunix: ace1 at isa0
Feb 26 15:19:47 weeble vmunix: lp0 at isa0
Feb 26 15:19:47 weeble vmunix: fdi0 at isa0
Feb 26 15:19:47 weeble vmunix: pci1000 at pci0 slot 11
Feb 26 15:19:47 weeble vmunix: lta0: Microcode Version: 1.11, Hardware Rev:
0.04
Feb 26 15:19:47 weeble vmunix: lta0 at pci1000 slot 0
Feb 26 15:19:47 weeble vmunix: lta0: DEC DGLPB ATM Interface, hardware
addresses:
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F0
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F1
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F2
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F3
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F4
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F5
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F6
Feb 26 15:19:47 weeble vmunix: 08-00-2B-80-6D-F7
Feb 26 15:19:47 weeble vmunix: ATM Subsystem configured with 1 restart threads
Feb 26 15:19:47 weeble vmunix: ltaregister: registered unit 0 with CMM
Feb 26 15:19:47 weeble vmunix: tu0: DECchip 21040-AA: Revision: 2.3
Feb 26 15:19:47 weeble vmunix: tu0 at pci0 slot 12
Feb 26 15:19:47 weeble vmunix: tu0: DEC TULIP Ethernet Interface, hardware
address: 08-00-2B-E4-CC-2F
Feb 26 15:19:47 weeble vmunix: tu0: console mode: selecting 10BaseT (UTP)
port: half duplex
Feb 26 15:19:47 weeble vmunix: kernel console: ace0
Feb 26 15:19:47 weeble vmunix: dli: configured
Feb 26 15:19:47 weeble vmunix: ATM UNI 3.x signalling: configured
Feb 26 15:19:48 weeble vmunix: ATM IP interface: configured
Feb 26 15:19:48 weeble vmunix: vm_swap_init: warning /sbin/swapdefault swap
device not found
Feb 26 15:19:48 weeble vmunix: vm_swap_init: swap is set to lazy (over
commitment) mode
Feb 26 15:19:48 weeble vmunix: lta0: link available
Feb 26 15:19:48 weeble vmunix: ATM LAN Emulation: configured for maximum of
4 ELANs
Feb 26 15:19:48 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:19:48 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:19:48 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df00"
Feb 26 15:19:48 weeble vmunix: Destination Address: "4707900000000000a03e0010"
Feb 26 15:19:48 weeble vmunix: Call Duration: 0 seconds
Feb 26 15:19:48 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df10"
Feb 26 15:19:48 weeble vmunix: Destination Address: "4707900000000000a03e0010"
Feb 26 15:19:48 weeble vmunix: Call Duration: 0 seconds
Feb 26 15:23:45 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:23:45 weeble last message repeated 3 times
Feb 26 15:23:45 weeble vmunix: ATM LANE - SVC PPA Deleted, associated ELAN
disconnected
Feb 26 15:23:45 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:23:45 weeble last message repeated 4 times
Feb 26 15:23:45 weeble vmunix: ATM LANE: cm_sap_xmt_vc - null conn_handle
Feb 26 15:23:45 weeble vmunix: ATM LANE: cm_sap_xmt_vc - null conn_handle
Feb 26 15:23:45 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:23:45 weeble vmunix: ATM LANE: cm_sap_xmt_vc - null conn_handle
Feb 26 15:23:45 weeble vmunix: ATM LANE - SVC PPA Deleted, associated ELAN
disconnected
Feb 26 15:23:45 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802bb513940"
Feb 26 15:23:45 weeble vmunix: Destination Address:
"3999990000802bb51380802b806df10"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802bb513930"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802b806df10"
Feb 26 15:23:46 weeble vmunix: Call Duration: 240 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df10"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802bb513930"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df10"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802bb513940"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802bb513910"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802bb513920"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Call Duration: 240 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802bb513920"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802bb513910"
Feb 26 15:23:46 weeble vmunix: Call Duration: 241 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380020da6e3102"
Feb 26 15:23:46 weeble vmunix: Call Duration: 240 seconds
Feb 26 15:23:46 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b8068480"
Feb 26 15:23:46 weeble vmunix: Destination Address:
"3999990000802bb51380802b806df00"
Feb 26 15:23:46 weeble vmunix: Call Duration: 77 seconds
Feb 26 15:23:49 weeble vmunix: ATM LANE - New PPA Bound to waiting ELAN.
ELAN coming up...
Feb 26 15:23:49 weeble vmunix: ATM LANE - New PPA Bound to waiting ELAN.
ELAN coming up...
Feb 26 15:25:06 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:25:06 weeble vmunix: ATM LANE - Connection Released, cause = 16
Feb 26 15:25:06 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df70"
Feb 26 15:25:06 weeble vmunix: Destination Address: "4707900000000000a03e0010"
Feb 26 15:25:06 weeble vmunix: Call Duration: 0 seconds
Feb 26 15:25:06 weeble vmunix: VC released on interface lta0:Source Address:
"3999990000802bb51380802b806df60"
Feb 26 15:25:06 weeble vmunix: Destination Address: "4707900000000000a03e0010"
Feb 26 15:25:06 weeble vmunix: Call Duration: 0 seconds
=================
His atm.conf
print Starting ATM Network
up driver=lta0
wait state=up driver=lta0
#
# wait till address registration is complete
run /usr/sbin/atmsig up driver=lta0
#
# allow dynamic ESI time to register with switch
sleep 5
#
# Create virtual interface elan0 and configure it for IP
run atmelan create driver=lta0 name=ELAN1
run ifconfig elan0 138.73.101.51 netmask 255.255.255.0
#
# Create virtual interface elan1 and configure it for IP
run atmelan create driver=lta0 name=ELAN2
run ifconfig elan1 138.73.102.51 netmask 255.255.255.0
#
print ATM network started
[Posted by WWW Notes gateway]
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 843.1 | Some more info needed... | SMURF::GREBUS | DTN 381-1426 - Digital Unix | Thu Feb 27 1997 17:49 | 37 |
| The first-order explanation is that the adapter is losing signalling or
ILMI connectivity to the switch, which is causing all the VC's to be
torn down. The:
vmunix: ATM LANE - SVC PPA Deleted, associated ELAN disconnected
message suggests ILMI was lost, causing all the ATM address
registrations (PPA's) to be deleted, which causes all the VC's to be
released.
The vmunix: ATM LANE: cm_sap_xmt_vc - null conn_handle
message is an artifact of having LANE attempting to release some of the
VC's which are also being released by the loss of connectivity. The
message can be ignored in this case.
The more fundamental question is why is connectivity being lost. In
theory, since everything is "best effort", the UDP traffic could just
be saturating the path to the host (I don't know if the switch reserves
bandwidth for signalling and ILMI...we don't by default).
There are also some issues we have been investigating with regard to
driver live-lock, and for multiple senders to a single receiver. It's
also curious that LANE doesn't recover after the longer burst.
BTW, it's not surprising the problem doesn't occur with TCP. TCP will
back off in the face of congestion (lost cells).
Some questions:
How many senders are transmitting to the Digital UNIX system? How big
are the UDP packets? What kind of system is doing the sending? (the
receiver is a relatively slow system)
/gary
Is the Gigaswitch using V2 (DAGGL-BA) line cards?
|
| 843.2 | I've seen this under NT | WASNT::"washabaugh@went.lkg.dec.com" | Born to be Mild | Fri Feb 28 1997 14:09 | 7 |
| We've seen similiar problems in the NT problem. Part of solving
the problem requires that the driver reserve transmit buffers for
signalling/ilmi use only, and also reserving receive buffers for
signalling/ilmi use only. If you don't do this, you'll never hold
up to an onslot of UDP traffic.
doug
|
| 843.3 | | SMURF::MENNER | it's just a box of Pax.. | Fri Feb 28 1997 14:51 | 7 |
| re: .2 (Doug)
Do you do this by making the signalling/ilmi CBR VCs? Does the
Gigaswitch also do something similiar?
thx...
/ron
|
| 843.4 | Depends on the limiting resource | SMURF::GREBUS | DTN 381-1426 - Digital Unix | Fri Feb 28 1997 17:04 | 18 |
| Reserving buffers won't help in a true livelock situation. The
limiting resource is CPU time. It is all consumed servicing interrupts
(and throwing away the received data), which leaves none for processing
the queued signalling/ILMI data.
If there is some other resource being exhausted (like hardware buffer
space), then making the VC's CBR might help on the transmit side. That
would reserve some transmit buffers and slots in the transmit
schedule. The switch would have to do likewise. I don't what our
driver does on the receive side to manage hardware resources.
There is a test patch that could be made available which addresses the
true livelock case. Submit an IPMT case against the OPPO driver if it
is important, and you are willing to try the patch.
/gary
|
| 843.5 | | WASNT::"washabaugh@went.lkg.dec.com" | Born to be Mild | Mon Mar 03 1997 16:15 | 8 |
| To solve the problem, you must make sure that both CPU cyles are
available, and memory/hardware resources are available. The memory
and hardware resources are easy, because most of the ATM products
support multiple transmit/receive queues. Guarenteeing that the
CPU cycles are available is harder, how did you do this for Digital
Unix?
doug
|