Title: | Alpha Support Conference |
Notice: | This is a new Alphanotes, please read note 2.2 |
Moderator: | VAXAXP::BERNARDO |
Created: | Thu Jan 02 1997 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 128 |
Total number of notes: | 617 |
Hello, I have a customer who is seeing something unusual. He recently upgraded an Alpha 2100 from OpenVMS Alpha V6.2 to V7.1. The system would crash at boot time due to a lowered PHYSICAL_MEMORY. He sets this on his 128 Meg system to 103, since he has some real-time process which they set aside 25 Meg for. This doesn't get started until VMS is up and running, then they log in to start this, so it shouldn't be affecting the boot. This has worked fine, and continues to, under V6.2 and V7.0. The console_version is V4.7-143 and palcoce_version is 5.56. Whenever he boots with PHYSICAL_MEMORY set to -1 or 128 (all memory) it boots ok. The other values he tried were 103, 100, 64 and 120. All these values produced the crash (console output below). The most infomation is with verbose flag 20000 (nothing additional with 10000). P00>>> b dkb100 (boot dkb100.1.0.1008.0 -flags 0) block 0 of dkb100.1.0.1008 is a valid boot block reading 904 blocks from dkb100.1.0.1008.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 71000 initializing HWRPB at 2000 initializing page table at 7ff0000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code OpenVMS(TM) Alpha Operating System, Version V7.1 ************************************************************** * Exception taken before exception handler has been loaded * * Unable to take crash dump! * ************************************************************** Translation not valid through vector 00000090 R00: 00000000 00000000 R01: 00000000 00003FF8 R02: FFFFFFFF 80056C40 R03: 00000090 82532A20 R04: FFFFFFFE 0009FED4 R05: 00000000 00000000 R06: FFFFFFFE 00000000 R07: 00000000 00000400 R08: 00000000 00002000 R09: 00000000 00000400 R10: 00000000 000003FF R11: FFFFFFFF 83190000 R12: FFFFFFFF 80C186C0 R13: FFFFFFFF 80C18000 R14: FFFFFFFF 833E7FD8 R15: FFFFFFFE 0009FEC0 R16: 00000000 00000000 R17: 00000000 00000000 R18: 00000000 00000000 R19: 00000000 00000001 R20: FFFFFFFF 83190000 R21: 00000000 00000000 R22: 00000000 000003FE R23: FFFFFFFF 82507288 R24: 00000000 00000001 R25: 00200000 3FFFFFF7 R26: FFFFFFFE 00000000 R27: FFFFFFFF 82506E18 R28: FFFFFFFF 82505000 R29: FFFFFFFF 82297F70 R30: 83397F00: FFFFFFFD FF7FDFF0 Saved R02 83397F08: 00000000 000003FE Saved R03 83397F10: FFFFFFFD FF800000 Saved R04 83397F18: 00000000 00000400 Saved R05 83397F20: FFFFFFFE 00000000 Saved R06 83397F28: 00000000 00000400 Saved R07 83397F30: FFFFFFFF 833CDA78 Exception PC 83397F38: 30000000 00001F00 Exception PS 82F23F40: FFFFFFFF 82F71AA9 82F23F48: FFFFFFFF 82F59590 82F23F50: FFFFFFFF 82D1C000 82F23F58: FFFFFFFF 80C18000 82F23F60: 00000000 82D1C000 82F23F68: 40100408 82F71AA9 82F23F70: FFFFFFFF 82F73FD8 82F23F78: 00000000 00000000 82F23F80: 00000000 000196B4 82F23F88: 00000000 00000A00 82F23F90: 00000000 000063A0 82F23F98: 00000000 00000001 82F23FA0: FFFFFFFF 80C18000 82F23FA8: 00000000 59532536 82F23FB0: 00000000 00000001 82F23FB8: 00000000 00000000 82F23FC0: 00000000 00000000 82F23FC8: 00000000 00000000 82F23FD0: 00000000 000550A8 82F23FD8: 00000000 00000B38 82F23FE0: 00000000 00000000 82F23FE8: 00000000 00000000 82F23FF0: 00000000 00000000 82F23FF8: 00000000 200B7F50 halted CPU 0 halt code = 5 HALT instruction executed PC = ffffffff833bc0c8 boot failure P00>>> After setting physical_memory back to -1, I had him boot the system and run SDA. SDA> Eval 833bc0c8 Hex = ffffffff.833BC0C8 DECIMAL = -2093236024 SDA> map 833bc0c8 SDA-E-NOTINIMAGE, address (833BC0C8) not within a system or user image. Lastly, he tried setting physical_memory to 103 on an Alphastation 250 4/266 that was upgraded to V7.1 recently (same CD as used for the 2100). The PHYSICAL_MEMORY on this system had always been left at -1. It had no problem booting, and show memory reported 103MB of memory as expected. Like the 2100, the Alphastation has 128MB of memory. He will be attempting to upgrade a 4100 to V7.1 today to see if that system has the same problem. The last two messages prior to the crash (also seen when there is no crash) are: %EXECINIT-I-FREEBS, freeing bootstrap space PFNs %EXECINIT-I-PFNDB, building PFN database Any ideas would be appreciated. Thank you. Peter King CSC Colorado, Internals/drivers team
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
67.1 | ZIMBRA::BERNARDO | Dave Bernardo, VMS Engineering | Mon Mar 24 1997 18:40 | 5 | |
Without the full output from all the boot messages there's no way to know what that system space address belongs to, and no way to tell you what is wrong. d. | |||||
67.2 | b -fl 0,30000 | STAR::jacobi.zko.dec.com::jacobi | Paul A. Jacobi - OpenVMS Systems Group | Tue Mar 25 1997 13:00 | 6 |
Try booting with flags of 0,30000 to obtain more information about loaded images. -Paul | |||||
67.3 | CLOUD::SHIRRON | Stephen F. Shirron, 223-3198 | Wed Mar 26 1997 11:49 | 9 | |
Can the customer downgrade to the V4.6 console? I made a change in the V4.7 console which moved the page tables built by the boot command from low memory to high memory. Apparently this is interacting with a change that OpenVMS made between V7.0 and V7.1 in how PHYSICAL_MEMORY is treated. I will work on this problem with OpenVMS and report back here when it is resolved. stephen | |||||
67.4 | more from the customer | CSC32::KING | Wed Mar 26 1997 14:57 | 178 | |
Thank you for the replies so far. I will suggest the customer try downgrading the console. This customer has been doing further testing. He sees this problem on an Alpha 2100 4/233 and a 2100 4/200, but not on an Alphastation 250 4/266 or a 4100. Here are the results of boot -flags 0,30000 dkb100. The information prior the the message "jumping to bootstrap code" and the lines beginning with "BOOT QIO:VA = " have been omitted to make the large amount of data a little smaller. This boot was attempted with PHYSICAL_MEMORY = 103. P000>>> b -fl 0,30000 dkb100 <Several lines omitted> jumping to bootstrap code %APB-I-APBVER, Alpha primary bootstrap, version X6C7 Initializing Xdelta... Initial breakpoint not taken... Checking PAL code revision... Creating APBs memory pool... Initializing TIMEDWAIT constants... %APB-I-BOOTDEV, determining bootdevice type Initializing the system root specification... %APB-I-BOOTDRIV, Selecting boot driver %APB-I-BOOTFILE, Selecting boot file %APB-I-BOOTVOL, Bootvol, mounting boot volume < 4 lines omitted beginning with BOOT QIO:VA= > %APB-I-SYSROOT, System root is [SYS0.] < 10 lines omitted beginning with BOOT QIO:VA= > %APB-I-LOADFILE, Loading [sys0.syscommon.sysexe]sysboot.exe;1 < 2 lines omitted beginning with BOOT QIO:VA= > %APB-I-SECBOOT, Transferring to secondary bootstrap %SYSBOOT-I-WLCM, Welcome to Alpha secondary bootstrap. Initializing the boot SCB Initializing Xdelta %SYSBOOT-I-LOADPARAM, Loading parameter file alphavmssys.par < 2 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSEXE]ALPHAVMSSYS.PAR;19 Creating the PFN memory map %SYSBOOT-I-CREATSPACE, Creating page table space %SYSBOOT-I-SYSPGTBL, Creating the system page tables %SYSBOOT-I-ALLOCPGS, Allocating loader huge pages Allocating physical memory for execlet code huge page Allocating physical memory for data huge page Allocating physical memory for VMS exec data huge page Allocating physical memory for resident image code huge page Allocating physical memory for VMS S2 exec data huge page Mapping execlet code huge page Mapping resident image code huge page Mapping VMS exec data huge page Allocating nonpaged pool expansion region Mapping execlet data huge page Mapping VMS S2 exec data huge page %SYSBOOT-I-LOADIMGS, Loading the base system images < 5 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYS$PUBLIC_VECTORS.EXE;1 < 9 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYS$BASE_IMAGE.EXE;1 < 4 lines omitted beginning with BOOT QIO:VA= > Fixing up sysboot references to the base images %SYSBOOT-I-INITDATA, Initialize MMG/loader/misc. system data cells Creating the balance set slots Creating then SYSPHD swp$gl_sysphd = 80C00000 mmg$gq_syswsl = 80C00448 Creating pool Allocating PAGED pool mmg$gl_pagedyn = 828E8000 Allocating NONPAGED pool mmg$gl_npagedyn - 80C18000 mmg$gl_npagnext = 810FA000 Allocating error log buffers exe$gl_scb = 82CD0000 Creating the primary CPU database Remapping file cache in system space Disconnecting the boot driver Remapping the memory descriptors into system space %SYSBOOT-I-REMAP. Remap HWRPB/SWRPB SWRPB = 80C186C0 HWRPB = 82D1C000 Moving the boot IO vector into system space Initializing the boot driver Initializing the primary CPU db and kstack Allocating the system kernel stack Kernel stack pointer/base = 82F24000 %SYSBOOT-I-ALLOCPCB, Allocate boot control block < 2 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-BITMAP, Opening bitmap.sys < 1 line omitted beginning with BOOT QIO:VA= > Creating the PFN database pfn$pq_database = FFFFFFFE00000000 %SYSBOOT-I-LOADEXEC, Loading boot driver execlets < 1 line omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYS$CNBTDRIVER.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > Loading execlets <1 line omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYS$OPDRIVER.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYSTEM_SYNCHRONIZATION_MIN.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]ERRORLOG.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]SYS$CPU_ROUTINES_0902.EXE;1 < 7 lines omitted beginning with BOOT QIO:VA= > %SYSBOOT-I-LOADFILE, Loading [SYS0.SYSCOMMON.SYS$LDR]EXEC_INIT.EXE;1 < 5 lines omitted beginning with BOOT QIO:VA= > Copying the LDR$GQ_HPDESC to pool %SYSBOOT-I-INITARG, Init boot param arglist for EXEC_INIT Copying boot port allocls list Disconnecting the boot driver %IOC$DISC_BOOT-I-ENTER_ROUTINE, Entered reoutine. %IOC$DISC_BOOT-I-DISC_PBD, Disconnecting from primary boot device %IOC$DISC_BOOT-I-EXIT-ROUTINE, Exiting routine. Copying the system parameters to base image. Swap boot process context to system process. %SYSBOOT-I-EXECINIT,Transferring control to EXEC_INIT %EXECINIT-I-PERCPU, Initializing per CPU database %EXECINIT-I-INITSS, Calling initialization routines %LOADER-I-INIT, Initializing SYS$CNBTDRIVER.EXE %LOADER-I-INIT, Initializing SYS$OPDRIVER.EXE %LOADER-I-INIT, Initializing SYSTEM_PRIMITIVES_MIN.EXE %LOADER-I-INIT, Initializing SYSTEM_SYNCHRONIZATION_MIN.EXE %LOADER-I-INIT, Initializing ERRORLOG.EXE %LOADER-I-INIT, Initializing SYS$CPU_ROUTINES.0902.EXE OpenVMS(TM) Alpha Operating System, Version V7.1 %EXECINIT-I-FREEBS, freeing bootstrap space PFNs %EXECINIT-I-PFNDB, building PFN database THE CRASH OCCURS HERE | |||||
67.5 | CLOUD::SHIRRON | Stephen F. Shirron, 223-3198 | Wed Mar 26 1997 15:17 | 5 | |
The customer's observations seem correct. I only made the change to move the page tables to high memory on the 2000, 2100, 2100A, 1000, and 1000A. I did not change the 250 or the 4100. stephen | |||||
67.6 | ZIMBRA::BERNARDO | Dave Bernardo, VMS Engineering | Wed Mar 26 1997 17:45 | 11 | |
re: .4 Thanks, but it was the BOOT QIO VA messages that I needed! That's the only way to determine where the execlets are loaded. But, Stephen has already found the failure in EXEC_INIT. The change in the console has exposed this problem, so hopefully downgrading it will be an acceptable workaround until I can get a fix out. | |||||
67.7 | it is a V4.7 SRM problem. | CSC32::KING | Thu Mar 27 1997 13:13 | 8 | |
Thank you. That definately seem to be the problem. My customer did not have SRM V4.6-201, but did have V4.5-51, so he tried this, and the system booted fine with a lowered PHYSICAL_MEMORY. Both of these versions show as supporting OpenVMS V7.0, so is it ok to use this with V7.1 in the interim? Should I IPMT This, or just watch for a reply here? Peter | |||||
67.8 | ZIMBRA::BERNARDO | Dave Bernardo, VMS Engineering | Thu Mar 27 1997 17:03 | 4 | |
If you IPMT the problem it will be easier for me to get the fix out, so yes, please do. I will also post a note when the fix is ready. d. |