Another 2.2 version of 3c59x.c

Andrew Morton andrewm@uow.edu.au
Wed Apr 26 10:38:49 2000


Bogdan Costescu wrote:
> 
> Hi,
> 

Hi, Bogdan.

> I tested the new version with some puzzling rezults: after I got it, I was
> "able" to crash one node with my testing procedure, I rebooted and it
> happened again, I rebooted again and now it's running for more than 24h
> under different loads: parallel jobs, flooding pings, ttcp transfers
> (separate or simultaneous)...

"Crash" how?  Do we know that it was driver-related?

> There is something else that I wanted to bring to your attention,

aargh :-)

> something related to identification of card properties. In the 90xB docs,
> page 31, there is a description of FIFO memory: 8k split for 90x and
> separated 2k for Tx and Rx for 90xB (and also for 90xC). The current
> driver is reporting even for B and C revisions 8K RAM split 5:3 (YMMV)
> which is invalid. Cf. docs, the bits are correctly interpreted for 90x,
> while the same bits are _not_ defined for 90xB and 90xC. (page 57-63 for B
> and 59-61 for C).
> >From what I can see, all the cards that are based on the 90xB (page 17)
> and C (905C and 980C cf. docs, but 980 seems not to have any B variant)
> design are declared as IS_CYCLONE. However, there are other cards
> (especially some CardBus ones) that are also defined IS_CYCLONE. Are they
> based on the 90xB design also? If yes, we can check in vortex_probe1,
> whenever we try to interpret the variable 'union wn3_config config', if
> the card is defined IS_CYCLONE and not interpret the offending bits,
> but report 2k buffers instead. If no... maybe we need another define like
> HAS_FIXED_FIFO.

Thanks.  I haven't paid any attention to this one: the drivers I'm using
appear to settle on 2k:2k which, as you say, doesn't look right.  I'll
look into it tomorrow.

Spent most of the day working on the "tx timeout" problem.  It's being
caused by 16 successive collisions.  You won't see it on switched
ethernet, of course.

I fixed it by resetting the transmitter and fiddling with the DMA engine
when it happens.  3Com assert that 'TxEnable' is enough to recover from
maxCollisions, but it isn't so.  TxEnable works most of the time on a
905B and _never_ on a 575.

I put the 2.3 patch out a few minutes ago.  I'll get a 2.2 patch out
later in the week.

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