[Info-vax] TCP/IP V5.6 ECO 4 caveat...
Jur van der Burg
lddriver at digiater dot nl
Thu Nov 5 02:57:49 EST 2009
I have a hard time believing that. IOC$SEARCHDEV calls
IOC_STD$SEARCHDEV which calls IOC$SEARCH. The last routine
preserves R4, the first two don't use it. This is from the
Alpha V8.3 listings. Which version are we talking about?
It could be a timing issue in tcpip where an interrupting thread
fails to preserve R4.
Jur.
0160 IOC$SEARCHDEV::
23DEFFF0 0160 LDA SP, -16(SP)
B75E0000 0164 STQ R26, (SP)
B5BE0008 0168 STQ R13, 8(SP)
47FB040D 016C MOV R27, R13
0170 $L7:
23DEFFF4 0170 LDA SP, -12(SP) ; 019973
227E0008 0174 LDA R19, 8(SP)
47FE0411 0178 MOV SP, R17
225E0004 017C LDA R18, 4(SP)
47E10410 0180 MOV R1, R16
47E09419 0184 MOV 4, R25
23DEFFFC 0188 LDA SP, -4(SP)
236DFFE0 018C LDA R27, -32(R13)
D35FFFCF 0190 BSR R26, IOC_STD$SEARCHDEV
A03E0004 0194 LDL R1, 4(SP)
A05E0008 0198 LDL R2, 8(SP)
A07E000C 019C LDL R3, 12(SP)
23DE0010 01A0 LDA SP, 16(SP)
01A4 $L8: ; 020136
A79E0000 01A4 LDQ R28, (SP)
A5BE0008 01A8 LDQ R13, 8(SP)
23DE0010 01AC LDA SP, 16(SP)
6BFC8001 01B0 RET R28
2FFE0000 01B4 UNOP
2FFE0000 01B8 UNOP
2FFE0000 01BC UNOP
00D0 IOC_STD$SEARCHDEV::
23DEFFA0 00D0 LDA SP, -96(SP)
B77E0000 00D4 STQ R27, (SP)
B75E0038 00D8 STQ R26, 56(SP)
B45E0040 00DC STQ R2, 64(SP)
B47E0048 00E0 STQ R3, 72(SP)
B5BE0050 00E4 STQ R13, 80(SP)
B7BE0058 00E8 STQ FP, 88(SP)
47FB040D 00EC MOV R27, R13
47FE041D 00F0 MOV SP, FP
B7FE0008 00F4 STQ R31, 8(SP)
00F8 $L5:
B63D0020 00F8 STQ R17, 32(FP) ; 019913
47F00401 00FC MOV R16, R1 ; 019909
47E83402 0100 MOV 65, R2 ; 019910
47FF0403 0104 CLR R3 ; 019911
236D0080 0108 LDA R27, 128(R13) ; 019913
B65D0028 010C STQ R18, 40(FP)
B67D0030 0110 STQ R19, 48(FP)
D340007E 0114 BSR R26, IOC$SEARCH
A63D0020 0118 LDQ R17, 32(FP)
A65D0028 011C LDQ R18, 40(FP)
A67D0030 0120 LDQ R19, 48(FP)
B0310000 0124 STL R1, (R17) ; 019915
B0520000 0128 STL R2, (R18) ; 019916
B0730000 012C STL R3, (R19) ; 019917
0130 $L6: ; 019919
47FD041E 0130 MOV FP, SP
A79D0038 0134 LDQ R28, 56(FP)
A45D0040 0138 LDQ R2, 64(FP)
A47D0048 013C LDQ R3, 72(FP)
A5BD0050 0140 LDQ R13, 80(FP)
A7BD0058 0144 LDQ FP, 88(FP)
23DE0060 0148 LDA SP, 96(SP)
2FFE0000 014C UNOP
6BFC8001 0150 RET R28
0310 IOC$SEARCH::
23DEFFB0 0310 LDA SP, -80(SP)
B75E0000 0314 STQ R26, (SP)
B49E0008 0318 STQ R4, 8(SP)
B4BE0010 031C STQ R5, 16(SP)
B4DE0018 0320 STQ R6, 24(SP)
B4FE0020 0324 STQ R7, 32(SP)
B51E0028 0328 STQ R8, 40(SP)
B53E0030 032C STQ R9, 48(SP)
B55E0038 0330 STQ R10, 56(SP)
B57E0040 0334 STQ R11, 64(SP)
B5BE0048 0338 STQ R13, 72(SP)
47FB040D 033C MOV R27, R13
0340 $L15:
A54D0010 0340 LDQ R10, 16(R13) ; 020185
47E0041B 0344 MOV R0, R27 ; 020186
47E1041A 0348 MOV R1, R26
......................
A79E0000 03E8 LDQ R28, (SP)
A49E0008 03EC LDQ R4, 8(SP)
A4BE0010 03F0 LDQ R5, 16(SP)
A4DE0018 03F4 LDQ R6, 24(SP)
A4FE0020 03F8 LDQ R7, 32(SP)
A51E0028 03FC LDQ R8, 40(SP)
A53E0030 0400 LDQ R9, 48(SP)
A55E0038 0404 LDQ R10, 56(SP)
A57E0040 0408 LDQ R11, 64(SP)
A5BE0048 040C LDQ R13, 72(SP)
23DE0050 0410 LDA SP, 80(SP)
6BFC8001 0414 RET R28
VAXman- @SendSpamHere.ORG wrote, On 4-11-2009 21:37:
> I've looked at two Alpha crashes today. Both were the results of kernel
> code that accesses telnet devices. The problem seems to be that a TCPIP
> ECO (TCPIP V5.6 ECO4) trounces on R4 when calling IOC$SEACTHDEV. Below
> is the comment header from the source listings for this routine. I took
> the liberty of deleting the listing lines so that this will fit into 80
> columns.
>
> ;+
> ;
> ; IOC$SEARCH - general I/O database search
> ; IOC$SEARCHDEV - search for specific physical device
> ; IOC$SEARCHALL - generic search for any device
> ;
> ; This routine searches the I/O database for the specified device, using
> ; the specified search rules. Depending on the search, a lock may or may
> ; not be taken out on the device when it is found.
> ;
> ; INPUTS:
> ;
> ; R1 = address of descriptor of device / logical name string
> ; R2 = flags
> ; R3 = address to store lock value block
> ; I/O database mutex held, IPL 2
> ;
> ; OUTPUTS:
> ;
> ; R0 = SS$_NORMAL - device found
> ; = SS$_ACCVIO - name string is not readable
> ; = SS$_NONLOCAL - nonlocal device
> ; = SS$_IVLOGNAM - invalid logical name (e.g., too long)
> ; = SS$_TOOMANYLNAM - max. logical name recursion exceeded
> ; = SS$_IVDEVNAM - invalid device name string
> ; = SS$_NOSUCHDEV - device not found
> ; = SS$_NODEVAVL - device exists but not available according to rules
> ; = SS$_DEVALLOC - device allocated to other user
> ; = SS$_NOPRIV - failed device protection
> ; = SS$_TEMPLATEDEV - can't allocate template device
> ; = SS$_DEVMOUNT - device already mounted
> ; = SS$_DEVOFFLINE - device marked offline
> ; R1 = UCB
> ; R2 = DDB
> ; R3 = system block
> ; R4 - R11 preserved
> ========^^================ Don't you believe it!
> ;
> ; Note: If failure, R1 - R3 point to the last structures looked at.
> ;
> ; R2 and R3 are input only to IOC$SEARCH.
> ;
> ; IOC$SEARCHDEV: R2 = IOC$M_PHY ! IOC$M_ANY
> ; R3 = 0
> ; IOC$SEARCHALL: R2 = IOC$M_ANY ! IOC$M_LOCAL
> ; R3 = 0
> ;
> ;-
>
> The crashes occurred after calling IOC$SEARCHDEV with a telnet device and
> then accessing the PCB which should have been preserved in R4 across this
> call according to the documentation. This particular bit of code has been
> in production for decades and only with installation of TCPIP V5.6 ECO 4
> has there been any issue. I've fixed the code by preserving R4 across the
> IOC$SEARCHDEV. This problem only occurs when accessing TCPIP devices and
> not with any other terminal device.
>
> Just a heads up!
>
More information about the Info-vax
mailing list