| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3638.1 | how often is often? | MARVIN::RIGBY | No such thing as an alpha beta | Wed May 14 1997 11:11 | 13 |
| Is the DECNIS actually set up to create a dump file? (HARDWARE DUMP CONTROL set
to Full Dump in the _extra files?)
You don't quite give enough console output to see what is actually happenning at
the time of the dump. Reason unknown is what is set up during startup so that if
the dump handler doesn't get called successfully (like the processor decides to
jump straight into the ROMs for such things as KERNEL STACK INVALID) then the
reason code is not reflecting the dump before. There is a fairly high
probability that an UNKNOWN reason code might not be generating a dump at all,
how often does this problem occur? (you just say often, is that once every 5
minutes or once a day?)
John
|
| 3638.2 | | MARVIN::HIGGINSON | Peter Higginson DTN 830 6293, Reading UK | Wed May 14 1997 11:44 | 6 |
|
Note also that you have a console connected to an MPC-I which is not
a supported configuration and can cause problems.
Peter
|
| 3638.3 | MPC-I can cause problem ? | TPOVC::MIKECHANG | | Thu May 15 1997 06:03 | 7 |
| Tomorrow We will check HARDWARE DUMP CONTROL for NIS600,set to FULL DUMP
by ncl and extra_set.ncl if neccessary.
For .2 >>Note also that you have a console connected to an MPC-I which is not
>>a supported configuration and can cause problem.
Would you point or explain some more about "MPC-I which is....can cause problem"
Thanks.
|
| 3638.4 | | MARVIN::HIGGINSON | Peter Higginson DTN 830 6293, Reading UK | Thu May 15 1997 15:39 | 23 |
|
>Would you point or explain some more about "MPC-I which is....can cause problem"
The MPC-I ships with a diagnostic port covered by a metalic label. There
are no useful commands that can be given (on the MPC-I) and no output
that can be relied upon. If you want the "last reboot reason" you should
use ncl to get it.
The metalic label is there for EMC reasons and should not be removed.
There are two known ways on hanging the DECNIS by connecting a device
to this port and would require the DECNIS to be power cycled to recover.
This happened a few years ago and resulted in an IPMT which took time
to investigate. There may be other things we don't know about.
Please disconnect the device and re-cover the port, you are not supported
otherwise.
In addition, anything that's printed on an MPC-I is just accidentally
left over. We don't check that changes we make don't cause inaccurate
information to be output because no-one is supposed to see it.
Peter
|