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

["Andrew Rinaldi" <andrew.rinaldi@xxxxxxxxxxxx>]

Hi Marthter.

 

I think it’s time to get yourself a new modem.  This behaviour is consistent with a firmware crash which cannot be resolved by the external interface on ‘standard’ modems.

 

Mainpine’s boards feature an external reset (part of the “SideBand” architecture) which allow modems to be restarted from the ‘wedge’ process.  We offer a 30 day return policy so why don’t you try a board and see if it resolves your issues ?

 

Regards

 

ANDREW RINALDI

Mainpine Limited - Support

USA +1 503 822 9944 | Asia/Europe +44 1225 869439  

andrew.rinaldi@xxxxxxxxxxxx | www.mainpine.com

 

From: hylafax-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:hylafax-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of marthter
Sent: 21 June 2007 04:42
To: Hylafax-Users; hylafax-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [hylafax-users] modem stuck in receiving state

 

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]