PATCH 2.2.15-pre15: tulip fix for 21041 chips

[Donald Becker]

On Fri, 24 Mar 2000, Hal Murray wrote:

> > It typically takes 60 minutes for a 10-only and 90 minutes for 
> > a 10/100 card to test a change to driver transceivers setting.  You 
> > will want it to *power off* the machine to make certain the residual 
> > settings don't keep a driver working -- the reset signal doesn't 
> > go to all board areas. 
> 
> You said "60 minutes". 
..
> Did "change to driver transceivers setting" mean change to the code 
> that sets those bits?  And "60 minutes" refer to running through 
> a set of tests by hand?

It certainly doesn't take 60 minutes for the driver to change media types.
I meant that it takes that long to do just a transceiver test by hand.

I know that seems like a long time, and it doesn't *feel* that long when I'm
doing it, but I've casually timed it.  (I frequently do this.  I habitually
timed how long it took me to reach each landmark on my old 30 mile drive to
work.  But, like any programmer, I mentally discard rather than average
unusual delays or diversions.  And I stop timing after turning off the car
rather than actually arriving at my destination, so using the timing in my
subsequent schedule always results in being a few minutes late. )

It has taken me most of a day to run through tests of a single Tulip board
type.  The D-Link board, with the bogus transceiver default wiring, was a
special pain.  The transceiver selects its power-up configuration with
external biasing resistors, and they had configured it to 10baseT-HD-only.
It used a new (at the time) Level One transceiver, which had its own quirks.
It actually took a about a week to change the driver to work reasonably, and
I spent the final days just testing "frozen" code.

I usually do only a few from-power-on tests, checking only 10 and 100,
unless I suspect that there is a special reset sequence.  Waiting a few
minutes each of the dozen times needed to test all power-on-reboot
combinations is pretty distracting.

> If so, do you have a list of the tests?  Or is it as simple as plug 
> it into one of everything and verify that it gets the right answer?

No.  You have switch types while in active use.  So you can't set up a
script to do it.

I do have a script that looks like

________________
mii-diag -F 100baseTx
sleep 4
ping -c 4 $(desthost)
mii-diag -F 10baseT
sleep 4
ping -c 4 $(desthost)
...
mii-diag -A 0x01d0
mii-diag -A 0x01d0 -R
sleep 4
ping -c 4 $(desthost)
... and so on.
________________

But this script should really be C program that measures how long it takes for
communications to be re-established with every transition.
Does anyone want to write it?

We also need a user-level multicast filter test.  I currently add in some
ad-hoc code to the driver itself during development.  This puts the device
into loopback mode and tests the filter accept and reject bit-by-bit.
This is ugly code, and a PITA to run, so I strip that code out before
release.  After that the multicast functionality is only indirectly tested.

A proper test program would both sample random addresses and know about the
common multicast filter hardware implementations to test the corner cases.
(Most filters are 8390-like, because they started from a 8390 clone design.)

Donald Becker
Scyld Computing Corporation, becker@scyld.com

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org