CU command completion status dropped

[Gary Bjerke]

I have modified the 1.3 release of this driver to work on a Phillips
Trimedia 1100 multimedia processor. I did the porting work on a system
with an 82558 chip, and am currently using the 82559. I have noticed
during testing that occasionally the driver's transmit side locks up.
I've tracked this down to the fact that the 82558/9 sometimes fails
to return completion status (0xa000) in the Tx descriptor. The interrupt

handler nevers sees completion on one descriptor, and so never processes

the subsequent descriptors (which do get completion).

This only seems to happen with one of the first two commands issued to
the
CU - either the IA setup command, or the config setup command. The
eepro100.c driver (versions 1.3 - 1.5) contains the following in
eepro100_open():

                /* Avoid a bug(?!) here by marking the command already
completed */
                sp->tx_ring[0].status = ((CmdSuspend | CmdIASetup) <<
16) | 0xa000;

Since I occasionally see this in the second command, this is no longer a

viable workaround. The driver chains these commands as fast as it can
set them up, waiting only for the CU to accept the command. I have found

that by waiting for completion status for each command before issuing
the next, the problem appears to go away.

The processor I am using is clocked at 125Mhz, but it is VLIW and up to
5 instructions are concurrently executed per clock cycle. So the actual
execution rate could be up 625 mips. It may be that the driver is now
able to issue these commands so quickly that it is exposing a race
condition that causes status to be dropped. If I'm right, then as
people move towards faster processors this may become more of a problem.