[eepro100] Unmarked transmit completed status

[Keith R. Mohlenhoff]

> > Anyone know what would cause the CU not to mark the buffer as being
> > sent?
>
> Presumably a microcode bug, where the command descriptor update is
> dropped by a higher priority receive transfer.
>

So much for operating independantly and concurrently.
If I used the CUHiPriStart/Resume, would the microcode then mess up on the
RX side?

> > There is a  comment in Mr. Becker's code
> > speedo_interrupt function
> > "Command unit failed to mark command ... as complete... "
> >
> > Does this happen often?
>
> Hmmm, writing a driver of your own?
>
Trying, but not doing a very good job. The data sheet was lacking alot of
information and the NDA is taking forever.

> It doesn't happen frequently, but when it does happen it tends to occur
> as a burst of missed updates.  This may have been fixed with new chip
> versions.
>
That is what I was seeing, and going back now it looks like all the packets
are getting through(testing with a smartbits).
So I just have to have faith and free the bufs?

When I send around 1000 (512 byte)packets per second out the tx function, I
sometimes see that the chip is still active after setting up the new Tx
frame and clearing the suspend of the previous frame.
What is the proper procedure in this case?

I did not see configuration structure for the 82559 in eepro100.c:v1.15, is
there another driver I should be looking at?

thanks

Keith R. Mohlenhoff

> 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
>