| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 842.1 | Crash log entry from failed EF | PRMS00::bjodial1_port6.bjo.dec.com::cascio | Steve Cascio, PRMS00::cascio | Tue Apr 08 1997 08:28 | 3 |
| Crash Log Entry Number 1
19(V1.5) fddiCntrlMain(): BAD CRC SENT!
|
| 842.2 | | IROCZ::GUNNER | | Tue Apr 08 1997 10:30 | 8 |
| We are aware of a problem with ATM bridge tunnels that will cause this
crash. First, make sure that you really have both ends of the bridge
tunnel set to FDDI - if you have one end set to Ethernet and one end
set to FDDI then you will get this crash. If you have them configured
correctly and it still crashes, then try powering off the EF modules
in both hubs, then restart the EAs, then restart the EFs.
Chris
|
| 842.3 | Here is how I set them up ... sound right? | PRMS00::bjodial1_port7.bjo.dec.com::cascio | Steve Cascio, PRMS00::cascio | Tue Apr 08 1997 11:49 | 34 |
| re .-1
Chris,
I tried your suggestion ... no help.
Just to make sure this isn't a pilot error ...
To configure the modules I:
1. Enabled Automatic VNbus mode in each 900 Multiswitch
2. Installed each of the EAs
2.1 Front Panel characteristics
2.1.1 set transmission type to SDH
2.1.2 left timing set to local
2.2 Logical Interfaces
2.2.2 Saw that interface 28 defaulted to Ethernet ATM Bridge
Tunnel
2.2.3 Disabled interface 28
2.2.4 Set it to FDDI ATM Bridge Tunnel (same VCI as before - 62)
2.3 Restarted EAs so the bridge tunnel change would be realized
3. Cabled the EAs together w/ short piece of fiber
4. Installed each of the EFs
4.1 Connected concentrators to FDDI rings (backplane & front panel)
After the EFs init'ed they crashed.
Does this procedure sound right??
Thanks,
Steve
|
| 842.4 | | IROCZ::GUNNER | | Tue Apr 08 1997 14:42 | 11 |
| Yes, that's what I meant you to do. I thought it might workaround
the problem but obviously it doesn't - sorry to have wasted your time.
Since we already have this bug reported in our internal PTR database
(number 19756) there's no need for you to log an IPMT case unless you
want to escalate it. Also, you may be able to workaround the problem
until we get a fix done by configuring the tunnel as an Ethernet
bridge tunnel instead. In our case that seems to avoid the problem.
It will mean that your maximum packet size will be limited to 1500bytes
but most FDDI-attached systems are able to work with this packet size.
Chris
|
| 842.5 | Another BAD CRC SENT! crash | KERNEL::GRIFFITHSJ | | Mon Apr 21 1997 04:38 | 25 |
| Hello
I also have a customer reporting VNswitch 900EF crashes with:-
2(V1.5) fddiCntrlMain(): BAD CRC SENT!
In this case however the only VN modules being used are the EF's forming
an FDDI ring between three HUB900's. There are no other FDDI devices on the
ring, the VNswitchs bridge to backplane connected ethernet ports and
ports 7-12 to front panel connected devices including, on two of the EF's
DECswitch 400's. Only one of the EF's has crashed two or three times now
the others are OK.
VNswitch at V1.5 MAM at V5.0
Has this been seen before??
regards Jim
Jim Griffiths
CSC Basingstoke.
|
| 842.6 | 3 causes of fddiCntrlMain(): BAD CRC SENT! | FORBIN::WILKINSON | | Mon Apr 21 1997 10:29 | 35 |
| re: .5
It is likely that there is a hardware problem with the EF module that
is crashing. The module should be swapped out and replaced with a
new unit.
We are seeing three possible causes of this symptom:
1. Software bug in the configuration of FDDI bridge tunnels. The
AE module must be sending packets from the tunnel to the the EF
module over the VNbus. There is a software fix for this in
the pipeline. The bug is actually in the AE software. The
work around is to use an ethernet bridge tunnel and let the
VNswitches translate the packets.
2. Hardware problems with the EF module reporting the error.
This is likely to be the problem if the EF module is only
receiving ethernet packets from other modules on the VNbus.
(If FDDI packets are being received by the EF module, either
from another EF module or an AE module, then see #3 below.)
This is also likely to be the problem for modules that exhibit
this problem when no traffic is being passed over the VNbus.
There are manufacturing diagnostics in place to prevent units
with these symptom from getting to customers.
3. Hardware problems with the interactions of MS900 hub clocking,
VNswitch clocking and LAN hopping. We don't expect to see this,
but if this is happening, receive input errors will be occurring
on the VNbus and the LAN hopped ethernet ports. Once again,
we have manufacturing diagnostics in place to identify units
with this problem.
Hugh
|
| 842.7 | Now two EF's crashing | KERNEL::GRIFFITHSJ | | Tue Apr 22 1997 06:43 | 23 |
| Hugh
Thanks for the information. This customer is now reporting that two of
the VN900EF's have crashed with this error at the same time. I have
raised this as an IPMT. Would you suggest a hardware swap for both
modules?
HW 06F1E1
RO V1.5.4
Serial numbers are
1R70803377
1R70605093
1R70605087
It is not clear which of the serial numbers are the crashing modules.
The modules are not connected to the VNbus.
regards Jim
|