[cmds] Ktcp enhancements and various small cleanups

[ghaerr]

Add '-s baudrate' option to ktcp, requested in #539. Modified /etc/rc.d/rc.sys, no need to run stty separately beforehand anymore.

Set new VMIN/VTIME serial line parameters for ktcp slip testing for @pawosm-arm, from #515.

Fixed lots of compiler warnings in ktcp, many more still there.

Add process ID to kernel sys_brk process out of memory errmsg, discussed off-topic in #586.

Temporary change to telnetd to exec /bin/login rather than /bin/sh for @pawosm-arm testing.

Quick one-line guess/fix to ash/mkinit.c to try to debug the occasional GitHub CI build errors that are seen just after merges/push to GitHub. This is the 'invalid character in file' that is generated and stops the build (see picture).

[pawosm-arm]

The new -s ktcp option looks ok, I'm not sure about the other changes though (~ECHOE, VMIN, VTIME), a telnet connection from ELKS to custom-made telnet server running on Linux seems extremely slow, no matter what speed I tried (up to 4800, as for 9600 the telnet connection could not even be established).
I couldn't benefit from IDs printed along with sys_brk failure message: changing sh to login solved the problem (so I guess it wasn't telnetd to blame). Unfortunately, I couldn't experience Linux to ELKS connection: although login process was spawned (as seen by ps output on ELKS), nothing appeared in telnet client on Linux. I suspect serial communication issue.

Generally, this (already merged) PR gives some benefit and addresses the matter of this ticket, yet underlying issue of interrupt-driven serial communication remains.

[ghaerr]

I'm not sure about the other changes though (~ECHOE, VMIN, VTIME)

Those changes will help, they don't change the serial port directly but allow larger data counts per read to be passed back to ktcp.

a telnet connection from ELKS to custom-made telnet server running on Linux seems extremely slow, no matter what speed I tried (up to 4800, as for 9600 the telnet connection could not even be established).

It appears your original issue is not solved. Did this fix allow your system to work faster than 300 baud? I am interested in results of any improvement. The kernel will now display serial overruns, so that is not apparently your problem.

changing sh to login solved the problem (so I guess it wasn't telnetd to blame).

Good to know. I will be able to debug sh vs login when I am able to get QEMU setup for networking, I need help on that.

Unfortunately, I couldn't experience Linux to ELKS connection: although login process was spawned (as seen by ps output on ELKS), nothing appeared in telnet client on Linux. I suspect serial communication issue.

I see. Did this not work at 300 baud either?

Generally, this (already merged) PR gives some benefit and addresses the matter of this ticket, yet underlying issue of interrupt-driven serial communication remains

Thanks. Agreed.

How do we know that your system UART chip in fact works correctly? Does this repeat on other machines? I'm sorry if you've already explained, but am just wondering about hardware possibilities at this point. We haven't got the full test results from @Mellvik on the improved sercat and serial handling yet, which is important.

[pawosm-arm]

Did this fix allow your system to work faster than 300 baud?

Nah, it was possible before to go as fast as 4800bps, but the quality of service was deteriorating with growing speed. It's just that 300bps allows to sustain established telnet communication for longer. Note that many times it was just a matter of luck how long the communication worked before stalled, and this didn't change. The only improvement I see is that deterioration (at faster speeds) less often cause the system to hang and even with connection stuck, it's still keyboard-responsible.

How do we know that your system UART chip in fact works correctly?

It works on FreeDOS at all speeds available. I'm either redirecting FreeDOS console to serial (using ctty command) or use Telix which allows to connect at greater speeds (it is possible since Telix makes use of hardware control flow lines, and a full hardware control null-modem cable is the only one I have here). Yet it's easy with DOS: it's a single process system, hence the communication program is never preempted.
Also, I've installed Windows 3.0 on top of FreeDOS (the last Windows version one could install on 8086/8088, the next version, Windows 3.1, required 80286 at least), it has the HyperTerminal program. Although its top speed is limited to 19200, it also offers stable communication with the other side.

[ghaerr]

It was possible before to go as fast as 4800bps, but the quality of service was deteriorating with growing speed.

So previous to all the serial mods in the last weeks, it worked better? Dang!

The only improvement I see is that deterioration (at faster speeds) less often cause the system to hang and even with connection stuck, it's still keyboard-responsible.

The recent changes have helped the system in general, I think, and are needed for higher throughput. But none of these changes seem related to the core issue with your machine.

It works on FreeDOS at all speeds available.

Great news, its a software problem! :) Time to look at the FreeDOS serial driver.

(it is possible since Telix makes use of hardware control flow lines, and a full hardware control null-modem cable is the only one I have here).

Oh. Maybe it isn't a software only problem - hardware flow control is needed for high speeds on your machine? We'll wait for @Mellvik's driver, since I don't (yet) have hardware to easily test with.

Can you confirm that you get high-speed data INPUT on FreeDOS without using the hardware null-modem cable? We're not using interrupt-driven serial output (yet).

Thanks for your testing!

[pawosm-arm]

Time to look at the FreeDOS serial driver.

I don't think it's the right stuff to examine. DOS serial port is hard to deal with (even its 'mode' command to configure communication parameters doesn't expose all the options both Telix and HyperTerminal have). Most of the DOS programs talk to the hardware directly (bypassing DOS) and have ability to provide ioports and IRQ.

Can you confirm that you get high-speed data INPUT on FreeDOS without using the hardware null-modem cable? We're not using interrupt-driven serial output (yet).

As I said, I don't have any other null-modem cable. Yet I managed to do some test with a DOS software that definitely can't handle hardware flow control. Up to speed 2400bps it's fine and stable. At 4800bps the inbound traffic (a longer piece of text pasted to minicom on the Linux side) started to suffer from minor character loses. That only confirms, not using hardware flow control is a bad idea...

[Mellvik]

IMO the serial driver may not be the primary culprit here. During my extensive testing over the past weeks, I have noticed (and some times reported) a system hang situation that severely affect serial reliability. More than half of the time when I dump my 12kb test file onto the serial line, one buffer (512b) or less actually make it to the destination file. The line speed makes a difference, but not much. With the current serial driver and what I like to call normal system activity, ELKS should easily handle 2400 bps w/o character loss even if there is no flow control, probably 4800 too. [Remember - with careful preparation(!) and no disturbances (whatever that is), we're able to get all of 12k through - w/only 12 characters lost. BTW - that is 12 characters every time, one per KB.] So while continuing the work on serial improvements, I think we need to be on the outlook for 'the other culprit'. I have no idea where to look. It is quite possible that The new sercat tool will help narrow it down. I plan to start working on the flow control issues toward the end of the week - possibly starting with soft flow control (XON/XOFF). In the meanwhile I'll be mostly offline. Apropos drivers to look at - Minix 2 seems like a good place to start.

…

-M

 Time to look at the FreeDOS serial driver. I don't think it's the right stuff to examine. DOS serial port is hard to deal with (even its 'mode' command to configure communication parameters doesn't expose all the options both Telix and HyperTerminal have). Most of the programs talk to the hardware directly and have ability to provide ioports and IRQ. Can you confirm that you get high-speed data INPUT on FreeDOS without using the hardware null-modem cable? We're not using interrupt-driven serial output (yet). As I said, I don't have any other null-modem cable. Yet I managed to do some test with a DOS software that definitely can't handle hardware flow control. Up to speed 2400bps it's fine and stable. At 4800bps the inbound traffic (a longer piece of text pasted to minicom on the Linux side) started to suffer from minor character loses. That only confirms, not using hardware flow control is a bad idea... —