More issues

[Andrew Morton]

Bogdan Costescu wrote:
> 
> Hi,
> 
> I discovered some other issues that are present in the current driver. In
> the order of importance (IMO):
> 
> 1. After changing fullDuplexEnable bit in Media Control register (page
> 179; page 198 in B docs), TxReset and RxReset must be issued. While in
> vortex_open() this is done, in vortex_timer() it's not!
> I assume that at present if such situation occur, either the card is able
> to continue without the resets (but violating the specs) or some error
> condition is triggered so that the routine for handling the error does a
> reset. Anyway, this should not happen very often, more probable when
> vortex_timer() is called the first time after driver init.

Yes, I spotted that also.

In the 2.3 driver I simply put a diagnostic printk() to see if its
occurrence is associated with any reported failures.  Wait-and-see mode.

TxResets are tricky things - I got in a bit of trouble with these when
integrating the 3cc575 support.

> 2. The driver has some defines in 'enum Window1' (aprox. line 376) which
> assume that the window 1 is always mapped at offsets 0x10-0x1F (as written
> in the driver this is true for vortex). 90xX cards do not obey this rule.

In the 2.3 driver these are not referenced if the NIC is a boomerang
series.  This may not be true in the 2.3 driver.  Need to review this.

> 3. RxError and RxStatus (from Window 1) do not exist for rev. B & C.
> RxStatus is still used in boomerang_rx() - although only for debugging.

Thanks.  I fixed this in the 2.3 driver.

> 4. At the beginning of vortex_interrupt() there is a line:
>         latency = inb(ioaddr + Timer);
> This variable is only used for debugging in the next printk, so it wastes
> cycles when debuging is not enabled. Should be moved inside the 'if'.

Ditto.

> 5. We acknowledge intRequest at the end of the big 'do' loop in
> vortex_interrupt(). While this is harmless, it should not be necessary as
> it's only set by execution of RequestInterrupt command or expiration of
> the Countdown register (neither used by the driver, AFAIS).

OK, I need to check this.

> After more than 24h of torture with parallel jobs, ttcp and cross flooding
> pings with diff. packet sizes, the computers are still up. Good sign!
> I notice however some Rx overruns, about 1800 for 1000Mpacket.

Rx overruns.  These are pretty easy to get when Linux blocks interrupts
for too long. Console output is a prime offender, as is the IDE driver
when you're not using 'hdparm -u'.

I'm surprised it happens much on SMP though.

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