Philip Guenther <guenther <at> gmail.com> writes:
> Oh, you're running 5.4-stable? I thought you were running -current
> and was worried there was another hang in there. I'm now 99% sure
> you're hitting the one I fixed back in October.
I did some more experimenting, and I found that the issue does not happen
when I leave out the "crtscts" option to stty.
With "crtscts" however, things get weird:
Opening and immediately closing cua01 is no problem:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
close cua01 # device probably didn't send anything yet
exit # exits normally
Opening cua01 and closing it later *is* a problem:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
sleep 15 # to make sure the device on the other end has sent some data
close cua01 # HANGS, but is interruptible after which everything is nicely
cleaned up
exit # never reached
Interrupting a read from cua01 results in a process that can't exit:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
while-loop {
read cua01 # blocks when the other end isn't sending anything; if the
process is interrupted now it won't ever exit;
cua01 is not released and only a reboot clears the process
}
close cua01 # HANGS, but is interruptible after which everything is nicely
cleaned up
exit # never reached
Again, if I leave out "crtscts" (and leave everything else the same),
everything works as expected: no hangs at all, and interrupting a read is no
problem.
I'm sorry, but I don't know which hang you fixed in October. With this
information, do you think it's the same hang?
Thanks,
Jurjen Oskam
