CPU/MEMORY/MATH-CO

[Tim Wright]

In <13777 at medusa.cs.purdue.edu> yeh at cs.purdue.EDU (Wei Jen Yeh) writes:

...
>  The next questions are for people running Dell 4.0 and have used any comm.
>program under it.  I use kermit to connect to the computer at school with a
>2400 baud modem.  When doing a long cat on the remote host, the local m/c
>will split out about 20-30 lines of text with intermittent stops, then the
>rest of the output is not displayed.  The connection is still there.  It looks
>like the async input buffer was full and the input handler just ignored the
>incoming characters without blocking the sender.  Has anyone seen this problem?
>BTW, this occured under both X and the ascii console.
This sounds like flow control. If you're using C-Kermit, check your
setup. 'set flow-control xon'. In fact it sounds more like your modem
setup. C-Kermit defaults to xon-xoff flow control, but the modem setup
could be wrong at either end. The only way to confirm is with a protocol
analyzer.

>  Another question.  A quit (ctrl-C) when executing some programs 
>causes ksh to dump core.  A reproducible example is the command
>"zcat gcc-1.39.tar | tar tvf -".  ksh prints the messages after ctrl-C is
>pressed:
>ksh: 24235 Quit(coredump)
>ksh: 24234 Quit(coredump)
>, where the two integers are pid's.
This is not ksh dumping core. You have said '^c' is mapped to QUIT, not INTR.
That is it is sending SIGQUIT. You had a pipeline of two processes (24234,
the zcat, and 24235, the tar), therefore it is quite natural for both to
coredump. Ksh (the shell you invoked them from) is reporting the fact - see
'set -o monitor'.

Regards,

Tim
--
Tim Wright, Dell Computer Corp., Bracknell    |  Domain: tim at dell.co.uk
Berkshire, UK, RG12 1RW. Tel: +44-344-860456  |  Uucp: ...!ukc!delluk!tim
Nobody ever said I was charming before. They said, "Rimmer, you're a total git"
- Red Dwarf, "Camille".