Changes Boot behavior on XP1000 since 2013 (2022 Views)
Reply
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 1 of 46 (2,022 Views)

Changes Boot behavior on XP1000 since 2013

XP1000,  VMS V7.2-1 or V7.3-2, latest Firmware V5.9-1, SYSGEN-TIMEPROMTWAIT=65535 (default), battery ok.

Since 2013 all machines booting up from "Power off" or after doing ">>> INIT" on the boot prompt stop booting and ask for the system time DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until login normally. All XP1000 boot normally too if power wasn't off or if no >>> INIT was given on the boot prompt.

Only XP1000 are infected, our DS10 and some other alphas boot as expected.

You can force the machines to boot through with another TIMEPROMPTWAIT value, but than the system time will be inaccurate (time of last boot or of last $SET TIME).

It seems that any time from 2013 on is an invalid time for the processors time-of-year clock and this clock becomes important after "power off" or INIT.

Please use plain text.
Respected Contributor
Bob Blunt
Posts: 314
Registered: ‎05-01-2003
Message 2 of 46 (2,010 Views)

Re: Changes Boot behavior on XP1000 since 2013

When a VMS system boots it checks the time stored against the time in the on-board clock and if they're different by more than an expected amount it triggers the time request.

 

One way to fix it is by using $ SET TIME to save the system's current time so it is closer to that saved in the on-board clock.  A regular pass through your system with $ SET TIME is probably a good idea to make sure the saved time is closer.  This is also why many distribution CDs and STABACKIT bootable disks also trigger the time/date request.  You can't fix the date saved on the CD and the non-system disks that are bootable don't get time set often enough to keep them happy.

 

bob

Please use plain text.
Honored Contributor
Steven Schweda
Posts: 9,075
Registered: ‎02-23-2005
Message 3 of 46 (2,000 Views)

Re: Changes Boot behavior on XP1000 since 2013

Please use plain text.
Frequent Advisor
Maurizio De Tommaso_
Posts: 40
Registered: ‎03-11-2004
Message 4 of 46 (1,980 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

When your system boots with OpenVMS V7.3-2, please post the output of the following commands :

 

$ Analyze /Image /Select=Link   sys$loadable_images:sys$base_image.exe

$ Set Term /Width=132
$ Product Show Product VMS /Full

 

 

Please use plain text.
Honored Contributor
Steven Schweda
Posts: 9,075
Registered: ‎02-23-2005
Message 5 of 46 (1,973 Views)

Re: Changes Boot behavior on XP1000 since 2013

Please use plain text.
Honored Contributor
Steven Schweda
Posts: 9,075
Registered: ‎02-23-2005
Message 6 of 46 (1,970 Views)

Re: Changes Boot behavior on XP1000 since 2013

Please use plain text.
Esteemed Contributor
H.Becker
Posts: 360
Registered: ‎04-09-2009
Message 7 of 46 (1,964 Views)

Re: Changes Boot behavior on XP1000 since 2013

>by using $ SET TIME to save the system's current time
which is saved in the base image, the file, at location EXE$GQ_TODCBASE, which is initially set in the source code and so independent of the link date.

If set time wasn't issued or failed to write into the image file - for whatever reason you will experience the problem when the time difference between the time in the base image and the hw clock is greater than (I think) 5  years. Then you will be prompted for the time. Writing the time into the base image is done on VAX and Alpha (, but not on I64 - except this was changed/fixed in the last year; because ECOs often contain a new base image with a more recent EXE$GQ_TODCBASE so that this problem rarely shows).

 

As you may know, set time is part of the system shutdown command procedure.

 

Please use plain text.
Frequent Advisor
Maurizio De Tommaso_
Posts: 40
Registered: ‎03-11-2004
Message 8 of 46 (1,932 Views)

Re: Changes Boot behavior on XP1000 since 2013

On OpenVMS, SET TIME command (with no arguments) is executed during an operator requested shutdown. In particular, on ALPHA systems, this SET TIME command results in a time stamp (the current OpenVMS system time) being written into the EXE$GQ_TODCBASE field and into the EXE$GQ_SAVED_HWCLOCK field in SYS$COMMON:[SYS$LDR]SYS$BASE_IMAGE.EXE.

 

As correctly reported in reply_7, On Alpha Platform there is a check at boot time that compares the hardware clock time with the EXE$GQ_TODCBASE provided from the SYS$BASE_IMAGE.EXE file. If the SYS$BASE_IMAGE.EXE file has a time stamp of some years earlier than the time the system gets from the hardware clock, OpenVMS may prompt for the "data and time".

 

Applying a recent SYS kit, that replaces SYS$BASE_IMAGE, corrects the problem since the new SYS$BASE_IMAGE will have EXE$GQ_TODCBASE set to 1-Jan-2010 or later.

 

Basing on the SYS$BASE_IMAGE.EXE link data reported by reply_6, this image results to be part of the following old patch kit (it included into the VMS732_SYS-V1600 path kit that was installed on the system ) :

 

 

DEC-AXPVMS-VMS732_SYS-V1100 (01-Nov-2006)

 

[SYS$LDR]SYS$BASE_IMAGE.EXE (new image)

         Image Identification Information         
         image name: "SYS$BASE_IMAGE"
         image file identification: "X-4"
         image file build identification: "XBCV-0060111050"
         link date/time: 6-SEP-2006 16:04:17.83
         linker identification:  "A11-50"
         Overall Image Checksum: 3468612897

 

 

To correct this issue, the author of this thread should apply the following patch kit , that is part of the  VMS732_UPDATE-V2500 (31-Oct-2012)

 

DEC-AXPVMS-VMS732_SYS-V2100   (18-Oct-2010)

 

[SYS$LDR]SYS$BASE_IMAGE.EXE (new image)

         Image Identification Information

         image name: "SYS$BASE_IMAGE"
         image file identification: "ALPHA XC3R-O2L"
         image file build identification: "XC3R-0060111095"
         link date/time: 11-MAY-2010 15:39:00.70
         linker identification:  "A11-50"
         Overall Image Checksum: 2870320181

 

 

I hope this helps.

Please use plain text.
Esteemed Contributor
H.Becker
Posts: 360
Registered: ‎04-09-2009
Message 9 of 46 (1,922 Views)

Re: Changes Boot behavior on XP1000 since 2013

> Applying a recent SYS kit, that replaces SYS$BASE_IMAGE, corrects the problem since the new SYS$BASE_IMAGE will have EXE$GQ_TODCBASE set to 1-Jan-2010 or later.
 
Whether it has a more recent date in EXE$GQ_TODCBASE depends on the build of the base image. The fact that it was linked in May-2010 doesn't imply this.
 
Anyway, which problem is corrected? The one that the "$ set time" wasn't issued? Or the one that "$ set time" didn't update the base image? Or the one that no recent sys patch/eco was applied? If there is no other reason to apply a patch I wouldn't want to do it just for such a problem. Other than finding out why the base image wasn't updated with "$ set time" I would use patch to write a recent date into the base image.
 
Please use plain text.
Frequent Advisor
Maurizio De Tommaso_
Posts: 40
Registered: ‎03-11-2004
Message 10 of 46 (1,915 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]
>>> Whether it has a more recent date in EXE$GQ_TODCBASE depends on the build of the base image. The fact that it was linked in May-2010 doesn't imply this.
 
The link date give me the possibility to track the version of the patch kit and then to take a look at the correspondent changes.
 
I suggest to install the latest Update kit VMS732_UPDATE-V2500 (that includes all the latest patches rating 1 and the VMS732_SYS-V2100, too).
 
In case the problem will persist, please elevate to your local HP support.
 
Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 11 of 46 (1,852 Views)

Re: Changes Boot behavior on XP1000 since 2013

Even with the lastest V7.3-2 patch (vms732_update-v2500)  the V7.3-2-XP1000 system asks for a new time value.

For we have a DS10 with V7.2-1 I have copied the sys$base_image.exe from the DS10 to the XP1000 with V7.2-1.

On DS10 the system boots without interrupt and on the XP1000 the systems asks for the new time again.

It seems that this strange behavior does not depend on the VMS version (see attachment itrc_2013_01_18_2.txt on earlier reply) nor on the sys$base_image.exe file; only XP1000 are concerned. So is it the firmware?

 

Here the output of the mentioned commands on our XP1000 with V7.3-2:

 

$ **bleep**/image/select=link sys$loadable_images:sys$base_image.exe
SYS$COMMON:[SYS$LDR]SYS$BASE_IMAGE.EXE;2
11-MAY-2010 15:39:00.70
$

$ prod show prod vms/full
------------------------------------ ----------- --------- ------------------------------------ ------------------------------------
PRODUCT                              KIT TYPE    STATE     MAINTENANCE                          REFERENCED BY
------------------------------------ ----------- --------- ------------------------------------ ------------------------------------
DEC AXPVMS VMS V7.3-2                Oper System Installed DEC AXPVMS VMS732_DCL V11.0          CPQ AXPVMS CDSA V2.0-109
                                                           DEC AXPVMS VMS732_MANAGE V8.0        DEC AXPVMS DFU V2.7
                                                           DEC AXPVMS VMS732_MUP V3.0           DEC AXPVMS DWMOTIF V1.3-1
                                                           DEC AXPVMS VMS732_PCSI V6.0          DEC AXPVMS FORTRAN V7.1-1
                                                           DEC AXPVMS VMS732_PCSI V5.0          DEC AXPVMS OPENVMS V7.3-2
                                                           DEC AXPVMS VMS732_SYS V21.0          DEC AXPVMS TCPIP V5.4-15ECO7
                                                           DEC AXPVMS VMS732_TDF V6.0           HP AXPVMS KERBEROS V2.0-6
                                                           DEC AXPVMS VMS732_TZ V3.0
                                                           DEC AXPVMS VMS732_UPDATE V25.0
                                                           DEC AXPVMS VMS732_UPDATE V22.0
                                                           DEC AXPVMS VMS732_UPDATE V21.0
------------------------------------ ----------- --------- ------------------------------------ ------------------------------------

1 item found

VMSINSTAL history file DISK$ESSSDA73_SYS:[VMS$COMMON.][SYSUPD]VMSINSTAL.HISTORY;1 contains additional information
$

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 12 of 46 (1,788 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Michael,

 

there is no debug output, which could be turned on at these low-level routines. To really find out what's wrong, you would probably need to use XDELTA to debug routine READ_SYSTEM_BBW in [SYSLOA]BBW_ROUTINES_DS1287. The most likely suspect here is the firmware/hardware. The chances to get that fixed - even if you would find out what's wrong - are pretty slim. Don't hope for a XP1000 SRM Firmware Upgrade ;-(

 

I would suggest to set TIMEPROMTWAIT=0 and try to come up with some DCL routine during startup, which fetches the 'correct' time from somewhere else (NTPDATE ?) and correctly sets the local time. Also try to run a job, which does a SET TIME = "''f$time()'" (like in SHUTDOWN.COM) from time to time, to make sure the time on disk is relatively current.

 

Other thoughts:

 

- is there any 'show time' or 'time' command at the XP1000 SRM prompt ? Or any other command, which may disply the time ?

- does the EXAMINE command on a XP1000 SRM console allow to examine to TOY device ?

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 13 of 46 (1,774 Views)

Re: Changes Boot behavior on XP1000 since 2013

Hallo Volker,

 

as a workaround we indeed have set TIMEPROMPTWAIT = 1 and use NTPDATE to set the time properly.

Also we have contemplated to run a batch job periodically to write the system time to disk.

 

If someone has a hardware service contract for a XP1000 with HP (this changed boot behavior is also monitored on XP1000 with VMS V8.4) , there are chances to get a new correct firmware working with VMS V7.2-1 or V7.3-2 too.

 

So has someone already made up a call to HP?

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 14 of 46 (1,755 Views)

Re: Changes Boot behavior on XP1000 since 2013

Michael,

 

using XDELTA to narrow down this problem is not impossible...

 

EXE$READ_BBW is a global symbol, so you can obtain this address with SDA from the running system or a crashdump. At an offset around +7C, you'll find the call to READ_SYSTEM_BBW, which actually is the routine, which reads the time from the BBW ! You'll need the source of this routine, which is in [SYSLOA]BBW_ROUTINES_DS1287 and a little bit of patience, to step through this routine and look at the values being read from the BBW chip...

 

SDA> exa/ins EXE$READ_BBW_C+0007C;4
EXE$READ_BBW_C+0007C:   BSR             R26,#X00004C      <<< calls #1, read_system_bbw
EXE$READ_BBW_C+00080:   BIS             R31,R0,R22
SDA> exa/ins EXE$READ_BBW_C+00080+4*4c;10
EXE$READ_BBW_C+001B0:   LDA             SP,#XFF80(SP)     <<< READ_SYSTEM_BBW: starts here
EXE$READ_BBW_C+001B4:   BIS             R31,#X02,R25
EXE$READ_BBW_C+001B8:   STQ             R26,#X0050(SP)
EXE$READ_BBW_C+001BC:   BIS             R31,R31,R31
EXE$READ_BBW_C+001C0:   STQ             R2,#X0058(SP)

 

 

I would not expect a lot of users having XP1000 hardware/software contracts with HP.

 

Volker.

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 15 of 46 (1,737 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Michael,

 

the first thing routine READ_SYSTEM_BBW checks, is whether the VALID bit in the D-register of the DS1287 chip is set. If not, it returns with SS$_IVTIME.

 

This call is the first BSR inside this routine:

 

EXE$READ_BBW_C+001EC:   BIS             R31,#X0D,R16
EXE$READ_BBW_C+001F0:   LDA             R27,#X0040(R2)
EXE$READ_BBW_C+001F4:   BSR             R26,#X000132    <<< call READ_DS1287
EXE$READ_BBW_C+001F8:   LDL             R0,#X0030(FP)   <<< check R0 here with XDELTA

EXE$READ_BBW_C+001FC:   LDQ             R1,#X0020(R2)

 

If R0 is %x80, the valid bit is set and the code continues. If not, the TOY clock value is invalid. So this may be what's happening, but without checking with XDELTA, it's just speculation...

 

If the valid bit is set, the code continues and reads the time and date from the TOY clock (DALLAS DS1287 chip). The date and time is stored in 2 quadwords on the stack and loaded into registers for further checking:

 

SDA> exa/ins exe$read_bbw_c+1b0+1dc-10;10
EXE$READ_BBW_C+0037C:   BSR             R26,#X0000D0
EXE$READ_BBW_C+00380:   LDQ             R1,#X0020(FP)    <<< 1st QW: hour, day, month, year
EXE$READ_BBW_C+00384:   LDL             R0,(R4)
EXE$READ_BBW_C+00388:   LDQ             R18,#X0028(FP)  <<< 2nd QW: minutes & seconds
EXE$READ_BBW_C+0038C:   LDQ             R25,#X0040(FP)

 

Volker.

 

 

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 16 of 46 (1,676 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Cross-reference:

 

This issue is also being discussed in comp.os.vms

 

e.g.

 

https://groups.google.com/group/comp.os.vms/browse_thread/thread/3710028ceddd2e3c?hl=de

 

And it looks like there may be more (older) systems affected.

 

Volker.

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 17 of 46 (1,643 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Here is how to obtain the date & time value read from the DALLAS DS1287 TOY chip during boot (in read READ_SYSTEM_BBW) for Alpha systems using this chip. This description can be used on a system showing the described behaviour to verify, whether the date & time read from the TOY clock are correct.

 

First obtain 2 virtual addresses from the instruction stream of routine READ_SYSTEM_BBW in the running system. Remember those virtual addresses, these are needed to set breakpoints once booted with XDELTA.

 

You may need to use different virtual addresses, if the instruction stream is slightly different, but I don't expect the READ_SYSTEM_BBW routine to have changed a lot over the last decade, although the instruction stream itself can change due to MACRO compiler version.

 

This example is from AlphaServer 400 with V7.3-2. Same instruction stream on AlphaServer 1000 with V8.2

 

FreeAXP - CHAALP $ ANALYZE/sys

OpenVMS (TM) system analyzer

SDA> exa/ins exe$read_bbw+1b0
EXE$READ_BBW_C+001B0:   LDA             SP,#XFF80(SP)   <<< READ_SYSTEM_BBW starts here

EXE$READ_BBW_C+001B4:   BIS             R31,#X02,R25
EXE$READ_BBW_C+001B8:   STQ             R26,#X0050(SP)
EXE$READ_BBW_C+001BC:   BIS             R31,R31,R31
EXE$READ_BBW_C+001C0:   STQ             R2,#X0058(SP)
EXE$READ_BBW_C+001C4:   STQ             R16,#X0040(SP)
EXE$READ_BBW_C+001C8:   STQ             R17,#X0048(SP)
EXE$READ_BBW_C+001CC:   LDA             R17,#X0030(SP)
EXE$READ_BBW_C+001D0:   STQ             R3,#X0060(SP)
EXE$READ_BBW_C+001D4:   STQ             R4,#X0068(SP)
EXE$READ_BBW_C+001D8:   STQ             FP,#X0070(SP)
EXE$READ_BBW_C+001DC:   STQ             R16,#X0038(SP)
EXE$READ_BBW_C+001E0:   STQ             R27,(SP)
EXE$READ_BBW_C+001E4:   BIS             R31,SP,FP
EXE$READ_BBW_C+001E8:   BIS             R31,R27,R2
EXE$READ_BBW_C+001EC:   BIS             R31,#X0D,R16
EXE$READ_BBW_C+001F0:   LDA             R27,#X0040(R2)
EXE$READ_BBW_C+001F4:   BSR             R26,#X000132   <<< call READ_DS1287 to check valid bit
EXE$READ_BBW_C+001F8:   LDL             R0,#X0030(FP)
EXE$READ_BBW_C+001FC:   LDQ             R1,#X0020(R2)
SDA> eva EXE$READ_BBW_C+001F8
Hex = FFFFFFFF.80018928   Decimal = -2147383000         EXE$READ_BBW_C+001F8

 

 

SDA> exa/ins exe$read_bbw+1b0+1d8-10;18
EXE$READ_BBW_C+00378:   BIS             R31,#X02,R25
EXE$READ_BBW_C+0037C:   BSR             R26,#X0000D0   <<< call READ_DS1287
EXE$READ_BBW_C+00380:   LDQ             R1,#X0020(FP)  <<< time_result low QW
EXE$READ_BBW_C+00384:   LDL             R0,(R4)
EXE$READ_BBW_C+00388:   LDQ             R18,#X0028(FP) <<< time_result high QW
EXE$READ_BBW_C+0038C:   LDQ             R25,#X0040(FP)
EXE$READ_BBW_C+00390:   SLL             R1,#X30,R17
SDA> eva EXE$READ_BBW_C+0038C
Hex = FFFFFFFF.80018ABC   Decimal = -2147382596         EXE$READ_BBW_C+0038C


>>>b -fl 0,6                                           <<< boot with XDELTA
(boot dka0.0.0.6.0 -flags 0,6)
block 0 of dka0.0.0.6.0 is a valid boot block
reading 1134 blocks from dka0.0.0.6.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 8dc00
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


    OpenVMS (TM) Alpha Operating System, Version V7.3-2
    © Copyright 1976-2003 Hewlett-Packard Development Company, L.P.


Brk 0 at 8000400C

8000400C!       BPT ;P                                          <<< proceed from initial breakpoint

 BRK - END OF INIT BREAKPOINT

Brk 0 at 8000400C

8000400C!       BPT G18928,1;B                         <<< set breakpoint after reading valid bit
;P                                                                         <<< proceed

Brk 1 at 80018928

80018928!       LDL             R0,#X0030(FP)  (New IPL = 3) S      <<< step
8001892C!       LDQ             R1,#X0020(R2) [B                           <<< set byte display mode
R0/80                                                                                            <<< examine R0, should be 80

 

G18ABC,2;B                                                              <<< set breakpoint after reading time_result
;P                                                                              <<< proceed

Brk 2 at 80018ABC

80018ABC!       LDQ             R25,#X0040(FP) S       <<< step
80018AC0!       SLL             R1,#X30,R17 [Q            <<< set quadword display mode
R1/0010001A 0001000D                                           <<< examine R1:  hh dd mm yy = 16 26 1 13
R18/00000000 00010016                                          <<< examine R18:       ss mm = 01 22

 

;B                                                                         <<< show all breakpoints
 1 80018928
 2 80018ABC

0,1;B                                                                    <<< delete breakpoint 1
0,2;B                                                                     <<< delete breakpoint 2
;B                                                                          <<< show all breakpoints -> none

;P                                                                           <<< proceed

%STDRV-I-STARTUP, OpenVMS startup begun at 26-JAN-2013 16:22:01.51  

                                    matches above date & time ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...

 

Enjoy and please report the results from testing on the various types of Alphas (together with the SRM Firmware Version).

 

Volker.

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 18 of 46 (1,620 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Here is another possible instruction stream seen (AlphaServer 4000, V8.3):

 

SDA> exa/ins exe$read_bbw_c+7c;10
EXE$READ_BBW_C+0007C:   BIS             R31,#X02,R25
EXE$READ_BBW_C+00080:   LDA             R27,#XF428(R2)
EXE$READ_BBW_C+00084:   BSR             R26,#XFFECC6   <<< calls READ_SYSTEM_BBW
EXE$READ_BBW_C+00088:   BIS             R31,R0,R23
EXE$READ_BBW_C+0008C:   BIS             R31,#X1F,R16

 

SDA> exa/ins EXE$READ_BBW_C+00088+4*ffFFECC6+30;20
SMP_STD$EXTENDED_HW_SETUP_C+005A0:      STQ             R17,#X0040(SP)
SMP_STD$EXTENDED_HW_SETUP_C+005A4:      LDA             R17,#X0030(SP)
SMP_STD$EXTENDED_HW_SETUP_C+005A8:      LDA             R27,#XFF60(R2)
SMP_STD$EXTENDED_HW_SETUP_C+005AC:      LDQ_U           R31,(SP)
SMP_STD$EXTENDED_HW_SETUP_C+005B0:      BSR             R26,#XFFFFC7  <<< call READ_DS1287
SMP_STD$EXTENDED_HW_SETUP_C+005B4:      LDL             R0,#X0030(FP)   <<< check R0=valid bit
SMP_STD$EXTENDED_HW_SETUP_C+005B8:      LDQ             R1,#X0020(R2)
SMP_STD$EXTENDED_HW_SETUP_C+005BC:      BIS             R31,#X4E,R16
SMP_STD$EXTENDED_HW_SETUP_C+005C0:      BIS             R31,#X0B,R17

 

SDA> exa/ins EXE$READ_BBW_C+00088+4*ffFFECC6+30+1c0;70
SMP_STD$EXTENDED_HW_SETUP_C+00760:      BIS             R31,#X02,R25
SMP_STD$EXTENDED_HW_SETUP_C+00764:      LDA             R27,#XFF60(R2)
SMP_STD$EXTENDED_HW_SETUP_C+00768:      BSR             R26,#XFFFF59   <<< call READ_DS1287
SMP_STD$EXTENDED_HW_SETUP_C+0076C:      LDQ             R0,#X0028(R2)
SMP_STD$EXTENDED_HW_SETUP_C+00770:      LDL             R18,#X0020(FP) <<< get time_result low LW
SMP_STD$EXTENDED_HW_SETUP_C+00774:      LDA             R1,#X076C(R31)
SMP_STD$EXTENDED_HW_SETUP_C+00778:      LDA             R16,#X07D0(R31)
SMP_STD$EXTENDED_HW_SETUP_C+0077C:      LDQ             R22,#X0020(R2)
SMP_STD$EXTENDED_HW_SETUP_C+00780:      BIS             R31,R31,R31
SMP_STD$EXTENDED_HW_SETUP_C+00784:      BIS             R31,#X0B,R17
SMP_STD$EXTENDED_HW_SETUP_C+00788:      BIS             R31,#X02,R25
SMP_STD$EXTENDED_HW_SETUP_C+0078C:      LDA             R27,#XFF78(R2)
SMP_STD$EXTENDED_HW_SETUP_C+00790:      LDL             R0,(R0)
SMP_STD$EXTENDED_HW_SETUP_C+00794:      SLL             R18,#X30,R3
SMP_STD$EXTENDED_HW_SETUP_C+00798:      ZAPNOT          R18,#XFC,R18
SMP_STD$EXTENDED_HW_SETUP_C+0079C:      SRA             R3,#X30,R3
SMP_STD$EXTENDED_HW_SETUP_C+007A0:      CMPLT           R3,R0,R0
SMP_STD$EXTENDED_HW_SETUP_C+007A4:      CMOVEQ          R0,R1,R16
SMP_STD$EXTENDED_HW_SETUP_C+007A8:      ADDQ            R3,R16,R3
SMP_STD$EXTENDED_HW_SETUP_C+007AC:      BIS             R31,#X4E,R16
SMP_STD$EXTENDED_HW_SETUP_C+007B0:      ZAPNOT          R3,#X03,R3
SMP_STD$EXTENDED_HW_SETUP_C+007B4:      BIS             R18,R3,R18
SMP_STD$EXTENDED_HW_SETUP_C+007B8:      STL             R18,#X0020(FP)
SMP_STD$EXTENDED_HW_SETUP_C+007BC:      LDL             R20,#X002C(FP)
SMP_STD$EXTENDED_HW_SETUP_C+007C0:      ZAPNOT          R20,#XFC,R20
SMP_STD$EXTENDED_HW_SETUP_C+007C4:      STL             R20,#X002C(FP)
SMP_STD$EXTENDED_HW_SETUP_C+007C8:      LDQ             R21,#X0038(FP)
SMP_STD$EXTENDED_HW_SETUP_C+007CC:      LDQ             R21,(R21)
SMP_STD$EXTENDED_HW_SETUP_C+007D0:      XOR             R21,#X01,R21

 

Depending on the system type and OpenVMS version, there may be other instructions streams.

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 19 of 46 (1,590 Views)

Re: Changes Boot behavior on XP1000 since 2013

Now we are able to read the hwc on XP1000; :

>>> e -b toy:0 -> secs

         e -b toy:2 -> mins

         e -b toy:4 -> hrs

         e -b toy:7 -> date

         e -b toy:8 -> month

         e -b toy:9 -> year offset

or together without secs

         e toy:2 -w -n 3

shows 4 (-n 3) halfwords (-w) beginning with address 2 (toy:2).

 

So we have made some tests on our XP1000 and have noticed:

>>> e toy:2 -w -n 3 shows the hwc time correct beginning with minutes and using year 2000 as base time (tested for years 2012 and 2013). After an >>> INIT on the boot prompt or after a power off (poweroff results in an INIT), the firmware changes the year byte if the byte is greater than 0C (0C -> 0C, 0D -> 5D, 10 -> 60).

The hwc shows this behavior:

 

VMS time 31.12.2012 23:45   2  772E       2E = 46 minute

                                                           4  BB17      17 = 23 hour

                                                           6  1F02       1F = 31 Day

                                                           8  0C0C        0C = 12 Month

                                                                                  0C = 12 Year + 2000 = 2012

 

after Poweroff                              2  7732        32 = 50

                                                           4  BB17

                                                           6  1F02

                                                           8  0C0C

 

after Poweroff for ~ 25 min      2  7712        12 = 18 minute

                                                           4  BB00         00 = 00 hour

                                                           6  0103         01 = 01 Day

                                                           8  5D01         01 = 01 Month

                                                                                   5D = 93 Year + 2000 = 2093 ?

 

boot with                                         2  770A         0A = 10

25-jan-2013 14:05                     4  BB0E          0E = 14

after shutdown                              6  1903         19 = 25

                                                            8  0D01         01 = 01

                                                                                    0D = 13 Year + 2000 = 2013

 

>>>INIT                                            2  770D         0D = 13

                                                           4  BB0E          0E = 14

                                                           6  1903         19 = 25

                                                           8  5D01          01 = 01

                                                                                    5D = 93

 

 

boot with 31.12.2012 23:50    2  7737         37 = 55

                                                            4  BB17         17 = 23

                                                            6  1F03         1F = 31

                                                            8  0C0C          0C = 12

                                                                                     0C = 12

 

after 10 minutes                            2  7700          00 = 00

                                                            4  BB00           00 = 00

                                                            6  0104           01 = 01

                                                            8  0D01           01 = 01

                                                                                      0D = 13    ,  after >>>INIT  0D -> 5D.

 

We have noticed too, that after year 2041 the time stays correct after an INIT, so only years between 2013 and 2040 (28 years) seem to be affected.

 

 

 

 

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 20 of 46 (1,587 Views)

Re: Changes Boot behavior on XP1000 since 2013

[ Edited ]

Michael,

 

thanks for sharing the details.

 

This means, that the Firmware seems to re-write the DALLAS DS1287 chip registers during INIT. Why ???

 

A generic solution would probably need a firmware update for all the Alpha system types affected.

 

For individual systems, this could be patched ! Routine READ_SYSTEM_BBW already modifies the time_result value for the YEAR read from the DALLAS TOY chip.

 

Something like:

 

IF time_result [tim$w_year] GEQ 93 THEN time_result [tim$w_year] = time_result [tim$w_year] - 80

 

(Assuming you won't ever run these systems with the time set into the last century, e.g. 19xx).

 

Did you ever try changing the wrong value after INIT and before booting with:

 

>>> d -b toy:9 0D

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 21 of 46 (1,577 Views)

Re: Changes Boot behavior on XP1000 since 2013

Volker,

 

I have just tested it (XP1000) after >>>init:

 

>>> d -b toy:9 0D  sets the year to 2013

 

>>> d -b toy:9 0E  sets the year to 2014.

 

My old alphastation 200 4/233  doesn't recognize the toy: syntax. It doesn't matter, it boots correct.

Please use plain text.
Occasional Visitor
Rob_Eulenstein
Posts: 1
Registered: ‎02-06-2013
Message 22 of 46 (1,414 Views)

Re: Changes Boot behavior on XP1000 since 2013

This issue appears to be related to the TOY clock implementation on some older Alpha systems following a “hard” INIT or power off.  The list of Alpha systems vulnerable to this problem is still being compiled.  The TOY clock in these older Alphas maintains a 2-digit year.  The value presented to OpenVMS jumped between 2012 and 2013 from 0C (12 decimal) to 5D (93 decimal).  We believe 2014 will be presented as 5E (94 decimal) and so on.  Testing is currently underway to confirm these values.

 

Given this 2-digit year from the TOY clock, OpenVMS uses the contents of EXE$GL_TRANSITION_YEAR to determine if the resulting 4-digit year should be 19xx or 20xx.  The current value in EXE$GL_TRANSITION_YEAR is 00000039 or 57 decimal.  Therefore, when OpenVMS sees the 93 decimal from the TOY clock, the year is set to 1993.  Since the hardware clock is now deemed to be in the past and therefore invalid, OpenVMS will prompt for the date and time to be entered at boot.

 

The following code segment is used by OpenVMS:

 

if .time_result [tim$w_year] GEQ .EXE$GL_TRANSITION_YEAR   

then

time_result [tim$w_year] = .time_result [tim$w_year] + 1900;

else                                                               

time_result [tim$w_year] = .time_result [tim$w_year] + 2000; 

 

OpenVMS engineering thought of the following fix / workaround for this issue.  In the above code, change the hardcoded 1900 to a 1920 (1920 + 93 = 2013).

 

This code lives in the SYS$CPU_ROUTINES_xxxx.EXE image.  The xxxx varies depending on the Alpha platform.  For one customer who was running on an AS1200, a patched SYS$CPU_ROUTINES_1605.EXE image was provided which did correct the problem.

 

The final/formal solution to this issue is still a work-in-progress.  If you are experiencing this issue please obtain the following information from the system:

 

1. The Alpha system type (XP1000, AS1200, etc.)

2. P00>>> e toy:2 -w -n 3

 

The output from the above examine command should be something similar to the following:

 

P00>>>e toy:2 -w -n 3

toy:                2 001B

toy:                4 0012

toy:                6 1D02

toy:                8 5D01

P00>>>

 

The 5D (93 decimal) in the word at offset 8 (5D01) is the year.

 

With this information in hand, please log a case through your normal customer support process, and please do watch for future updates on this issue.

 

Thank you.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 23 of 46 (1,359 Views)

Re: Changes Boot behavior on XP1000 since 2013

Which of the SYS$CPU_ROUTINES_xxxx.EXE is called by a XP1000 with VMS 7.2-1 or 7.3-2?

Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,203
Registered: ‎04-26-2004
Message 24 of 46 (1,357 Views)

Re: Changes Boot behavior on XP1000 since 2013

Michael,

 

this is NOT dependant on the OpenVMS version.

 

The execlet is being opened during OpenVMS boot, so you can check on the XP1000 with:

 

$ PIPE SHOW DEV/FILES SYS$SYSDEVICE | SEARCH SYS$PIPE SYS$CPU

 

Volker.

Please use plain text.
Frequent Advisor
Michael Menge
Posts: 59
Registered: ‎07-26-2005
Message 25 of 46 (1,329 Views)

Re: Changes Boot behavior on XP1000 since 2013

Volker,

 

I thought SYS$CPU_ROUTINES_xxxx.EXE would only be used for booting and wouldn't stay open any longer.

Your command shows SYS$CPU_ROUTINES_2208.EXE be open on XP1000.

A patch of this routine as mentioned before would result in a workaround for the next 20 years.

I have patched some VAX images 20 years ago using DISM32 to find the right position, but not yet an alpha image.

Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation