[hylafax-users] Intermittent problem with a Multitech MT5634Z PX- PCI

["Donald, Adam" <adam.donald@xxxxxxxxxxx>]

Aidan

Thank you for the suggestions.
No, I was not dialing the modem during the original straces I sent to you.
I performed another strace on a modem that I had left "stuck" while I was
dialing the modem's number (and receiving ringback), and the results can be
seen for the first few minutes of the attached strace log.  You should be
able to find when I tried your suggestion of echoing the AT command to ttyS2
(around 2:35).  faxgetty eventually answered the call, and after a few
seconds, I hung up the phone.  This has caused the modem to function
normally again.  I am running 4.2.1 on FC3 with 1 USR Courrier modem and 2
MT5634 modems.  This behavior always occurs with the MT modems sometime over
the weekend.  When I leave work on Friday, the MT modems function normally,
when I come in on Monday, I expect to find them "stuck".  I have never
experienced this issue with the USR modem.


AD

-----Original Message-----
From: Aidan Van Dyk [mailto:aidan@xxxxxxxx] 
Sent: Monday, April 18, 2005 8:24 AM
To: Donald, Adam
Cc: Lee Howard; Steve Tuckner; hylafax-devel@xxxxxxxxxxx
Subject: Re: [hylafax-users] Intermittent problem with a Multitech MT5634Z
PX-PCI

* Donald, Adam <adam.donald@xxxxxxxxxxx> [050418 09:00]:
> Aidan
> 
> Attached are the log files that you requested from our 2 "stuck" Multitech
> MT5634ZPX modems.
And you are absolutely certain that the modem should be "ringing" during
these STRACE?
If so, then we have to throw the problem back down to the modem/serial
driver.
These strace show that faxgetty is *definitely* selecting with the modem
file descriptor, but that the kernel never tells it there is anything
available to read on it.
fd 8 is the descriptor to the serial device:
	lrwx------  1 root root 64 Apr 18 07:48 8 -> /dev/ttyS1
	lrwx------  1 root root 64 Apr 18 07:49 8 -> /dev/ttyS2
And both faxgetty's show a repeated pattern:
	07:51:59.879887 select(9, [5 8], [], [8], {29, 999907}) = 0
(Timeout)
	07:52:29.876327 select(9, [5 8], [], [8], {0, 3467}) = 0 (Timeout)
and 
	07:57:08.409258 select(9, [5 8], [], [8], {29, 999914}) = 0
(Timeout)
	07:57:38.405712 select(9, [5 8], [], [8], {0, 3461}) = 0 (Timeout)
These mean that we are waiting for the kernel to tell us that a fd [5 or
8] is ready for reading, or an exception on fd 8.  And the kernel
continually tells us nothing is happening...
At this point, we have to start trying to figure out why the modem
events aren't propagating up the stack correctly.
What happens if when the phone should be ringing (keep an strace
of faxgetty running) you do something like:
 	echo "AT" > /dev/ttyS1 (or ttyS2, whichever should be ringing)
This "sneaks" under faxgetty with no lock file, and doesn't cause
faxgetty to close/reopen the modem device, but should prod the modem
into some sort of action from the uart side instead of the line side,
(and thus output, which faxgetty should be able to read), but shouldn't
reset the modem, or anything.  
We really have to use trial and error, and try and figure out exactly
what is needed to get events from the modem received again.
And I would start looking for "patterns" leading up to these stuck
times.  Like the last communication on the device is ...  I always
happens after callerid XXX, etc.
a.
-- 
Aidan Van Dyk                                             aidan@xxxxxxxx
Senior Software Developer                          +1 215 438-4638 x8103
iFAX Solutions, Inc.                                http://www.ifax.com/

Attachment: ttyS2.strace
Description: Binary data