* Re: [parisc-linux] C110 builtin nic slow?
@ 2003-11-10 11:10 Joel Soete
2003-11-10 12:31 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-10 11:10 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Hello Grant,
> netperf home is netperf.org.
Yes I check and the sources in debian (non-free tree) are the last one alailable
near netperf.org.
> It does run/build on parisc. I've used it before.
Yes, I check it at the office on a b180 :) (dpkg-buildpackage after
an apt-get source netperf; i don't see why it is not pre-build, well doesn't
matter)
>Note that with B180, I can only get about 1MB/s throughput max.
The same here at the office.
>With C3000 I get about 5 or 6 MB/s 100BT link.
What's up, if you connect it via a 10BT hub (but don't reboot and don't
restart or reset the interface). That should be what hapen on my pc box
(but I couldn't verify).
>Your network performance numbers are pretty far off from that but
>there might be other factors involved.
Well trying to help to fix fdisk in 2.6, I don't have time to install netperf
on my C110, sorry.
Any way, a big part of the problem should come from the bad auto-configuration:
As explained before, I start up first my pc (to get a minicom 'console').
As it is setup with auto-negociation and the c110 is not yet pw up, the
nic should be set at 100/full-duplex. Then when I boot the c110, the nic
is setup with the best of its availability: 10/half-duplex.
That seems to be confirm when I launch '/etc/init.d/networking stop and
latter start (restart don't seems to have same effect but again I couldn't
verify yet) on the pc,then I can log peack of 350k/s (that is already better
but that should be the limit of the adsl at this moment).
Another limits seems then to come from squid's caching which drop down flow
to about 100K/s.
So I still have to test ft without squid on the pc, with midle and big size
file, with get and put with various protocol from the two platform to confirm
this hypothesis (obvioulsy another way would be to use a 100bt router or
switch, but I couldn't get any one, and it would need to much time for me
to learn this
os).
>I expect mem copy routines are saturating the CPU and thrashing
>the data cache. The tulip driver copies the entire buffer from
>where the card DMA'd to the skbuff in order to "bias" the buffer
>by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
>Adding "unaligned access" macros to the "common" networking code
>path has been discussed and rejected (again) in the past month or so.
>Linus himself has rejected such proposals in the past to.
>
>If you twiddle the tulip driver to NOT copy all the data for
>packets > 512 bytes, the kernel will tell you when/where the network
>stack makes unaligned accesses. You can fix those and keep that as
>a local patch. I'd be interested in hearing the netperf (or httperf)
>numbers with such a patch when compared to the current behavior.
>
Ok I will try it first.
>thanks,
>grant
>
Thanks to your attention,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 11:10 [parisc-linux] C110 builtin nic slow? Joel Soete
@ 2003-11-10 12:31 ` Joel Soete
2003-11-10 14:00 ` Joel Soete
2003-11-10 17:37 ` Grant Grundler
0 siblings, 2 replies; 35+ messages in thread
From: Joel Soete @ 2003-11-10 12:31 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Sorry for auto-reply but I just remember that on the c110 the builtin nic
is:
"8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,
0x0, 0x8a"
ie a Lasi_82596 (as Matthew mentioned in a previous mail).
That you look for that stuff in that code :)
Joel
>-- Original Message --
>From: "Joel Soete" <soete.joel@tiscali.be>
>To: "Grant Grundler" <grundler@parisc-linux.org>
>Cc: "parisc-linux" <parisc-linux@lists.parisc-linux.org>
>Date: Mon, 10 Nov 2003 12:10:46 +0100
>Subject: Re: [parisc-linux] C110 builtin nic slow?
>
>
>Hello Grant,
> netperf home is netperf.org.
Yes I check and the sources in debian (non-free tree) are the last one alailable
near netperf.org.
> It does run/build on parisc. I've used it before.
Yes, I check it at the office on a b180 :) (
>pkg-buildpackage after
an apt-get source netperf; i don't see why it is not pre-build, well doesn't
matter)
>Note that with B180, I can only get about 1MB/s throughput max.
The same here at the office.
>With C3000 I get about 5 or 6 MB/s 100BT
>link.
What's up, if you connect it via a 10BT hub (but don't reboot and don't
restart or reset the interface). That should be what hapen on my pc box
(but I couldn't verify).
>Your network performance numbers are pretty far off from that but
>th
>re might be other factors involved.
Well trying to help to fix fdisk in 2.6, I don't have time to install netperf
on my C110, sorry.
Any way, a big part of the problem should come from the bad auto-configuration:
As explained before, I start up f
>rst my pc (to get a minicom 'console').
As it is setup with auto-negociation and the c110 is not yet pw up, the
nic should be set at 100/full-duplex. Then when I boot the c110, the nic
is setup with the best of its availability: 10/half-duplex.
T
>at seems to be confirm when I launch '/etc/init.d/networking stop and
latter start (restart don't seems to have same effect but again I couldn't
verify yet) on the pc,then I can log peack of 350k/s (that is already better
but that should be the limi
> of the adsl at this moment).
Another limits seems then to come from squid's caching which drop down flow
to about 100K/s.
So I still have to test ft without squid on the pc, with midle and big size
file, with get and put with various protocol fr
>m the two platform to confirm
this hypothesis (obvioulsy another way would be to use a 100bt router or
switch, but I couldn't get any one, and it would need to much time for me
to learn this
os).
>I expect mem copy routines are saturating the
>PU and thrashing
>the data cache. The tulip driver copies the entire buffer from
>where the card DMA'd to the skbuff in order to "bias" the buffer
>by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
>Adding "unaligned access"
>macros to the "common" networking code
>path has been discussed and rejected (again) in the past month or so.
>Linus himself has rejected such proposals in the past to.
>
>If you twiddle the tulip driver to NOT copy all the data for
>packets > 512
>bytes, the kernel will tell you when/where the network
>stack makes unaligned accesses. You can fix those and keep that as
>a local patch. I'd be interested in hearing the netperf (or httperf)
>numbers with such a patch when compared to the current
>ehavior.
>
Ok I will try it first.
>thanks,
>grant
>
Thanks to your attention,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le
>onde.
http://reg.tiscali.be/default.asp?lg=fr
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 12:31 ` Joel Soete
@ 2003-11-10 14:00 ` Joel Soete
2003-11-10 17:35 ` Grant Grundler
2003-11-10 17:37 ` Grant Grundler
1 sibling, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-10 14:00 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Grant,
Sorry again, but having find this interesting stuff in 82596.c:
---------><---------
[...]
/* Check if the packet is long enough to just accept
* without copying to a properly sized skbuff.
*/
if (pkt_len > rx_copybreak) {
struct sk_buff *newskb;
[...]
}
else
skb = dev_alloc_skb(pkt_len + 2);
[...]
---------><---------
This seems well what you describe?
and more:
---------><---------
[...]
/* Copy frames shorter than rx_copybreak, otherwise pass on up in
* a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha).
*/
static int rx_copybreak = 100;
[...]
---------><---------
and finaly:
---------><---------
/*
[...]
TBD:
[...]
* performace test to tune rx_copybreak
[...]
---------><---------
(I just copy as read preformace and not performance as my mind abuse :) )
This last notice seems what I am loocking for?
Have you a better idea then try and test (ie rx_copybreak=512, test, rx_copybreak=256,
... and btw rx_copybreak = PKT_BUF_SZ == 1536)?
Or is it better to tiddle code before?
Thanks for additional advise,
Joel
>-- Original Message --
>From: "Joel Soete" <soete.joel@tiscali.be>
>To: "Grant Grundler" <grundler@parisc-linux.org>
>Cc: "parisc-linux" <parisc-linux@lists.parisc-linux.org>
>Date: Mon, 10 Nov 2003 13:31:45 +0100
>Subject: Re: [parisc-linux] C110 builtin nic slow?
>
>
>Sorry for auto-reply but I just remember that on the c110 the builtin nic
is:
"8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,
0x0, 0x8a"
ie a Lasi_82596 (as Matthew mentioned in a previous mail).
That you look for tha
> stuff in that code :)
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 14:00 ` Joel Soete
@ 2003-11-10 17:35 ` Grant Grundler
2003-11-11 12:54 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Grant Grundler @ 2003-11-10 17:35 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Mon, Nov 10, 2003 at 03:00:37PM +0100, Joel Soete wrote:
> if (pkt_len > rx_copybreak) {
> struct sk_buff *newskb;
yup - the rx_copybreak support is exactly what I'm talking about.
tulip driver has similar support.
> /* Copy frames shorter than rx_copybreak, otherwise pass on up in
> * a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha).
> */
> static int rx_copybreak = 100;
The comment is wrong. Tulip uses 1518 for nearly everything but x86.
ie it copies all packets since the MTU is <= 1518.
> This last notice seems what I am loocking for?
> Have you a better idea then try and test (ie rx_copybreak=512, test, rx_copybreak=256,
> ... and btw rx_copybreak = PKT_BUF_SZ == 1536)?
> Or is it better to tiddle code before?
I don't know. It depends on if/when the misaligned access happens.
It's possible the misaligned access is less expensive than
the full copy on your machine.
grant
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 17:35 ` Grant Grundler
@ 2003-11-11 12:54 ` Joel Soete
2003-11-12 3:22 ` Grant Grundler
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-11 12:54 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Grant Grundler wrote:
> On Mon, Nov 10, 2003 at 03:00:37PM +0100, Joel Soete wrote:
>
>> if (pkt_len > rx_copybreak) {
>> struct sk_buff *newskb;
>
>
> yup - the rx_copybreak support is exactly what I'm talking about.
> tulip driver has similar support.
>
>
>>/* Copy frames shorter than rx_copybreak, otherwise pass on up in
>> * a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha).
>> */
>>static int rx_copybreak = 100;
>
>
> The comment is wrong. Tulip uses 1518 for nearly everything but x86.
> ie it copies all packets since the MTU is <= 1518.
>
Correct :)
I so try rx_copybreak = 1518
and also run from pc netperf (the script
/usr/share/doc/netperf/examples/snapshot_script palin)
but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak =
1518):
do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
...
:(
and i never get any miss alignement messages?
I restart this test this morning but in the contrary way ie from c110:
sh /usr/share/doc/netperf/examples/snapshot_script sid.home
then
Netperf snapshot script started at Tue Nov 11 12:52:15 CET 2003
Starting 56x4 TCP_STREAM tests at Tue Nov 11 12:52:52 CET 2003
------------------------------------
Testing with the following command line:
/usr/bin/netperf -t TCP_STREAM -l 60 -H sid.home -i 10,3 -I 99,5 -- -s
57344 -S 57344 -m 4096
seems to send some pkt and finaly hung?
hmm I will try to run it under gdb and so hope to discover what append.
Cheers,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-11 12:54 ` Joel Soete
@ 2003-11-12 3:22 ` Grant Grundler
2003-11-15 19:41 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Grant Grundler @ 2003-11-12 3:22 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Tue, Nov 11, 2003 at 12:54:25PM +0000, Joel Soete wrote:
...
> but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak =
> 1518):
> do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
> ...
hrm...this sounds familiar...I might have only run the netperf "client"
on parisc and ran "netserver" on either ia64 or ia32 box. :^/
sorry,
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-12 3:22 ` Grant Grundler
@ 2003-11-15 19:41 ` Joel Soete
2003-11-15 22:56 ` M. Grabert
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-15 19:41 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Hi Grant,
I quiet sure now that the pb come from the 2d nic of my pc.
It is a:
00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 24)
I with google, I find back a mail of Andrew Morton in which he mentioned
a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
# ./vortex-diag -aem
[...]
Transceiver type in use: 10baseT.
MAC settings: full-duplex.
^^^^^^^^^^^^
Station address set to 00:10:4b:63:2e:bf.
Configuration options 000a.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
Device ID 9055, Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
No BIOS ROM is present.
Transceiver selection: 10baseT.
Options: force full duplex, link beat required.
^^^^^^^^^^^^^^^^^
PCI Subsystem IDs: Vendor 10b7 Device 9055.
[...]
So i will continue to see how to set it up in half-duplex (would it not
be the default in 10BT?)
Cheers,
Joel
Grant Grundler wrote:
> On Tue, Nov 11, 2003 at 12:54:25PM +0000, Joel Soete wrote:
> ...
>
>>but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak =
>>1518):
>>do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
>>...
>
>
> hrm...this sounds familiar...I might have only run the netperf "client"
> on parisc and ran "netserver" on either ia64 or ia32 box. :^/
>
> sorry,
> grant
>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-15 19:41 ` Joel Soete
@ 2003-11-15 22:56 ` M. Grabert
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: M. Grabert @ 2003-11-15 22:56 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Sat, 15 Nov 2003, Joel Soete wrote:
> Hi Grant,
>
> I quiet sure now that the pb come from the 2d nic of my pc.
>
> It is a:
> 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
> (rev 24)
>
> I with google, I find back a mail of Andrew Morton in which he mentioned
> a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
> # ./vortex-diag -aem
> [...]
> Transceiver type in use: 10baseT.
> MAC settings: full-duplex.
> ^^^^^^^^^^^^
> Station address set to 00:10:4b:63:2e:bf.
> Configuration options 000a.
> Saved EEPROM settings of a 3Com Vortex/Boomerang:
> 3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
> OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
> Device ID 9055, Manufacturer ID 6d50.
> Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
> No BIOS ROM is present.
> Transceiver selection: 10baseT.
> Options: force full duplex, link beat required.
> ^^^^^^^^^^^^^^^^^
> PCI Subsystem IDs: Vendor 10b7 Device 9055.
> [...]
>
> So i will continue to see how to set it up in half-duplex (would it not
> be the default in 10BT?)
How is it connected?
Is it connected to a Switch (with Full-Duplex support, not a regular Hub)?
Or is it connected to another PC via a Cross-Over cable?
If either of them is true, then 10BaseT will auto-negotiate Full-Duplex,
of both ends support it.
It's usually safe with 10BaseT only cards, but it's might come to some
little problems if some cheap 100BaseTx cards are involved (more complex
auto-negotiation involved, some cheap cards don't do it correctly).
Then you might have to force it to 10Mbit, 100Mbit, Full or Half-Duplex
manually.
However I don't see why the network card should be *automatically* forced
to Full-Duplex, since 'forced' implies that is was done manually!
Actually if one end point uses Full-Duplex and the other end uses
Half-Duplex, there should be no connection possible. The same for
the situation when one side uses 10Mbit and the other is set to
explicitly use 100MBit.
The only situation where such a decreased network performance occurs
is IMHO that your have a cheap network equipment.
IE. a dodgy network cable that isn't properly shielded or doesn't use all
8 wires, and/or cheap network cards that don't test whether the network
connection/cable is capable of supporting Full-Duplex reliably.
In this (worst case) scenario there will be a lot of packet drop on
the physical layer and the network cards will re-send the ethernet
packets autmatically (usually) without notifying you. You will see
decreased network performace as you mentioned it.
Unfortunately I have seen this a couple of times in my life, especially
in the old 10Base2/5 days with broken terminators or tranceivers, but also
with 10BaseT, and even more so with 100Mbit and low-quality network cables.
greetings, Max
PS: oh, yes, another possible problem might be an IRQ conflict (which is
rather unlikely on PA-RISC). It would cause also degraded network
performance.
^ permalink raw reply [flat|nested] 35+ messages in thread* [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-15 22:56 ` M. Grabert
@ 2003-11-15 23:22 ` buggz
2003-11-15 23:34 ` Matthew Wilcox
2003-11-16 1:51 ` Grant Grundler
2003-11-15 23:58 ` [parisc-linux] C110 builtin nic slow? M. Grabert
2003-11-16 16:53 ` Joel Soete
2 siblings, 2 replies; 35+ messages in thread
From: buggz @ 2003-11-15 23:22 UTC (permalink / raw)
To: parisc-linux
Anyone get dual NICs working on this machine?
The second one is on the EISA expansion card.
It works in HPUX.
I'd like to get this to work in linux and use the box as a router/gw.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
@ 2003-11-15 23:34 ` Matthew Wilcox
2003-11-15 23:50 ` buggz
2003-11-16 1:51 ` Grant Grundler
1 sibling, 1 reply; 35+ messages in thread
From: Matthew Wilcox @ 2003-11-15 23:34 UTC (permalink / raw)
To: buggz; +Cc: parisc-linux
On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.
> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.
When you asked on IRC, I asked you what kind of EISA network card it is.
I don't know what driver you'll need to enable.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-15 23:34 ` Matthew Wilcox
@ 2003-11-15 23:50 ` buggz
0 siblings, 0 replies; 35+ messages in thread
From: buggz @ 2003-11-15 23:50 UTC (permalink / raw)
To: parisc-linux
On Sat, 15 Nov 2003, Matthew Wilcox wrote:
> On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> > Anyone get dual NICs working on this machine?
> > The second one is on the EISA expansion card.
> > It works in HPUX.
> > I'd like to get this to work in linux and use the box as a router/gw.
>
> When you asked on IRC, I asked you what kind of EISA network card it is.
> I don't know what driver you'll need to enable.
>
> --
> "It's not Hollywood. War is real, war is primarily not about defeat or
> victory, it is about death. I've seen thousands and thousands of dead bodies.
> Do you think I want to have an academic debate on this subject?" -- Robert Fisk
>
Oh, the expansion card?
I gave the P/N of the NIC.
I will reply here w/ the P/N's of both the cards.
Those parts are at work, so it will be Tuesday before I know.
Thanks.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
2003-11-15 23:34 ` Matthew Wilcox
@ 2003-11-16 1:51 ` Grant Grundler
2003-11-16 4:16 ` Shane G. Brodie
1 sibling, 1 reply; 35+ messages in thread
From: Grant Grundler @ 2003-11-16 1:51 UTC (permalink / raw)
To: buggz; +Cc: parisc-linux
On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.
EISA DMA isn't working, IIRC.
I don't recall if anyone has published Wax (EISA) DMA docs.
If not, that means someone from HP would have to write it
or get enough detail from someone inside HP to write it.
> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.
At one we had a NIC working using PIO (not DMA).
But don't expect stellar performance.
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-16 1:51 ` Grant Grundler
@ 2003-11-16 4:16 ` Shane G. Brodie
2003-11-16 4:32 ` Grant Grundler
0 siblings, 1 reply; 35+ messages in thread
From: Shane G. Brodie @ 2003-11-16 4:16 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Slightly off topic: I've been fighting with a 715/80 with an EISA 10/100 VG
AnyLan card in it for the last 2 weeks. I can not get the network to come
up. I have a whole series of issues to resolve unrelated to the network
hardware, but that's another long story ... (the old SCSI CD-ROM doesn't
like CD-RW ... don't have spare CD-R ... disc 2 of my downloaded set is
unreadable - how I wish the MD5 checksums were up-to-date ... I could set
up dial-up (eeek!) but ...
I don't have have an EtherTwist transceiver for the built-in (and don't know
if it'll work anyway) - can anyone advise me whether or not the the built-in
10-Base-2 Ethernet NIC will work using a AUI-10MB Ethernet transceiver
connected to a Linksys DSL 10/100 router? (I have a CenterCOM MX10 IEEE
802.3 MicroTransceiver 10-Base-2 - a lot of good that'll do me ...).
Regards
Shane Brodie
-----Original Message-----
From: parisc-linux-admin@lists.parisc-linux.org
[mailto:parisc-linux-admin@lists.parisc-linux.org]On Behalf Of Grant
Grundler
Sent: November 15, 2003 7:52 PM
To: buggz
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Dual NICs on 9000/715, anyone?
On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.
EISA DMA isn't working, IIRC.
I don't recall if anyone has published Wax (EISA) DMA docs.
If not, that means someone from HP would have to write it
or get enough detail from someone inside HP to write it.
> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.
At one we had a NIC working using PIO (not DMA).
But don't expect stellar performance.
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] Dual NICs on 9000/715, anyone?
2003-11-16 4:16 ` Shane G. Brodie
@ 2003-11-16 4:32 ` Grant Grundler
0 siblings, 0 replies; 35+ messages in thread
From: Grant Grundler @ 2003-11-16 4:32 UTC (permalink / raw)
To: Shane G. Brodie; +Cc: parisc-linux
On Sat, Nov 15, 2003 at 10:16:11PM -0600, Shane G. Brodie wrote:
> Slightly off topic: I've been fighting with a 715/80 with an EISA 10/100 VG
> AnyLan card in it for the last 2 weeks. I can not get the network to come
> up.
If it's trying to use DMA, it won't work.
> I have a whole series of issues to resolve unrelated to the network
> hardware, but that's another long story ... (the old SCSI CD-ROM doesn't
> like CD-RW ... don't have spare CD-R ... disc 2 of my downloaded set is
> unreadable - how I wish the MD5 checksums were up-to-date ... I could set
can you clarify which MD5 csums are stale?
Post the URL on this list and likely someone can fix it.
> up dial-up (eeek!) but ...
>
> I don't have have an EtherTwist transceiver for the built-in (and don't know
> if it'll work anyway) - can anyone advise me whether or not the the built-in
> 10-Base-2 Ethernet NIC will work using a AUI-10MB Ethernet transceiver
> connected to a Linksys DSL 10/100 router?
The 715 built-in (LASI "apricot", uses lasi_82596 driver) works fine.
I wouldn't expect any compatibility problems with Linksys router.
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-15 22:56 ` M. Grabert
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
@ 2003-11-15 23:58 ` M. Grabert
2003-11-16 17:00 ` Joel Soete
2003-11-16 16:53 ` Joel Soete
2 siblings, 1 reply; 35+ messages in thread
From: M. Grabert @ 2003-11-15 23:58 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
Sorry to reply myself, but think I might need to clarify some points
(I'm a little bit tired, so I have missed some things in my previous post)
On Sat, 15 Nov 2003, M. Grabert wrote:
[...]
> > So i will continue to see how to set it up in half-duplex (would it not
> > be the default in 10BT?)
Yes, usually it defaults to 10Mbit half-duplex and then (if the cards
support it) it tries to negotiate better connections (full-duplex, 100Mbit ...)
> Actually if one end point uses Full-Duplex and the other end uses
> Half-Duplex, there should be no connection possible.
This is true if the (forced full-duplex) network card test for full-duplex
capable connection and doesn't find it. However most (cheap?) cards will
skip the test for full-duplex if it was 'forced', and you can still connect.
Light traffic will work, but you will have problems with large traffic.
The explanation:
The half-duplex side will send a packet, and assumes the other end stops
sending if a collision occurs, ie. if the other side was sending something
at the same time (CSMA/CD).
The full-duplex side will however will always send/receive as fast as it
can as it doesn't do CSMA/CD, ie. it doesn't care about collisions.
The effect is that there will be a massive amount of collisions if both
sides want to send data, and only the half-duplex card will try to resend
the packets (causing even more collisions).
You will see slow traffic when sending from half-duplex, and dropped
packets when sending from full-duplex when both cards are sending.
This will be most likely your problem, since it fits your description
perfectly (forced full-duplex mode). Sorry, I overlooked that in
my first post.
> The same for the situation when one side uses 10Mbit and the other is
> set to explicitly use 100MBit.
This will definitely never work.
> The only situation where such a decreased network performance occurs
> is IMHO that your have a cheap network equipment.
> IE. a dodgy network cable that isn't properly shielded or doesn't use all
> 8 wires,
I mean in the context for 10BaseT, ie. all 4 wires (1/2,3/6) are connected,
but not the rest. There will be noise/crosstalk that will lead to
collisions.
[...]
> In this (worst case) scenario there will be a lot of packet drop on
> the physical layer and the network cards will re-send the ethernet
> packets autmatically (usually) without notifying you. You will see
> decreased network performace as you mentioned it.
The network card (only in half-duplex) will think it detects collisions
due to noise/crosstalk and will automatically resend the packets without
notification.
Slan,
Max
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-15 23:58 ` [parisc-linux] C110 builtin nic slow? M. Grabert
@ 2003-11-16 17:00 ` Joel Soete
2003-11-21 21:44 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-16 17:00 UTC (permalink / raw)
To: M. Grabert; +Cc: parisc-linux
M. Grabert wrote:
> Sorry to reply myself,
Don't worry, I do it also frequently (tired or not i need some more time
to test more stuff or find back more info ;) )
> but think I might need to clarify some points
> (I'm a little bit tired, so I have missed some things in my previous post)
>
> On Sat, 15 Nov 2003, M. Grabert wrote:
>
> [...]
>
>
>>>So i will continue to see how to set it up in half-duplex (would it not
>>>be the default in 10BT?)
>
>
> Yes, usually it defaults to 10Mbit half-duplex and then (if the cards
> support it) it tries to negotiate better connections (full-duplex, 100Mbit ...)
>
>
>>Actually if one end point uses Full-Duplex and the other end uses
>>Half-Duplex, there should be no connection possible.
>
>
> This is true if the (forced full-duplex) network card test for full-duplex
> capable connection and doesn't find it. However most (cheap?) cards will
> skip the test for full-duplex if it was 'forced', and you can still connect.
>
> Light traffic will work, but you will have problems with large traffic.
> The explanation:
>
> The half-duplex side will send a packet, and assumes the other end stops
> sending if a collision occurs, ie. if the other side was sending something
> at the same time (CSMA/CD).
> The full-duplex side will however will always send/receive as fast as it
> can as it doesn't do CSMA/CD, ie. it doesn't care about collisions.
>
> The effect is that there will be a massive amount of collisions if both
> sides want to send data, and only the half-duplex card will try to resend
> the packets (causing even more collisions).
> You will see slow traffic when sending from half-duplex, and dropped
> packets when sending from full-duplex when both cards are sending.
>
> This will be most likely your problem, since it fits your description
> perfectly (forced full-duplex mode). Sorry, I overlooked that in
> my first post.
>
That explain perfectly the pb I encounter; thanks :)
>
>
>
>>The same for the situation when one side uses 10Mbit and the other is
>>set to explicitly use 100MBit.
>
>
> This will definitely never work.
>
>
>>The only situation where such a decreased network performance occurs
>>is IMHO that your have a cheap network equipment.
>>IE. a dodgy network cable that isn't properly shielded or doesn't use all
>>8 wires,
>
>
> I mean in the context for 10BaseT, ie. all 4 wires (1/2,3/6) are connected,
> but not the rest. There will be noise/crosstalk that will lead to
> collisions.
>
I check: all 8 wires are connected
> [...]
>
>
>>In this (worst case) scenario there will be a lot of packet drop on
>>the physical layer and the network cards will re-send the ethernet
>>packets autmatically (usually) without notifying you. You will see
>>decreased network performace as you mentioned it.
>
>
> The network card (only in half-duplex) will think it detects collisions
> due to noise/crosstalk and will automatically resend the packets without
> notification.
>
>
> Slan,
> Max
>
>
Thanks again,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-16 17:00 ` Joel Soete
@ 2003-11-21 21:44 ` Joel Soete
2003-11-21 22:37 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-21 21:44 UTC (permalink / raw)
To: Joel Soete; +Cc: M. Grabert, parisc-linux
Hi all,
Joel Soete wrote:
>
>
> M. Grabert wrote:
>
>> Sorry to reply myself,
>
this is me now ;)
A small follow-up: I exchange my 3com with another hp nic (the same as
the first one).
The pb now, is that the new one become eth0 (and works fine) but the old
one (which would be eth1) is not any-more usable (no means to configure
to setup and configure it):
# cat /proc/pci
[...]
Bus 0, device 11, function 0:
Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI
LAN Ada
ter (rev 0).
IRQ 9.
Master Capable. Latency=64. Min Gnt=8.Max Lat=32.
I/O at 0xe000 [0xe0ff].
Non-prefetchable 32 bit memory at 0xeb000000 [0xeb001fff].
Bus 0, device 12, function 0:
Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI
LAN Ada
ter (#2) (rev 0).
IRQ 10.
Master Capable. Latency=64. Min Gnt=8.Max Lat=32.
I/O at 0xe400 [0xe4ff].
Non-prefetchable 32 bit memory at 0xeb002000 [0xeb003fff].
[...]
Any idea?
Thanks again,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-11-21 21:44 ` Joel Soete
@ 2003-11-21 22:37 ` Joel Soete
0 siblings, 0 replies; 35+ messages in thread
From: Joel Soete @ 2003-11-21 22:37 UTC (permalink / raw)
To: Joel Soete; +Cc: M. Grabert, parisc-linux
Hi all,
Joel Soete wrote:
> Hi all,
>
>
> Joel Soete wrote:
>
>>
>>
>> M. Grabert wrote:
>>
>>> Sorry to reply myself,
>>
>>
> this is me now ;)
Again, apologies
>
> A small follow-up: I exchange my 3com with another hp nic (the same as
> the first one).
>
> The pb now, is that the new one become eth0 (and works fine) but the old
> one (which would be eth1) is not any-more usable (no means to configure
> to setup and configure it):
> # cat /proc/pci
> [...]
> Bus 0, device 11, function 0:
> Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI
> LAN Ada
> ter (rev 0).
> IRQ 9.
> Master Capable. Latency=64. Min Gnt=8.Max Lat=32.
> I/O at 0xe000 [0xe0ff].
> Non-prefetchable 32 bit memory at 0xeb000000 [0xeb001fff].
> Bus 0, device 12, function 0:
> Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI
> LAN Ada
> ter (#2) (rev 0).
> IRQ 10.
> Master Capable. Latency=64. Min Gnt=8.Max Lat=32.
> I/O at 0xe400 [0xe4ff].
> Non-prefetchable 32 bit memory at 0xeb002000 [0xeb003fff].
> [...]
>
> Any idea?
>
I found: ether=9,0,eth0 ether=10,0,eth1 as additional bootparam.
It works but I am confused:
at the office I also have two nic (well of tulip model) on my b2k but I
never have to add any bootparam to make recognise the second card?
Is it linked with the model capability?
Thanks,
Joel
PS: ft problem seems to be solved :)
hmm this 3com works perfectly with 10BT-hd at the office but connected
this time to a hub (10BT capable) :0
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-15 22:56 ` M. Grabert
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
2003-11-15 23:58 ` [parisc-linux] C110 builtin nic slow? M. Grabert
@ 2003-11-16 16:53 ` Joel Soete
2 siblings, 0 replies; 35+ messages in thread
From: Joel Soete @ 2003-11-16 16:53 UTC (permalink / raw)
To: M. Grabert; +Cc: parisc-linux
Hi Max,
M. Grabert wrote:
> On Sat, 15 Nov 2003, Joel Soete wrote:
>
>
>>Hi Grant,
>>
>>I quiet sure now that the pb come from the 2d nic of my pc.
>>
>>It is a:
>>00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
>>(rev 24)
>>
>>I with google, I find back a mail of Andrew Morton in which he mentioned
>>a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
>># ./vortex-diag -aem
>>[...]
>>Transceiver type in use: 10baseT.
>> MAC settings: full-duplex.
>> ^^^^^^^^^^^^
>> Station address set to 00:10:4b:63:2e:bf.
>> Configuration options 000a.
>>Saved EEPROM settings of a 3Com Vortex/Boomerang:
>> 3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
>> OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
>> Device ID 9055, Manufacturer ID 6d50.
>> Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
>> No BIOS ROM is present.
>> Transceiver selection: 10baseT.
>> Options: force full duplex, link beat required.
>> ^^^^^^^^^^^^^^^^^
>> PCI Subsystem IDs: Vendor 10b7 Device 9055.
>>[...]
>>
>>So i will continue to see how to set it up in half-duplex (would it not
>>be the default in 10BT?)
>
>
> How is it connected?
> Is it connected to a Switch (with Full-Duplex support, not a regular Hub)?
> Or is it connected to another PC via a Cross-Over cable?
>
A cross-cable (of high quality).
btw I bring back my office 'thinkpad' (win2k) at home, connect it with
the same cable to c110's nic and ftp my last kernel src (about 30mb):
ftp stat showing about 800k/s; that is normal.
I use so the same cable to connect 'thinkpab' to my 3com nic and do the
same ftp: ftp hang after 600k?
> If either of them is true, then 10BaseT will auto-negotiate Full-Duplex,
> of both ends support it.
> It's usually safe with 10BaseT only cards, but it's might come to some
> little problems if some cheap 100BaseTx cards are involved (more complex
> auto-negotiation involved, some cheap cards don't do it correctly).
> Then you might have to force it to 10Mbit, 100Mbit, Full or Half-Duplex
> manually.
>
many strange things occurs with this card:
* I don't see it initialized in dmesg as the other nic (even though it
is well configure (ifconfig :) )
* mii-tool shows:
eth1: 10 Mbit, half duplex, no link
^^^^^^^
even though:
# ping hpalin
PING hpalin (172.16.248.45): 56 data bytes
64 bytes from 172.16.248.45: icmp_seq=0 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=1 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=2 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=3 ttl=64 time=0.4 ms
--- hpalin ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
or
# ping hpalin -s 3000
PING hpalin (172.16.248.45): 3000 data bytes
3008 bytes from 172.16.248.45: icmp_seq=0 ttl=64 time=5.7 ms
3008 bytes from 172.16.248.45: icmp_seq=1 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=2 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=3 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=4 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=5 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=6 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=7 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=8 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=9 ttl=64 time=5.6 ms
--- hpalin ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
* above mentioned tools (vortex-diag) also mentioned:
[...]
Basic mode status register 0x3000 ... 3000.
Link status: not established.
Capable of 100baseTx 10baseT-FD.
Unable to perform Auto-negotiation, negotiation not complete.
This transceiver has no vendor identification.
I'm advertising 3000:
Advertising no additional info pages.
Using an unknown (non 802.3) encapsulation.
Link partner capability is 3000:.
Negotiation did not complete.
I need so definitely to force 10baseT-hd but I don't yet find how (I
lost my isp connection during my last evening research :( ).
> However I don't see why the network card should be *automatically* forced
> to Full-Duplex, since 'forced' implies that is was done manually!
>
As explain above, it is not the only one incoherencies :(; a cheap bug?
(afaik it is not the standard to 'force fd' when autoneg failed?)
>
> Actually if one end point uses Full-Duplex and the other end uses
> Half-Duplex, there should be no connection possible.
By experience (recently we have to fix to 100-fd all server nic and
related switch ports to avoid such autoneg pb, only with some supplier
nic not hp :) ), I wouldn't say 'no connection' but well degraded
connection ;)
> The same for
> the situation when one side uses 10Mbit and the other is set to
> explicitly use 100MBit.
>
In this case, iirc there are well no connection possible.
> The only situation where such a decreased network performance occurs
> is IMHO that your have a cheap network equipment.
> IE. a dodgy network cable that isn't properly shielded or doesn't use all
> 8 wires, and/or cheap network cards that don't test whether the network
> connection/cable is capable of supporting Full-Duplex reliably.
>
I don't know if they were cheap but a bit old now:
[...]
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
Device ID 9055, Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
[...]
> In this (worst case) scenario there will be a lot of packet drop on
> the physical layer and the network cards will re-send the ethernet
> packets autmatically (usually) without notifying you. You will see
> decreased network performace as you mentioned it.
> Unfortunately I have seen this a couple of times in my life, especially
> in the old 10Base2/5 days with broken terminators or tranceivers, but also
> with 10BaseT, and even more so with 100Mbit and low-quality network cables.
>
> greetings, Max
>
>
> PS: oh, yes, another possible problem might be an IRQ conflict (which is
> rather unlikely on PA-RISC). It would cause also degraded network
> performance.
>
That is the first thing I check:
# cat /proc/pci
PCI devices found:
[...]
Bus 0, device 7, function 2:
USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 1).
IRQ 10.
Master Capable. Latency=64.
I/O at 0xd000 [0xd01f].
Bus 0, device 7, function 3:
Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 2).
IRQ 9.
[...]
Bus 0, device 11, function 0:
Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 36).
IRQ 9.
Master Capable. Latency=64. Min Gnt=10.Max Lat=10.
I/O at 0xe000 [0xe07f].
Non-prefetchable 32 bit memory at 0xec006000 [0xec00607f].
Bus 0, device 12, function 0:
Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI
LAN Adapter (rev 0).
IRQ 10.
Master Capable. Latency=64. Min Gnt=8.Max Lat=32.
I/O at 0xe400 [0xe4ff].
Non-prefetchable 32 bit memory at 0xec000000 [0xec001fff].
[...]
hmm well the same irq 9 for bridge:... ACPI and nic: 3Com, should it be
the source of pb?
Thanks for advise and attention,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 12:31 ` Joel Soete
2003-11-10 14:00 ` Joel Soete
@ 2003-11-10 17:37 ` Grant Grundler
2003-11-10 19:23 ` Joel Soete
2003-11-11 1:31 ` M. Grabert
1 sibling, 2 replies; 35+ messages in thread
From: Grant Grundler @ 2003-11-10 17:37 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
> ie a Lasi_82596 (as Matthew mentioned in a previous mail).
yeah - that's not going to perform as well as tulip.
And 10-Half is going to be substantially slower.
Sounds like it has a bug in the negotiation.
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 17:37 ` Grant Grundler
@ 2003-11-10 19:23 ` Joel Soete
2003-11-10 20:38 ` Joel Soete
2003-11-11 1:31 ` M. Grabert
1 sibling, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-11-10 19:23 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Grant Grundler wrote:
> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
>
>>ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>
>
> yeah - that's not going to perform as well as tulip.
> And 10-Half is going to be substantially slower.
> Sounds like it has a bug in the negotiation.
Hmm I could verify, i would have to had ethtool support.
btw is somebody knows a driver which support it (i test without succes
3com an hp100 driver).
Thx,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 19:23 ` Joel Soete
@ 2003-11-10 20:38 ` Joel Soete
0 siblings, 0 replies; 35+ messages in thread
From: Joel Soete @ 2003-11-10 20:38 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, parisc-linux
(sorry for auto-reply) but I find effectively interesting stuff:
man ethtool mentioned: /usr/share/doc/ethtool/README.Debian
in which it seems that is:
Last column show current capabilities of these drivers:
D = get driver infos
C = get/set card settings
W = get/set wake-on-lan settings
M = get/set message-level
L = get link status
R = restart autonegotiation
G = get registers
P = get EEPROM
An 'x' indicates that the feature is available, a '.' indicates not.
Ethernet card family linux driver DCWMLRGP
--------------------------------------------------------------------
[...]
NatSemi DP8381x series natsemi xxxxxxxx
[...]
which own the most of ethtool support.
Again sorry for anoyance,
Joel
Joel Soete wrote:
>
>
> Grant Grundler wrote:
>
>> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
>>
>>> ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>>
>>
>>
>> yeah - that's not going to perform as well as tulip.
>> And 10-Half is going to be substantially slower.
>> Sounds like it has a bug in the negotiation.
>
> Hmm I could verify, i would have to had ethtool support.
> btw is somebody knows a driver which support it (i test without succes
> 3com an hp100 driver).
>
> Thx,
> Joel
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-10 17:37 ` Grant Grundler
2003-11-10 19:23 ` Joel Soete
@ 2003-11-11 1:31 ` M. Grabert
2003-11-11 11:45 ` Joel Soete
1 sibling, 1 reply; 35+ messages in thread
From: M. Grabert @ 2003-11-11 1:31 UTC (permalink / raw)
To: Grant Grundler; +Cc: Joel Soete, parisc-linux
On Mon, 10 Nov 2003, Grant Grundler wrote:
> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
> > ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>
> yeah - that's not going to perform as well as tulip.
> And 10-Half is going to be substantially slower.
> Sounds like it has a bug in the negotiation.
Very likely!
My C200 is also very picky whether to enable 100MBit or not.
I'm using a no-name 100MBit-Switch, and it works fine for all
5 other PCs in my house).
I was not able to force 100MBit by changing the settings in the
PDC, but the following DID work:
> mii-tool -A 100baseTx,10baseT eth0
On my C3000 I don't have these problems.
Take a look in the mailing-list archive (about a year ago I guess and
later I found it also here: http://www.unixnerd.demon.co.uk/hp_unix.html).
Note that this is a problem with the C2x0, but I guess it might be
also true for the entire Cxxx series.
Max
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-11-11 1:31 ` M. Grabert
@ 2003-11-11 11:45 ` Joel Soete
0 siblings, 0 replies; 35+ messages in thread
From: Joel Soete @ 2003-11-11 11:45 UTC (permalink / raw)
To: M. Grabert; +Cc: Grant Grundler, parisc-linux
Hi Max,
M. Grabert wrote:
> On Mon, 10 Nov 2003, Grant Grundler wrote:
>
>
>>On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
>>
>>>ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>>
>>yeah - that's not going to perform as well as tulip.
>>And 10-Half is going to be substantially slower.
>>Sounds like it has a bug in the negotiation.
>
>
> Very likely!
>
> My C200 is also very picky whether to enable 100MBit or not.
> I'm using a no-name 100MBit-Switch, and it works fine for all
> 5 other PCs in my house).
>
> I was not able to force 100MBit by changing the settings in the
> PDC, but the following DID work:
>
>
>>mii-tool -A 100baseTx,10baseT eth0
>
Ah interesting:
on my pc,
# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
eth1: 10 Mbit, half duplex, no link
and eth1 is the nic I use to connect my c110 :) (don't see what no link
means but that is the right setup that I need with c110)
otc on the c110:
# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
no MII interfaces found
:(
Thx a lot,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* [parisc-linux] C110 builtin nic slow?
@ 2003-10-26 16:49 Joel Soete
2003-10-26 17:25 ` Grant Grundler
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-10-26 16:49 UTC (permalink / raw)
To: parisc-linux
Hi all,
Here are the devices found on my c110 box:
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0x7, 0xb
2. SkyHawk 100/120 FW-SCSI (4) at 0xf3f8c000 [8/12], versions 0x1f, 0x0,
0x89
3. Raven T' Core BA (11) at 0xffd00000 [8/16], versions 0x32, 0x0, 0x81,
additional addresses: 0xffd0c000 0xffc00000
4. Raven T' Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x32,
0x0, 0x74, additional addresses: 0xffd01000 0xffd03000
5. Raven T' Audio (10) at 0xffd04000 [8/16/1], versions 0x32, 0x0, 0x7b
6. Raven T' Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x32,
0x0, 0x8c
7. Raven T' Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x32, 0x0, 0x82
8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,
0x0, 0x8a
9. Raven T' Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x32,
0x0, 0x84
10. Raven T' Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x32,
0x0, 0x84
11. Raven T' Core PC Floppy (10) at 0xffd0a000 [8/16/10], versions 0x32,
0x0, 0x83
12. Raven T' Wax BA (11) at 0xffe00000 [8/20], versions 0x1e, 0x0, 0x8e,
additional addresses: 0xffe03000 0xffe06000
13. Raven T' Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x1e, 0x0, 0x73
14. Raven T' Wax RS-232 (10) at 0xffe02000 [8/20/2], versions 0x1e, 0x0,
0x8c
15. Raven T' Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x1e,
0x0, 0x90, additional addresses: 0xffc88400 0xf4000000
16. U2-IOA BC GSC+ Port (7) at 0xf3fbf000 [8/63], versions 0x501, 0x1,
0xc, additional addresses: 0xf3f80000
17. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0x7, 0xb
18. Raven T' GSC Core Graphics (10) at 0xf4000000 [10/16], versions
0x32, 0x0, 0x85, additional addresses: 0xf0069000
19. U2-IOA BC GSC+ Port (7) at 0xf3fff000 [10/63], versions 0x501, 0x1, 0xc
20. Raven 120 T' (0) at 0xfffa0000 [32], versions 0x58e, 0x0, 0x4
21. Memory (1) at 0xfffb1000 [49], versions 0x49, 0x0, 0x9
CPU(s): 1 x PA7200 (PCX-T') at 120.000000 MHz
And, at the office, I use to obtain around nice 1Mb/s when I do such
rsync or ftp between my b180 connected via a hub.
But here at home, I connect the builtin nic of my c110 with a
cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the
kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc
connected in place of the c110). Is it possible to improve the
performance of this builtin nic?
Thanks in advance,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-26 16:49 Joel Soete
@ 2003-10-26 17:25 ` Grant Grundler
2003-10-26 20:40 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Grant Grundler @ 2003-10-26 17:25 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Sun, Oct 26, 2003 at 04:49:04PM +0000, Joel Soete wrote:
> 8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,
> 0x0, 0x8a
This is a 10Mb link.
> And, at the office, I use to obtain around nice 1Mb/s when I do such
> rsync or ftp between my b180 connected via a hub.
Which protocol?
> But here at home, I connect the builtin nic of my c110 with a
> cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the
> kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc
> connected in place of the c110). Is it possible to improve the
> performance of this builtin nic?
Earlier this year I exchanged email with someone on linux-ia64 list with
a similar sounding problem. They were trying to NFS mount some exported
by the ia64-linux server but perf was ~80KB/s vs 50MB/s (1000BT) across
the same link to another ia64-linux box. We never found the root cause
since netperf demonstrated the UDP throughput was > 50MB/s (expected)
in the same config. I could only guess it was something in the NFS
stack having to do with 16K pages.
But thinking about this more, I'm wondering if some kernel code is
accessing misaligned data someplace in the networking stack.
The arguments I've heard is this is expected behavior.
Joel,
1) Can you verify dmesg has no misaligned data access reports?
2) Can you clarify how you are measuring performance?
(ie which protocols and which tools?)
3) Can you setup/run netperf or httperf with the PC to verify whatever
protocol you are using basically works?
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-26 17:25 ` Grant Grundler
@ 2003-10-26 20:40 ` Joel Soete
2003-10-26 21:10 ` Joel Soete
2003-11-10 4:36 ` Grant Grundler
0 siblings, 2 replies; 35+ messages in thread
From: Joel Soete @ 2003-10-26 20:40 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux
Hi Grant,
Grant Grundler wrote:
> On Sun, Oct 26, 2003 at 04:49:04PM +0000, Joel Soete wrote:
>
>>8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,
>>0x0, 0x8a
>
>
> This is a 10Mb link.
>
Yes ;)
>
>>And, at the office, I use to obtain around nice 1Mb/s when I do such
>>rsync or ftp between my b180 connected via a hub.
>
>
> Which protocol?
>
ftp (ncftp), rsync, scp
>
>>But here at home, I connect the builtin nic of my c110 with a
>>cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the
>>kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc
>>connected in place of the c110). Is it possible to improve the
>>performance of this builtin nic?
>
>
> Earlier this year I exchanged email with someone on linux-ia64 list with
> a similar sounding problem. They were trying to NFS mount some exported
> by the ia64-linux server but perf was ~80KB/s vs 50MB/s (1000BT) across
> the same link to another ia64-linux box. We never found the root cause
> since netperf demonstrated the UDP throughput was > 50MB/s (expected)
> in the same config. I could only guess it was something in the NFS
> stack having to do with 16K pages.
>
Well all kernel tested since now (2.4 or 2.6) were well configured to
support NFS (even if exports file is empty). I can try to remove this
support?
> But thinking about this more, I'm wondering if some kernel code is
> accessing misaligned data someplace in the networking stack.
> The arguments I've heard is this is expected behavior.
>
> Joel,
> 1) Can you verify dmesg has no misaligned data access reports?
Unfortunately no such a messages :(
> 2) Can you clarify how you are measuring performance?
> (ie which protocols and which tools?)
what ever the protocol I use (ftp, rsync, scp) they report their own
stat which are very low and correspond to the results of gkrellm (iptraf
seems to lock the trafic).
hm another strange thing: I just compressed the my last kernel 2.4
sources (about 30Mb) and on my pc I get it with scp from the c110: scp
and gkrellm showing a rate of about 150Kb/s. Then remove the file on the
c110 and on this i grab the same file with scp (also) and this time scp
amd gkrellm showing togehter a rate a about 50Kb/s. That is get now put
show same results (i mean on pc put to c110: rate about 50Kb/s; on c110
put to pc: rate about 150Kb/s).
That say. I also try to re-do the same test with ncftp which seems to
show the same results excepted that 'put' from c110 to pc 'stail' after
only one hundred Kb (and I installed the same ftp server on each ie:
ii ftpd 0.17-16 FTP server
ii tftpd 0.17-10 Internet trivial file transfer
protocol serv).
> 3) Can you setup/run netperf or httperf with the PC to verify whatever
> protocol you are using basically works?
I try to install the non-free (?) dpkg on my pc but:
sid:/home/jso/work # netperf -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST to localhost
udp_send: data send error: Message too long
sid:/home/jso/work # netperf -t UDP_STREAM -f m
UDP UNIDIRECTIONAL SEND TEST to localhost
udp_send: data send error: Message too long
sid:/home/jso/work # netperf -t TCP_RR
TCP REQUEST/RESPONSE TEST to localhost
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 9.99 15980.06
16384 87380
sid:/home/jso/work # netperf -t UDP_RR
UDP REQUEST/RESPONSE TEST to localhost
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 10.00 27145.26
65535 65535
hmm may be should I try to rebuild the very last src (from hp).
More over the pkg is not available for parisc but I trust it would just
be rebuild for this platform?
(i just haven't enough time to do it right now, sorry)
The few I can let iptraf running it didn't show's me any udp trafic :(
Statistics for eth1
Total: 5350 4077724 2411 459794 2939 3617930
IP: 5350 4002824 2411 426040 2939 3576784
TCP: 5350 4002824 2411 426040 2939 3576784
UDP: 0 0 0 0 0 0
ICMP: 0 0 0 0 0 0
Other IP: 0 0 0 0 0 0
Non-IP: 0 0 0 0 0 0
Thanks for help,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-26 20:40 ` Joel Soete
@ 2003-10-26 21:10 ` Joel Soete
2003-10-27 19:39 ` Grant Grundler
2003-11-10 4:36 ` Grant Grundler
1 sibling, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-10-26 21:10 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, parisc-linux
Hi Grant,
Sorry to answer to my mail but
> That say. I also try to re-do the same test with ncftp which seems to
> show the same results excepted that 'put' from c110 to pc 'stail' after
> only one hundred Kb (and I installed the same ftp server on each ie:
> ii ftpd 0.17-16 FTP server
> ii tftpd 0.17-10 Internet trivial file transfer
> protocol serv).
>
How may I find and reset the speed setup of a nic (I mean which 10 or
100 Mb, half or full duplex)?
In a second though I just remember that the pc boot first (i need
minicom console to boot c110) then latter the c110. So it could be that
the first one is set in 100 half as default (no connection at boot time)
and the second 10 half?
Thanks,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-26 21:10 ` Joel Soete
@ 2003-10-27 19:39 ` Grant Grundler
2003-10-27 20:13 ` Matthew Wilcox
2003-10-28 8:39 ` Joel Soete
0 siblings, 2 replies; 35+ messages in thread
From: Grant Grundler @ 2003-10-27 19:39 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
> How may I find and reset the speed setup of a nic (I mean which 10 or
> 100 Mb, half or full duplex)?
ethtool?
> In a second though I just remember that the pc boot first (i need
> minicom console to boot c110) then latter the c110. So it could be that
> the first one is set in 100 half as default (no connection at boot time)
> and the second 10 half?
shouldn't matter unless auto-negotiation is broken for one driver or
the other. If they are point-to-point, I expect the negotiation
to take place when the link is brought up with the second NIC.
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-27 19:39 ` Grant Grundler
@ 2003-10-27 20:13 ` Matthew Wilcox
2003-10-28 8:39 ` Joel Soete
1 sibling, 0 replies; 35+ messages in thread
From: Matthew Wilcox @ 2003-10-27 20:13 UTC (permalink / raw)
To: Grant Grundler; +Cc: Joel Soete, parisc-linux
On Mon, Oct 27, 2003 at 12:39:11PM -0700, Grant Grundler wrote:
> On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
> > How may I find and reset the speed setup of a nic (I mean which 10 or
> > 100 Mb, half or full duplex)?
>
> ethtool?
I know the lasi_82596 driver doesn't support ethtool yet.
Someone who was interested and had time & the right machine could do some
serious work on lasi_82596:
- Get rid of "static struct net_device *netdevs[MAX_DRIVERS];"
- Make it work on peecees and 680x0 too and then get rid of the original
82596 driver.
- Add ethtool support.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-27 19:39 ` Grant Grundler
2003-10-27 20:13 ` Matthew Wilcox
@ 2003-10-28 8:39 ` Joel Soete
2003-10-28 19:32 ` Joel Soete
1 sibling, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-10-28 8:39 UTC (permalink / raw)
To: Grant Grundler, Matthew Wilcox; +Cc: parisc-linux
Grant, Matthew,
>>
>>On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
>> How may I find and reset the speed setup of a nic (I mean which 10 or
>> 100 Mb, half or full duplex)?
>
>ethtool?
>
I will check on my own pc (hp cards but don't remember the model)
hmm I test here with a 3C905B (on an hp vectra) but:
# ethtool eth0
Settings for eth0:
No data available
???
(same results on a b180 with eth0: Digital DS21143 Tulip rev 65 [last kernel
2.4.21])
>> In a second though I just remember that the pc boot first (i need
>> minicom console to boot c110) then latter the c110. So it could be that
>> the first one is set in 100 half as default (no connection at boot time)
>> and the second 10 half?
>
>shouldn't matter unless auto-negotiation is broken for one driver or
>the other. If they are point-to-point,
It is a cross-cable
> I expect the negotiation to take place when the link is brought up with
>the second NIC.
I am curious to see if ethtool works for my pc's nic to check the behaviour
on this side.
Thanks for all info,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [parisc-linux] C110 builtin nic slow?
2003-10-28 8:39 ` Joel Soete
@ 2003-10-28 19:32 ` Joel Soete
2003-10-28 19:34 ` Matthew Wilcox
0 siblings, 1 reply; 35+ messages in thread
From: Joel Soete @ 2003-10-28 19:32 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, Matthew Wilcox, parisc-linux
Hi all,
Sorry for this auto-answer but don't see how better follow-up without
breacking thread?
Joel Soete wrote:
> Grant, Matthew,
>
>
> I will check on my own pc (hp cards but don't remember the model)
>
> hmm I test here with a 3C905B (on an hp vectra) but:
> # ethtool eth0
> Settings for eth0:
> No data available
>
> ???
>
> (same results on a b180 with eth0: Digital DS21143 Tulip rev 65 [last kernel
> 2.4.21])
>
And unfortunately no better results:
[...]
hp100: eth0: Busmaster mode enabled.
hp100: eth0: HP J2585B at 0xe400, IRQ 10, PCI bus, 32k SRAM (rx/tx 75%).
hp100: eth0: Adapter is attached to 10Mb/s network.
[...]
hmm I don't find the second nic in may dmesg (I just know that is also
an hp but a bit older)?
Anyway:
# ethtool eth1
Settings for eth1:
No data available
# ethtool eth0
Settings for eth0:
No data available
Any idea (may be switching the two interfaces: I mean just change
interfaces)?
Thanks again for your attention,
Joel
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-28 19:32 ` Joel Soete
@ 2003-10-28 19:34 ` Matthew Wilcox
2003-10-29 6:43 ` Joel Soete
0 siblings, 1 reply; 35+ messages in thread
From: Matthew Wilcox @ 2003-10-28 19:34 UTC (permalink / raw)
To: Joel Soete; +Cc: Grant Grundler, Matthew Wilcox, parisc-linux
On Tue, Oct 28, 2003 at 07:32:29PM +0000, Joel Soete wrote:
> Anyway:
> # ethtool eth1
> Settings for eth1:
> No data available
> # ethtool eth0
> Settings for eth0:
> No data available
>
> Any idea (may be switching the two interfaces: I mean just change
> interfaces)?
As I said, the lasi_82596 driver doesn't support ethtool.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [parisc-linux] C110 builtin nic slow?
2003-10-26 20:40 ` Joel Soete
2003-10-26 21:10 ` Joel Soete
@ 2003-11-10 4:36 ` Grant Grundler
1 sibling, 0 replies; 35+ messages in thread
From: Grant Grundler @ 2003-11-10 4:36 UTC (permalink / raw)
To: Joel Soete; +Cc: parisc-linux
On Sun, Oct 26, 2003 at 08:40:52PM +0000, Joel Soete wrote:
> hmm may be should I try to rebuild the very last src (from hp).
netperf home is netperf.org.
> More over the pkg is not available for parisc but I trust it would just
> be rebuild for this platform?
It does run/build on parisc. I've used it before.
Note that with B180, I can only get about 1MB/s throughput max.
With C3000 I get about 5 or 6 MB/s 100BT link.
Your network performance numbers are pretty far off from that
but there might be other factors involved.
I expect mem copy routines are saturating the CPU and thrashing
the data cache. The tulip driver copies the entire buffer from
where the card DMA'd to the skbuff in order to "bias" the buffer
by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
Adding "unaligned access" macros to the "common" networking code
path has been discussed and rejected (again) in the past month or so.
Linus himself has rejected such proposals in the past too.
If you twiddle the tulip driver to NOT copy all the data for
packets > 512 bytes, the kernel will tell you when/where the network
stack makes unaligned accesses. You can fix those and keep that as
a local patch. I'd be interested in hearing the netperf (or httperf)
numbers with such a patch when compared to the current behavior.
thanks,
grant
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2003-11-21 22:37 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-10 11:10 [parisc-linux] C110 builtin nic slow? Joel Soete
2003-11-10 12:31 ` Joel Soete
2003-11-10 14:00 ` Joel Soete
2003-11-10 17:35 ` Grant Grundler
2003-11-11 12:54 ` Joel Soete
2003-11-12 3:22 ` Grant Grundler
2003-11-15 19:41 ` Joel Soete
2003-11-15 22:56 ` M. Grabert
2003-11-15 23:22 ` [parisc-linux] Dual NICs on 9000/715, anyone? buggz
2003-11-15 23:34 ` Matthew Wilcox
2003-11-15 23:50 ` buggz
2003-11-16 1:51 ` Grant Grundler
2003-11-16 4:16 ` Shane G. Brodie
2003-11-16 4:32 ` Grant Grundler
2003-11-15 23:58 ` [parisc-linux] C110 builtin nic slow? M. Grabert
2003-11-16 17:00 ` Joel Soete
2003-11-21 21:44 ` Joel Soete
2003-11-21 22:37 ` Joel Soete
2003-11-16 16:53 ` Joel Soete
2003-11-10 17:37 ` Grant Grundler
2003-11-10 19:23 ` Joel Soete
2003-11-10 20:38 ` Joel Soete
2003-11-11 1:31 ` M. Grabert
2003-11-11 11:45 ` Joel Soete
-- strict thread matches above, loose matches on Subject: below --
2003-10-26 16:49 Joel Soete
2003-10-26 17:25 ` Grant Grundler
2003-10-26 20:40 ` Joel Soete
2003-10-26 21:10 ` Joel Soete
2003-10-27 19:39 ` Grant Grundler
2003-10-27 20:13 ` Matthew Wilcox
2003-10-28 8:39 ` Joel Soete
2003-10-28 19:32 ` Joel Soete
2003-10-28 19:34 ` Matthew Wilcox
2003-10-29 6:43 ` Joel Soete
2003-11-10 4:36 ` Grant Grundler
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.