Alpha/V8.3/Backup/Control-T/BUGCHECK
David B Sneddon
my
system disk to see if the 100% reproducible UNXSIGNAL bugcheck had been
fixed -- it hasn't.
Having just upgraded, I thought it would be a good idea to backup the
system
and started the process, then I thought I would check out the new
control-T
display in backup... control-T, BANG down it went like a sack of sh't.
Tried it again and it did the same.
Anyone else come across this one yet?
Dave
Volker Halle
a little bit more information on the nature of the bugcheck would be
quite helpful. Let's at least see a SDA> CLUE CRASH output.
---
Volker Halle, Invenate GmbH, OpenVMS Support
An OpenVMS crashdump analysis a day
makes the Windows headaches go away.
Guy Peleg
"David B Sneddon" <dbsn...@bigpond.com> wrote in message
news:1157797127....@h48g2000cwc.googlegroups.com...
I find it hard to believe that BACKUP is the culprit. The new
CTRL-T code is all in user mode, the results are sent to the
terminal using sys$brkthru system service. As Volker said,
let's start with the output of SDA>CLUE CRASH.
Guy
--
Posted via a free Usenet account from http://www.teranews.com
Richard Maher
Cheers Richard Maher
"David B Sneddon" <dbsn...@bigpond.com> wrote in message
news:1157797127....@h48g2000cwc.googlegroups.com...
Volker Halle
now that you've raised the visibility of this problem, we should be
pretty quickly find out the root cause of this problem - between the 3
of us ;-)
David B Sneddon
Guy Peleg wrote:
>
> I find it hard to believe that BACKUP is the culprit. The new
> CTRL-T code is all in user mode, the results are sent to the
> terminal using sys$brkthru system service. As Volker said,
> let's start with the output of SDA>CLUE CRASH.
>
> Guy
Here goes...
Crash Time: 9-SEP-2006 08:58:08.67
Bugcheck Type: INVEXCEPTN, Exception while above ASTDEL
Node: ZEN (Standalone)
CPU Type: Digital Personal WorkStation
VMS Version: V8.3
Current Process: Dave at FTA11
Current Image: $253$DKB0:[SYS0.SYSCOMMON.][SYSEXE]BACKUP.EXE
Failing PC: FFFFFFFF.80108ED4 IOC$DISMOUNT_C+00374
Failing PS: 30000000.00000801
Module: IO_ROUTINES (Link Date/Time: 8-AUG-2006
08:28:53.76)
Offset: 0002EED4
Boot Time: 9-SEP-2006 02:03:53.00
System Uptime: 0 06:54:15.67
Crash/Primary CPU: 0./0.
System/CPU Type: 1E05
Saved Processes: 0
Pagesize: 8 KByte (8192 bytes)
Physical Memory: 448 MByte (57344 PFNs, contiguous memory)
Dumpfile Pagelets: 917504 blocks
Dump Flags: olddump,writecomp,errlogcomp
Dump Type: raw,full,dosd,shared_mem
EXE$GL_FLAGS: poolpging,init,bugdump
Paging Files: 1 Pagefile and 0 Swapfiles installed
Stack Pointers:
KSP = 00000000.7FF87B58 ESP = 00000000.7FF8BD60 SSP =
00000000.7FF9CC80
USP = 00000000.7AD08EA8
General Registers:
R0 = 00000000.00000000 R1 = 00000000.0000000C R2 =
00000000.7FF87D50
R3 = FFFFFFFF.818CEC60 R4 = 00000000.7FF87BC0 R5 =
00000000.7FF87D38
R6 = 00000000.7FF87D80 R7 = 30000000.00000801 R8 =
00000000.00000001
R9 = 00000000.00000001 R10 = FFFFFFFF.81DD9B00 R11 =
00000000.00000000
R12 = 00000000.00000000 R13 = FFFFFFFF.818DCCD0 R14 =
00000000.7FFF0190
R15 = 00000000.00000000 R16 = 00000000.000001CC R17 =
00000000.7FF87BC0
R18 = 00000000.7FF87D80 R19 = 00000000.00000000 R20 =
00000000.0000000E
R21 = 00000000.00000000 R22 = 00000000.00000C10 R23 =
00000000.0DEC4021
R24 = FFFFFFFF.8180A0B0 AI = 00000000.00200000 RA =
00000000.00000002
PV = 00000000.00000000 R28 = 00000000.00001000 FP =
00000000.7FF87E60
PC = FFFFFFFF.800A5CE8 PS = 18000000.00000800
How much do you want?
Dave
Volker Halle
how about the signal array the the instruction stream ?
Volker.
David B Sneddon
Exception Frame:
R2 = 20000000.00000003 R3 = 00000000.00000001 R4 =
FFFFFFFF.820A82C0
R5 = FFFFFFFF.81DD9B00 R6 = FFFFFFFF.83C81F30 R7 =
00000000.7B0C4378
PC = FFFFFFFF.80108ED4 PS = 30000000.00000801
Signal Array: 64-bit Signal Array:
Arg Count = 00000005 Arg Count =
00000005
Condition = 0000000C Condition =
00000000.0000000C
Argument #2 = 00000000 Argument #2 =
00000000.00000000
Argument #3 = 00000052 Argument #3 =
00000000.00000052
Argument #4 = 80108ED4 Argument #4 =
FFFFFFFF.80108ED4
Argument #5 = 00000801 Argument #5 =
30000000.00000801
Mechanism Array:
Arguments = 0000002C Establisher FP =
00000000.7FF87E60
Flags = 00000000 Exception FP =
00000000.7FF87D80
Depth = FFFFFFFD Signal Array =
00000000.7FF87D38
Handler Data = 00000000.00000000 Signal64 Array =
00000000.7FF87D50
R0 = 00000000.0000003A R1 = 00000000.00010057 R16 =
00000000.00000001
R17 = 00000000.00000000 R18 = 00000000.00000000 R19 =
00000000.00000000
R20 = 00000000.0000000E R21 = 00000000.00000000 R22 =
00000000.00000C10
R23 = 00000000.0DEC4021 R24 = FFFFFFFF.8180A0B0 R25 =
00000000.00200000
R26 = 00000000.00000002 R27 = 00000000.00000000 R28 =
00000000.00001000
System Registers:
Page Table Base Register (PTBR)
00000000.00009390
Processor Base Register (PRBR)
FFFFFFFF.81D1A000
Privileged Context Block Base (PCBB)
00000000.1271E080
System Control Block Base (SCBB)
00000000.00000ADA
Software Interrupt Summary Register (SISR)
00000000.00000000
Address Space Number (ASN)
00000000.00000029
AST Summary / AST Enable (ASTSR_ASTEN)
00000000.0000000F
Floating-Point Enable (FEN)
00000000.00000001
Interrupt Priority Level (IPL)
00000000.00000008
Machine Check Error Summary (MCES)
00000000.00000000
Virtual Page Table Base Register (VPTB)
FFFFFEFC.00000000
Failing Instruction:
IOC$DISMOUNT_C+00374: LDQ_U R23,#X0018(R0)
Instruction Stream (last 20 instructions):
IOC$DISMOUNT_C+00324: AND R28,#X10,R26
IOC$DISMOUNT_C+00328: BIS R28,#X10,R28
IOC$DISMOUNT_C+0032C: INSBL R28,#X01,R24
IOC$DISMOUNT_C+00330: BIS R27,R24,R27
IOC$DISMOUNT_C+00334: STL R27,#X00D8(R5)
IOC$DISMOUNT_C+00338: BNE R26,#X000006
IOC$DISMOUNT_C+0033C: LDQ_U R31,(SP)
IOC$DISMOUNT_C+00340: BLBC R3,#X000004
IOC$DISMOUNT_C+00344: LDL R22,#X00D8(R5)
IOC$DISMOUNT_C+00348: LDA R28,#X1000(R31)
IOC$DISMOUNT_C+0034C: BIC R22,R28,R22
IOC$DISMOUNT_C+00350: STL R22,#X00D8(R5)
IOC$DISMOUNT_C+00354: LDL R26,#X00A4(R5)
IOC$DISMOUNT_C+00358: AND R26,#XFF,R26
IOC$DISMOUNT_C+0035C: LDA R16,#XFFFF(R26)
IOC$DISMOUNT_C+00360: BNE R16,#X000004
IOC$DISMOUNT_C+00364: LDL R16,#X00D8(R5)
IOC$DISMOUNT_C+00368: SRL R16,#X0E,R25
IOC$DISMOUNT_C+0036C: LDQ_U R31,(SP)
IOC$DISMOUNT_C+00370: BLBC R25,#X000007
IOC$DISMOUNT_C+00374: LDQ_U R23,#X0018(R0)
IOC$DISMOUNT_C+00378: EXTBL R23,R0,R22
IOC$DISMOUNT_C+0037C: BIC R22,#X04,R24
IOC$DISMOUNT_C+00380: INSBL R24,R0,R28
IOC$DISMOUNT_C+00384: MSKBL R23,R0,R23
Dave
Volker Halle
you're using the new IO_ROUTINES from VMS83A_ADDENDUM-V0100 !
The problem is R0=3A - an invalid address causing an ACCVIO during the
reference to VA=00000052 when executing LDQ_U R23,#X0018(R0)
The instruction stream offset in IOC$DISMOUNT_C in the new IO_ROUTINES
has changed against the V8.3 SSB version - probably indicating
new/modified code.
cross-reference link to ITRC:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=842851
You should really open a new thread in ITRC for this NEW problem.
Volker.
Volker Halle
R5 should be pointing to the tape UCB. And R0 should be pointing to the
VCB.
The failing code is trying to clear the VCB$V_MNTVER bit in
VCB$B_STATUS2(R0).
What's in UCB$L_VCB ?
SDA> EXA 81DD9B00+UCB$L_VCB
Volker.
David B Sneddon
SDA> exam 81dd9b00+ucb$l_vcb
FFFFFFFF.81DD9B58: 00000000.82096400 ".d......"
SDA>
David B Sneddon
OK, the control-T bit is a red herring, I just tried another
backup, no control-t this time and it bugchecked...
now waiting for it to come back to life so I can undo
the addendum patch.
Dave
Volker Halle
BACKUP is out of the picture. As well as the CTRL-T handler.
A simple and plain MOUNT/FOR tape followed by a DISM/NOUNL tape causes
this crash with VMS83A_ADDENDUM-V0100 installed.
Stay tuned for the crash analysis ...
and thanks for PRODUCT UNDO PATCH
Volker Halle
there is some new code (added in VMS83A_ADDENDUM-V0100) in
IOC$DISMOUNT, which overwrites R0 (should be pointing to VCB) with the
UCB fork lock index (UCB$B_FLCK). The ACCVIO later happens, because the
failing instruction tries to access VCB$B_STATUS2(R0) - assuming that
R0 still points to the VCB - but it does not.
...
IOC$DISMOUNT_C+002B4: RET R31,(R28)
IOC$DISMOUNT_C+002B8: LDQ_U R31,(SP)
IOC$DISMOUNT_C+002BC: LDQ_U R31,(SP)
IOC$DISMOUNT_C+002C0: LDQ R28,#X0010(R13) <<< local
subroutine entry point
IOC$DISMOUNT_C+002C4: LDL R0,#X0008(R5) <<< load
UCB$W_SIZE,TYPE,FLCK longword
SDA> exa ucb+08
UCB+00008: 81A24D50.3A100208 "...:PM¢."
^^ UCB$B_FLCK
IOC$DISMOUNT_C+002C8: LDL R26,#X0B48(R28)
SDA> exa 818D9CD0 +10
IOC$DISMOUNT+00010: FFFFFFFF.81808000 "........"
SDA> exa 81808000+b48
SMP$GL_FLAGS: 00000000.00000007 "........"
IOC$DISMOUNT_C+002CC: EXTBL R0,#X03,R0 <<< extract
UCB$B_FLCK
IOC$DISMOUNT_C+002D0: BLBC R26,#X00008B <<< do not
branch to +04E0 (R26=7)
IOC$DISMOUNT_C+002D4: LDA R16,#XFFE0(R0)
...
...
IOC$DISMOUNT_C+00374: LDQ_U R23,#X0018(R0) <<< R0 used
here causing crash
JF Mezei
> I find it hard to believe that BACKUP is the culprit.
Yeah ! yeah ! says the guy fleeing VMS engineering just before his bugs
make it to the customers !!!!!!!
Now we know why you left :-) :-) :-) :-) :-) :-) :-)
Volker Halle
VMS83A_ADDENDUM-V0100 and is going to provide a new IO_ROUTINES.EXE
image on monday - you need to log a support call with your HP support
center. See the above entry in the ITRC OpenVMS forum.
I would also expect the VMS83A_ADDENDUM-V0100 patch to be put on hold
and a new version to be released quite soon...
Guy Peleg
"JF Mezei" <jfmezei...@teksavvy.com> wrote in message
news:45035D82...@teksavvy.com...
I'm busted ;-)
--
Posted via a free Usenet account from http://www.teranews.com
Warning: Do not use Ultimate-Anonymity
They are worthless spamers that are running a scam.
Guy Peleg
JF Mezei
>
> OpenVMS engineering has acknowledged this problem in
> VMS83A_ADDENDUM-V0100 and is going to provide a new IO_ROUTINES.EXE
> image on monday
That is very good. This type of response where VMS engineering provides
a patch within a couple of days of a problem being reported on the net
should go into some of the marketing materials for VMS.
- you need to log a support call with your HP support center.
This is not something that needs to go into the marketing. Considering
8.3 was released so recently, shouldn't the patch be freely available
without having to go through a support centre ?
Volker Halle
as I said, expect VMS83A_ADDENDUM-V0100 to be put on hold and a new
version of that patch to be released publicly.
If you are in real need of a new IO_ROUTINES.EXE, then the fastest way
to get that would be via a support call.
Volker.
Paul Sture
JF Mezei <jfmezei...@teksavvy.com> wrote:
Bzzt. It takes long longer to build, test and document a full ECO
replacement (i.e. take it through the full formal process), than issuing
just one executable.
--
Paul Sture
Robert Deininger
The support center can likely make an image file available almost as soon
as it is available. Patch kits don't turn around that fast. If the time
since V8.3 release is relevant, I don't see how.
Do you think there is someone better able to field customer calls than the
support center? Is there a constructive suggestion somewhere here that I
missed?
JF Mezei
> If the time
> since V8.3 release is relevant, I don't see how.
Something about warrantee ? Aren't there jurisdictions in the world
where the vendor would be forced to provide major bug fixes for free
within a certain amount of time of software becoming available ?
> Do you think there is someone better able to field customer calls than the
> support center?
This assumes everyone has access to the support centre. Are HP's
business proactices such that anyone buying softrware or t5he right to
an upgrade gets free support (aka: access to support centre) for a
certain amount of time ? If not, then some customers may have purchanged
aa licence-only for 8.3 and have no access to the support centre to get
that critical patch.
Dave Froble
Perhaps you should research the issue before taking any shots at anyone.
While I haven't checked lately, the last time I checked, VMS comes with
a 90 day warranty. Such would provide access to the support center.
For those with support, and with access to the new release via the
support, they also have access to the support center.
So just who might have an unserviced need that you're worrying about?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Ian Miller
ftp://ftp.itrc.hp.com/openvms_patches/alpha/V8.3/
and the patch kit is not marked as on hold. Its been a couple of days
since this problem was found. Enough time to drop the kit from the ftp
site and issue a hold notice.
Ian Miller
kit for OpenVMS Alpha V8.3 and the VMS83I_ADDENDUM-V0100 patch kit for
HP Integrity Servers running OpenVMS V8.3 are being placed on hold.
I see that the patches are still on the ftp site but, following this
advisory, I expect them to disappear soon.