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.