Re: flexfax: Large number of errors with Hylafax and ZyXEL Omni modem

[David Woolley <david@djwhome.demon.co.uk>]

> they are 16550A. How do I find out the chipset? Do I have to open the
> cabinet and look inside? That'll be a bit tough; my server runs round
> the clock.

I'm afraid that's the case.  Basically I know that Intel UARTs can misbehave
when transmit interrupts are disable on the fly, and I have circumstancial 
evidence that emulations do the same, but possibly different misbehaviour.
However, the data sheet doesn't suggest that they should, so the problem is
probably an internal design one, that might differ between different
implementations.

> 
> | 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.
> 
> You mean no one in the Linux developers group has time to look into it?
> Sad. Again, as you said, maybe only the fax user and dialup UUCP user
> needs to bother about it.

I've tried to raise it once or twice on USENET with no response and there
were no relevant changes in the 2.1 sources last time I looked.  I think
the problem is that most heavy users of serial comms, particularly those
using protocols which do fast line turnrounds, are using PPP or UUCP.
The PPP users probably just think the broken packets are general network
problems, and few UUCP users probably look at the logs, and those that
do probably don't fully realise that a properly flow controlled error
correcting modem should produce virtually no errors at the UUCP protocol
level (long time UUCP users may be used to non error-correcting modems,
and newer ones may not look inside the guts).

There are basically two approaches I have to getting this considered
seriously.  One is to actually rework the ISR to drive the UARTs as
intended and the other is to get enough statistical evidence to prove
that there is a real problem.  The first one requires significant
amounts of my free time and also phone costs (it is causing problems
with our UUCP link from the office, but the extra phone costs aren't
commensurate with the risk of disruption and the time costs involved in
doing this in office hours).

Getting statistics requires finding enough people who are concerned and
have the technical knowledge to understand that there are real problems
which are not the result of the network.

Some more background:  The original symptoms which led me to a USENET
response pointing out that disabling interrupts was the wrong thing
was not on Linux, and was with real UARTs, not ASICs.  In that case a
NUL either replaced the last character or was appended to it (I can't
remember the fine details).  My Linux problems are more consistent with
input being corrupted in proportiion to the number of transmit stops that
collide with input).  In no cases does Linux log an overrun to syslog,
which I believe it would do for a genuine overrun.

One test I did with UUCP once was to do transfers between a motherboard 
serial port and a Rocket Card.  All the errors occured from the Rocket
port to the standard serial port.

One suspicion is that some of the modem sensitivity depends on how fast
the modems respond to commands.