[tulip] Tulip XMT and RCV descriptors - an observation

[Donald Becker]

On Sun, 17 Feb 2002, Moti Haimovsky wrote:

> This is not a bug - but its good to be aware to the following:
> background:

This is certainly not a bug, but a carefully considered part of the
driver design.

> The observation:
>  Looking at the tulip driver I've noticed the driver writes the "next
> descriptor" address to
>  buffer2 address field of the descriptor as if it plans to use it in chain
> mode, BUT
>  it does not set the "second address chained" bit of that descriptor.
>  this means that one may be fooled to believe that the chip is programmed to
> work in chained mode
>  while the chip is actually working in ring mode (or better say "fixed gap
> mode").

This is deliberate.  While the real Tulip design works in both modes,
some of the clone chips work in only one of the modes.  By having  the
driver lay out this descriptors to work in either mode, we work with all
chips.

The linking of descriptors is done at initialization time and imposes
no run-time overhead.

>  This of course creates no problem in the current driver due to the
> descriptors memory layout
>  the driver is using, but the driver will fail to work if one will try to
> use a different
>  memory scheme, such as widening the gap between the descriptors (one
> descriptor per cache line
>  for examples), or when the descriptors will not reside in a physically
> contiguous memory.

Rule: Don't mess with the Tulip driver unless you really know what you
are doing.  This is a good example where someone could "optimize" the
driver and break it in a way that isn't discovered with their own tests.
There are many sections of the media selection code that similarly go
beyond the documentation to make the code work with all known designs.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993