On Oct  6,  3:38pm, BLAZ.ZUPAN@uni-mb.si wrote:
> When the buffer fills up, the modem raises a line which tells the
> computer not to send any more data (I think its the DSR line?). A

  The modem should be dropping CTS when it can't receive anymore, and
then raise it when it can accept more data.  If the modem is using some
other signal, the serial driver isn't going to know anything about it.

> happens, the process is still there. The process only exits, when
> I turn off the modem. So this suggests that the process hangs in
> some driver code, right?

  The process is probably waiting for the driver to complete some operation.
A ps -l should show you what the process is waiting for (I think I've seen
a process in "ttyout" when it was waiting for the CTS handshake).

> I probably described the problem a bit strange, so if anything is
> unclear then tell me :-)  I think this is a bug in the serial driver
> (or maybe even in PPP?) but I'm still no kernel expert to fix it myself ...

  There is a bug in the serial driver that can potentially halt the data
transmission.  If the CTS signal drops, the output interrupt routine will
stop sending data.  When the CTS signal goes high again, the polling routine
called from the vertical blank interrupt will see that change and set the
transmit buffer empty interrupt, causing the output interrupt routine to
contintue.  If the CTS signal drops, and the output stops, and then the CTS
signal goes high again before the polling routine is called, then the polling
routine will never see that CTS went low and thus never restart the output.
I only noticed then when I was running at very high speeds (115200 bps)
between two Amigas.

Michael