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.
As far as I can tell, I have completely solved this problem. The bad news is that it took a rearchitecting of the whole way we manage PPP connections. You can install the new initscripts from rawhide, along with everything else that the new initscripts package requires, and try that out, or you can wait for Red Hat Linux 6.1 and see if it solves your problem. I'm going to label this as fixed in the next release; please reopen the bug report if either of these two approaches fails to solve the problem.