Anomaly when using Kermit transferring files to FreeAXP using telnet console

FreeAXP 4.0.0.646 (problem also occurs on FreeAXP 2.6.4.558)

OpenVMS 8.4

K95 V2 connecting to AXP telnet console on port 9000

Connection reports errors including timeouts on transmissions. Kermit packet size set to 4000. Problem does not appear to occur when Kermit packet size is reduced to 128. When problem occurs, attempting to HALT the AXP results in console errors and a sporadic emulator fault.

Since K95 has no problem with telneting to a real processor over the LAN with 4K Kermit packets, there would appear to be a problem with the telnet server implementation included in FreeAXP. Flow control issues should be possible on a proper functioning telnet implementation.

Will endeavor, time permitting, to see at what threshold the problem occurs. As noted above, packet size 4000 fails and packet size 128 seems ok (no problems, 402k packets transmitted error free so far).

Even if there is a limit on Kermit packet size, which should be noted in Release Notes, the HALT function should work correctly without crashing the emulator).

I spoke (sic) too soon.

The 128 byte packet test finished, no reported errors. However, the AXP side became non-responsive.

When I tripped the HALT, FreeAXP bugchecked with the following entries were in end of the log:

(large number of "Serial port buffer overrun" messages)

20200509150234.017: Wrote crash report file to E:\Gezelter\OpenVMS\ODYSSEUS2-kermit_20200509_150231985_halt.cra (547354 bytes - 35328 compressed)
20200509150234.119: De-asserting halt button...

20200509150308.200: ESL-F-FAIL: Emulator Failure:
20200509150308.200: Exception: ESL-F-RTM: Runtime error in 'class CEv4'.'cpu0' thread
20200509150308.200: Runtime exception: AXP-F-CPUEXC: cp(control).alpha(alpha (AS400)).cpu0(EV4): Exception in CPU thread: Runtime exception: Win32 Exception: ACCESS_VIOLATION at 0x0000000140064FE5 (params: 1,404917984) 0000000140064FE5 (0000000140191489,00000000004D1D40,0000000012590090,0000000015E0E1F0)
20200509150308.200: 000000014006203D (0000000012590090,0000000000000000,0000000000000000,0000000000000000)
20200509150308.200: 000000014010CE5F (000000001473C690,0000000000000000,0000000000000000,0000000000000000)
20200509150308.200: 00007FFF560B7BD4 (0000000000000000,0000000000000000,0000000000000000,0000000000000000)
20200509150308.200: 00007FFF5798CE51 (0000000000000000,0000000000000000,0000000000000000,0000000000000000)
20200509150308.200: : ..\..\src\hpal\Exception.cpp, line 134, function 'ExFilter'.
20200509150308.200: Possible location: PC af
20200509150309.580: Wrote crash report file to E:\Gezelter\OpenVMS\ODYSSEUS2-kermit_20200509_150308200_excp.cra (553451 bytes - 36107 compressed)

20200509150309.581: ***** LMS - last messages *****
20200509150330.328: PDB-I-CLSE: Ended my process. Returned 1 cores and 0 units to the pool.
20200509150330.330: No key found PID Key/Emulator Units Cores
20200509150330.330: Key + Base 0 f
20200509150330.330: Available 0 f

20200509150330.832: ASY-I-FREEMEM: cp(control).alpha(alpha (AS400)): Freeing memory in use by system...
20200509150330.932: Bq3287: asserted 56624222 times
20200509150330.932: de-asserted 56592573 times
20200509150330.932: re-asserted 76004 times
20200509150330.957: DFL-I-CLOSE: cp(control).alpha(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file): Closing file.

20200509150331.087: IOC STATISTICS FOR cp(control).alpha(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.0(file)
20200509150331.087: read (async): issued 0 times, completed 0 times
20200509150331.087: read (sync ): issued 13630 times, completed 0 times
20200509150331.087: write (async): issued 0 times, completed 0 times
20200509150331.087: write (sync ): issued 964 times, completed 0 times

20200509150331.087: DFL-I-CLOSE: cp(control).alpha(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file): Closing file.

20200509150331.119: IOC STATISTICS FOR cp(control).alpha(alpha (AS400)).pcibus(dc21071da).pci6(symbios).disk0.1(file)
20200509150331.119: read (async): issued 0 times, completed 0 times
20200509150331.119: read (sync ): issued 0 times, completed 0 times
20200509150331.119: write (async): issued 0 times, completed 0 times
20200509150331.119: write (sync ): issued 0 times, completed 0 times

20200509150331.120: Cache size reset to original.

I have the associated crash file and will preserve.

As noted previously, two problems:

- One should not be able to "overrun" a serial buffer on a telnet connection.
- In any event, FreeeAXP should not end up in a situation where HALT generates an apparent emulator failure

The console port (OPA0) on an AlphaServer 400 has buffer restrictions. Large packet transfers and large transfers in general will overrun it. Try using the TTA0 port instead.

Better yet, use FTP over a proper telnet connection.

I can understand a limit, although it would seem that a better solution to this situation would be to stop reading the telnet tcp stream and let the tcp throttling control things.

That said, I would understand if Kermit on both sides reported errors. The emulator in any event should not crash, as appears to be indicated in the posted log file.

Does using TTA0 for the transfer resolve the issue?

Using the console port for transfers is problematic for two reasons:

1) It's buffering capacity is restricted. This is a "hardware" limitation specific to the console port.

2) It's the system console port, which controls the system. Special characters, particularly in binary transfers, can be interpreted as console control commands and cause unexpected results.

The CPU exception generated when the halt was issued is unexpected. We are looking into that.

Thank you for looking into the HALT problem. If nothing else, that should not bugcheck.

Regarding TTA0. Am awaiting HP Hobbyist PAK. In any event, the license text file will need to be transferred. Will try to do things via the other port, will advise.

Concerning OPA0, I understand what you are saying. However, why not ju7st stop receiving on the telnet connection when the buffer is full?