From: David Acker <dacker@roinet.com>
To: "Kok, Auke" <auke-jan.h.kok@intel.com>
Cc: John Ronciak <john.ronciak@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Milton Miller <miltonm@bga.com>, Jeff Garzik <jgarzik@pobox.com>,
netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
Scott Feldman <sfeldma@pobox.com>
Subject: Re: [PATCH] Fix e100 on systems that have cache incoherent DMA
Date: Fri, 07 Sep 2007 16:41:00 -0400 [thread overview]
Message-ID: <46E1B75C.6090208@roinet.com> (raw)
In-Reply-To: <46E17CD7.8080605@intel.com>
Kok, Auke wrote:
> first impressions are not good: pings are erratic and shoot up to 3
> seconds. In an overnight stress test, the receive unit went offline and
> never came back up (TX still working).
>
> it sounds like something in the logic is suspending the ru too much, but
> I haven't had time to look deeply into the code yet.
I don't have an e100 enabled x86 box handy but I will look into getting one setup.
I just applied this patch to my PXA255 based system http://www.compulab.co.il/x255/html/x255-cm-datasheet.htm .
It is running 2.6.18.4 plus compulab patches plus some hostap patches plus the e100 patch. I get:
pings going from the embedded system to a desktop machine.
100 packets transmitted, 100 received, 0% packet loss, time 98996ms
rtt min/avg/max/mdev = 0.239/0.728/1.512/0.571 ms
Pings going the from the desktop machine to the embedded system
100 packets transmitted, 100 received, 0% packet loss, time 99217ms
rtt min/avg/max/mdev = 0.206/0.876/1.473/0.575 ms
iperf tcp from embedded to desktop gets:
[ 5] 0.0-100.0 sec 1007 MBytes 84.4 Mbits/sec
iperf udp from the embedded to the desktop gets (embedded told to send at 100mbps):
[ 5] Server Report:
[ 5] 0.0-100.0 sec 947 MBytes 79.4 Mbits/sec 0.068 ms 16/675645 (0.0024%)
[ 5] 0.0-100.0 sec 1 datagrams received out-of-order
iperf tcp from the desktop to the embedded gets:
[ 6] 0.0-100.0 sec 1.01 GBytes 86.4 Mbits/sec
iperf udp from the desktop to the embedded gets the following when the desktop sent at 100 mbps
[ 5] 0.0-100.0 sec 964 MBytes 80.8 Mbits/sec 0.359 ms 126467/813760 (16%)
[ 5] 0.0-100.0 sec 1 datagrams received out-of-order
Boot messages for my e100 are:
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
PCI: enabling device 0000:00:09.0 (0000 -> 0003)
PCI: Setting latency timer of device 0000:00:09.0 to 64
e100: eth0: e100_probe: addr 0x10131000, irq 111, MAC addr 00:09:30:FF:F2:F6
cat /sys/bus/pci/drivers/e100/0000\:00\:09.0/{device,vendor,subsystem_device,subsystem_vendor}
0x1209
0x8086
0x0000
0x0000
It's on its own interrupt line:
cm-debian:~# cat /proc/interrupts |grep eth0
111: 402428 - eth0
lspci shows:
00:09.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast Ethernet Controller (rev 09)
Let me know if there is any other information I can provide you. I will look through the code to see what could be
going on with your machine. I will also look into reproducing these results with a newer kernel. This may be tricky
since compulab's patches are pretty stale and don't always apply easily.
-Ack
next prev parent reply other threads:[~2007-09-07 20:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-31 20:54 [PATCH] Fix e100 on systems that have cache incoherent DMA David Acker
2007-09-04 17:02 ` Kok, Auke
2007-09-07 16:31 ` Kok, Auke
2007-09-07 20:41 ` David Acker [this message]
2007-09-07 21:03 ` Kok, Auke
2007-09-07 21:18 ` Kok, Auke
2007-09-07 23:24 ` Jeff Garzik
2007-09-11 20:54 ` David Acker
2007-09-12 11:30 ` James Chapman
2007-09-12 20:11 ` David Acker
-- strict thread matches above, loose matches on Subject: below --
2007-11-02 13:27 David Acker
2007-11-02 16:05 ` Kok, Auke
2007-11-02 16:11 ` Jeff Garzik
2007-11-06 17:01 ` Kok, Auke
2007-11-08 18:17 Auke Kok
2007-11-28 19:12 ` David Acker
2007-11-28 19:21 ` Kok, Auke
2007-11-28 19:26 ` Jeff Garzik
2007-11-28 19:50 ` David Acker
2008-06-18 18:54 ` Anders Grafström
2008-06-18 19:16 ` David Acker
2008-06-19 12:38 ` Anders Grafström
2008-07-01 8:26 ` Andrew Morton
2008-07-01 9:49 ` Jeff Garzik
2008-07-01 18:07 ` Andrew Morton
2008-07-02 17:36 ` Anders Grafström
2008-07-02 17:45 ` Andrew Morton
2008-07-01 21:35 ` David Acker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46E1B75C.6090208@roinet.com \
--to=dacker@roinet.com \
--cc=auke-jan.h.kok@intel.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=jgarzik@pobox.com \
--cc=john.ronciak@intel.com \
--cc=miltonm@bga.com \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.