From dbdb80cfc5c7b520e20a476f7f4c20527e6cb1bc Mon Sep 17 00:00:00 2001 From: Alan Cox Date: Sat, 26 Jan 2019 23:03:29 +0000 Subject: [PATCH] process: Fix nready panic and hangs when using rts/cts Actually what happens is that spend long enough waiting to write the byte that we hit the poll timeout. In the usual case it doesn't matter but if 1. You hit a key 2. We are idle 3. We are doing idle key polling 4. The echo is blocked for a long long time We then try and sleep the current process, only we are in idle so there isn't one. Idle is really like being in an interrupt. Now arguably we should fix tty output to retry the echo write until it gets kicked for timing offences and then give up but tht means auditing all the ininterrupt uses and also encourages the existing bad behaviour of not running a small tx buffer. So if it annoys you fix your tty output code 8) --- Kernel/process.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Kernel/process.c b/Kernel/process.c index b4bb47c8..f122e827 100644 --- a/Kernel/process.c +++ b/Kernel/process.c @@ -148,8 +148,12 @@ void switchout(void) in platform_idle or an interrupt wakes someone up */ while (nready == 0) { ei(); + /* We are idle, that means we cannot sleep */ + udata.u_ininterrupt = 1; platform_idle(); di(); + /* We never idle in an interrupt so this is valid */ + udata.u_ininterrupt = 0; } /* If only one process is ready to run and it's us then just return. This is the normal path in most Fuzix use cases as we -- 2.34.1