[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

603.0. "Any "recent" vax sysgen changes in driver size max?" by STAR::EVERHART () Thu May 15 1997 11:30

    Someone reported to me that a VAX pseudo driver I've had for some
    time stopped working on VMS 7.1 vax. I have verified this.
    
    The driver in fact refuses to load, and crashes VMS when loaded.
    It crashes in sysgen attempting to load the driver (2nd movc in
    a row, a movc 8(r9),(r9),(r11) that is copying the driver to a
    kernel buffer). I've looked briefly and seen nothing odd, and
    a related driver works fine.
    
    The difference between the two is that the driver that now fails
    has a sizable (8k or so bytes) buffer allocated with a .BLKL
    in the driver itself. The driver that succeeds grabs the buffer
    from pool at runtime.
    
    Anyone know of a change in vax sysgen between 6.2 and 7.1 that
    could affect the loading? I intend to continue to look at this
    as time permits but the system is acting as though the max
    size allocated for a driver has dropped dramatically.
    glenn everhart
T.RTitleUserPersonal
Name		DateLines
603.1CSC64::BLAYLOCKIf at first you doubt,doubt again.Thu May 15 1997 14:5112

The size of a device driver on OpenVMS VAX systems is still
65K�.  That is, the DPT$W_SIZE is still the same and the largest chunk
of non-paged pool is limited to a word (IRP$W_SIZE).

Is it possible that by adding the 8K static buffer, the DPT$W_SIZE
value is a modulo value of 65535?


� The DUDRIVER and SHADRIVER get around this by making SYSINIT/SYSGEN believe
they are loadable execlets.
603.2dtp$w_size is okSTAR::EVERHARTThu May 15 1997 15:0112
    No, dtp$w_size is still well within legal range as in the past.
    The surprising thing was that the thing stopped working; no changes
    had been made in ages, yet the 3100 wouldn't load it. I've been
    well aware of the 64K (k=1024) size limit for some time. The
    /list/show=binary shows dptab perfectly legal in appearance.
    
    Granted, the thing has the same name as a DEC driver (fqdriver)
    BUT the relevant DEC driver is not loaded and the file is renamed
    prior to attempting to load the thing (and the crash can be
    reproduced with a non colliding name too). The crash dump of course
    shows no structures for the driver connected anywhere.
603.3Check DPTXDELTA::HOFFMANSteve, OpenVMS EngineeringThu May 15 1997 15:0514
   I've typically used storage in or via the UCB, and have not tried to
   incorporate (potentially non-reentrant) data psects into the driver
   image.  I have had problems when trying to use multi-module drivers,
   and drivers with multiple psects.

   .0 sounds like a pretty good guess -- it sounds like you might have
   tripped over a 64K limit, as that would be one of the few typical
   reasons one would choose to use two MOVCs in a row to load a driver.

   Just for grins, see if enough of the DPT is in the dump -- or take
   a look at the driver directly -- and see what the driver looks like
   to the loader.
603.4CSC64::BLAYLOCKIf at first you doubt,doubt again.Thu May 15 1997 15:5415
.    It crashes in sysgen attempting to load the driver (2nd movc in
.    a row, a movc 8(r9),(r9),(r11) that is copying the driver to a
.    kernel buffer). I've looked briefly and seen nothing odd, and

I guess then, I would say "Crashes How?"  I presume an ACCVIO error.
I don't see a loop in LOADDRIV.LIS that would indicate a second chance
at the 

18$:    MOVC    DPT$W_SIZE(R9),(R9),(R11) ;MOVE DRIVER TO THE BUFFER

line.

What does a FORMAT @R9/type=dpt show?

What does a SEARCH FQDRIVER.MAP "VIRTUAL MEMORY" show?
603.5please send crash footprint to CANASTAHAN::HALLEVolker Halle MCS @HAO DTN 863-5216Fri May 16 1997 02:5726
    Re: .0
    
    Glenn,
    
    could you please obtain the CLUE file and send it to the CANASTA Mail
    Server. Just to document this crash footprint and see, whether others
    have seen this kind of crash before.
    
    Please use the following mail command:
    
    $ MAIL CLUE$OUTPUT:CLUE$LAST_node.LIS XOCOMP::CAN_SERVER -
    	/subj="DIAGNOSE CASE=VMSNOTES_603 customer=notes_on_vaxaxp"
    
    You can also extract the CLUE file from the crash history file with:
    
    $ CLUE:==$CLUE
    $ CLUE/DISPL
    CLUE> extract/out=x.x n		(where n is the crash number)
    
    and then mail the x.x file ...
    
    Thanks,
    
    Volker
    
    PS: You can find more infor about CANASTA in note 233
603.6LINK behaves differently than in 6.2...STAR::EVERHARTFri May 16 1997 15:06360
    I have done some further analysis and the difference seems to be a
    change in LINK so the driver image no longer has the array stuff in
    it. Is a workaround available?
    
    Here are the specifics

SDA> form @r9
00072000   DPT$B_STR_STRUC                       00
           DPT$L_FLINK
00072001                                   000000
00072004   DPT$L_BLINK                     00000000
00072008   DPT$W_SIZE                          29D2
0007200A   DPT$B_TYPE                        1E
0007200B   DPT$B_REFC                      00
0007200C   DPT$B_ADPTYPE                         05
0007200D                                       00
0007200E   DPT$W_UCBSIZE                   0150
00072010   DPT$B_FLAGS                           02
           DPT$L_FLAGS
00072011                                   000001
00072014   DPT$W_INITTAB                       0082
00072016   DPT$W_REINITTAB                 00C9
00072018   DPT$W_UNLOAD                        0000
0007201A   DPT$W_MAXUNITS                  0002
0007201C   DPT$W_VERSION                       0005
0007201E   DPT$W_DEFUNITS                  0002
00072020   DPT$W_DELIVER                       0000
00072022   DPT$W_VECTOR                    0000
00072024   DPT$T_NAME                      "FQDRIVER"
00072024                                   44514608
00072028                                   45564952
0007202C                                   00000052
00072030   DPT$Q_LINKTIME                  00000000
00072034                                   00000000
00072038   DPT$L_ECOLEVEL                  00000000
0007203C   DPT$L_UCODE                     00000000
00072040   DPT$Q_LMF_1                     00000000
00072044                                   00000000
00072048   DPT$Q_LMF_2                     00000000
0007204C                                   00000000
00072050   DPT$Q_LMF_3                     00000000
00072054                                   00000000
00072058   DPT$Q_LMF_4                     00000000
0007205C                                   00000000
00072060   DPT$Q_LMF_5                     00000000
00072064                                   00000000
00072068   DPT$Q_LMF_6                     00000000
0007206C                                   00000000
00072070   DPT$Q_LMF_7                     00000000
00072074                                   00000000
00072078   DPT$Q_LMF_8                     00000000
0007207C                                   00000000
00072080   DPT$W_DECW_SNAME                    0000
           DPT$C_LENGTH
System crash information
------------------------
Time of system crash: 11-MAY-1996 15:14:03.79


Version of system: OpenVMS (TM) VAX Version V7.1

System Version Major ID/Minor ID: 1/0


System type: VAXstation 3100/SPX

Crash CPU ID/Primary CPU ID:  00/00

Bitmask of CPUs active/available:  00000001/00000001


CPU bugcheck codes:
        CPU 00 -- SSRVEXCEPT, Unexpected system service exception
CPU 00 Processor crash information
----------------------------------


CPU 00 reason for Bugcheck: SSRVEXCEPT, Unexpected system service exception


Process currently executing on this CPU: GCE


Current image file: ROW$DKB100:[SYS0.SYSCOMMON.][SYSEXE]SYSGEN.EXE


Current IPL: 0  (decimal)


CPU database address:  8207E000


General registers:

        R0  = 00000009   R1  = 7FFE778C   R2  = 000029D2   R3  = 81AE7EC0
        R4  = 00000000   R5  = 000000C9   R6  = 00000020   R7  = 0001B7CC
        R8  = 0001AA32   R9  = 00072000   R10 = 00002A00   R11 = 81AE7EC0
        AP  = 7FFE7768   FP  = 7FFE7750   SP  = 7FFE7750   PC  = 817479E3
        PSL = 00000000




Processor registers:


        P0BR   = 825B3000     SBR    = 01F67200     ASTLVL = 00000004
        P0LR   = 00000397     SLR    = 0001D980     SISR   = 00000000
        P1BR   = 81DF3000     PCBB   = 00992A20     ICCS   = 00000040
        P1LR   = 001FF454     SCBB   = 01F60E00     SID    = 0A000005

        TODR    = 53CA331F    CADR   = 000000FC
        CACR    = AFFFC154    MSER   = 00000000
CPU 00 Processor crash information
----------------------------------
        ISP    = 8207F600
        KSP    = 7FFE7750
        ESP    = 7FFE9800
        SSP    = 7FFECA44
        USP    = 7FE8CE78

                No spinlocks currently owned by CPU 00
         SP =>  7FFE7750  00000000
                7FFE7754  00000000
                7FFE7758  7FE8CECC
                7FFE775C  7FFE77A8      CTL$GL_KSTKBAS+005A8
                7FFE7760  80000014      EXE$QIOW_3+00004
                7FFE7764  8174A2D1      EXE$CONTSIGNAL+0007C
                7FFE7768  00000002
                7FFE776C  7FFE778C      CTL$GL_KSTKBAS+0058C
                7FFE7770  7FFE7774      CTL$GL_KSTKBAS+00574
                7FFE7774  00000004
                7FFE7778  7FFE77E4      CTL$GL_KSTKBAS+005E4
                7FFE777C  FFFFFFFD      LKB$K_SCSWAIT
                7FFE7780  05C029D2
                7FFE7784  00072000
                7FFE7788  000008F8      BUG$_SYSAPLERR
                7FFE778C  00000005

                7FFE7790  0000000C
                7FFE7794  00000001
                7FFE7798  000749D0
                7FFE779C  00007391
                7FFE77A0  08C00004
                7FFE77A4  00000001
                7FFE77A8  00000000
                7FFE77AC  0FFC0000
                7FFE77B0  7FE8CE94
                7FFE77B4  7FFE77E4      CTL$GL_KSTKBAS+005E4
                7FFE77B8  8179DA11      EXE$CMKRNL+0000D
                7FFE77BC  00011148
                7FFE77C0  000012A0      VCRP$K_EC_DLL_LAST+00095
                7FFE77C4  81AE0B80

SDA> exam/inst 7340:7391
%SDA-W-INSKIPPED, unreasonable instruction stream - 1 bytes skipped
00007341:  INCB    @#C14BFFFF
00007347:  NOP
00007348:  EXTZV   (R6)+,@#C251FFFF,VCRP$K_EC_DLL_LAST+000C4,R1
00007355:  MOVL    R1,R5
00007358:  ADDL2   #10,R1
0000735B:  JSB     @#V_EXE$ALONPAGVAR
00007361:  BLBS    R0,00007373
00007364:  MOVW    R10,08(R11)
00007368:  MOVL    R11,R0
0000736B:  JSB     @#V_EXE$DEANONPAGED
00007371:  BRB     0000732E
00007373:  MOVL    R2,VCRP$K_EC_DLL_LAST+000CC
0000737A:  MOVAL   08(R2),R2
0000737E:  MOVW    R1,(R2)+
00007381:  MOVW    #0062,(R2)+
00007386:  MOVL    R1,(R2)+
00007389:  MOVC3   R5,@VCRP$K_EC_DLL_LAST+000C4,(R2)
00007391:  MOVC3   08(R9),(R9),(R11)
00007396:  BISL2   VCRP$K_EC_DLL_LAST+000BE,10(R11)


This is inside SYSGEN trying to copy the driver into memory.
SDA> exam @r9;20
01500005 001E29D2 00000000 00000000  ........�)....P.     00072000
00020005 00020000 00C90082 00000102  ......�.........     00072010


SDA> exam @r11;20
FFFFFFFF FFFFFFFF 00042A00 81AEA8C0  ��..*..........     81AE7EC0
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF  ................     81AE7ED0


Problem seems to be the bulk of the driver isn't in memory
SDA> exam 749d0
%SDA-E-NOTINPHYS, 000749D0 : virtual data not in physical memory
SDA> exam 72000+29d2
%SDA-E-NOTINPHYS, 000749D2 : virtual data not in physical memory
SDA> exam 72000+29cf
%SDA-E-NOTINPHYS, 000749CF : virtual data not in physical memory
SDA> exam 72000+29c0
%SDA-E-NOTINPHYS, 000749C0 : virtual data not in physical memory
SDA> exam 72000+2900
%SDA-E-NOTINPHYS, 00074900 : virtual data not in physical memory
SDA> exam 72000+2200
%SDA-E-NOTINPHYS, 00074200 : virtual data not in physical memory
SDA> exam 72000+2000
%SDA-E-NOTINPHYS, 00074000 : virtual data not in physical memory
SDA> exam 72000+1000
%SDA-E-NOTINPHYS, 00073000 : virtual data not in physical memory
SDA> exam 72000+0800
00072800:  008CC52C   ",�.."

so the copy-from address is invalid.

SDA> exam 72000+0c00
00072C00:  0000BC0F   ".�.."
SDA> exam 72000+0d00
00072D00:  00000000   "...."
SDA> exam 72000+0e00
%SDA-E-NOTINPHYS, 00072E00 : virtual data not in physical memory

So the area loaded is 0000 - 0dff (720df0 is ok).
That is 7 blocks' worth, the size of the driver image.



From the map file
   Cluster      Type Pages   Base Addr  Disk VBN PFC Protection and Paging     $
   -------      ---- -----   ---------  -------- --- ---------------------     $

DEFAULT_CLUSTER    0     5    00000000          2   0 READ WRITE   COPY ON REF
                   0    16    00000A00          0   0 READ WRITE   DEMAND ZERO
                   0     1    00002A00          7   0 READ WRITE   FIXUP VECTORS
                 253    20    7FFFD800          0   0 READ WRITE   DEMAND ZERO

                                                 +----------------+
                                                 ! Image Synopsis !
                                                 +----------------+

Virtual memory allocated:                         00000000 00002BFF 00002C00 (1$
Stack size:                                             20. pages
Image header virtual block limits:                       1.        1. (    1. b$
Image binary virtual block limits:                       2.        7. (    6. b$
Image name and identification:                    FQDRIVER V02-003CB
System component mask:                             0004803C
        SYS$K_VERSION_IO                                 1,81
        SYS$K_VERSION_FILES_VOLUMES                      2,0
        SYS$K_VERSION_PROCESS_SCHED                      1,81
        SYS$K_VERSION_SYSGEN                             1,81
        SYS$K_VERSION_VOLATILE                           1,80
        SYS$K_VERSION_MULTI_PROCESSING                   1,1
Number of files:                                         4.
Number of modules:                                       3.
Number of program sections:                              5.
Number of global symbols:                               36.
Number of image sections:                                4.
Debugger transfer address:                        7FFEDF68
Image type:                                       EXECUTABLE.
Map format:                                       FULL in file SYS$SYSDEVICE:[E$
Estimated map length:                             21. blocks


Thus the binary limits are 7 blocks, but there is a bunch of extra data
which is supposed to be "there" but is not apparently used.




Now if I link the same source...no changes at all...on VMS 6.2 Vax
the file is 24 blocks long, not 8, and the map contains this:

                                             +------------------------+
                                             ! Image Section Synopsis !
                                             +------------------------+

   Cluster      Type Pages   Base Addr  Disk VBN PFC Protection and Paging     $
   -------      ---- -----   ---------  -------- --- ---------------------     $

DEFAULT_CLUSTER    0    21    00000000          2   0 READ WRITE   COPY ON REF
                   0     1    00002A00         23   0 READ WRITE   FIXUP VECTORS
                 253    20    7FFFD800          0   0 READ WRITE DEMAND ZERO




and



                                                 +----------------+
                                                 ! Image Synopsis !
                                                 +----------------+

Virtual memory allocated:                         00000000 00002BFF 00002C00 (1$
Stack size:                                             20. pages
Image header virtual block limits:                       1.        1. (    1. b$
Image binary virtual block limits:                       2.       23. (   22. b$
Image name and identification:                    FQDRIVER V02-003CB
System component mask:                             0004803C
        SYS$K_VERSION_IO                                 1,81
        SYS$K_VERSION_FILES_VOLUMES                      2,0
        SYS$K_VERSION_PROCESS_SCHED                      1,81
        SYS$K_VERSION_SYSGEN                             1,81
        SYS$K_VERSION_VOLATILE                           1,80
        SYS$K_VERSION_MULTI_PROCESSING                   1,1
Number of files:                                         4.
Number of modules:                                       3.
Number of program sections:                              5.
Number of global symbols:                               36.
Number of image sections:                                3.
Debugger transfer address:                        7FFEDF68
Image type:                                       EXECUTABLE.
Map format:                                       FULL in file SYS$SYSDEVICE:[E$
Estimated map length:                             21. blocks


If now I link the .OBJ file assembled under VMS V7.1 with the VMS 6.2 linker
the executable is again 24 blocks long, not just 8, and the link map shows
this:
                                             +------------------------+
                                             ! Image Section Synopsis !
                                             +------------------------+

   Cluster      Type Pages   Base Addr  Disk VBN PFC Protection and Paging     $
   -------      ---- -----   ---------  -------- --- ---------------------     $

DEFAULT_CLUSTER    0    21    00000000          2   0 READ WRITE   COPY ON REF
                   0     1    00002A00         23   0 READ WRITE   FIXUP VECTORS
                 253    20    7FFFD800          0   0 READ WRITE DEMAND ZERO

                                                 +----------------+
                                                 ! Image Synopsis !
                                                 +----------------+

Virtual memory allocated:                         00000000 00002BFF 00002C00 (1$
Stack size:                                             20. pages
Image header virtual block limits:                       1.        1. (    1. b$
Image binary virtual block limits:                       2.       23. (   22. b$
Image name and identification:                    FQDV7OBJ V02-003CB
System component mask:                             0004803C
        SYS$K_VERSION_IO                                 1,81
        SYS$K_VERSION_FILES_VOLUMES                      2,0
        SYS$K_VERSION_PROCESS_SCHED                      1,81
        SYS$K_VERSION_SYSGEN                             1,81
        SYS$K_VERSION_VOLATILE                           1,80
        SYS$K_VERSION_MULTI_PROCESSING                   1,1
Number of files:                                         4.
Number of modules:                                       3.
Number of program sections:                              5.
Number of global symbols:                               36.
Number of image sections:                                3.
Debugger transfer address:                        7FFEDF68
Image type:                                       EXECUTABLE.
Map format:                                       FULL in file SYS$SYSDEVICE:[E$
Estimated map length:                             21. blocks


The linkage in all cases is done the same way:

$ link fqdriver+sys$system:sys.stb/sel+sys$input/opt
base=0
$
603.7ZIMBRA::BERNARDODave Bernardo, VMS EngineeringFri May 16 1997 15:213
    It's probably the demand zero stuff... you can't have demand zero pages
    in a driver. You need to include a DZRO_MIN statement in your options
    file.
603.8Found a workaroundSTAR::EVERHARTFri May 16 1997 15:255
    I have answered my own question. If you link the .OBJ on VMS 7.1
    with /system=0/head
    the loader gets things all right and works.
    The driver image is then larger also.