On 6/7/07, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
[...]
Miles, could you try if this patch helps?
Björn
Stop destroying devices when all of their ifas are gone, as we no longer
recreate them when ifas are added.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
--
diff --git a/net/ipv4
Please don't drop CCs.
Qi, Yanling <[EMAIL PROTECTED]> wrote:
>
>> Qi, Yanling <[EMAIL PROTECTED]> wrote:
>> > @@ -2571,6 +2572,13 @@ sg_page_malloc(int rqSz, int lowDma, int
>> >resp = (char *) __get_free_pages(page_mask, order);
>> > /* try half */
>> >resSz = a_s
Baruch Even <[EMAIL PROTECTED]> wrote:
>
> I have a machine on which I have an applications that sends multicast
> through eth interface with hardware tx checksum enabled. On the same
> machine I have mrouted running that routes the multicast traffic to a
> set of ppp interfaces. The packets th
> If the QDISC_RUNNING flag guarantees that only one CPU can call
> dev->hard_start_xmit(), then why do we need to hold netif_tx_lock
> for non-LLTX drivers?
I thought the correct use is to get this lock on clean_tx side which
can get called on a different cpu on rx (which also cleans up slots
for
Hi Evgeniy,
> Let me clarify: there are two possibilities to send data:
> 1. via batched sending, which runs via queue of packets and performs
> prepare call (which only setups some private flags, no work with
> hardware) and then sending call.
> 2. old xmit function (which seems to be unused by k
Hi Jamal,
> Would be nice to run three sets - but i think even one would be
> sufficiently revealing.
I will try multiple runs over the weekend. During the week, the systems
are used for other purposes too.
> I expect UDP to overwhelm the receiver. So the receiver needs a lot more
> tuning (like
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 10:08:29 +0200
> There are races involving the garbage collector, that can throw away
> perfectly good packets with AF_UNIX sockets in them.
>
> The problems arise when a socket goes from installed to in-flight or
> vice versa during
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 7 Jun 2007 21:18:26 -0400 (EDT)
> On Thu, 7 Jun 2007, Paul Moore wrote:
>
> > The current NetLabel code has some redundant APIs which allow both
> > "struct socket" and "struct sock" types to be used; this may have made
> > sense at
> > some poin
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 7 Jun 2007 21:20:20 -0400 (EDT)
> On Thu, 7 Jun 2007, Paul Moore wrote:
>
> > IPv4 options are not very well aligned within the packet and the format of a
> > CIPSO option is even worse. The result is that the CIPSO engine in the
> > kernel
> >
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 8 Jun 2007 08:54:52 +1000
> On Thu, Jun 07, 2007 at 03:06:53PM -0700, Andrew Morton wrote:
> >
> > > I'm not able to bring an ethernet interface down and back up again
> > > with this if avahi-autoipd is installed on my Ubuntu boxes. I've seen
>
On Thu, 2007-07-06 at 17:31 -0700, Sridhar Samudrala wrote:
> If the QDISC_RUNNING flag guarantees that only one CPU can call
> dev->hard_start_xmit(), then why do we need to hold netif_tx_lock
> for non-LLTX drivers?
I havent stared at other drivers, but for e1000 seems to me
even if you got ri
On Thu, 7 Jun 2007, Paul Moore wrote:
> IPv4 options are not very well aligned within the packet and the format of a
> CIPSO option is even worse. The result is that the CIPSO engine in the kernel
> does a few unaligned accesses when parsing and validating incoming packets
> with
> CIPSO options
On Thu, 7 Jun 2007, Paul Moore wrote:
> The current NetLabel code has some redundant APIs which allow both
> "struct socket" and "struct sock" types to be used; this may have made sense
> at
> some point but it is wasteful now. Remove the functions that operate on
> sockets and convert the calle
On Thu, 2007-06-07 at 14:17 -0500, Linas Vepstas wrote:
> Jeff, please apply for the 2.6.23 kernel tree. The pach series
> consists of two major bugfixes, and several bits of cleanup.
>
> The major bug fixes are:
>
> 1) a rare but fatal bug involving "RX ram full" messages,
>which results
On Thu, 2007-06-07 at 16:00 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 07 Jun 2007 18:54:08 -0400
>
> > On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
> > > From: jamal <[EMAIL PROTECTED]>
> > > Date: Thu, 07 Jun 2007 17:57:25 -0400
> > >
> > > > I empathize
On Thu, 2007-07-06 at 16:00 -0700, David Miller wrote:
> That's right we fixed that the other week.
Circa 2.6.18 to be exact - Hence "In Pursuit of Herbert Xu" ;->
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 18:54:08 -0400
> On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
> > From: jamal <[EMAIL PROTECTED]>
> > Date: Thu, 07 Jun 2007 17:57:25 -0400
> >
> > > I empathize but take a closer look; seems mostly useless.
> >
> > I thought E1000
On Thu, 2007-07-06 at 15:30 -0700, Kok, Auke wrote:
> our rx interrupt/clean can trigger tx cleans, reaching the same code...
I see that - What i am saying is tx_lock never protects that.
Am i mistaken? i.e
CPU0 entering tx and and CPU1 entering rx interupt/clean can not be
blocked from each othe
> > I empathize but take a closer look; seems mostly useless.
>
> I thought E1000 still uses LLTX, and if so then multiple cpus
> can most definitely get into the ->hard_start_xmit() in parallel.
Not with how the qdisc status protects it today:
include/net/pkt_sched.h:
static inline void qdisc
On Thu, Jun 07, 2007 at 03:06:53PM -0700, Andrew Morton wrote:
>
> > I'm not able to bring an ethernet interface down and back up again
> > with this if avahi-autoipd is installed on my Ubuntu boxes. I've seen
> > it on three different computers with different NIC hardware.
Sorry, it was my p
On Thu, 2007-07-06 at 15:44 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 07 Jun 2007 17:57:25 -0400
>
> > I empathize but take a closer look; seems mostly useless.
>
> I thought E1000 still uses LLTX, and if so then multiple cpus can most
> definitely get into the ->h
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 17:57:25 -0400
> I empathize but take a closer look; seems mostly useless.
I thought E1000 still uses LLTX, and if so then multiple cpus can most
definitely get into the ->hard_start_xmit() in parallel.
-
To unsubscribe from this list: send t
On Wed, 2007-06-06 at 09:49 -0400, jamal wrote:
> If you help out, when you post your results, can you please say what
> hardware and setup was?
Ok, i have tested on new hardware with pktgen:
Machine: Dual Xeon processor with EMT64 - kernel is 32 bit.
Chipset: E7520 Memory Controller Hub (MCH).
Hello,
I have a machine on which I have an applications that sends multicast
through eth interface with hardware tx checksum enabled. On the same
machine I have mrouted running that routes the multicast traffic to a
set of ppp interfaces. The packets that are received by the client have
their
jamal wrote:
On Thu, 2007-07-06 at 15:06 -0700, Kok, Auke wrote:
the contention isn't between multiple tx attempts, but between e1000_clean and
tx.
I got you the first time but i think i am missing something: given that
the lock is used only on tx - how is that protecting the contention
bet
On Thu, 2007-07-06 at 15:06 -0700, Kok, Auke wrote:
> the contention isn't between multiple tx attempts, but between e1000_clean
> and
> tx.
I got you the first time but i think i am missing something: given that
the lock is used only on tx - how is that protecting the contention
between tx a
Rolf Eike Beer <[EMAIL PROTECTED]> :
[...]
> fine. Even the next try with this file didn't produce a crash. What was
> different on this tests was that I used the console instead of X (don't want
> to munch up too many file systems). Any ideas?
X and friends ?
Can you send the usual dmesg, lspc
On Thu, 2007-07-06 at 20:13 +0400, Evgeniy Polyakov wrote:
> Actually I wonder where the devil lives, but I do not see how that
> patchset can improve sending situation.
> Let me clarify: there are two possibilities to send data:
> 1. via batched sending, which runs via queue of packets and perfor
On 2007.06.07 13:15:59 -0700, Andrew Morton wrote:
> On Thu, 7 Jun 2007 11:25:30 -0700
> "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > Hi Andrew,
> >
> > This might be some problem with my kernel configuration.
> > I added:
> > CONFIG_BONDING=y
> >
> > # dhclient eth1
> > There is already a pid
On Thu, 7 Jun 2007 17:46:09 -0400
[EMAIL PROTECTED] (Joseph Fannin) wrote:
> On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
>
> I'm not able to bring an ethernet interface down and
jamal wrote:
On Thu, 2007-07-06 at 08:03 -0700, Kok, Auke wrote:
To prevent against multiple entries bumping head & tail at the same time as well
as overwriting the same entries in the tx ring (contention for
next_to_watch/next_to_clean)?
In current code that lock certainly doesnt protect th
On Thu, 2007-07-06 at 09:08 -0700, Stephen Hemminger wrote:
>
> There could be bad packet reordering with this (like some SMP routers used to
> do).
You can avoid re-ordering if you guarantee that "related" flows always
end up on the same CPU via say tc filters i.e i dont think just a 5
tuple c
On Thu, 2007-07-06 at 08:03 -0700, Kok, Auke wrote:
> To prevent against multiple entries bumping head & tail at the same time as
> well
> as overwriting the same entries in the tx ring (contention for
> next_to_watch/next_to_clean)?
In current code that lock certainly doesnt protect those sp
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 7 Jun 2007 15:18:39 +0200
> Yes, this was discovered two days ago and David reverted four commits.
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=82c5fde20031375cd93fa5a247cf15603ea1f152
>
> So it should probably b
On Thu, 7 Jun 2007 11:25:30 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> This might be some problem with my kernel configuration.
> I added:
> CONFIG_BONDING=y
>
> # dhclient eth1
> There is already a pid file /var/run/dhclient.pid with pid 134993416
> Internet Systems Consorti
Documentation for the spidernet driver.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Documentation/networking/spider_net.txt | 204
1 file changed, 204 insertions(+)
Index: linux-2.6.22-rc1/Documentation/networking/spider_net.txt
=
At some point, the transmit descriptor chain end interrupt (TXDCEINT)
was turned on. This is a mistake; and it damages small packet
transmit performance, as it results in a huge storm of interrupts.
Turn it off.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.h |
The transmit frame tail bit is stranglely misnamed as
"no checksum". Fix the name to what it should be:
"transmit frame tail". No functional change,
just a name change.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |2 +-
drivers/net/spider_net.h |2 +-
A minor optimization on the RX side is that the hardware does
not need to be kicked if space did not open up in the RX ring.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.22-r
Altough the previous patch resolved issues with hangs when the
RX ram full interrupt is encountered, there are still situations
where lots of RX ramfull interrupts arrive, rsulting in a noisy
log in syslog. There is no need for this.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers
This patch fixes a rare deadlock that can occur when the kernel
is not able to empty out the RX ring quickly enough. Below follows
a detailed description of the bug and te fix.
As long as the OS can empty out the RX buffers at a rate faster than
the hardware can fill them, there is no problem. I
The current error checking is flagging some perfectly normal, but
usually rare packets as being bad. Do not flag these packets.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
Index: linux-2.6.22-r
Another way of minimizing the likelyhood of RX ram from overflowing
is to empty out the entire rx ring every chance we get. Change
the crazy watchdog timeout from 50 seconds to 3 seconds, while
we're here.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.h |9 +++
When entering the netdev poll routine, empty out the RX
chain first, before cleaning up the TX chain. This should
help avoid RX buffer overflows.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: lin
Some versions of the spider have a firmware bug, where the
RX ring sequencer goes crazy when the RX RAM on the device
fills up. Appearently the only viable wrkaround is a soft
reset of the card.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 15 +++---
Crazy device problems are hard to debug, when one does not have
good trace info. This patch makes a major enhancement to the
device dump routine.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 78 ++-
1 file changed
Subject: [PATCH 7/18] spidernet: Don't terminate the RX ring
There is no real reason to terminate the RX ring; it
doesn't make the operation any smooother, and it does
require an extra sync. So don't do it.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 18 +
If the ethernet interface is brought down while there is still
RX traffic in flight, the device shutdown routine can end up
trying to double-free an skb, leading to a crash in mm/slab.c
Avoid the double-free by nulling out the skb pointer.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
d
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6.22-
Put the enable and disable routines next to one-another,
as this makes verifying thier symmetry that much easier.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
Index: linux
From: Stephen Hemminger <[EMAIL PROTECTED]>
It doesn't look like spidernet hardware can really checksum all protocols,
the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
instead of NETIF_F_HW_CSUM.
The driver doesn't need it's own get/set for ethtool tx csum, and it
sho
Use dev_err() to print device error messages.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 67 ---
drivers/net/spider_net.h |2 -
2 files changed, 36 insertions(+), 33 deletions(-)
Index: linux-2.6.22-rc1/dri
From: Florin Malita <[EMAIL PROTECTED]>
The stats update code in spider_net_pass_skb_up() is touching the skb
after it's been passed up to the stack. To avoid that, just update the
stats first.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
-
Jeff, please apply for the 2.6.23 kernel tree. The pach series
consists of two major bugfixes, and several bits of cleanup.
The major bug fixes are:
1) a rare but fatal bug involving "RX ram full" messages,
which results in a driver deadlock.
2) misconfigured TX interrupts, causing a seve
It doesn't look like spidernet hardware can really checksum all protocols,
the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
instead of NETIF_F_HW_CSUM.
The driver doesn't need it's own get/set for ethtool tx csum, and it
should use the standard ethtool_op_get_link.
Sig
> > If they have multiple TX queues, independantly programmable, that
> > single lock is stupid.
> >
> > We could use per-queue TX locks for such hardware, but we can't
> > support that currently.
>
> There could be bad packet reordering with this (like some SMP
> routers used to do).
My orig
On Tue, May 29, 2007 at 05:24:36PM -0700, Stephen Hemminger wrote:
> It doesn't look like spidernet hardware can really checksum all protocols,
> the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM
> instead of NETIF_F_HW_CSUM.
>
> The driver doesn't need it's own get/set
Pavel Emelianov wrote:
Hmm... The loopback must be doing bad things then. It first calls
eth_type_trans and then accounts for the new skb->len.
Perhaps it should be changed. e100 calculates the entire
frame as far as I can tell, and e1000 and tg3 do it in hardware
(not sure what all they are
On Thu, Jun 07, 2007 at 07:43:49AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> Folks, we need help. Please run this on different hardware. Evgeniy, i
> thought this kind of stuff excites you, no? ;-> (wink, wink).
> Only the sender needs the patch but the receiver must be a more powerful
> machine (s
On Wed, 06 Jun 2007 16:56:02 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Wed, 06 Jun 2007 19:35:46 -0400
>
> > There is no potential for parallelizing on transmit that i can think of.
> > Dave, please explain it slowly so i can understand it.
> >
On Thu, 07 Jun 2007 15:16:34 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> The usage is
> # ip link add [name] type veth [peer ] [mac ] [peer_mac ]
>
> This version doesn't include the fix for ip/iplink.c as Patrick
> said that he had included it into his patches already.
>
> Signed-off-by:
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Ben Greear wrote:
>>
>>> Pavel Emelianov wrote:
>>>
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Rolf Eike Beer wrote:
> You wrote:
> > Rolf Eike Beer <[EMAIL PROTECTED]> :
> > [...]
> >
> > > I just had another freeze using your patches. After 512kB over smb it
> > > was dead.
> >
> > In-kernel smb/cifs ?
>
> Copying to a partition mounted via smb:// protocol in konqueror which uses
> kio_smb
Pavel Emelianov wrote:
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver k
Pavel Emelianov wrote:
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the de
The current NetLabel code has some redundant APIs which allow both
"struct socket" and "struct sock" types to be used; this may have made sense at
some point but it is wasteful now. Remove the functions that operate on
sockets and convert the callers. Not only does this make the code smaller and
IPv4 options are not very well aligned within the packet and the format of a
CIPSO option is even worse. The result is that the CIPSO engine in the kernel
does a few unaligned accesses when parsing and validating incoming packets with
CIPSO options attached which generate error messages on certain
Two straight-forward, smallish patches against David's net-2.6 tree which fix
some kernel unaligned access errors/messages and remove some redundant code.
I've tested this patchset on both x86 and ia64 platforms and have not seen
any regressions.
I'm not sure about my timing, but if it is too late
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Veth stands for Virtual ETHernet. It is a simple tunnel driver
>> that works at the link layer and looks like a pair of ethernet
>> devices interconnected with each other.
>>
> As Dave mentioned, there is already a driver known as 'veth'. Maybe borr
>>
>> no one is against generic code and ability to create 2 interfaces in
>> *one* namespace.
>> (Like we currently allow to do so in OpenVZ)
>>
>> However, believe me, moving an interface is a *hard* operation. Much
>> harder then netdev
>> register from the scratch.
>>
>> Because it requires to
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the etun name as well?
I wo
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device
jamal wrote:
On Wed, 2007-06-06 at 20:47 -0400, Jeff Garzik wrote:
1) you need (a) well-designed hardware _and_ (b) a smart driver writer
to avoid bottlenecking on internal driver locks. As you can see we have
both (a) and (b) for tg3 ;-)
How about the following patch which fixes #b for e1
On Thu, Jun 07, 2007 at 12:51:59PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> > What bout checking if page belongs to kmalloc cache (or any other cache
> > via priviate pointers) and do not perform any kind of reference counting
> > on them? I will play with this a bit later today.
>
> That mi
Kirill Korotaev wrote:
Deniel,
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But
Deniel,
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
>
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK
me
On Thu, 7 Jun 2007 20:40:39 +0900
Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Hello.
>
> Same local ports are assigned to multiple sockets.
> The following program should print different local port number.
>
> - Start of program -
> #include
> #include
> #include
> #include
> #include
On Wed, 2007-06-06 at 20:47 -0400, Jeff Garzik wrote:
> 1) you need (a) well-designed hardware _and_ (b) a smart driver writer
> to avoid bottlenecking on internal driver locks. As you can see we have
> both (a) and (b) for tg3 ;-)
How about the following patch which fixes #b for e1000 ;->
I t
On Wed, 2007-06-06 at 21:08 -0400, jamal wrote:
> It's too depressing - so i came back here for a break ;->
I am sure you would agree it was too depressing ;->
> As a side note: You will have to do a lot of surgery to the current code
> to make tx run on multi CPUs. It needs some experimenting t
KK,
On Thu, 2007-07-06 at 14:12 +0530, Krishna Kumar2 wrote:
> I have run only once instead of
> taking any averages, so there could be some spurts/drops.
Would be nice to run three sets - but i think even one would be
sufficiently revealing.
> These results are based on the test script that I
On Thu, 2007-07-06 at 11:46 +0530, Krishna Kumar2 wrote:
> My somewhat confusing netperf script (to run on client) is attached below.
> Server just requires
> to run netserver. Client is not completely accurate since I am not using
> netperf4 (moving to
> that after some initial hiccups).
Thanks K
NetXen: Add NETXEN prefixes to macros to clean them up.
This is a cleanup patch which adds NETXEN prefix to some stand
alone macro names.
These posed compile errors when NetXen driver was backported to 2.6.9
on PPC architecture as macros like USER_START are defined in file
arch/ppc64/mm/hash_utils
NetXen: Add multi cast filter code
This patch adds multi cast filter code to NetXen NIC driver.
It also adds capabilities to setup the multicast address in hardware
from the host side.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h | 24 +
drive
NetXen: Fix initialization and subsequent ping issue on 3.4.19 firmware
This patch fixes the ping problem seen X/PBlades after the adapter's
firmware was moved to 3.4.19. After configured interface up, ping
failed.
NetXen adapter couldn't accept ARP broadcast packet. Manual addition of
MAC addre
NetXen: Fix incorrect link status even with switch turned OFF.
NetXen driver failed to accurately indicate when a link is up or down.
This was encountered during failover testing, when the first port
indicated that the link was up even when the 10G switch it was assigned
to in the Bladecenter was
Hi All,
I will be sending bug fixes related to initialization, link status and
some compile issues of NetXen's 1/10G Ethernet driver in subsequent
mails.
These patches are wrt netdev#upstream-fixes.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
The usage is
# ip link add [name] type veth [peer ] [mac ] [peer_mac ]
This version doesn't include the fix for ip/iplink.c as Patrick
said that he had included it into his patches already.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/ip/Makefile b/ip/Makefile
index 9a5bf
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces
but it can be used as is as well.
Eric recently sent a similar driver c
On Thu, Jun 07 2007, Evgeniy Polyakov wrote:
> On Wed, Jun 06, 2007 at 09:17:25AM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > > Some pages have zero reference counter here.
> >
> > But it's somewhat annoying to get pages with zero reference counts
> > there, I wonder how that happens. I gu
>
> so is it possible to unregister tcp and register my protocol dynamically.
inet_unregister_protosw()/inet_register_protosw().
oops...can't unregister tcp (permanent protocol).
-Kalash
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
On 6/7/07, Tej Parkash <[EMAIL PROTECTED]> wrote:
hi
i just want to have something like tcp layer sitting below inet layer.
so that i can directly offload everything to NIC
and i want it to be placed dynamically. so depending on the nic i can
offload the feature or can make it normal flow.
i.e.
First of all I managed to reproduce this bug with Gentoo LiveCD 2007.0 amd64
so now Im sure it is not Ubuntu specific. 2007.0 comes with kernel
2.6.19-gentoo-...
On Tuesday 05 of June 2007 22:37:09 you wrote:
> Can you reproduce the problem if this module is not loaded at all ?
>
> Please unders
>> I did this at the very first version, but Alexey showed me that this
>> would be wrong. Look. When we create the second device it must be in
>> the other namespace as it is useless to have them in one namespace.
>> But if we have the device in the other namespace the RTNL_NEWLINK
>> message from
David Miller wrote:
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer
Pavel Emelianov wrote:
Patrick McHardy wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network nam
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
> David Miller wrote:
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Wed, 06 Jun 2007 19:11:38 +0400
> >
> >
> >>Veth stands for Virtual ETHernet. It is a simple tunnel driver
> >>that works at the link laye
Hi Jamal,
I ran these bits today and the results are included. For comparison, I am
running 2.6.22-rc3 original bits. The systems are both 2.8Ghz, 2 cpu, P4,
2GB RAM, one E1000 82547GI card connected using a crossover cable.
The test runs for 3 mins for each case. I have run only once instead of
t
On Wednesday 06 June 2007 23:04:07 Stephen Hemminger wrote:
>
> > I don't think we need +1, if you need to fire immediately
> > (on the next tick). The timer core will always fire
> > timers that are in the past immediately.
>
> Thanks, but is it worth bothering to change it again?
No, I don't t
Michael Ellerman <[EMAIL PROTECTED]> wrote on 06/07/2007 02:35:00 AM:
> On Wed, 2007-06-06 at 20:53 +0200, Thomas Klein wrote:
> > This patch fixes a possible kernel panic due to not checking the vlan
group
> > when processing received VLAN packets and a malfunction in
VLAN/hypervisor
> > registra
1 - 100 of 105 matches
Mail list logo
