Hi Scott,
A minor error handling bug
+ const u32 *data = of_get_property(np, phy-handle, len);
+ if (!data || len != 4)
+ return -EINVAL;
+
+ phynode = of_find_node_by_phandle(*data);
+ if (!phynode)
+ return -EINVAL;
+
+ mdionode =
On Sun, Sep 30, 2007 at 05:47:30PM +0200, Patrick McHardy wrote:
In the IPv6 case we're only changing the multicast list,
so we're never calling into __dev_set_promiscuity.
I actually even added a comment about this :)
/* Unicast addresses changes may only happen under the rtnl,
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
got it !
r3-06.test.meiosys.com login: WARNING: at
/home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
tcp_fastretrans_alert()
Call Trace:
IRQ [8040fdc3] tcp_ack+0xcd6/0x18af
[...snip...]
TCP 0
Hmm, so it's SACK
On Mon, Sep 24, 2007 at 11:44:19AM +0200, Krzysztof Oledzki wrote:
So, with DR mode, packet goes by the lo device (with bad checksum) and
then get redirected outside. Unfortunately, when it leaves host it has bad
checksum, too. :(
Did you check this by taking a tcpdump on an external host?
Signed-off-by: Dmitry Baryshkov [EMAIL PROTECTED]
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index ae98818..c70a87d 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -38,6 +38,7 @@
#include linux/times.h
#include linux/net.h
#include linux/in.h
+#include linux/igmp.h
#include
Larry McVoy [EMAIL PROTECTED] wrote:
One of my clients also has gigabit so I played around with just that
one and it (itanium running hpux w/ broadcom gigabit) can push the load
as well. One weird thing is that it is dependent on the direction the
data is flowing. If the hp is sending then
The Blackfin Ethernet MAC driver does not compile. It seems the driver is
missing some pinmux defines.
CC drivers/net/bfin_mac.o
drivers/net/bfin_mac.c: In function 'setup_pin_mux':
drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared (first use in
this function)
On Sun, 2007-30-09 at 18:59 -0700, Kok, Auke wrote:
the IDs are the only thing needed to enable all pci-e e1000 hardware.
I'll give it a whirl in the next few days. It failed as a module (with
e1000 compiled out), i will try to compile it in. I have access to the
hardware in quiet times - so it
On Mon, 2007-01-10 at 17:21 -0700, Michael Chan wrote:
Jamal, in tg3_enqueue_buggy(), we may have to call tg3_tso_bug() which
will recursively call tg3_start_xmit_dma_bug() after segmenting the TSO
packet into normal packets. We need to restore the VLAN tag so that the
GSO code will create
Hi Domen,
On Sun, Sep 02, 2007 at 09:41:43AM +0200, Domen Puncer wrote:
+ */
+static void fec_start(struct net_device *dev)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv-fec;
+ u32 rcntrl;
+ u32 tcntrl;
+ u32 tmp;
+
+ /*
This patch set try to introduce memory usage accounting for
UDP(currently ipv4 only).
This is the second post of take 2 patch, because previous
post was broken by my MUA setting.
Only what I chage is my MUA setting. There is no code
change from take 2.
This patch set is for 2.6.23-rc8.
I
This patch introduces sndbuf size check before
memory allcation for send buffer.
signed-off-by: Satoshi Oshima [EMAIL PROTECTED]
signed-off-by: Hideo Aoki [EMAIL PROTECTED]
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===
---
This patch introduces global variable for UDP memory accounting.
The unit is page.
signed-off-by: Satoshi Oshima [EMAIL PROTECTED]
signed-off-by: Hideo Aoki [EMAIL PROTECTED]
Index: 2.6.23-rc3-udp_limit/include/net/sock.h
===
---
This patch introduces memory usage measurement for UDP.
signed-off-by: Satoshi Oshima [EMAIL PROTECTED]
signed-off-by: Hideo Aoki [EMAIL PROTECTED]
Index: 2.6.23-rc8-udp_limit/net/ipv4/ip_output.c
===
---
This patch adds a protocol/address family number, ARP hardware type,
ethernet packet type, and a line discipline number for the SocketCAN
implementation.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/if.h |4 +++-
This patch adds the CAN raw protocol.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 11
net/can/Makefile|3
net/can/raw.c | 821
Hello Dave, hello Patrick,
this is the nineth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.
Since our last post we have changed the following:
* Changes suggested by Arnaldo Carvalho de Melo:
- Use gfp_any() instead of checking in_interrupt().
This patch adds documentation for the PF_CAN protocol family.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
Documentation/networking/00-INDEX |2
Documentation/networking/can.txt | 637 ++
2 files
This patch adds entries in the CREDITS and MAINTAINERS file for CAN.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
CREDITS | 16
MAINTAINERS |9 +
2 files changed, 25 insertions(+)
Index:
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
drivers/net/Makefile |1
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 13
net/can/Makefile|3
net/can/bcm.c | 1774
Em Tue, Oct 02, 2007 at 03:10:07PM +0200, Urs Thuermann escreveu:
This patch adds a protocol/address family number, ARP hardware type,
ethernet packet type, and a line discipline number for the SocketCAN
implementation.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs
On Tue, 2 Oct 2007, Herbert Xu wrote:
On Mon, Sep 24, 2007 at 11:44:19AM +0200, Krzysztof Oledzki wrote:
So, with DR mode, packet goes by the lo device (with bad checksum) and
then get redirected outside. Unfortunately, when it leaves host it has bad
checksum, too. :(
Did you check this
On Tue, Oct 02, 2007 at 04:15:15PM +0200, Krzysztof Oledzki wrote:
I'm not sure if we should call it a bug. LVS does not support such
configuration by default - it requires kernel patching. However, it worked
with older kernels so that's why I asked if it is possible to force full
TCP/UDP
Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs
Em Tue, Oct 02, 2007 at 03:10:09PM +0200, Urs Thuermann escreveu:
This patch adds the CAN raw protocol.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 11
Arnaldo Carvalho de Melo [EMAIL PROTECTED] writes:
--- net-2.6.24.orig/include/linux/if_arp.h 2007-10-02 12:10:51.0
+0200
+++ net-2.6.24/include/linux/if_arp.h 2007-10-02 12:11:01.0
+0200
@@ -52,6 +52,7 @@
#define ARPHRD_ROSE270
#define ARPHRD_X25
On 02/10/07 14:49 +0200, Sascha Hauer wrote:
Hi Domen,
Hi Sascha!
On Sun, Sep 02, 2007 at 09:41:43AM +0200, Domen Puncer wrote:
+ */
+static void fec_start(struct net_device *dev)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv-fec;
Em Tue, Oct 02, 2007 at 03:10:08PM +0200, Urs Thuermann escreveu:
This patch adds the CAN core functionality but no protocols or drivers.
No protocol implementations are included here. They come as separate
patches. Protocol numbers are already in include/linux/can.h.
Signed-off-by: Oliver
Trivial fix: Swap comments for dev_put() and dev_hold() to get them
at the right place.
Typo introduced by 4fa57c9ea9f36f9ca852f3a88ca5d2f1aebbc960.
Signed-of-by: Benjamin Thery [EMAIL PROTECTED]
---
include/linux/netdevice.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index:
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:07PM +0200, Urs Thuermann escreveu:
Index: net-2.6.24/include/linux/if_arp.h
===
--- net-2.6.24.orig/include/linux/if_arp.h 2007-10-02 12:10:51.0
+0200
Em Tue, Oct 02, 2007 at 04:27:40PM +0200, Urs Thuermann escreveu:
Arnaldo Carvalho de Melo [EMAIL PROTECTED] writes:
--- net-2.6.24.orig/include/linux/if_arp.h2007-10-02
12:10:51.0 +0200
+++ net-2.6.24/include/linux/if_arp.h 2007-10-02 12:11:01.0
+0200
On a machine running Debian testing, I get complete lockups
(Num lock LED not responding anymore)
when I try to use the network in the following configuration:
eth0: Marvell 8056 Gigabit LAN Controller, sky2 driver;
the driver reports: Yukon EC Ultra (0xb4) rev 2
eth1: Compex ReadyLink 2000
Em Tue, Oct 02, 2007 at 04:42:24PM +0200, Oliver Hartkopp escreveu:
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:07PM +0200, Urs Thuermann escreveu:
Index: net-2.6.24/include/linux/if_arp.h
===
---
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:09PM +0200, Urs Thuermann escreveu:
+
+ if (ro-bound ro-ifindex)
+ dev = dev_get_by_index(init_net, ro-ifindex);
dev_get_by_index can fail, are you sure that raw_enable_filters can cope
Larry McVoy wrote:
A short summary is can someone please post a test program that sources
and sinks data at the wire speed? because apparently I'm too old and
clueless to write such a thing.
Here's a simple reference tcp source/sink that's I've used for years.
For example, on a couple
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
+
+/* To be moved to linux/can/dev.h */
Is this comment still valid? If so can this move happen now? If not I
think it would be better to stick a FIXME: just before it, no?
On Tue, Oct 02, 2007 at 06:52:54PM +0800, Herbert Xu wrote:
One of my clients also has gigabit so I played around with just that
one and it (itanium running hpux w/ broadcom gigabit) can push the load
as well. One weird thing is that it is dependent on the direction the
data is flowing.
From: Hans-Jürgen Koch [EMAIL PROTECTED]
Compiling macb.c fails because the type of parameter 2 of macb_poll()
was changed from int* to int. Furthermore, a local variable was removed
but was still used inside the function. This patch fixes it.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
On Tue, 2 Oct 2007, Herbert Xu wrote:
On Sun, Sep 30, 2007 at 05:47:30PM +0200, Patrick McHardy wrote:
I'm a bit uncomfortable with having a function (change_flags)
that's sometimes in a sleepable context and sometimes running
with BH disabled.
So how about splitting up the
Dmitry,
Good catch; a couple comments:
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr-s6_addr32[3];
+ struct ip_mreqn mreq;
+
On Tue 2 Oct 2007 07:30, Kalle Pokki pondered:
The Blackfin Ethernet MAC driver does not compile. It seems the driver is
missing some pinmux defines.
CC drivers/net/bfin_mac.o
drivers/net/bfin_mac.c: In function 'setup_pin_mux':
drivers/net/bfin_mac.c:275: error: 'P_MII0' undeclared
Interesting data point. My test case is like this:
server
bind
listen
while (newsock = accept...)
transfer()
client
connect
transfer
If the server side is the source of the data, i.e, it's transfer is a
write loop, then I get the bad
On Tue, Oct 02, 2007 at 04:32:02PM +0200, Domen Puncer wrote:
The patch looks ok to me.
Short update: even with the patch, the driver doesn't work on an
rt-preempt enabled kernel, or at least not reliable. It survives normal
traffic and ping -f, but dies when running nmap against the box, with a
Jay Vosburgh wrote:
ACK patches 3 - 9.
Roland, are you comfortable with the IB changes in patches 1 and 2?
Jeff, when Roland acks patches 1 and 2, please apply all 9.
-J
Hi Jeff,
Roland acked the IPoIB patches. If you haven't done so already can you please
apply them?
If the server side is the source of the data, i.e, it's transfer is a
write loop, then I get the bad behaviour.
...
So is this a bug or intentional?
For whatever it is worth, I believed that we used to get better performance
from the same hardware. My guess is that it changed somewhere
On Tue, 2 Oct 2007, Larry McVoy wrote:
Interesting data point. My test case is like this:
server
bind
listen
while (newsock = accept...)
transfer()
client
connect
transfer
If the server side is the source of the data, i.e, it's
Em Tue, Oct 02, 2007 at 05:07:40PM +0200, Oliver Hartkopp escreveu:
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
+
+/* To be moved to linux/can/dev.h */
Is this comment still valid? If so can this move happen now? If not I
think
On Tue, 2 Oct 2007 09:25:34 -0700
[EMAIL PROTECTED] (Larry McVoy) wrote:
If the server side is the source of the data, i.e, it's transfer is a
write loop, then I get the bad behaviour.
...
So is this a bug or intentional?
For whatever it is worth, I believed that we used to get
Isn't this something so straightforward that you would have tests for it?
This is the basic FTP server loop, doesn't someone have a big machine with
10gig cards and test that sending/recving data doesn't regress?
Sounds like a bug to me, modulo the above caveat of making sure that it's
not
On Tue, Oct 02, 2007 at 09:47:26AM -0700, Stephen Hemminger wrote:
On Tue, 2 Oct 2007 09:25:34 -0700
[EMAIL PROTECTED] (Larry McVoy) wrote:
If the server side is the source of the data, i.e, it's transfer is a
write loop, then I get the bad behaviour.
...
So is this a bug or
Larry McVoy wrote:
Interesting data point. My test case is like this:
server
bind
listen
while (newsock = accept...)
transfer()
client
connect
transfer
If the server side is the source of the data, i.e, it's transfer is a
write loop,
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c921ec3..40019aa 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -44,7 +44,8 @@
printk( Assertion failed! %s,%s,%s,line=%d\n, \
Moni Shoua wrote:
Jay Vosburgh wrote:
ACK patches 3 - 9.
Roland, are you comfortable with the IB changes in patches 1 and 2?
Jeff, when Roland acks patches 1 and 2, please apply all 9.
-J
Hi Jeff,
Roland acked the IPoIB patches. If you haven't done so already can
Ron Mercer wrote:
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 69da95b..c3fe1c7 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@
Dale Farnsworth wrote:
From: Dale Farnsworth [EMAIL PROTECTED]
This driver erroneously zeros dev-tx_queue_len, since
mp-tx_ring_size has not yet been initialized. Actually,
the driver shouldn't modify tx_queue_len at all and should
leave the value set by alloc_etherdev(), currently 1000.
Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c921ec3..40019aa 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -44,7 +44,8 @@
printk( Assertion failed! %s,%s,%s,line=%d\n, \
Peter Korsgaard wrote:
Please apply to 2.6.23.
---
dm9601 didn't take the ethernet header into account when calculating
RX MTU, causing packets bigger than 1486 to fail.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/usb/dm9601.c |2 +-
1 file changed, 1 insertion(+), 1
Folks,
I posted this query to LKML last week but have had no response, but I've
since found that Ilya Pashkovsky raised the same issue - and supplied
what appears to be a good patch for it - here back in 2004:
http://marc.info/?l=linux-netdevm=110312719803402w=2
Ilya's patch didn't get
jamal wrote:
On Sun, 2007-30-09 at 18:59 -0700, Kok, Auke wrote:
the IDs are the only thing needed to enable all pci-e e1000 hardware.
I'll give it a whirl in the next few days. It failed as a module (with
e1000 compiled out), i will try to compile it in. I have access to the
hardware in
I have a more complex configuration application, but I don't see this
problem in my testing. Using e1000 nics and modern hardware
I'm using a similar setup, what kernel are you using?
I am purposefully setting the socket send/rx buffers, as well has
twiddling with the tcp and netdev
On Tue, 2 Oct 2007 09:49:52 -0700
[EMAIL PROTECTED] (Larry McVoy) wrote:
On Tue, Oct 02, 2007 at 09:47:26AM -0700, Stephen Hemminger wrote:
On Tue, 2 Oct 2007 09:25:34 -0700
[EMAIL PROTECTED] (Larry McVoy) wrote:
If the server side is the source of the data, i.e, it's transfer is a
The existing OF glue code was crufty and broken. Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.
The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
Larry McVoy wrote:
A short summary is can someone please post a test program that sources
and sinks data at the wire speed? because apparently I'm too old and
clueless to write such a thing.
http://www.netperf.org/svn/netperf2/trunk/
:)
WRT the different speeds in each direction talking
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/mv643xx_eth.c |1 -
drivers/net/qla3xxx.c |7 +++
drivers/net/usb/dm9601.c |2 +-
3 files changed, 8
Larry McVoy wrote:
I have a more complex configuration application, but I don't see this
problem in my testing. Using e1000 nics and modern hardware
I'm using a similar setup, what kernel are you using?
I'm currently on 2.6.20, and have also tried 10gbe nics on 2.6.23 with
good
On Tue, Oct 02, 2007 at 10:14:11AM -0700, Rick Jones wrote:
Larry McVoy wrote:
A short summary is can someone please post a test program that sources
and sinks data at the wire speed? because apparently I'm too old and
clueless to write such a thing.
WRT the different speeds in each
On Tue, 2007-10-02 at 12:57 -0400, Jeff Garzik wrote:
\ @@ -1924,7 +1925,7 @@ static void rtl_hw_start_8169(struct net_device *dev)
if ((tp-mac_version == RTL_GIGA_MAC_VER_02) ||
(tp-mac_version == RTL_GIGA_MAC_VER_03)) {
- dprintk(KERN_INFO PFX Set MAC Reg C+CR
I'm currently on 2.6.20, and have also tried 10gbe nics on 2.6.23 with
My guess is that it is a bug in the debian 2.6.18 kernel.
Have you tried something like ttcp, iperf, or even regular ftp?
Yeah, I've factored out the code since BitKeeper, my test program,
and John's test program all
Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
This patch series applies to the net-2.6.24 branch.
drivers/net/fs_enet/fs_enet-main.c | 85 ---
drivers/net/fs_enet/fs_enet.h |4 +-
drivers/net/fs_enet/mac-fcc.c |1 -
Jan-Bernd Themann wrote:
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
applied
-
To
Haavard Skinnemoen wrote:
From: Hans-Jürgen Koch [EMAIL PROTECTED]
Compiling macb.c fails because the type of parameter 2 of macb_poll()
was changed from int* to int. Furthermore, a local variable was removed
but was still used inside the function. This patch fixes it.
Signed-off-by: Hans J.
Markus Brunner wrote:
Hi,
this are the changes to the smc911x driver, which were necessary
to get it running on the Magic Panel R2 (smsc9115).
It is a SH3-DSP based board. The other patches are available on
the linuxsh-dev mailinglist.
http://marc.info/?l=linuxsh-devr=1b=200708w=2
It was
Nobuhiro Iwamatsu wrote:
Hi, all.
This patch supports Hitachi Solution Engine (SuperH) of smc91x.
Please apply this patch .
applied
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
jamal wrote:
Auke,
heres part of something i promised.
I couldnt do any packet testing on because 82571EB is disabled in the
driver. I uncommented the code out in the table, but the best i could
get was the module loading, some probing and some sysfs renaming
failures (probably a
On Tue, 2 Oct 2007 10:21:55 -0700
[EMAIL PROTECTED] (Larry McVoy) wrote:
I'm currently on 2.6.20, and have also tried 10gbe nics on 2.6.23 with
My guess is that it is a bug in the debian 2.6.18 kernel.
Have you tried something like ttcp, iperf, or even regular ftp?
Yeah, I've factored
has anyone already asked whether link-layer flow-control is enabled?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2 Oct 2007 08:00:47 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9112
Summary: tcpdump on a syncppp interface panics kernel
Product: Networking
Version: 2.5
KernelVersion: 2.6.22.9
Platform: All
Jeff Garzik [EMAIL PROTECTED] wrote:
Moni Shoua wrote:
Jay Vosburgh wrote:
ACK patches 3 - 9.
Roland, are you comfortable with the IB changes in patches 1 and 2?
Jeff, when Roland acks patches 1 and 2, please apply all 9.
-J
Hi Jeff,
Roland acked the IPoIB patches. If you
OK -- just to make sure I'm understanding what you're saying: have you
confirmed that your proposed [CM MRA] patches actually fix the issue?
Not directly. I cannot easily test kernel patches on our larger, production
clusters. We've seen the issue with specific applications on 512 and
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 06:52:54PM +0800, Herbert Xu wrote:
One of my clients also has gigabit so I played around with just that
one and it (itanium running hpux w/ broadcom gigabit) can push the load
as well. One weird thing is that it is dependent on the direction the
data
Make sure you don't have slab debugging turned on. It kills performance.
It's a stock debian kernel, so unless they turn it on it's off.
--
---
Larry McVoylm at bitmover.com http://www.bitkeeper.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
--
---
Larry McVoylm at
Umm... this is a difficult situation for me to merge the changes then.
We're changing the CM retry behavior blind here. How do we know that
the MRA changes don't make the scalability issue worse?
What's currently upstream doesn't work for Intel MPI on our larger clusters.
The connection requests
Looks like you have TSO enabled. Does it behave differently if it's
disabled?
It cranks the interrupts/sec up to 8K instead of 5K. No difference in
performance other than that.
I think Rick Jones is on to something with the HP ack avoidance.
I sincerely doubt it. I'm only using the
When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it. The problem is in this code in
ndisc_redirect_rcv():
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {
On Tue, 2 Oct 2007, Larry McVoy wrote:
tcpdump is a good idea, take a look at this. The window starts out
at 46 and never opens up in my test case, but in the rsh case it
starts out the same but does open up. Ideas?
I don't think that's an issue, since you only send one way. The window
On Tue, 2 Oct 2007, Larry McVoy wrote:
No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
has everything to do with the direction the data is flowing.
Can you tcpdump both cases and send snippets (both of steady-state, and
the initial connect)?
More data, we've conclusively eliminated the card / cpu from the mix.
We've got 2 ia64 boxes with e1000 interfaces. One box is running
linux 2.6.12 and the other is running hpux 11.
I made sure the linux one was running at gigabit and reran the tests
from the linux/ia64 = hp/ia64. Same results,
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
While I am often
Larry McVoy wrote:
More data, we've conclusively eliminated the card / cpu from the mix.
We've got 2 ia64 boxes with e1000 interfaces. One box is running
linux 2.6.12 and the other is running hpux 11.
I made sure the linux one was running at gigabit and reran the tests
from the linux/ia64 =
I also would have expected more ACK's from the HP box. It's been a long
time since I did TCP, but I thought the rule was still that you were
supposed to ACK at least every other full frame - but the HP box is acking
roughly every 16K (and it's *not* always at TSO boundaries: the earlier
ACK's
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index d6d9413..6acfdc4 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -444,7 +444,7 @@ static
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
I'm currently out of ideas where it could come from... so lets try
brute-force checking as your test case is not very high-speed... This
could hide it though... :-(
Please put the patch below on top of clean rc8-mm2 (it includes the patch
I gave
Ayaz Abdulla wrote:
I am trying to track down a forcedeth driver issue described by bug
9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
load). I added a patch to synchronize the timer handlers so that one
handler doesn't accidently enable the IRQ while another timer
I think I'm still missing some basic data here (probably because this
thread did not originate on netdev). Let me try to nail down some of
the basics. You have a linux ia64 box (running 2.6.12 or 2.6.18?) that
sends slowly, and receives faster, but not quite a 1 Gbps? And this is
true
I recently noticed that when calling:
# ethtool -s eth0 autoneg on
on a 5722 (though I'm sure it's not specific to that card) that
subsequent checks of the cards status looked like this:
# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 12:29:50 -0700 (PDT)
On Tue, 2 Oct 2007, Larry McVoy wrote:
No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
has everything to do with the direction the data is flowing.
Can you tcpdump both cases
From: Linus Torvalds [EMAIL PROTECTED]
Date: Tue, 2 Oct 2007 12:27:53 -0700 (PDT)
We see a single packet containing 16060 bytes, which seems to be because
of TSO on the sending side (you did your tcpdump on the sender, no?), so
it will actually be broken up into 11 1460-byte regular frames
Brian,
ipv6_addr_type() returns a mask, so checking for equality will
fail to
match if any other (irrelevant) attributes are set. How about using
bitwise
operators for that? Also, the error message is no longer descriptive of
the
failure if it's a link-local multicast, but you could
1 - 100 of 177 matches
Mail list logo
