| --------------------------------------------------------------------------------
Regarding the first dump that seem to be a coding problem in inetdriver code
as we discussed on the phone.
--------------------------------------------------------------------------------
The second one has the following call sequence (this I got from show call
- show call/next sequence, searching on Saved PC to get this extract).
This shows all the return pcs, newest at the top...
823C8548
81E00EC6 EXDRIVER+01006
80369B20
80368C0F
8036AD78
8036AEBD
80368B02
80370478
80375CAA
80376BF8
80376756
80378676
80378357
81EA7AF3 INETDRIVER+008C3
804F8020 EXE$EXCEPTION+00225 ! system service despatch call frame.
8055C9B2 * EXE$RUNDWN+001D2 ! call sys$dassgn here.
804F8020 EXE$EXCEPTION+00225 ! system service despatch call frame.
8056DF85 EXE$CREPRC+00C95 ! call sys$rundwn.
8055DD55 EXE$ASTDEL+00003 ! delete ast queue to process.
8055A830 EXE$EXIT+00030 ! sys$exit calls sys$delprc.
804F8020 EXE$EXCEPTION+00225 ! system service despatch call frame.
Process calls sys$exit first of all...
This shows that the process is in deletion and is in the delete process ast,
calling sys$dassgn (at stage *) for each channel the process (it does each one
at a time, calling sys$assign with the channel no as parameter). at this point
we are processing channel 1890 (show proc/chan doesn't show it, as it has
already been deleted, however can find what it was as follows).
SDA> form/type = ccb @ctl$gl_ccbbase-1890
7FF3D160 CCB$L_UCB 821E47E0 UCB
7FF3D164 CCB$L_WIND 00000000
7FF3D168 CCB$B_STS 00
7FF3D169 CCB$B_AMOD 00
7FF3D16A CCB$W_IOC 0000
7FF3D16C CCB$L_DIRP 00000000
CCB$C_LENGTH
Note that most stuff in the ccb has been cleared by now, this stops show
proc/chan from recognising it as a valid chanel.
SDA> show dev/addr =@(@ctl$gl_ccbbase-1890)
I/O data structures
-------------------
INET2667 Unknown UCB address: 821E47E0
Device status: 00010010 online,deleteucb
Characteristics: 0C140001 rec,avl,mbx,idv,odv
00000000
Owner UIC [000035,000001] Operation count 1 ORB address 821E4890
PID 00000000 Error count 0 DDB address 83F4FF00
Class/Type 00/00 Reference count 0 DDT address 81EA730C
Def. buf. size 65535 BOFF 0000 CRB address 83F4FE80
DEVDEPEND 00000000 Byte count 0000 I/O wait queue empty
DEVDEPND2 00000000 SVAPTE 00000000
FLCK index 34 DEVSTS 0002
DLCK address 8058BCF0
Charge PID 00160021
*** I/O request queue is empty ***
So by calling dassgn for that device we end up calling the inetdriver code
(to be expected as deassgn calls the cancel code for the device we are
deassigning). Once we go into inetdriver we seems to end up going through a
lot of call frames in allocatable system space. THis turns out to be a block
of code that if you examine text right at the start of it has the string
INET in it. (see stars article by searching on INET allocatable system space).
However all these frames are different, so doesn't look we got in an endless
loop (usual cause of these krnlstkinv crashes), rather looks like the kernel
stack is not big enough for what we are trying to do. (this is often a problem
with C code that runs in kernel mode, the stack can get used heavily if you call
a lot of subroutines with lots of arguments/saved registers etc - you can
easily run out of k-stack space).
On axp there is a sysgen param, for the kernal stack size (kstackpages) but
not aware of anything on vax. I think it is fixed at 4 pages or whatever.
Will need to get the customer to get back to the inet vendors as they will need
to modify their code to use the stack less...
|