| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
The counters below are from a OSF/1 3.2B machine.
With a V3.2C machine (counters not shown here) customer get the same
messages/counters except the "ring initialized" messages.
Both machines get the same brand of FDDI PCI board, and same firmware (2.46).
(I told the customer to upgrade the firmware in order to get rid of the overruns,
but no luck...).
On this ring there are also 2 HP machines whose counters stay nulls,
(i.e. they do no detect problems, nor ring intialization)...
The customer says that the network is very simple (4 or 5 machines, and none
of them were shutdown, and no cables where unplugged).
Also, he noticed that the DEC machines send themselves about 1500 frames
after the "ring initialized" messages (to test the network I think).
Isn't it a bit too much ?
Also, what could be deduced from these messages/behaviour ?
Are the HP boards less sensible, or the DEC one too much ?
Any help appreciated
Thanx
Pascal d'Ornano
*****************************************
netstat -I fta0 -s
*****************************************
fta0 FDDI counters at Fri Jan 26 11:31:35 1996
44409 seconds since last zeroed
21754352 ANSI MAC frame count
0 ANSI MAC frame error count
4 ANSI MAC frames lost count
9151971 bytes received
2889336 bytes sent
29027 data blocks received
37400 data blocks sent
3008 multicast bytes received
48 multicast blocks received
7059 multicast bytes sent
69 multicast blocks sent
0 transmit underrun errors
0 send failures
0 FCS check failures
0 frame status errors
0 frame alignment errors
0 frame length errors
0 unrecognized frames
0 unrecognized multicast frames
906 receive data overruns
0 system buffers unavailable
0 user buffers unavailable
12 ring reinitialization received
0 ring reinitialization initiated
0 ring beacon process initiated
0 ring beacon process received
0 duplicate tokens detected
0 duplicate address test failures
0 ring purger errors
0 bridge strip errors
0 traces initiated
0 traces received
0 LEM reject count
0 LEM events count
0 LCT reject count
0 TNE expired reject count
5 Completed Connection count
0 Elasticity Buffer Errors
fta0 FDDI status
Adapter State: Link Available State
LED State: Green
Link State: On Ring Running
Duplicate Address Condition: Absent
Ring Purger State: Purger off
Negotiated TRT: 7.987 ms
Upstream Neighbor Address: 08-00-09-6C-C4-59
UNA Timed Out: False
Downstream Neighbor Address: 08-00-09-6C-84-39
Claim Token Yield: False
Frame Strip Mode: Source Address Match
Ring Error Reason: Ring Init Received
Last Direct Beacon SA: 00-80-16-08-00-18
Physical Port State: In Use
Neighbor Physical Port Type: Master
Reject Reason: No Reason
Physical Link Error Estimate: 15
Full Duplex Mode: Disabled
fta0 FDDI characteristics
Link Address: 08-00-2B-B4-89-61
Firmware Revision: 2.46
Hardware Revision: 1
SMT Version ID: 2
Requested TRT: 7.987 ms
Maximum TRT: 173.0 ms
Valid Transmission Time: 2.621 ms
LEM Threshold: 8
Restricted Token Timeout: 1000.000 ms
PMD Type ANSI Multimode
Counter Update Interval: 1 sec
******************************************************
/var/adm/messages
******************************************************
Jan 23 04:06:22 mx1 vmunix: fta0: Ring initialized
Jan 23 04:06:24 mx1 vmunix: fta0: Link Unavailable.
Jan 23 04:06:30 mx1 vmunix: fta0: Directed beacon received
Jan 23 04:06:31 mx1 vmunix: fta0: Receive Overrun
Jan 23 04:06:39 mx1 vmunix: fta0: Link Available.
Jan 23 04:06:40 mx1 vmunix: fta0: Ring initialized
Jan 23 09:22:41 mx1 vmunix: WARNING: too many System corrected errors. Reporting suspended.
Jan 23 11:04:46 mx1 vmunix: fta0: Ring initialized
Jan 23 11:04:48 mx1 vmunix: fta0: Link Unavailable.
Jan 23 11:04:55 mx1 vmunix: fta0: Directed beacon received
Jan 23 11:04:55 mx1 vmunix: fta0: Receive Overrun
Jan 23 11:04:55 mx1 vmunix: fta0: Directed beacon received
Jan 23 11:04:56 mx1 vmunix: fta0: Receive Overrun
Jan 23 11:05:03 mx1 vmunix: fta0: Link Available.
Jan 23 11:05:05 mx1 vmunix: fta0: Ring initialized
Jan 24 11:07:52 mx1 vmunix: fta0: Ring initialized
Jan 24 11:07:54 mx1 vmunix: fta0: Link Unavailable.
Jan 24 11:08:00 mx1 vmunix: fta0: Directed beacon received
Jan 24 11:08:01 mx1 vmunix: fta0: Receive Overrun
Jan 24 11:08:09 mx1 vmunix: fta0: Link Available.
Jan 24 11:08:10 mx1 vmunix: fta0: Ring initialized
Jan 25 08:47:39 mx1 vmunix: fta0: Ring initialized
Jan 25 08:48:05 mx1 vmunix: fta0: Ring initialized
Jan 25 08:50:55 mx1 last message repeated 2 times
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1944.1 | NETCAD::STEFANI | I *CAN* drive 65! | Wed Feb 07 1996 11:26 | 18 | |
>> Both machines get the same brand of FDDI PCI board, and same firmware
>> (2.46). (I told the customer to upgrade the firmware in order to get
>> rid of the overruns, but no luck...).
v2.46 is still the current firmware for DEFPA, so there's no reason to
suggest an upgrade at this time.
>>Also, what could be deduced from these messages/behaviour ?
>>Are the HP boards less sensible, or the DEC one too much ?
Not sure. There could be a problem with the cables, or connectors, or
the hub port. Perhaps look at the link error rate values on the hub to
see if the ports that the DEFPA's are attached to indicate a high error
rate. The ring initializations are normal if the adapter is losing its
link then regaining it. The question to answer is WHY the adapter is
going link unavailable.
/l
| |||||
| 1944.2 | 36677::GINGER | Ron Ginger | Thu Jun 13 1996 12:38 | 65 | |
We are seeing a similar problem, but it resulted in a hung system. The
log shows:
Jun 13 08:20:12 test vmunix: NFS3 server dasysmgr not responding still
trying
Jun 13 08:21:24 test vmunix: fta0: Receive Overrun
Jun 13 08:21:29 test last message repeated 5 times
Jun 13 08:21:29 test vmunix: NFS3 server dasysmgr ok
Jun 13 08:21:30 test vmunix: fta0: Receive Overrun
Jun 13 08:22:01 test last message repeated 19 times
At about this time the system seemed to hang- all terminal sessions
hung, wouldnt answer ping, and even its console would not 'wake up' the
screen saver. We had to push the halt button to recover.
The customer wants to replace the fddi board (we have firmware rev 2.3)
I also note the following from netstat
fta0 FDDI counters at Thu Jun 13 11:28:06 1996
13143 seconds since last zeroed
75581169 ANSI MAC frame count
0 ANSI MAC frame error count
0 ANSI MAC frames lost count
10746617 bytes received
516820 bytes sent
80496 data blocks received
2132 data blocks sent
10562253 multicast bytes received
77662 multicast blocks received
2702 multicast bytes sent
35 multicast blocks sent
0 transmit underrun errors
0 send failures
0 FCS check failures
0 frame status errors
0 frame alignment errors
0 frame length errors
0 unrecognized frames
0 unrecognized multicast frames
0 receive data overruns
6 system buffers unavailable
0 user buffers unavailable
1 ring reinitialization received
0 ring reinitialization initiated
0 ring beacon process initiated
0 ring beacon process received
0 duplicate tokens detected
0 duplicate address test failures
0 ring purger errors
0 bridge strip errors
0 traces initiated
0 traces received
0 LEM reject count
0 LEM events count
0 LCT reject count
0 TNE expired reject count
0 Completed Connection count
0 Elasticity Buffer Errors
Is it normal to have so many multicast bytes?
| |||||
| 1944.3 | 12368::thomas | The Code Warrior | Thu Jun 13 1996 13:17 | 2 | |
What platform? What board? Make sure are using 2.46 of the firmware (assuming DEFPA or DEFEA). | |||||
| 1944.4 | 36677::GINGER | Ron Ginger | Thu Jun 13 1996 14:36 | 4 | |
Sorry, this is Unix 3.2C. alpha 2100. 1 190mhz cpu, 256 mb. DEFEA-DA.
Firmware rev shows 2.3 on netstat -I fta0 -s
| |||||
| 1944.5 | 12368::thomas | The Code Warrior | Thu Jun 13 1996 14:59 | 1 | |
Upgrade the DEFEA to 2.46 (via the firmware CD) and see if it still happens. | |||||