![]() |
> 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.