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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:20 EST