| This was the asnwer from canasta:
CANASTA was unable to find a rule matching the footprint of this
crash. If, in the future, a new rule is added that matches this
crash, you will be notified via mail.
This does not necessarily indicate that this is a new or unknown
problem, but that there is currently no CANASTA rule that matches
this case.
Regards
Ricardo.
|
| Ricardo,
so you have used CANASTA (thanks !), but there was no rule match for
your case. The FIND_SIMILAR_CASES function in the CANASTA Mail
Server did have additional information for you:
There was a list of CANASTA cases with SIMILAR (or even IDENTICAL)
footprints and some of them were IPMT cases, e.g. like this one:
MGO102481.0 OGO bs_frag_has_stg:1665, 0xfffffc00003bd3b4] nil
MGO102481.2 OGO UNIDENTIFIED USEG 17-JUL-1996 10:31:39.00 booster2
^^^^^^^^^<<< IPMT number ^^^^escalated to USEG !!!
MGO102481.2 OGO V3.2D-1 ~
MGO102481.2 OGO boot panic advfs_sad bs_frag_has_stg msfs_real_syscall
msfs_syscall syscall _Xsyscall
MGO102481.2 OGO bs_frag_has_stg:1665, 0xfffffc00003bdc44] nil
This has shown you, that this crash has been seen (and sent to CANASTA)
before. Please see note SPECXN::CANASTA 239 & 244 on how to read and
interpret the information from CAN_OSF1_CASES.SEQ
When you check that IPMT, you'll see that the problem has been moved
into the QAR database as QAR 49275. If you then check that QAR (SET
HOST to node GORGE, enter Username: QAR_INTERNAL, select OSF_QAR db),
you'll find it to be similar to QAR 39341 and it also seems to say,
that it's fixed in V4.0...
You can also check the UNIX or ADVFS patch readme files for any of the
above strings: MGO102481, 49275 and 39341 to find out, if the problem
might have been fixed.
If this doesn't help your customer, you'll have to raise an IPMT ...
Sorry, but that's the way it is...
Volker.
|