minicom and kernel 2.6.25.1 (at least) (DTR)

minicom and kernel 2.6.25.1 (at least) (DTR)

[jmcgowan]

MINICOM AND KERNEL 2.6.25.1
===========================
Minicom drops DTR in two places (that I see).

*If there is an initialization string configured for the modem*
when starting, or when the option to (re)initialize the modem
is selected, minicom drops DTR, bring DTR up again and sends the
initialization string.

Minicom can be configured to hang-up either by dropping DTR
and bringing it up again a few seconds later (the time delay
being configurable) (this is the default) or not to drop DTR
but to use the Hayes's command string, "+++ATH".

This works in kernel 2.6.24. On my system with kernel 2.6.25.1
(and kernel 2.6.24) minicom can not bring up DTR after dropping
it, the result being that, *if a modem configuration string is set,*
upon starting, it drops DTR and that stays down - the modem is
dead until minicom is restarted. If one starts minicom with the
"-o" switch (to prevent it from initializing the modem) and makes
a call and hangs up using the default or used the option to
initialize the modem then the modem is dead until minicom is
restarted.

WORK AROUND FOR KERNEL 2.6.25.1
-------------------------------
Either start minicom with the "-o" switch (and don't use the option
to initialize the modem) or remove the initialization string
(if that string is null it seems that minicom doesn't drop DTR) and
configure minicom not to drop DTR but to use the Hayes's command
to hang up. If one needs to set some parameters in the modem (and
does not want to use its flash ram to save it as the new default)
either manually enter the Hayes's commands one minicom has started
or write a script to enter them - but a script, not something
minicom recognizes as "initializing the modem", so minicom does not
drop DTR when sending the commands to the modem.

Re: minicom and kernel 2.6.25.1 (at least) (DTR)

[Alan Cox]

Yes I've seen a couple of reports of this but so far failed to find any
explanation as to why it is behaving oddly. The serial core code raises
DTR when an open completes and when the user asks it so at the moment
I've not managed to duplicate the bug, although from the several reports
it seems real enough.

What type of serial port are you using ?