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 r
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:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> I w
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 ho
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
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,17 @@ int i
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
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)
drivers/net/bfin_mac.c:27
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 creat
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 appre
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
===
--- 2.6.23-rc8-udp_limit.or
On Tue, 2007-02-10 at 00:25 -0400, Bill Fink wrote:
> One reason I ask, is that on an earlier set of alternative batching
> xmit patches by Krishna Kumar, his performance testing showed a 30 %
> performance hit for TCP for a single process and a size of 4 KB, and
> a performance hit of 5 % for a s
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 file
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: net-2.6.24/CRE
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
drivers
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:
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 by
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/
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
> net
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
> > #def
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 =
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: Ol
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.
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
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 gigab
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?
Bring
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 flo
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]>
Si
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 unicast/multicast
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;
> + mreq.imr_multiad
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' undecl
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 beha
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
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:08PM +0200, Urs Thuermann escreveu:
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family: address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr:transport
> 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,
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
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
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 so
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 thi
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, th
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", \
#expr,__FILE__
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 you
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.
S
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-netdev&m=110312719803402&w=2
Ilya's patch didn't get acce
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
> hardw
> 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 transf
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
existin
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 wi
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 res
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 e
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
> 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 exhi
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 -
drive
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 unsubscr
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-dev&r=1&b=200708&w=2
It was n
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 http://vger.kernel.or
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Hi,
Jeff> applied. in the future, please note (and avoid) a patch formatting
Jeff> error. As noted in #14 of Documentation/SubmittingPatches, any
Jeff> comments on the patch like "Please apply to 2.6.23" should go AFTER
Jeff> the patch
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 de
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
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:
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 ac
> >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 5
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 b
>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 reques
> 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 wind
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 <=> h
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 i
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 @@ stati
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 g
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 handle
> 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
> t
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: 10baseT/H
1 - 100 of 182 matches
Mail list logo
