lkml.org 
[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe: reflections on the 3c905 v0.40 driver
On Apr 26, root wrote:

> and I see in the code that:
>
>
> char *ram_split[] = {"5:3", "3:1", "1:1", "3:5"};
> config.i = inl(ioaddr + Wn3_Config);
> printk(" %dK %s-wide RAM %s Rx:Tx split, %s%s interface.\n",
> 8 << config.u.ram_size,
> config.u.ram_width ? "word" : "byte",
> ram_split[config.u.ram_split],
>
> Anybody know if the Rx:Tx split can be changed? Or is it hard-coded on the
> card?


that's exactly what I did yesterday using this patch

--- 3c59x.c-0.40.orig Thu Apr 17 01:51:39 1997
+++ 3c59x.c-0.40 Sat Apr 26 10:58:51 1997
@@ -708,6 +708,16 @@
ram_split[config.u.ram_split],
config.u.autoselect ? "autoselect/" : "",
media_tbl[config.u.xcvr].name);
+#if 1 /* KTS */
+ config.u.ram_split = 1;
+ outl(config.i, ioaddr + Wn3_Config);
+ printk(" %dK %s-wide RAM %s Rx:Tx split, %s%s interface.\n",
+ 8 << config.u.ram_size,
+ config.u.ram_width ? "word" : "byte",
+ ram_split[config.u.ram_split],
+ config.u.autoselect ? "autoselect/" : "",
+ media_tbl[config.u.xcvr].name);
+#endif
dev->if_port = config.u.xcvr;
vp->default_media = config.u.xcvr;
vp->autoselect = config.u.autoselect;
I've tested all 4 possible settings and got the following sustained transfer rates
sending data from either a Linux/3c905 using v0.37 or a SGI O2 running IRIX 6.2
to Linux/3c905 using v0.40 (with "Rx Pacing bug") [ Linux == idle PPro200 ].
in kBytes/sec on 100Mbit using "rsh" (sort of):

config.u.ram_split Rx:Tx 3C v0.37 SGI O2

0 5:3 630 1000
1 6:2 (3:1) 850 1300
2 4:4 (1:1) 315-400 800
3 (default!) 3:5 210 570


so obviously, the "3:5" is by far the worst setting for not using Rx busmastering
(at least for 100Mbit).

now I've tried using only the following patch to see what happens when I'm using Rx DMA
despite of this "Rx Pacing bug" (PLEASE, can anyone really give details what this bug
is about ???)

--- 3c59x.c-0.40.orig Thu Apr 17 01:51:39 1997
+++ 3c59x.c-0.40 Sat Apr 26 10:58:51 1997
@@ -727,8 +737,8 @@
printk(" Rx Pacing bug fixed, enabling bus-master receives.\n");
vp->full_bus_master_rx = 1;
} else {
- printk(" Rx Pacing bug exists, disabling bus-master receives.\n");
- vp->full_bus_master_rx = 0;
+ printk(" Rx Pacing bug exists, but *NOT* disabling bus-master receives.\n");
+ vp->full_bus_master_rx = 1; /* KTS */
}
}

now I got 9-10MBytes/sec for both Rx/Tx (used the same patched v0.40 or
v0.37 on the remote side). now I've used the first patch too with

config.u.ram_split = 0;

just in case I'd get these

eth0: transmit timed out, tx_status 88 status e000.
eth0: Transmitter encountered 16 collisions -- network network cable problem?
Flags; bus-master 1, full 1; dirty 560482 current 560498.
Down list 07ffe940 vs. 07ffe920.

errors again because this would disable busmaster receives:

if (vp->full_bus_master_rx) {
printk(" Switching to non-bus-master receives.\n");
outw(SetStatusEnb | AdapterFailure|IntReq|StatsFull |
(vp->full_bus_master_tx ? DownComplete : TxAvailable) |
RxComplete | (vp->bus_master ? DMADone : 0),
ioaddr + EL3_CMD);
}

using Rx:Tx 5:3 I then got only ~6.5MB/sec then. haven't done any further
tests yet about Rx:Tx influence on busmatering, maybe next week...


Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.034 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site