3com 3c905c-txm

[Andrew Morton]

Donald Becker wrote:
> 
> ...
> > command is used on a heavily loaded, hubbed LAN.  A LAN on which there
> > are many collisions.  A LAN on which I can easily force the '16
> > successive collisions' condition.
> 
> Which chip was this with?

3c905B for me.

> The download stall should be an instantaneous thing.  The CPU must have the
> PCI bus to send the command, and the chip only needs to stop requesting the
> bus for downloading packets.  At most the chip should finish a transfer it
> had already requested, which should happen before reading the status.

Well, the manual says "The DnStall command stops the NIC from fetching
the DnNextPtr DPD entry and loading it into the DnListPtr register".

So the question is: what happens if the DMA engine is only partway
through a packet?  Suppose it is reading a 512 byte packet, that it has
read 256 bytes and that we then issue DnStall.  From my reading, it is
possible that the DnStall will not complete until the remaining 256
bytes have been transferred.

More on this in amother email...

> This behavior might have changed with the newer chips.  The Download-Stall
> method is no longer required, and the semantics might have been
> unintentionally changed to "break" the command.  If so, we will have to add
> another transmit and receive function pair to handle Tornado chips (which
> might not be a bad idea anyway).  Note that I'm only guessing here -- it
> could be another bug that we are seeing, such as a interrupt that is occuring
> during the CommandComplete check.

mm..  The spin_lock_irqsave() should prevent this.

> Given that there are alread two (and perhaps a third) Tx and Rx methods, the
> natural question is why the driver has not been split.
> 
> The answer is that the Tx and Rx paths are very compact.  They have to be
> that way for good performance.  Having multiple functions doesn't add much
> to the driver size.  But the large, complex media selection code is shared
> across generations and card types.
> 
> Splitting the driver up by generation would result in three slightly smaller
> drivers, with a total size much larger than now and version skew in the
> media selection code.

I fully agree.  If we were to split the driver two or three ways, the
maintenance overhead would rise a lot, and we're not exactly overflowing
with network driver maintainers at this time.

So if the cost of easier maintenance is a bit of bloat, tough luck!  If
the code size was identified as an issue I'd prefer to slice the driver
up with conditional compilation or dead code elimination, rather than
creating extra .c files.


> 4000 PCI cycles is a *very* long time.  Ages.  It should only 0 to 2 PCI
> cycles to queue a packet.

mmm..  Next email...

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