This is long, so I apologize in advance.


After upgrading from RH5.1 to 6.0 I have developed a modem
related problem.  The best I can tell, no one else seems to
be having this problem so it must be caused by curious
combination of factors. The problem is also sporadic so has
been a little hard to get a grip on, but essentially I wind
up with a completely dead modem. Chat hangs at the first
reference to /dev/modem (or /dev/ttySx) eg, '' ATZ.
Substitute anything you want for ATZ.  statserial hangs,
stty /dev/modem hangs, strace hangs, echo AT > /dev/ttySx
from bash prompt hangs. The last one gives a 'bash:
interrupted system call' when terminated with CTRL-C.  Using
all RH updates on intel. pppd is ppp-2.3.7-2, also tried
2.3.8-1. Modem is an external 56k Diamond.  I've tried
reinstalling various packages too. Modem is ttyS0, mouse on
ttyS1, no other serial devices.  No apparent IRQ conflitts.

The only way back to a sane modem is either reboot or start
minicom letting it initialize the modem and then exit
*without* resetting.  This always works. I presume minicom
is doing its thing at a lower level and is thus bypassing
whatever is flaky at the user level. The modem also works
fine if I use dosemu with a DOS comm program there, even if
the modem is simultaneouly hung in linux. I think this
pretty much eliminates a possible hardware problem. And it
is not a lock file problem, I've searched high and low for
this.

While this scenario can occur randomly it is much more likey
to occur after a dropped connection or if pppd fails to
establish a connection. In fact, I would say pretty much
everytime I'd get a lifeless modem here. It does, however,
occasionally occur even after a routine ppp-down, but is
much less likely in this case.  Another factor may be noisy
phone lines that I am forced to deal with here.  I regularly
have a tough time getting a reliable connection. So maybe
this is a little more of an annoyance to me than someone
that has the good fortune to not have to deal with this.
Perhaps this is a factor either directly or indirectly.
Dunno. But again, this never once happened before the
upgrade, now pretty much a daily event. Other than this
problem, everything else on the system is running
flawlessly.

The reason I am digressing here is that I feel there is an
obscure bug somewhere but am not exactly sure where and
probably I should report it but don't know to whom. Have no
idea whether this is pppd not returning modem to a sane
state, or whether it is something else in the OS that pppd
is relying on.


FWIW, this snippet gives me back access to modem when it is
hung:

==========================================================
int main(void) {
  minp = open("/dev/modem", O_RDWR | O_NOCTTY | O_NONBLOCK);
  if(minp < 0) {
    perror("cannot open /dev/modem");
    return EXIT_FAILURE;
  }

  retval = tcgetattr ( minp, &old_termios);
  if(retval != 0) {
    perror("cannot use tcgetattr");
    return EXIT_FAILURE;
  }

  old_termios.c_cflag = old_termios.c_cflag | CLOCAL;

  retval = tcsetattr( minp, TCSAFLUSH, & old_termios );
  if(retval != 0) {
    perror("cannot use tcsetattr");
    return EXIT_FAILURE;
  }

  close(minp);
  return EXIT_SUCCESS;
}

=============================================================

I am not nearly smart enough to come up with this. It is
courtesy of Mark Gray who I happened into on the RH list.
Thanks Mark!

While I can now access the modem after running this bit,
pppd will still consistently fail to connect. If I pump a
saved version of 'stty -g' back through stty, then all is
well again.  ;) (This idea also from Mark.) If I was smart
enough I would be better able to give a more precise source
of the problem even though I've been trying to track this
down for 4-5 weeks now.  Maybe someone else can get to the
bottom of it.