[Info-vax] XPERR analysis

[Volker Halle]

On 7 Dez., 18:34, Steve <etmsr... at yahoo.co.uk> wrote:
> On Dec 2, 3:10 pm, 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 in the
> > > Files-11 sub-system (F11BXQP). This kind of bugcheck is an INLINE
> > > bugcheck, initiated by a BUGW macro instruction. This is a TRAP
> > > instruction, so the updated PC points to the NEXT instruction. That
> > > instruction is totally unrelated , but provides an important crash
> > > footprint information.
>
> > > A XQPERR crash with the next instruction being a 'PUSHL R2' is a known
> > > footprint. Are you running any defragmentation tools on this node ?
> > > Make sure to get the most recent F11BXQP.EXE from the latest V7.1
> > > build from HP.
>
> > > Volker.
>
> > Thank you for that response, Volker - I did notice that the disk has
> > more than its fair share of badly fragmented files. Some have many
> > 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 have
> the latest F11X patch - VAXF11X06_071.
> :o(
> Since the system was reduced to a single CPU last weekend it's been
> stable though (touch wood!)
> Steve- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Steve,

this crash is most likely in routine RES_SEQ_MISMATCH with a source
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 in
those cases. If you have (prior version !) support, you need to
escalate this problem to HP and ask for the most recent F11BXQP.EXE
from the last build for the remedial stream for V7.1.

If the crash only happens if enabling a SECOND CPU, this may very well
be a synchronization bug within the XQP, which gets triggered if
running on a SMP system.

Volker.