From: huntting@advtech.uswest.com (Brad Huntting)
Subject: Re: Only National NS16550's OK/bug-free?
Organization: U S WEST Advanced Technologies
Date: Sun, 4 Oct 1992 18:16:39 GMT

In article <kurtk.717350790@ee.ualberta.ca> kurtk@ee.ualberta.ca (Kurt Klingbeil) writes:
>There are a few 16550 'compatable' chips available.
>Presumably some are clones, others are licensed second-sources?

[...]

>Has anyone had any experience with this, or could anyone shed some
>detailed light on this topic...

I asked this question on the BSD386 mailing list some time back.

Here is one of the responses:
----------------------------------------------------------------------
[Brad asks]
>>  Can anyone recommend a serial board with a 16550 UART. My Gateway 2000
>>  came with a serial I/O board that has a 16450 UART and I'm
>>  experiencing lots of silo overflows when running SLIP at 9600 baud.

[Someone responded]
> Be shure you get a real National Semiconducter 16550AF, clones
> exist, but are rummered to have problems.

[Brian respondes]
I am willing to sign an affidavit that when I was using
Modular Semiconductor 16550As they had at least one bug that 
basically made them useless for UNIX applications.  Their
engineers even eventually admitted to the problem, sort of.

It was a great bug, would you like to hear about it?

If not skip to end.

I was using an 8 port serial card, after a few days of running getty's
on modems I would find that the ports had become locked up.  Sometimes
they would lock up in a matter of minutes, but usually it would be
16 hours or more before they failed.

It was an infurorating problem.  Of course, the problem never
manifested itself when using NS16500AFN UARTs.

After months of assuming there was a problem in the driver, we hooked 
all the useful pins of one of the MSI parts to a Biomation K450 logic
analyzer with active probes and waited...

16 hours later it happened.  A burst of output from the UART.  There
was no motivating input. All input was silent, but the chip just 
suddenly went into a frenzy of outputing IRQs and driving its other
outputs randomly.  The software desperately tried to respond to
the frenzy of output but to no avail.  The chip was simply no longer
functional and usually died leaving the IRQ high.

We ran the same test with the software setting up the chip for normal
operation but then turning the software off once the chip was in the
waiting for incoming call state.  After about 20 hours the same burst
of output happened and then the chip was dead.

We felt we had enough proof to confront MSI about the problem.  Which
we did.  They responded that, "if we were having a problem, we
should consider and'ing the output with our bus-read signal."

It seemed to us that they had been aware of the problem, but had just
failed to mention it until we confronted them with our evidence.

Obviously piles of AND gates was not the solution and didn't even
address the IRQ line.  We stopped using the MSI parts and asked for
our money back, as they had claimed their parts were replacements
for the NS16500AFN, and they were not.  We never got our money
back. (We had 600 of the parts).

However, there part does work fine for what we call normal DOS usage.
That is if the part is "turned off" when idle.  And only "turned on"
during use, and then "turned off" again.  The part only seemed to
explode after many hours of being in the on state idle.

They may well have fixed the problem by now.  They had no plans to
fix or admit there was a problem when we were dealing with them.

So its not a rumor that there are bad 16550A compatibles out there,
its a fact.

brian@apt.bungi.com
----------------------------------------------------------------------

brad
	huntting@advtech.uswest.com