WTB: Pro380, VAXstation

From: Tony Duell <ard_at_p850ug1.demon.co.uk>
Date: Tue Apr 20 17:20:56 2004

> >Intel 82586, if I remember right. It uses queues, not rings, for its

I think you do rememebr right.

> >commands. There are race conditions in the programming interface so
> >that the chip sometimes sets a queue to empty at the same time that
> >the driver puts a new entry on the queue, which forces the driver to
> >notice that and repair the confusion.
> >
> >This is why real Ethernet chips use rings.
> >
> > paul
>
> In the process of debugging that driver, the programmer involved with it,
> found and identified a number of problems/bugs that Intel was unaware of
> and refused to admit to until they finally isolated and fixed them in a
> later rev.

Has Intel ever made a single LSI chip that worked correctly? They even
managed to screw up a parallel I/O chip !. The 8255 has the ridiculous
'feature' that any write to the mode control register (even if it doesn't
change the contents of said register) clears all output lines to 0's.
Since they start off as inputs after reset (effectively floating), and
since an unconnected TTL input floats high (if you do the right thing and
add a pull up/down resistor, it's a lot easier to pull up than pull down,
so the line will stille be high), you get the situation that the logic
connected to that chip sees high levels immeediately after the reset
which then become 0's when the 8255 is initialised, and then you have to
give them the right levels. Some things get terribly confused by this!

Other parallel I/O chips let you write to the output register before
defining the directions of the I/O lines, so you can set lines to 1's and
then make them outputs. There are then no momentary 0 states to drive
your logic mad.

And IIRC the Intel 8251 USART chip has the feature that there's no way to
get it into a known state under certain circumstances (IIRC this happens
if you're initialising it in synchronous mode and don't know how many
bytes you've written to it).

-tony
Received on Tue Apr 20 2004 - 17:20:56 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:30 BST