[Info-vax] XPERR analysis

Wed Dec 9 12:28:44 EST 2009

In article <a7315ebd-a333-4e8b-8d43-d598bb05cff4 at m3g2000yqf.googlegroups.com>, GerMarsh <marsh.family at tirhir.com> writes:
>On 9 Dec, 14:46, VAXman-  @SendSpamHere.ORG wrote:
>> In article <3a0bfe8f-9bd7-4359-a9fd-b4a0a227e... at j14g2000yqm.googlegroups=
>..com>, GerMarsh <marsh.fam... at tirhir.com> writes:
>>
>>
>>
>>
>>
>> >On 8 Dec, 17:37, Volker Halle <volker_ha... at hotmail.com> wrote:
>> >> On 8 Dez., 15:12, Steve <etmsr... at yahoo.co.uk> wrote:
>>
>> >> > On 8 Dec, 08:28, Volker Halle <volker_ha... at hotmail.com> wrote:
>>
>> >> > > On 7 Dez., 18:34, Steve <etmsr... at yahoo.co.uk> wrote:
>>
>> >> > > > On Dec 2, 3:10=3DA0pm, GerMarsh <marsh.fam... at tirhir.com> wrote:
>>
>> >> > > > > On 1 Dec, 18:13, Volker Halle <volker_ha... at hotmail.com> wrote=
>:
>>
>> >> > > > > > A XQPERR is most likely caused by a software inconsistency i=
>n t=3D
>> >he
>> >> > > > > > Files-11 sub-system (F11BXQP). This kind of bugcheck is an I=
>NLI=3D
>> >NE
>> >> > > > > > bugcheck, initiated by a BUGW macro instruction. This is a T=
>RAP
>> >> > > > > > instruction, so the updated PC points to the NEXT instructio=
>n. =3D
>> >That
>> >> > > > > > instruction is totally unrelated , but provides an important=
> cr=3D
>> >ash
>> >> > > > > > footprint information.
>>
>> >> > > > > > A XQPERR crash with the next instruction being a 'PUSHL R2' =
>is =3D
>> >a known
>> >> > > > > > footprint. Are you running any defragmentation tools on this=
> no=3D
>> >de ?
>> >> > > > > > Make sure to get the most recent F11BXQP.EXE from the latest=
> V7=3D
>> >..1
>> >> > > > > > build from HP.
>>
>> >> > > > > > Volker.
>>
>> >> > > > > Thank you for that response, Volker - I did notice that the di=
>sk =3D
>> >has
>> >> > > > > more than its fair share of badly fragmented files. Some have =
>man=3D
>> >y
>> >> > > > > extension headers.
>>
>> >> > > > > I'll see if there's a patch for the ancient F11BXQP.
>>
>> >> > > > Gerald and I have found that although one of the clustered nodes
>> >> > > > doesn't have the latest one, the system that keeps crashing DOES=
> ha=3D
>> >ve
>> >> > > > the latest F11X patch - VAXF11X06_071.
>> >> > > > :o(
>> >> > > > Since the system was reduced to a single CPU last weekend it's b=
>een
>> >> > > > stable though (touch wood!)
>> >> > > > Steve- Zitierten Text ausblenden -
>>
>> >> > > > - Zitierten Text anzeigen -
>>
>> >> > > Steve,
>>
>> >> > > this crash is most likely in routine RES_SEQ_MISMATCH with a sourc=
>e
>> >> > > code comment of:
>>
>> >> > > Found a stale referenced or nondirectory FCB in FCB queue
>>
>> >> > > The last F11BXQP.EXE from VAXF11X06_071 is from 13-OCT-2009.
>>
>> >> > > Crashes with this footprint have been seen on V6.2, V7.1 and even
>> >> > > V7.2. VMS engineering has supplied the most recent F11BXQP image i=
>n
>> >> > > those cases. If you have (prior version !) support, you need to
>> >> > > escalate this problem to HP and ask for the most recent F11BXQP.EX=
>E
>> >> > > from the last build for the remedial stream for V7.1.
>>
>> >> > > If the crash only happens if enabling a SECOND CPU, this may very =
>wel=3D
>> >l
>> >> > > be a synchronization bug within the XQP, which gets triggered if
>> >> > > running on a SMP system.
>>
>> >> > > Volker.- Hide quoted text -
>>
>> >> > > - Show quoted text -
>>
>> >> > Hi Volker,
>>
>> >> > Did you mean 2009 or 1999? =3DA0If 1999 then we have it installed. =
>=3DA0If
>> >> > 2009...
>>
>> >> > Steve- Zitierten Text ausblenden -
>>
>> >> > - Zitierten Text anzeigen -
>>
>> >> Steve,
>>
>> >> OpenVMS VAX V7.1 is more than 10 years old. The last XQP patch for
>> >> V7.1 has been released on 13-JUN-2000 ! The F11BXQP.EXE file had a
>> >> link date of 13-OCT-1999 - this should be the version you're running.
>>
>> >> You would need to contact HP, if you want a newer F11BXQP.EXE, which
>> >> may fix those crashes.
>>
>> >> Volker.- Hide quoted text -
>>
>> >> - Show quoted text -
>>
>> >Does the instruction stream point to the suspect module?...
>>
>> >SDA> ex @pc-10:@pc+10/instr
>> >%SDA-W-INSKIPPED, unreasonable instruction stream - 2 bytes skipped
>> >F11BXQP+02C95: =A0TSTL =A0 =A042(R2)
>> >F11BXQP+02C98: =A0BEQL =A0 =A0F11BXQP+02C9F
>> >F11BXQP+02C9A: =A0TSTW =A0 =A018(R2)
>> >F11BXQP+02C9D: =A0BEQL =A0 =A0F11BXQP+02CA3
>> >F11BXQP+02C9F: =A0BUGW =A0 #05CC
>> >F11BXQP+02CA3: =A0PUSHL =A0 R2
>> >F11BXQP+02CA5: =A0CALLS =A0 #01,F11X$INIT_XQP+002FD
>> >F11BXQP+02CAC: =A0PUSHL =A0 R2
>> >F11BXQP+02CAE: =A0CALLS =A0 #01,F11BXQP+01546
>> >F11BXQP+02CB5: =A0PUSHL =A0 R2
>> >SDA>
>>
>> That helps. =A0A look at what's in the data pointed to by R2 at the point=
> of
>> the bugcheck could help too.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESIS(=
>dot)ORG
>>
>> =A0http://www.quirkfactory.com/popart/asskey/eqn2.png
>>
>> =A0 "Well my son, life is like a beanstalk, isn't it?"- Hide quoted text =
>-
>>
>> - Show quoted text -
>
>Is this at all helpful?...
>
>SDA> ex/instr @pc
>F11BXQP+02CA3:  PUSHL   R2
>SDA> ex r2
>R2:  8FA0C100   ".=C1.."
>SDA> ex/instr @r2
>8FA0C100:  ADDB2   PC,#40[R4]
>SDA> ex @r2
>8FA0C100:  8F445F80   "._D."
>SDA>

R2 points to a region/collection of data as you can see in that brief
snippet of code you previously posted.  I like to use:

SDA> SHOW STACK/LONG base;range

for example:

SDA> SHOW STACK/LONG @R2;100

Data used in this fashion in VMS is often a data structure and SDA has
the smarts to decode and format that data using the SDA> FORMAT command.
You could also give that a go.  You may need to load symbol table files
in order to get the FORMAT command to format the particular structure.
If the address points to a sturcture which can be formatted, the third
longword will maintain the size (word) and two 1 byte fields describing
the data structure type.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png

  "Well my son, life is like a beanstalk, isn't it?"