3com 3c905c-txm

[Bogdan Costescu]

First of all thank you for Cc-ing to linux-vortex, I read l-k only as
KernelTraffic.

On Thu, 11 May 2000, Donald Becker wrote:

> Which chip was this with?

I'm using 3C905C for these tests.

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

I fully agree with the ideea of adding specific functions for Tornado; I
already started to...
I suspect that the place which produced the errors in my case is
boomerang_start_xmit; this is already after spin_lock_irqsave.

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

Agreed, but you also have the power management routines that only apply to
the newer hardware; if you count them too, it might be feasible to split
at least in two.

> > I suspect that the NIC has started to send a packet, encounters a
> > collision and somehow blocks the downstall completion until it reaches a
> > suitable state.  It _should_ just give up and leave the packet in the Tx
> > FIFO.

There is no indication in the docs that this should happen, one way or
another. When there is no rule, I believe what I see.

> > Bogdan was getting driver failure after <30 minutes with the 2.2
> > driver.  After upping the counter he has run his tests for four days. 
> > He's on a switched LAN, which tends to torpedo the above theories...

In fact, I did the 2.3 driver approach, meaning having a function
wait_for_completion. This adds a jmp/ret to the code and might even affect
the cache.

> I'm going with either
>   - new hardware badly emulates the old behavior in firmware, expecting that
>     nothing was using it.
>   - a misinterpretation what is going on.

I have no means of verifying the first one and surely no other ideea about
what's going on. Can you give us another explanation? (and a fix...)

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De

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