Re: Program hangs only on certain terminal
Kevin L
> Hi, it's me again ;-) Hopefully I'm not too much OT, for it seems to be
> a problem of the line, not the terminal itself...
>
> Ok, I got a strange problem here, maybe one of you has a hint for me
> where to continue searching...
>
> First of all, I have a Linux box with five character cell terminals
> attached to it. Three of them are Bull Questar 310, two are genuine
> Digital VT510.
>
> With only _one_ of the Bull terminals the following behavior occurs:
> When _leaving_ the links or lynx program (it only happens with those)
> the screen freezes, and the only way to release it is to kill the
> process (just kill -9 works). Switching the terminal off and on again
> does _not_ release the line. Also, it seems not to be a problem of lost
> XON/XOFF chars (the terminals do XON/XOFF handshaking).
>
> I tried to run the links program from within gdb, but the same behavior
> occured, I was not able to return to gdb, the screen was again frozen
> within links.
>
> Then I moved a DEC VT510 terminal from another location to the one in
> question and connected it to the same line/port. The screen again
> _froze_.
>
> So it must be a problem of the serial line I think. I then compared the
> output of "stty < /dev/ttyS0" to the output of "stty < /dev/ttyS5" (the
> latter is a line that's working). They are 100% identical.
>
> So, what's left?
>
> Volker
It could be a few things specific to Linux:
1. /dev/ttyS5 might be some strange UART or multi-port board that Linux only
partially supports. I have used an 8-port board with Linux that had a strange
bug that was only solved by assigning the io/irq to a different /dev/ttySxx
device. Strange but it worked, and I've no idea why.
2. There might be a hardware flow control issue. In Linux 2.4.22, I wrote a
program that opens a serial port, then brings down DTR with an ioctl(), then
close()s on the port, and it hung just like you are describing on the close()
call. I had to change my program to bring DTR back up before calling close() to
fix it.
Kevin L
> Kevin L wrote:
>
>>Volker Englisch wrote:
>>
> The strange thing here is that the ports located on the multiport board
> are the ones working properly :-) On /dev/ttyS1 the UPS control is
> connected, ttyS2 is a single serial board connected to the modem, and
> ttyS3..S6 are on a fourport board serving terminals. ttyS0 and S1 are
> located on the computer's mainboard, bound to int4 and int3 with no
> collissions...
Hardware sounds OK, but it could still be a problem with the serial driver, OR
come to think of it with devfsd. Are your /dev/ttySxx devices real devices or
links into the /dev filesystem? If the latter, you may have a permissions issue
on the device -- see /etc/devfs/* .
> Hardware flow control is (should be) disabled on the terminal lines. At
> least, stty shows -crtscts, ixon, ixoff, and the terminal isn't capable
> of handling RTS/CTS, so it is set to XON/XOFF handshake. Is there a way
> to find out the real state of the UART? Maybe stty reports nonsense?
Another possibility: are there any other programs trying to access the device,
such as a getty in /etc/inittab ?
Also, how does it behave if you do login, ls, logout? If it behaves, then check
it with the following: mc, emacs, ssh (ssh localhost, logout). I'm thinking
that perhaps it is the calls to ioctl(TCSETSW) and/or ioctl(TIOCGWINSIZ) that is
the magic that kills it. Finally, do this:
$ strace lynx 2>tmpfile
...and reach your hang point, then let's see what tmpfile says. This will get
you to the actual system call that is hung.
As you can tell, a configuration issue with Linux is far from simple is tracking
down. You might get some real expert help in comp.os.linux.misc .
Richard S. Shuford
|
| I have a Linux box with five character-cell terminals attached to it.
| Three of them are Bull Questar 310, two are genuine Digital VT510.
| With only _one_ of the Bull terminals the following behavior occurs:
| from another location to the one in question and connected it to the
| same line/port. The screen again _froze_. So it must be a problem of
| the serial line I think. I then compared the output of
| "stty < /dev/ttyS0" to the output of "stty < /dev/ttyS5" (the latter
| is a line that's working). They are 100% identical.
Perhaps you could try adding "-a" and post at least one sample of the
resulting output for inspection here, i.e.,
# stty -a < /dev/ttyS0
--
Eager eaters of yogurt can read the "Bovine Bugle"...
http://www.stonyfield.com/weblog/BovineBugle/index.html
Tony Lawrence
> Volker Englisch <eh97(at)despammed.com> wrote:
> |
> | I have a Linux box with five character-cell terminals attached to it.
> | Three of them are Bull Questar 310, two are genuine Digital VT510.
> | With only _one_ of the Bull terminals the following behavior occurs:
> | the screen freezes, and the only way to release it is to kill the
> | process (just kill -9 works). ... Then I moved a DEC VT510 terminal
> | from another location to the one in question and connected it to the
> | same line/port. The screen again _froze_. So it must be a problem of
> | the serial line I think. I then compared the output of
> | "stty < /dev/ttyS0" to the output of "stty < /dev/ttyS5" (the latter
> | is a line that's working). They are 100% identical.
>
> Perhaps you could try adding "-a" and post at least one sample of the
> resulting output for inspection here, i.e.,
>
> # stty -a < /dev/ttyS0
>
Also the terminals themselves aren't necessarily set identically.
A few things that might "freeze" a terminal:
flow control set to ixon but not ixany; accidentally hit CTRL-S (CTRL-Q
will unfreeze).
Application sends "local" or transparent print sequence but printer
isn't correctly configured.
Terminal can be put into scan code mode or app thinks it can..
But this sounds like flow control.
--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Dances With Crows
On 30 May 2005 16:22:57 GMT, Volker Englisch staggered into the Black
Sun and said:
> Richard S. Shuford wrote:
>> Volker Englisch <eh97(at)despammed.com> wrote:
>> > I have a Linux box with five character-cell terminals attached to it.
5 serial ports? Info on the addon serial card(s) may be useful.
>> > Three of them are Bull Questar 310, two are genuine Digital VT510.
>> > With only _one_ of the Bull terminals the following behavior occurs:
>> > the screen freezes, and the only way to release it is to kill the
>> > process (just kill -9 works). ... Then I moved a DEC VT510 terminal
>> > from another location to the one in question and connected it to the
>> > same line/port. The screen again _froze_. So it must be a problem of
>> > the serial line I think.
>> # stty -a < /dev/ttyS0
> speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\;
> erase = ^?; kill = ^U; eof = ^D; eol = <undefined>; eol2 =
[snip]
> But, in the meantime, I think I got a bit closer. I stopped the getty
> process on this line, and re-initialized the port as a 16450 UART (it
> was initialized as a 16550A before). Now the terminal doesn't hang any
> more.
Hmm. This is at least a workaround. Sometimes a workaround is as good
as a fix.
> Unfortunately, I do not have an idea what mainboard is inside the box
dmidecode may be useful here.
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / Hire me!
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume
Dances With Crows
Sun and said:
> Dances With Crows schrieb:
>> ["Followup-To:" header set to comp.os.linux.misc.]
> f'up.
? This is a little strange. There's always groups.google.
>>> Unfortunately, I do not have an idea what mainboard is inside the
>> dmidecode may be useful here.
> Where to find this? It's not on my system :-(
If you hear the name of a Linux program, and you want to know where to
get it, you can almost always find the source code on either
freshmeat.net or sourceforge.net .
> For I don't have easy access to the Linux group, for I'm an uucp only
> user without automated group manager,
I thought they'd shot UUCP and shoveled dirt over it 8 years ago. How
do you manage to do the whole mail/Web thing without TCP/IP? Mail might
work, since sendmail can speak UUCP if you kick it hard enough, but
almost everything else these days sort of requires TCP/IP.
> The workaround is working so far.
Good to know. If the board is old, it might actually have a 16450 UART
on it--or something like that. dmidecode should give you exact
information about what's on the board, like "dmidecode | grep -1 'Port
Type' ". HTH,