![]() |
We continue to have problems with our Hylafax 4.0pl2 solaris 2.6 servers, which pump out thousands of pages of research reports to our clients each day: o Our modems (we use MultiTechs ranging from the MT2834MR6 to some older models) work as expected, but over time they 'wedge' one by one. Only power cycling the modem returns them to a responsive state. I have initialized each modem with the following commands, which should reset the modem to a known state when DTR goes low: ATE1V1Q0X4&D3&SF1&S0&C0&F9&W0 This makes wedging more infrequent, but does not fully solve the problem. o The 'wedge' command does not fix the above. (Probably because the modem becomes completely unresponsive.) The following error message is repeated in /var/adm/messages: MODEM /dev/sts/ttyD0b appears to be wedged Isn't faxq supposed to take the modem out of service??? o Possibly related to the above, 'faxquit' only kills 'faxq' if there are no currently running 'faxsend' processes. If there ARE faxsend processes running, faxq just keeps on spawning new faxsends instead of waiting for the running processes to finish and then exiting. 'faxstate' doesn't reliably allow me to mark a modem out of service. It seems the whole business of modem status doesn't seem to be working correctly. In spite of the fact that we use HylaFAX as an outbound fax server only, I have tried running the system using 'faxgettys' and 'faxmodem'. Neither approach solves these problems. We have been using HylaFAX on five Ultra 2s with 96 modems on each server. I have come to the conclusion that the software is not production ready for the quantities of faxes that we generate. We may have to abandon Hylafax andgo back to a commercial product if we can't get Hyla to work reliably. Any ideas???? Has anyone seen these problems before? ---------------------------------------------------------------------- Dave Bloom "But meanwhile, I'm still thinking..." Neversoft Corp dave@andromeda.rutgers.edu