HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: back with the problem



>       Multi-Modem MT2834 (bought today :) on /dev/cua0 (replaced USR
> V.Everything)

cua0 is deprecated in the next kernel, you ought to use ttyS0; however,
you must do this consistently for all modem locking applications.

> Jun 10 22:01:41 e FaxGetty[24830]: OPEN /dev/modem

This is even more likely to cause problems then cua0, as it is very likely
that there is something referencing cua0 (or ttyS0) rather than /dev/modem.
If you were using a non plug and play version of Linux, I would say delete
/dev/modem and reconfigure everything to use /dev/ttyS0.

> Jun 10 22:02:09 e FaxGetty[24830]: ANSWER: Can not lock modem device

This is the normal situation for a (non-Hylafax originated?) outgoing call.

>   The image quality is of question, only Silicon Graphics logo was

Your session log indicates that you sent nothing at all; please turn up the
logging level to that seen in other articles on this list and resubmit.

> transmitted ok, text is shifted and smashed. I have tried tif file
> as well. Could only read one line out 25 with very bad quality. 

Sounds like a flow control problem.  If not that, a modem hardware problem.
Check that you are sending the correct flow control setup sequence to the
modem, that it supports your choice of hardware v software flow control when
in fax mode, and, if you are using hardware flow control, that you have a
properly wired cable (e.g. no loop backs).

A full session log should confirm flow control by showing a steady state rate
consistent with the port speed, rather than just short of the DCE to DCE
speed over 10 in bytes per second.  The will be a faster initial burst as
buffers are primed.




Project hosted by iFAX Solutions