Re: [hylafax-users] modem stuck in receiving state

[marthter <marthter@xxxxxxxx>]

Finally this problem happened this time outside of critical hours when I normally just have to reboot it as quickly as possible...



marthter wrote:

Lee Howard wrote:
  

marthter wrote:

    

a Rockwell modem of some kind:

ati0 14400 [OK]
ati1 007 [OK]
ati2 [OK]
ati3 V1.620-BP39 ROCKWELL RPI (TM) MODEM [OK]

About once or twice per month, the incoming modem gets stuck and
keeps the phone off hook indefinitely.  When this happens, faxstat
shows it thinks it is still receiving, even though this might have
been several hours ago:
      

If I restart hylafax (including faxgettys) it is stuck "Initializing
server" seemingly indefinitely (I waited 20+ minutes).  The lock file
is there with the process ID of the new faxgetty, so I don't think it
is a problem of old lock files.  The only way I've found to clear it
is reboot the machine.

I had been limping along with a USR in that receiving slot for
several years.  About 6 months ago (feeling guilty about asking this
list (esp. Lee) for more help than that modem deserved) I switched it
for the above modem.  This (or a similar) problem was happening with
that USR modem too, so that leads me to believe it isn't modem specific.

The log file of the last incoming session is attached.  Anyone have
any suggestions on what might be going wrong, or how to remedy it?
      

The log file indicates pretty much the same thing that you're telling
us here: that the modem firmware has locked up.  To verify that
HylaFAX has concluded this correctly, you should (when this happens)
    

Before stopping or disabling faxgetty, I thought I'd check what was running:

[root@socrates log]# ps -elf |grep fax
5 S uucp      1357     1  0  75   0    -  1683 schedu Jun08 ?        00:01:11 [faxq]
1 S uucp      1359     1  0  75   0    -   893 schedu Jun08 ?        00:00:16 [hfaxd]
4 S uucp     20812     1  0  75   0    -  1090 schedu 11:36 ?        00:00:00 [faxgetty]
4 S uucp     20813     1  0  75   0    -  1065 schedu 11:36 ?        00:00:00 [faxgetty]
4 S uucp     20814     1  0  75   0    -  1065 schedu 11:36 ?        00:00:00 [faxgetty]
1 Z uucp     20922 20812  0  81   0    -     0 t>     12:39 ?        00:00:00 [faxgetty <defunct>]
1 Z uucp     20923 20812  0  81   0    -     0 t>     12:39 ?        00:00:00 [faxgetty <defunct>]
4 Z uucp     20924 20812  0  79   0    -     0 >      12:39 ?        00:00:00 [faxrcvd <defunct>]
0 S root     22556 22453  0  81   0    -   920 pipe_w 22:52 pts/0    00:00:00 grep fax

[root@socrates log]# faxstat -s
HylaFAX scheduler on socrates.builderlynx.com: Running
Modem ttyS4 (+1-xxx-yyy-5204): Running and idle
Modem ttyS5 (+1-xxx-yyy-0055): Running and idle
Modem ttyS0 (+1-xxx-yyy-4233): Receiving from "xxxyyy9491"

[root@socrates log]# ll /var/lock
total 8
-r--r--r--    1 uucp     uucp           11 Jun 20 12:38 LCK..ttyS0
drwxr-xr-x    2 root     root         4096 Jun  8 18:44 subsys


[root@socrates log]# cat /var/lock/LCK..ttyS0
     20812

disable faxgetty 

I commented the faxgetty lines in inittab and did "init q" and checked that they were stopped:

[root@socrates log]# ps -elf |grep fax
5 S uucp      1357     1  0  75   0    -  1683 schedu Jun08 ?        00:01:11 [faxq]
1 S uucp      1359     1  0  75   0    -   893 schedu Jun08 ?        00:00:16 [hfaxd]
0 S root     22585 22453  0  81   0    -   919 pipe_w 22:56 pts/0    00:00:00 grep fax

Stopping those faxgettys apparently doesn't clear the lock file, I'm not sure if that's important:

[root@socrates log]# cat /var/lock/LCK..ttyS0
     20812

Though eventually this lock file disappeared on its own.

and then run minicom on the modem and try to "wake"
it up.  (Maybe try "ATZ" or "AT&F" or just plain "AT".)

    

Running minicom (checking that it is indeed using ttyS0)

[root@socrates log]# cat /etc/minirc.dfl
# Machine-generated file - use "minicom -s" to change parameters.
pr port             /dev/ttyS0
pu baudrate         57600


Then running minicom, nothing responded to ATZ, AT&F, or AT.  And in fact, when quitting minicom, it says Resetting Modem, then the terminal window goes blank and won't give back the command prompt back until minicom is killed.

If you can't wake it up, then the modem apparently will need to be
power-cycled to wake it up.  This will require a reboot if it is an
internal modem.
    

[root@socrates root]# ps -elf |grep fax
5 S uucp      1357     1  0  75   0    -  1683 schedu Jun08 ?        00:01:11 [faxq]
1 S uucp      1359     1  0  75   0    -   893 schedu Jun08 ?        00:00:16 [hfaxd]
0 S root     22776 22644  0  81   0    -   920 pipe_w 23:23 pts/1    00:00:00 grep fax

At this point I did /etc/init.d/hylafax stop

[root@socrates root]# setserial /dev/ttyS5
/dev/ttyS5, UART: 16550A, Port: 0xe000, IRQ: 11
[root@socrates root]# setserial /dev/ttyS4
/dev/ttyS4, UART: 16550A, Port: 0xe800, IRQ: 10
[root@socrates root]# setserial /dev/ttyS0
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4

The above shows that it is using IRQ 4, so I'm not sure how that reflects on the IRQ 3 comments from way back.

At this point I re-enabled the faxgettys in inittab, and did /etc/init.d/hylafax start.  That still had ttyS0 stuck at "Initializing server" as always when this happened, so I did a warm boot (shutdown -r now) and that's still the only thing (plus cold boot of course) that I know that gets things going again.  I guess its good at least I can do that remotely.

Anyway I'm about this close to taking out and stomping on the modem but I just thought I'd make one more stab at it (the minicom suggestion from way back, to try to wake it up) and see if anyone has any suggestions, or at least to note the above observations for archival purposes.

Cheers and thanks for suggestions made up to now.

Regards.

Martin

I don't think that the USRs and this had a common problem... unless
you have some other hardware sharing IRQ 3.  Normally, however, I've
not known USRs to lock up like this very often.  They do crash, yes,
but they reset themselves when they do.  It may be some kind of serial
misconfiguration of some kind, too.  But most probably it's a firmware
issue.  After all, the modem is probably 12 years old now.

Lee.

    

Replying to an old 2005 thread of my own.  On this same computer, still
RH9, and same modem, which would be like 14 years old now, this is still
happening.  On May 15, I upgraded to the latest hylafax 4.3.4 (from
source), and that didn't help either.

Any suggestions on how I could further investigate or rule out the IRQ 3
sharing?

Hopefully I'll be able to try the minicom suggestion above next time it
happens, but usually I just need to reboot it ASAP to get access to the
phone line back (it is also the voice line, fax is on a distinctive ring
number).  Would someone picking up the line to try to make a voice call
explain this possibly?

It is really just at the threshold of annoyance (obviously I've been
tolerating the occasional need to reboot for 2 years now) but I thought
I'd take another stab at it.  I guess my next try after this will be new
OS install with same hardware (that's overdue anyway), and then maybe
swapping to some other motherboard if I can find one around, and then
removing, stomping on, and burning the modem.

I've got 2 logs this time, one from a failed incoming attempt, and one
from a successful one shortly thereafter from the same sender (probably
the same fax content too).

Any comments appreciated.


  

[large log from May 24, 2007 e-mail purged from thread]