[eepro100] Transmitter Timeout -- addednum

[Donald Becker]

On Tue, 1 Aug 2000, Kallol Biswas wrote:

> > Hmmm, the documentation does states that the chip will examine the 'S' bit
> > of the i+1 command, but this is only an optimization and should not impact
> > correct operation.  If the suspend bit is set on the current i'th command
> > (as it will be if the subsequent command is still being constructed), the
> > chip will suspend.  It will then re-read the i+1'th command at the next
> > RESUME command.
> 
> 
> Section #6.5.3.2 CU_RESUME
> 
>  "If the CU is in active state it will check the validity of the S-bit
> in the current and next action command. If the S-bit is cleared in the
> current CB, it will proceed to the next CB in the list after executing the
> current CB."

Yes, this is the PCI bus access optimization.  I'm guessing that it is done
this way so that the second bus access request isn't delayed by analyzing
the status of the first result.  This delay is critical-path because the
usual use of CU_RESUME is when the current command 'S' bit has just been
cleared.

But if the CU reads the 'S' as set in the current (i'th) command, it goes to
the suspend state and the next CU_RESUME will cause it to re-read the next
(i+1) command 

> The other case as I told earlier:
>       The card prefetches old next cmd word, goes to suspended state, the
> driver updates this old next cmd word, and sends a CU_RESUME, upon receiving 
> the resume the card executes the old cmd word and stalls. We would
> not have this problem if all the cmd words in the ring were only
> TX commands, as a prefetched command would always be a TX cmd.

This is obviously unreasonable.  If this were the case, all next commands
would have to be Tx commands.  The driver could transmit 

> I am not sure if Intel's driver uses NOP or has separate TX and
> non-tx command ring, but I saw some driver would use NOP.
> If I get some free time I will definitely read existing drivers.

I use a NoOp to link in longer commands.  This must be done because of the
saved-link-pointer semantics.  The NoOp commands are rare: the longer
command are only used at configuration time and when changing the multicast
list.

You might be recalling drivers for the older Intel chips, such as the
i82586.  There every other command had to be a NoOp.  The chip took eons to
resume operation from a suspend.  I think it was Russ Nelson that found a
trick that gave reasonable performance: rather than have the chip suspend,
the NoOp just pointed to itself.  The command unit looped until the driver
linked in a new command with a trailing NoOp.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403