[eepro100] Re: Transmitter Timeout -- addednum

[Andrey Savochkin]

On Sun, Jul 30, 2000 at 10:41:29AM -0400, Kallol Biswas wrote:
> I don't know about the latest eepro100 driver, but the version 
> I saw had a fundamental design problem, again I will try explain:
>    82559 prefetches the next command from the command ring,
> suppose the cmd unit is executing ith command and has 
> has prefetched the next one, i.e. (i+1)th already, driver 
> sets up the the (i+1)th cmd, sets the S bit and sends RESUME,
> if the CU:
> 	*in Suspended state it goes to active state, does not re-read next
> link ponter(address for i+1th) re-reads the Sbit of of ith command.
> If the Sbit of ith command is cleared then executes the i+1th otherwise
> goes back to suspended state.
>          *If CU is active it checks the validity of S bits of next(i+1 th)
> and present(ith) cmd(PCI cmd 0x6 MR is used to re-read Sbit of a TxCB, I saw
> it on analyzer).
> Please note that it does not say it re-analize the next(i+1 th) command but
> the S bit.

If I understand right, you state that the hardware reads and caches the
command from the (i+1)th slot when it proceeds (i)th even if (i)th descriptor
has S bit in it, don't you?
If it does so, it's a very broken piece!
I don't know what documentation states about TX ring processing, but this
policy clearly contradicts the common sense!

> So if the i+1 th command was a previously executed say transmit cmd and 
> driver sets up now as a say multicast cmd then the card executes
> i+1 th cmd with invalid parameters, and the card stall.
> 
> Our initial version of the 82559 driver would hang on an Itanium processor
> based system because of this problem, but adding a NOP after a
> cmd has solved the problem. Now our stress tests run for days without
> any problem on 82559. 
> 
> Hope I could make this clear, if you have any question please feel
> free to make a call at 973-443-7469/973-442-0164.
> I will try to explain as much as I can.

Best regards
					Andrey V.
					Savochkin