Date: Mon, 24 Jul 1995 08:18:28 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, terry@cs.weber.edu Cc: hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <199507232218.IAA23750@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Ok, I finaly understand what you say now :-)
>So, described situation is possible, only when some dialout application
>previously send chars at different speed and modem remember
>last speed. So, my comhardclose() fix with comparam(com->it_in)
>isn't enough, because driver need to send AAAT\r command to modem
>after it additionly :-(
It might be enough to send a single character while carrier is down
The modem has to determine the speed before it can read an `A' :-).
Are your extra A's to help it do this?. What determines the speed
after the following sequence:
1) turn on modem
2) open port (don't write)
3) wait for carrier
4) write to port ?
The Linux driver has (had?) some optional support to help getty handle
this. After the last close of cuaa, sleeping opens of ttyd return
EAGAIN. This gives getty a chance to send the AT command.
>Getty becomes too modem specific after it.
Yes :-(.
>So, any dialout program which change serial speed becomes
>getty-killer. We need to document locked devices to getty/gettytab
>manpage too as mandatory to not allow speed changes.
The modem is supposed to reset itself when DTR is dropped. We
don't document this but it should be the hardware default. It
also helps for the modem to be locked at the same speed as getty
will use, or at least default to that speed after it resets.
If the modem can't do this then the dialout user had better
leave it in a good state.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507232218.IAA23750>