-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ktcp should provide ability to use hardware flow control on SLIP connections #539
Comments
Yes. My latest push on the open serial port PR #535 will display errors (finally) by the UART on the console, including framing error (received data overrun), and interrupt signaled without receive data ready (QEMU seems buggy in this respect). I think we're making progress, but I can't personally test on real hardware, so thank you for your testing.
I thought some users had been using serial TCP/IP already? Can you test it, or is this just a request that ELKS needs it? This issue should likely be renamed "Provide serial port hardware flow control [enhancement]", as |
Hi @pawosm-arm, @ghaerr,
Lack of hardware flow control makes serial connection unusable.
This is not the case - for a number of reasons. HW flow control is useful and increases effective bandwidth for obvious reasons, but SLIP will work fine with a reasonable amount of character loss (and subsequent packet retransmissions). Thus the option to turn off that requirement from the command line.
In fact, as is today, SLIP will probably work fine in ELKS @ 9600 bps, where the character loss is minimal.
Also remember that modern day serial lines hardly ever have any flow control at all, just TTL level RX, TX, GND - possibly augmented by a 232MAX chip to yank up the voltages to RS232 levels. The assumption seems to be that the hardware is fast enough to keep up with the 115200 bps speeds and higher anyway.
Our vintage hardware is a different story, as indicated by Kermit, x/y/z-modem and the like. So HW flow control will be a very welcome addition to ELKS.
…--Mellvik
|
Does it mean,
but...
I can do
Similarly, pinging ELKS from Linux can occasionally cause ELKS's crash. Also, I think ELKS should have |
Hi @pawosm-arm, thanks for your inspection of
I just checked and all those options are parsed and passed to the not-implemented (yet) TIOMCSET
It seems that
Thanks for this testing. I haven't yet tried connecting to another system with TCP/IP.
Very likely. I'll add a
Bad news. I thought SLIP TCP/IP was working on ELKS for some people. I'm not sure what the SLIP packet size is, I haven't dove into any of the TCP/IP code at this point. Perhaps there are others that have successfully run SLIP TCP/IP on ELKS? Comments?
Noted. |
@ghaerr, @pawosm-arm -
the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead.
So I suggest we await a stable and dependable serial.c before debugging slip further.
—Mellvik
… 12. apr. 2020 kl. 18:00 skrev Gregory Haerr ***@***.***>:
Hi @pawosm-arm <https://github.com/pawosm-arm>, thanks for your inspection of miniterm and testing of TCP/IP!
Does it mean, miniterm started with -r -d behaves no different than when started without those flags?
I just checked and all those options are parsed and passed to the not-implemented (yet) TIOMCSET ioctl for the serial driver. These are the same ioctl's that I just commented out in my last commit due to their returning an error and causing miniterm to exit.
but... ktcp does not specify neither it checks for -L option:
It seems that ktcp doesn't try to specify either hardware or software flow control to the kernel. I haven't looked to see whether the it's slip driver tries to implement its own software flow control (using ^S/^Q).
I can do slattach/ifconfig on Linux then start ktcp and telnetd on ELKS. Then telnet connection can be established from Linux (at least the telnet client reports so), yet not for long. After a while things on ELKS side do crash in two possible ways:
Thanks for this testing. I haven't yet tried connecting to another system with TCP/IP.
telnetd crashes complaining about sbrk (I guess it's memory allocation issue)
Very likely. I'll add a -mout-chmem= to its build for you.
the system just hangs (with no messages on console) and needs manual power down.
Similarly, pinging ELKS from Linux can occasionally cause ELKS's crash.
Bad news. I thought SLIP TCP/IP was working on ELKS for some people. I'm not sure what the SLIP packet size is, I haven't dove into any of the TCP/IP code at this point.
Perhaps there are others that have successfully run SLIP TCP/IP on ELKS? Comments?
Also, I think ELKS should have ping command so I could ping the other way round.
Noted.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#539 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOG7DSWQ2ADRFBP4WP3RMHQSDANCNFSM4MGEVAQA>.
|
Please give more detail! What exactly was the hang, and was there any serial I/O going on? |
Sorry, I just had to mention this. There aren't much detail yet. I've had elks running for days and weeks on physical, idle - just a few occasional commands. Elks is stable. Then today, after a lot of banging on serial, I cameback and the system was frozen. No messages, just hard hung (requiring power off).
More beating to come.
Mouse? None in sight - unfortunately.
- Mellvik
… 12. apr. 2020 kl. 20:49 skrev Gregory Haerr ***@***.***>:
the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead.
Please give more detail! What exactly was the hang, and was there any serial I/O going on?
We definitely need more details on this. Also, perhaps you could attach a mouse to your serial port and run mouse and report whether your results are the same as @pawosm-arm's.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Correction, @ghaerr:
I may actually have a serial mouse coming in with a vintage machine whenever the postal package service (from australia) starts working again. Another opportunity for real hw testing.
…--M
12. apr. 2020 kl. 21:12 skrev Helge Skrivervik ***@***.***>:
Sorry, I just had to mention this. There aren't much detail yet. I've had elks running for days and weeks on physical, idle - just a few occasional commands. Elks is stable. Then today, after a lot of banging on serial, I cameback and the system was frozen. No messages, just hard hung (requiring power off).
More beating to come.
Mouse? None in sight - unfortunately.
- Mellvik
>> 12. apr. 2020 kl. 20:49 skrev Gregory Haerr ***@***.***>:
>>
>
> the compete hang situation may be serial related. When testing heavily on serial over the past couple of days, I have experienced complete system hang at a couple of occasions. Not in the middle of a transfer, but suddenly all dead.
>
> Please give more detail! What exactly was the hang, and was there any serial I/O going on?
> We definitely need more details on this. Also, perhaps you could attach a mouse to your serial port and run mouse and report whether your results are the same as @pawosm-arm's.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or unsubscribe.
|
One more thing |
Hello @pawosm-arm, PR #664 allows high speed serial communication, which may allow networking without having to have hardware flow control, depending on the speed of your system, the SLIP MTU length, and the ELKS serial ring buffer size. The ability pass a baud rate to Currently the serial ring buffer is set to 1024. I plan on enhancing |
According to https://github.com/jbruchon/elks/blob/master/Documentation/text/networking.txt in order to establish SLIP connection between ELKS and Linux one needs to type:
The
-L
option meansEnable 3 wire operation. The terminal is moved into CLOCAL mode, carrier watching is disabled.
. I assume this is due toktcp
's inability to specify (and utilize?) hardware flow control. Lack of hardware flow control makes serial connection unusable.The text was updated successfully, but these errors were encountered: