![]() |
You've probably already said this, but what operating system, what type of serial interrface and what driver are you using with that interface? If this is a PC type machine and a dumb serial interface, exactly which chipset (not 16550, but the ASIC identity)? The reason for asking is that I have fairly good circumstancial evidence that the Linux standard serial driver is flawed, at least for some chipsets. I've tried to raise this before, but I think most people are using error corrected protocols and don't notice, whereas fax is less tolerant. It seems likely that many tpc.int Hylafax installations are Linux based. The problem, I suspect, is that it treats 8250 type UARTs (emulation, not chipset, now) as though they were any other type, and uses interrupt enable to control the starting and stopping of output. This is not the way 8250s were designed to be used, and I have empirical evidence that they can lose or corrupt characters under these conditions. (On the other hand, I can think of no internal design reason why they should and don't understand why the problem would apply to emulations as well as the real thing - unless the emulations were based on the original logic design.) I keep meaning to try changing the code. It's fairly self contained, but not so trivial that one can try it in an hour. (If you also run UUCP over error correcting modems and get any errors at all, but no overruns logged, this may be the same problem. In the UUCP context, Comtrol Rocket cards are clean.) (8250s have edge triggered interrupts, so once the interrupt is acknowledged, it goes away, whereas other designs will jam the interrupt line until a new character is sent, or transmit interrupts are turned off.)