Re: HELP modem locks (hardware lock) since new linux upgrade
Matt Birkholz wrote:
> You shouldn't use /dev/cua1. Use /dev/ttyS1 instead. I changed minicom,
> dip, mgetty+sendfax and other programs that use the modem to use
> /dev/ttyS1 instead of /dev/cua1 and it works like a charm.
>
> Huh? I thought /dev/cua1 was the callout device and /dev/ttyS1 was the
> callin device -- the one that blocks until CarrierDetect. Assuming
> minicom, dip and "other programs" call out, they should use /dev/cua1,
> while mgetty+sendfax and other getty's should use /dev/ttyS1. No?
That will only work if you use the modem auto-answer feature. Mgetty does
not use auto-answer (it just waits for the RING messages). Here is what
the mgetty author says about this:
<<<
*Important note:* Use the `/dev/ttyS*' devices for getty and for
dial-out (that is, for kermit, uucico, cu, seyon, ...) - *never* use
`/dev/cua*'. Dialing out on `/dev/cua*' will result in the error
message "device busy". (There are reasons why `mgetty' cannot use the
"`ttyS*' vs. `cua*' kernel locking mechanism", see below), and dialing
in (ugh) on `/dev/cua*' will result in dozens of strange things
happening because the process may not get a controlling tty.
Some guys seemingly can't resist posting misinformation to the net
all the time, don't believe 'em. The `/dev/cua*' devices are *not*
different from the `/dev/ttyS*' devices concerning data flow or modem
control lines. The only difference is how the device reacts if you do an
`open()': Opening `/dev/ttyS*' normally blocks until the "carier
detect" line goes active (unless `open()' is called with the `O_NDELAY'
flag; `mgetty' and all dial-out programs do that), and opening
`/dev/cua*' will return an error message (`errno=EBUSY') if another
process has the device already open, thus *preventing dial-out on
`/dev/cua*'* if `mgetty' is active on `/dev/ttyS*'.
We use `/dev/ttyS*' all the time for dial-in *and* for dial-out, and
believe me, it works, and it's the *only* combination that will work
properly. The kernel locking mechanism only works if you use modem
auto-answer (the getty process sleeps until the modem gets a carrier),
and mgetty uses manual answer (it waits for the RING message from the
modem), which will save your callers a lot of grief because their calls
will only be answered if your computer is ready to receive a call. Part
of the motivation for writing mgetty was being tired of losing lots of
money for useless calls to a hung machine.
<<<
Peter
--
Peter Tobias EMail:
Fachhochschule Ostfriesland tobias@et-inf.fho-emden.de
Fachbereich Elektrotechnik und Informatik tobias@perseus.fho-emden.de
Constantiaplatz 4, 26723 Emden, Germany
Reply to: