| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2695.1 | what the trap means | TOOK::MILLBRANDT | answer mam | Thu Aug 31 1995 13:35 | 18 |
| Hi Sergio -
The common code base for the V3.1 DEChub 900 is no longer
on disk, so I can't readily look up the exact line of code
that was trapped. However, the trap was probably related
to a buffer being returned to pool twice - two separate
code routines thought they owned it.
A number of bugs of this nature, including a tendency
to run out of buffers, have been fixed in the latest
release of code for the DEChub 900 and the DECbridge900.
A new code release for the DECrepeater 900TM is still
being prepared.
You should read the notes in this conference about
upgrading, and prepare to upgrade your site.
Dotsie
|
| 2695.2 | will upg fix the problem ? | MLNCSC::CAREMISE | and then they were ...four ! | Thu Aug 31 1995 14:49 | 4 |
|
Do you mean , upgrading to v. 4.02 will fix the problem ?
|
| 2695.3 | | TOOK::MILLBRANDT | answer mam | Thu Aug 31 1995 16:31 | 21 |
| > Do you mean , upgrading to v. 4.02 will fix the problem ?
What I mean is that many, many fixes were made between V3.1
and V4.0.2, and V4.0.2 is the one we currently support. I
can't promise it will solve your problem, but the odds of
someone looking at it will be much higher.
A trap on an occurrence such as a buffer returning twice
is a bit of a catch-all. There is no indication of what
code functions or routines were both using the same buffer.
Thus, your log entry alone can't tell us what caused the
mishandled buffers, and we can't tell if that matches a
known fix. Perhaps the error logs on the modules in the
hub show some activity at about the same time as the crash.
There will be an upgrade of V4.0.2 available in N weeks,
where N = "contact the product manager". If this crash
is infrequent and upgrading is not easy at your site,
you could wait. Otherwise, just do it!
Dotsie
|
| 2695.4 | ..troubleshooting procedures ? | MLNCSC::CAREMISE | and then they were ...four ! | Fri Sep 01 1995 07:55 | 13 |
|
Thanks a lot for the explanation .
The last isssue remain unsolved : How can a FS engineer decode such
a entries , or better where are the troubleshooting procedures
documented ?
Just in case other problems arises .....8-)
Ciao e grazie.
Sergio.
|
| 2695.5 | | NETCAD::DOODY | Michael Doody | Fri Sep 01 1995 12:59 | 29 |
| Here's your errorlog entry as an example:
Entry = 89
Time stamp = 0 2614
Reset count = 20
TRAP @411 in bufpool.c
Entry = 89
This is the 89th entry written to the errorlog for this Hub. You
can only see the last 6 entries; older ones are overwritten.
Time stamp = 0 2614
This is how long the Hub was operational at the time the errorlog
entry was written. This Hub was up 26.14 seconds.
Reset count = 20
The hub has been reset 20 times at the time the entry was written.
TRAP @411 in bufpool.c
The Hub crashed at line 411 in the source code module bufpool.c.
This is the format of the MAM's errorlog entries. Other products'
will be more or less similar depending on the particular
requirements of the product.
|