| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 902.1 | How to troubleshoot unsolicited resets. | HULLEY::HULLEY | | Mon Mar 22 1993 13:38 | 7 |
| I may be attempting to work in this problem (same customer). Is there a list
of this that can cause unsolicited resets on a concentrator 500. It seems
the concentrators with higher populations of these new systems increment this
counter more. I think this customer has an FDDI analyzer of some sort. What
other tools could be used to determine the cause?
tom
|
| 902.2 | Sun may need a patch ...wait ? | LEMAN::BRUNNER | | Fri May 14 1993 12:01 | 11 |
| Hi all,
Customer having 5 DEFCN 500 on which they have 1 Sun Sparc Center 2000
and 31 Sun Sparc SS10 Stations was also having "Unsollicited resets".
It seems that an engineer fron Sun flew in, installed a patch and no
"Unsollicited resets" anymore. As soon as I know which patch was
installed I will put another reply here.
BTW: They were also running 4.1.3 of Sun/OS.
Regards
Walter
|
| 902.3 | Sun patch explained ... | LEMAN::BRUNNER | | Tue May 18 1993 13:34 | 16 |
| Hi all,
Partial answer:
It seems to be a patch in some code for the SUN Sbus controller which
detected some error on the line and sended a Trace. Customer tells
that SMT rule says the concentrator should do a self-test. Our DEFCN
does a reset and the "Unsollicited reset" counter increments as it
should increment a "Sollicited self-test counter". In the MIB there is
a number of received trace messages "eSMTTracesReceived" which stays
zero.
Is this counter then of any use and when should it increment ?
Thanks Walter
|
| 902.4 | | KONING::KONING | Paul Koning, A-13683 | Tue May 18 1993 16:32 | 3 |
| Do you know why the Sun node started the trace?
paul
|
| 902.5 | defcn v3.2 still resets (sun patch not in yet) | CROWES::HULLEY | | Mon May 24 1993 16:38 | 13 |
| We still have this happening at our site. (No SUN patch yet)
I attempted to capture a trace by having the concentrator issue a trap
and triggering the analyzer off that event. So far all I have seen was
non-stop beaconing from 1 sun station before the concentrator triggered
the analyzer. I couldnt capture back far enough to see what led up to
this (yet).
Any more info on the patch from sun? Whats it called, whats it fix
specifically?
And the big question: Is our concentrator doing the correct thing by
doing the unsolicited reset?
Thanks
Tom
|
| 902.6 | | KONING::KONING | Paul Koning, A-13683 | Mon May 24 1993 17:39 | 4 |
| Re "the big question": yes. A trace is a signal to execute selftest, which
is done by resetting the box.
paul
|
| 902.7 | How to trigger on a trace and see what preceeds it | CROWES::HULLEY | | Tue May 25 1993 09:23 | 8 |
| Excellent.. Now can you point me to the format of this trace frame so
I can capture this on the analyzer. I havnt seen that yet on this site
and would like to see it for myself. Also, it seems only 1
concentrator will log a reset at any given time. Will the trace not be
seen by all the concentrators on the ring or might it be lost when
it hits the first concentrator and it resets.
Tom
|
| 902.8 | | KONING::KONING | Paul Koning, A-13683 | Tue May 25 1993 12:50 | 6 |
| Trace isn't a frame. Trace is signalled by MLS (master line state) on an
active port.
(see the SMT spec, chapter 9)
paul
|
| 902.9 | No name for the patch | LEMAN::BRUNNER | | Wed May 26 1993 10:56 | 13 |
| RE .4
The SUN Sbus controller detects erronously a fault on the primary ring,
therefore starts a trace on the secondary ring. This in turn causes
the station and concentrator to leave the ring and run Pathtest. If an
error is detected on one component, that component doesn't attempt to
join the ring again. As both elements run Pathtest without errors they
both reconnect to the ring. Everything starts again sometimes later.
BTW: The "eSMTTracesReceived" counter never increments as it should when
the Trace (MLS) is started. Will that be corrected sometime ?
Best regards
Walter
|