T.R | Title | User | Personal Name | Date | Lines |
---|
5431.1 | IPMT case number? Dump file location? | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Fri Apr 11 1997 17:43 | 14 |
|
Since this is a customer problem of some urgency, I
suggest that you IPMT the case so that it gets
addressed formally. I suspect that the first
thing that a maintainer will ask for is a
system dump from the time of the crash.
I hope this helps cut down the cycle time for
your customer. The longer
the time to an IPMT, with proper supporting evidence,
the longer the time to a fix. (I think I'm going
to can that text and start using it as my signature ;-))
Lee
|
5431.2 | | UCXAXP::KIMMEL | | Fri Apr 11 1997 19:47 | 12 |
| It should be easy to narrow this one down a little bit more.
First - the ucx$ucp image can't crash the system - because it's not
privileged. There is nothing that this image does which would cause
it to be in some active state for any length of time.
Could something that UCP call crash the system? Sure thing.
What I'm trying to get at here is - if it's crashing the system - it
is probably happening during a UCX startup or shutdown.
Perhaps doing a $SET VERIFY and getting a log of the action would
help.
|
5431.3 | ASTDEL: Module:UCX$BGDRIVER/Offset:44774 ??? | VIRGIN::BASSI | | Mon Apr 14 1997 09:19 | 25 |
|
Hi Johnny,
check whether customer configured an illegal-big value for the minimum number
of small/large buffers:
UCX> SHOW CONFIG COMM
MINIMUM ETHERNET FDDI
--------------------------------------------------
Small Buffers 127 127
Large Buffers 31 13
If this is the case then:
UCX> SET CONFIG COMMUNICATION /LARGE=(MIN:nnn)/SMALL=(MIN:nnnn)
$REBOOT
Best regards.
Gianbattista
|