* Re: [BUG] crashes with kvm/nat networking and net-next
From: Stephen Hemminger @ 2010-05-12 22:15 UTC (permalink / raw)
To: Bart De Schuymer; +Cc: Patrick McHardy, Eric Dumazet, netdev
In-Reply-To: <4BEAB54A.2070203@pandora.be>
On Wed, 12 May 2010 16:03:54 +0200
Bart De Schuymer <bdschuym@pandora.be> wrote:
> Patrick McHardy wrote:
> > Eric Dumazet wrote:
> >> Le mardi 11 mai 2010 à 20:25 -0700, Stephen Hemminger a écrit :
> >>> This is a regression that is showing up now in net-next, not sure what
> >>> changed recently in bridge netfilter that could be causing it?
> >>>
> >>> [ 4593.956206] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> >>> [ 4593.956219] IP: [<ffffffffa03357a4>] br_nf_forward_finish+0x154/0x170 [bridge]
> >> Not sure, but br_nf_forward_ip() has following check :
> >>
> >> if (!skb->nf_bridge)
> >> return NF_ACCEPT;
> >>
> >> while br_nf_forward_arp() missed this check ...
> >>
> >> So we can dereference null pointer later
> >
> > That looks correct to me, offset 0x18 would be nf_bridge_info->mask.
> > Bart, please review, thanks.
> >
> >> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> >> index 93f80fe..cd2e5f5 100644
> >> --- a/net/bridge/br_netfilter.c
> >> +++ b/net/bridge/br_netfilter.c
> >> @@ -723,6 +723,9 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
> >> return NF_ACCEPT;
> >> #endif
> >>
> >> + if (!skb->nf_bridge)
> >> + return NF_ACCEPT;
> >> +
> >> if (skb->protocol != htons(ETH_P_ARP)) {
> >> if (!IS_VLAN_ARP(skb))
> >> return NF_ACCEPT;
>
> That won't fix it since nf_bridge isn't used in the ARP case. The
> correct fix is below. Does anyone know why the null pointer
> dereference (skb->nf_bridge->mask & BRNF_8021Q) in
> nf_bridge_update_protocol() didn't cause my uml kernel to crash??
>
> cheers,
> Bart
>
>
> Don't call nf_bridge_update_protocol() for ARP traffic as
> skb->nf_bridge isn't used in the ARP case.
>
>
> Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
>
> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> index 93f80fe..4442099 100644
> --- a/net/bridge/br_netfilter.c
> +++ b/net/bridge/br_netfilter.c
> @@ -643,10 +643,10 @@ static int br_nf_forward_finish(struct sk_buff *skb)
> skb->pkt_type = PACKET_OTHERHOST;
> nf_bridge->mask ^= BRNF_PKT_TYPE;
> }
> + nf_bridge_update_protocol(skb);
> } else {
> in = *((struct net_device **)(skb->cb));
> }
> - nf_bridge_update_protocol(skb);
> nf_bridge_push_encap_header(skb);
>
> NF_HOOK_THRESH(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, in,
>
This has worked all day for me without problem.
--
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-12 22:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1273634421.2512.21.camel@edumazet-laptop>
On Wed, 12 May 2010 05:20:21 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 11 mai 2010 à 22:50 +0200, Eric Dumazet a écrit :
> > Le mardi 11 mai 2010 à 04:08 +0000, Bijay Singh a écrit :
> > > Hi Eric,
> > >
> > > I guess that makes me the enviable one. So I am keen to test out this feature completely, as long as I know what to do as a next step, directions, patches.
> > >
> > > Thanks
> >
> >
> > I believe third problem comes from commit 4957faad
> > (TCPCT part 1g: Responder Cookie => Initiator), from William Allen
> > Simpson.
>
> And a fourth problem might be that tcp_md5_hash_skb_data() is not
> frag_list aware ?
>
>
>
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 8ce2974..56ee0f2 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2985,6 +2985,7 @@ int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *hp,
> const unsigned head_data_len = skb_headlen(skb) > header_len ?
> skb_headlen(skb) - header_len : 0;
> const struct skb_shared_info *shi = skb_shinfo(skb);
> + struct sk_buff *frag_iter;
>
> sg_init_table(&sg, 1);
>
> @@ -2999,6 +3000,10 @@ int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *hp,
> return 1;
> }
>
> + skb_walk_frags(skb, frag_iter)
> + if (tcp_md5_hash_skb_data(hp, frag_iter, 0))
> + return 1;
> +
> return 0;
> }
Yes, that looks like a possible bug, not sure what hardware
generates frag_list.
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: David Miller @ 2010-05-12 22:24 UTC (permalink / raw)
To: shemminger
Cc: eric.dumazet, Bijay.Singh, bhaskie, bhutchings, netdev,
ilpo.jarvinen
In-Reply-To: <20100512152207.0e0c321a@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 12 May 2010 15:22:07 -0700
> Yes, that looks like a possible bug, not sure what hardware
> generates frag_list.
GRO generates frag_list
^ permalink raw reply
* Re: mmotm 2010-05-11 - dies in pm_qos_update_request()
From: Rafael J. Wysocki @ 2010-05-12 22:33 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, David S. Miller, linux-kernel, e1000-devel, netdev
In-Reply-To: <17286.1273702370@localhost>
On Thursday 13 May 2010, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 12 May 2010 23:07:20 +0200, "Rafael J. Wysocki" said:
>
> > > I suspect this commit:
> > >
> > > commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
> > > Author: Rafael J. Wysocki <rjw@sisk.pl>
> > > Date: Sun Mar 14 14:35:17 2010 +0000
> > >
> > > e1000e / PCI / PM: Add basic runtime PM support (rev. 4)
> >
> > No, I don't think so. I'm running -rc6 with this patch applied on a box with
> > e1000e and it works just fine.
> >
> > Please try to revert this one instead:
> >
> > http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=patch;h=ed77134bfccf5e75b6cbadab268e559dbe6a4ebb
>
> Isn't a clean revert - build dies with:
>
> CC net/mac80211/scan.o
> net/mac80211/scan.c: In function 'ieee80211_scan_state_decision':
> net/mac80211/scan.c:510: error: implicit declaration of function 'pm_qos_request'
> make[1]: *** [net/mac80211/scan.o] Error 1
> make: *** [net/mac80211/scan.o] Error 2
>
> Will investigate more later, find what other commit needs reverting.
Simply rename pm_qos_request() to pm_qos_requirement() in
ieee80211_scan_state_decision() and it should build.
Rafael
^ permalink raw reply
* [PATCH 0/5] sky2: Avoid memory allocations on suspend/resume
From: Mike McCormack @ 2010-05-12 23:16 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Hi Stephen,
This patch set rearranges sky2_suspend and sky2_resume so that we don't free memory and reallocate it when suspending.
Furthermore, there's two small fixes (Avoid race in sky2_change_mtu) for which I've clarified the commit message, and
(Restore multicast after restart) which restores the multicast settings after reset, as they may be lost.
thanks,
Mike
^ permalink raw reply
* [PATCH 1/5] sky2: Avoid race in sky2_change_mtu
From: Mike McCormack @ 2010-05-12 23:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
netif_stop_queue does not ensure all in-progress transmits are complete,
so use netif_tx_disable() instead.
Secondly, make sure NAPI polls are disabled before stopping the tx queue,
otherwise sky2_status_intr might trigger a TX queue wakeup between when
we stop the queue and NAPI is disabled.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 088c797..b839bae 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2236,8 +2236,8 @@ static int sky2_change_mtu(struct net_device *dev, int new_mtu)
sky2_write32(hw, B0_IMSK, 0);
dev->trans_start = jiffies; /* prevent tx timeout */
- netif_stop_queue(dev);
napi_disable(&hw->napi);
+ netif_tx_disable(dev);
synchronize_irq(hw->pdev->irq);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/5] sky2: Restore multicast after restart
From: Mike McCormack @ 2010-05-12 23:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Multicast settings will be lost on reset, so restore them.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index b839bae..58ae840 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3293,6 +3293,7 @@ static void sky2_restart(struct work_struct *work)
continue;
sky2_hw_up(sky2);
+ sky2_set_multicast(dev);
netif_wake_queue(dev);
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/5] sky2: Shut off interrupts before NAPI
From: Mike McCormack @ 2010-05-12 23:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Interrupts should be masked, then synchronized, and
finally NAPI should be disabled.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 58ae840..04adcee 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3266,10 +3266,10 @@ static void sky2_restart(struct work_struct *work)
rtnl_lock();
- napi_disable(&hw->napi);
- synchronize_irq(hw->pdev->irq);
imask = sky2_read32(hw, B0_IMSK);
sky2_write32(hw, B0_IMSK, 0);
+ synchronize_irq(hw->pdev->irq);
+ napi_disable(&hw->napi);
for (i = 0; i < hw->ports; i++) {
struct net_device *dev = hw->dev[i];
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/5] sky2: Refactor down/up code out of sky2_restart()
From: Mike McCormack @ 2010-05-12 23:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Code to bring down all sky2 interfaces and bring it up
again can be reused in sky2_suspend and sky2_resume.
Factor the code to bring the interfaces down into
sky2_all_down and the up code into sky2_all_up.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 26 +++++++++++++++++++-------
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 04adcee..a8060c8 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3258,15 +3258,11 @@ static int sky2_reattach(struct net_device *dev)
return err;
}
-static void sky2_restart(struct work_struct *work)
+static void sky2_all_down(struct sky2_hw *hw)
{
- struct sky2_hw *hw = container_of(work, struct sky2_hw, restart_work);
- u32 imask;
int i;
- rtnl_lock();
-
- imask = sky2_read32(hw, B0_IMSK);
+ sky2_read32(hw, B0_IMSK);
sky2_write32(hw, B0_IMSK, 0);
synchronize_irq(hw->pdev->irq);
napi_disable(&hw->napi);
@@ -3282,8 +3278,12 @@ static void sky2_restart(struct work_struct *work)
netif_tx_disable(dev);
sky2_hw_down(sky2);
}
+}
- sky2_reset(hw);
+static void sky2_all_up(struct sky2_hw *hw)
+{
+ u32 imask = Y2_IS_BASE;
+ int i;
for (i = 0; i < hw->ports; i++) {
struct net_device *dev = hw->dev[i];
@@ -3294,6 +3294,7 @@ static void sky2_restart(struct work_struct *work)
sky2_hw_up(sky2);
sky2_set_multicast(dev);
+ imask |= portirq_msk[i];
netif_wake_queue(dev);
}
@@ -3302,6 +3303,17 @@ static void sky2_restart(struct work_struct *work)
sky2_read32(hw, B0_Y2_SP_LISR);
napi_enable(&hw->napi);
+}
+
+static void sky2_restart(struct work_struct *work)
+{
+ struct sky2_hw *hw = container_of(work, struct sky2_hw, restart_work);
+
+ rtnl_lock();
+
+ sky2_all_down(hw);
+ sky2_reset(hw);
+ sky2_all_up(hw);
rtnl_unlock();
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 5/5] sky2: Avoid allocating memory in sky2_resume
From: Mike McCormack @ 2010-05-12 23:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Allocating memory can fail, and since we have the memory we need
in sky2_resume when sky2_suspend is called, just stop the hardware
without freeing the memory it's using.
This avoids the possibility of failing because we can't allocate
memory in sky2_resume(), and allows sharing code with sky2_restart().
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 20 +++++---------------
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index a8060c8..02d9d6f 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -4842,12 +4842,12 @@ static int sky2_suspend(struct pci_dev *pdev, pm_message_t state)
cancel_work_sync(&hw->restart_work);
rtnl_lock();
+
+ sky2_all_down(hw);
for (i = 0; i < hw->ports; i++) {
struct net_device *dev = hw->dev[i];
struct sky2_port *sky2 = netdev_priv(dev);
- sky2_detach(dev);
-
if (sky2->wol)
sky2_wol_init(sky2);
@@ -4856,8 +4856,6 @@ static int sky2_suspend(struct pci_dev *pdev, pm_message_t state)
device_set_wakeup_enable(&pdev->dev, wol != 0);
- sky2_write32(hw, B0_IMSK, 0);
- napi_disable(&hw->napi);
sky2_power_aux(hw);
rtnl_unlock();
@@ -4872,12 +4870,11 @@ static int sky2_suspend(struct pci_dev *pdev, pm_message_t state)
static int sky2_resume(struct pci_dev *pdev)
{
struct sky2_hw *hw = pci_get_drvdata(pdev);
- int i, err;
+ int err;
if (!hw)
return 0;
- rtnl_lock();
err = pci_set_power_state(pdev, PCI_D0);
if (err)
goto out;
@@ -4895,20 +4892,13 @@ static int sky2_resume(struct pci_dev *pdev)
goto out;
}
+ rtnl_lock();
sky2_reset(hw);
- sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
- napi_enable(&hw->napi);
-
- for (i = 0; i < hw->ports; i++) {
- err = sky2_reattach(hw->dev[i]);
- if (err)
- goto out;
- }
+ sky2_all_up(hw);
rtnl_unlock();
return 0;
out:
- rtnl_unlock();
dev_err(&pdev->dev, "resume failed (%d)\n", err);
pci_disable_device(pdev);
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2010-05-13 1:02 UTC (permalink / raw)
To: reinette chatre
Cc: David Miller, netdev, linux-next, linux-kernel, Berg, Johannes,
John W. Linville
In-Reply-To: <1273680943.2370.9533.camel@rchatre-DESK>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
Hi Reinette,
On Wed, 12 May 2010 09:15:43 -0700 reinette chatre <reinette.chatre@intel.com> wrote:
>
> Please note that this member of iwl_priv is now located in two
> places ... here and also in the device specific union a few lines up
> inside the _agn struct. In the code it is indeed the one in the _agn
> struct that is being used (see usage in iwl-agn.c), so adding this line
> is not necessary.
>
> This should not cause any problems with driver operation and can
> probably remain as such if indeed it is cleaned up somewhere else before
> it hits you again or linux-2.6.
Thanks for pointing this out. I will update my merge resolution in
linux-next and I assume it will be done correctly when Dave or John also
do that merge.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Config Items appearing twice in same Kconfig file?
From: Michael Ellerman @ 2010-05-13 1:08 UTC (permalink / raw)
To: Christoph Egger
Cc: linux-ia64, vamos, Jesse Barnes, Timo Teras, Chen Liqin,
Paul Mackerras, H. Peter Anvin, Lennox Wu, Jesper Nilsson,
Pekka Savola (ipv6), x86, James Morris, Ingo Molnar,
Alexey Kuznetsov, Matt Turner, Fenghua Yu, Mike Frysinger,
Arnd Bergmann, Graf Yang, Mikael Starvik, Ivan Kokshaysky,
Thomas Gleixner, Arjan van de Ven, Richard Henderson,
Karsten Keil
In-Reply-To: <20100512144017.GA722@faui48a.informatik.uni-erlangen.de>
[-- Attachment #1.1: Type: text/plain, Size: 994 bytes --]
On Wed, 2010-05-12 at 16:40 +0200, Christoph Egger wrote:
> Just noticed it might have been worth adding the output so everyone
> out there doesn't ned to grep through his tree for reference:
>
> % grep ^config **/Kconfig* | sort | uniq -dc
That didn't actually work for me?
> 2 arch/powerpc/Kconfig:config KERNEL_START
> 2 arch/powerpc/Kconfig:config PAGE_OFFSET
> 2 arch/powerpc/Kconfig:config PHYSICAL_START
> 2 arch/powerpc/Kconfig:config RELOCATABLE
The duplication of these is caused by the second definitions being
inside an "if PPC64" block.
For PAGE_OFFSET and KERNEL_START we want the 2nd definitions, the
default value is different between 32 & 64 bit.
For RELOCATABLE it's a little weird, but we want the 2nd definition
because the depends condition is different between 32 & 64bit - though
they could probably be merged.
I don't really see why we need two versions of PHYSICAL_START.
cheers
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* printk mac address --hangs
From: ratheesh k @ 2010-05-13 5:16 UTC (permalink / raw)
To: netdev
/* code snippent */
char src[ETH_ALEN+2];
char dst[ETH_ALEN+2];
eth_header = eth_hdr(skb);
memcpy(src , eth_header->h_source , ETH_ALEN );
memcpy(dst , eth_header->h_dest , ETH_ALEN );
Linux crashes . But if comment out memcpy lines . It works . What is
the problem here ?
How can i printk both source mac and dest mac address ?
Thanks,
Ratheesh
^ permalink raw reply
* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
From: Ha, Tristram @ 2010-05-13 5:38 UTC (permalink / raw)
To: Arce, Abraham, Ben Dooks
Cc: David Miller, netdev, linux-kernel, Jan, Sebastien
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043DF7779A@dlee03.ent.ti.com>
I use a web browser to send patches through my company's e-mail system. The message is composed by cut and paste, so it may not conform to Linux standard.
The latest nuttcp default size for UDP is 1500 bytes, rather than 8192 bytes. In my case, the transmit performance improves from 10 Mbps to 11. Have you tried TCP?
-----Original Message-----
From: Arce, Abraham [mailto:x0066660@ti.com]
Sent: Thu 5/6/2010 10:02 PM
To: Ha, Tristram; Ben Dooks
Cc: David Miller; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Jan, Sebastien
Subject: RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
Hi,
[snip]
> There is a driver option no_tx_opt so that the driver can revert to original
> implementation. This allows user to verify if the transmit performance
> actually improves.
Should we limit patch description to 80 characters also?
> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> ---
> This replaces the [patch 01/13] patch I submitted and was objected by David.
>
> Other users with Micrel KSZ8851 SNL chip please verify the transmit
> performance does improve or not.
Tested-by: Abraham Arce <x0066660@ti.com>
Executing some nuttcp scenarios:
- Without Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
1.2676 MB / 1.00 sec = 10.6330 Mbps 0 / 1298 ~drop/pkt 0.00 ~%loss
1.2705 MB / 1.00 sec = 10.6579 Mbps 0 / 1301 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6496 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6414 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2646 MB / 1.00 sec = 10.6086 Mbps 0 / 1295 ~drop/pkt 0.00 ~%loss
1.2686 MB / 1.00 sec = 10.6412 Mbps 0 / 1299 ~drop/pkt 0.00 ~%loss
1.2695 MB / 1.00 sec = 10.6498 Mbps 0 / 1300 ~drop/pkt 0.00 ~%loss
12.7314 MB / 10.02 sec = 10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss
- With Patch -
# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
1.2891 MB / 1.00 sec = 10.8133 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8217 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8299 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2891 MB / 1.00 sec = 10.8135 Mbps 0 / 1320 ~drop/pkt 0.00 ~%loss
1.2900 MB / 1.00 sec = 10.8216 Mbps 0 / 1321 ~drop/pkt 0.00 ~%loss
1.2910 MB / 1.00 sec = 10.8298 Mbps 0 / 1322 ~drop/pkt 0.00 ~%loss
12.9492 MB / 10.02 sec = 10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
%loss
Also simulated heavy transmission consisting of 40 processes executed in parallel:
- 20 ping instances using packet size of 32768
- 20 dd instances creating a 50MB file each under the nfs rootfs
If any specific test scenario/application is required please do let me know...
Best Regards
Abraham
^ permalink raw reply
* Re: [PATCH net-next 0/16] tipc: 1st integration of basic changes from sourceforge
From: David Miller @ 2010-05-13 6:28 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, allan.stephens
In-Reply-To: <1273624218-22514-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue, 11 May 2010 20:30:02 -0400
> The following patches are step one in making use of the changes that
> were stored away on sourceforge but not yet integrated into the kernel.
>
> Since I am far from knowledgeable on tipc, this starts by pulling in
> the 1st batch of basic/cosmetic changes that will at least start to
> reduce the delta between the two. Hopefully getting all the simple
> stuff out of the way 1st will help clarify what is left of interest.
>
> I've also put the same commits on the branch tipc-May11_2010 in:
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git
> in case that is more convenient for people.
All applied to net-next-2.6, thanks for doing this work Paul.
^ permalink raw reply
* Re: [PATCH NEXT 0/4]netxen: bug fixes
From: David Miller @ 2010-05-13 6:29 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 12 May 2010 02:53:01 -0700
> Series of 4 patches to fix diagnostic tools access and register usage
> for NX3031.
> Please apply them on net-next branch.
All applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/6] ipv6: ip6mr: support multiple independant multicast routing instances
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <1273586551-3521-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Tue, 11 May 2010 16:02:25 +0200
> The following patches add support for multiple independant IPv6 multicast
> routing instances. This can be useful to seperate traffic when building
> a multicast router that is serving multiple independant networks.
>
> The patchset is pretty much a straight forward port from IPv4 with no
> significant differences.
...
> These patches have been tested using pim6sd and mrd6.
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/ipmr-2.6.git master
Pulled, thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH 01/12] e1000e: use static params to save stack space (part 2)
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan, jesse.brandeburg
In-Reply-To: <20100511005801.30827.50808.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> A couple stack cleanups missed in an earlier patch from Jesse.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 02/12] e1000e: bad state after running ethtool diagnostics with AMT enabled
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511005929.30827.30176.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:31 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When running ethtool online diagnostics with no open interface, there is a
> short period of time where the driver relinquishes control of the adapter
> during which time AMT (manageability firmware) can put the adapter into an
> unknown state resulting in such things as link test failure, hardware hang,
> reporting an incorrect link speed, etc. Resetting the adapter during an
> open() resolves this by putting the adapter into a quiescent state.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 03/12] e1000e: initialize manageability (IPMI) pass-through in 82574/82583
From: David Miller @ 2010-05-13 6:31 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511005949.30827.62576.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 17:59:51 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> 82574/82583 uses different registers/bits to setup manageability filters
> than all other parts supported by e1000e; set them accordingly for IPMI
> pass-through. Rename the function to better reflect what it does.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 04/12] e1000e: s/w initiated LSC MSI-X interrupts not generated; no transmit
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010008.30827.45897.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> In MSI-X mode when an IMPI SoL session was active (i.e. the PHY reset was
> blocked), the LSC interrupt generated by s/w to start the watchdog which
> started the transmitter was not getting fired by the hardware because bit
> 24 (the 'other' cause bit) also needed to be set. Without an active SoL
> session, the PHY was reset which caused the h/w to fire the LSC interrupt.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 05/12] e1000e: cleanup multiple common exit points
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010029.30827.82837.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:31 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> ...in e1000_update_nvm_checksum_ich8lan().
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 06/12] e1000e: Remove EN_MAC_ADDR_FILTER check from enable_mng_pass_thru check
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010048.30827.12737.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:00:50 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Patch addresses issues when manageability passthrough is enabled, but the
> MAC_ADDR_FILTER bit is not set in the MANC register.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 07/12] e1000e: Cleanup e1000_sw_lcd_config_ich8lan()
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010108.30827.47964.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:01:10 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> After every reset all ICH/PCH parts call this function which acquires the
> swflag, performs a workaround on applicable parts and releases the swflag.
> There is no reason for parts for which this workaround is not applicable
> to acquire and release the swflag so the function should just return
> without doing anything for these parts. This also provides for the
> indentation of most of the function contents to be shifted left cleaning up
> the code.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 08/12] e1000e: Incorrect function pointer set for force_speed_duplex on 82577
From: David Miller @ 2010-05-13 6:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20100511010128.30827.12447.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 10 May 2010 18:01:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The force_speed_duplex function pointer was incorrectly set. Instead of
> calling the 82577-specific version it was calling the m88 version which,
> among other incorrect things, reset the PHY causing autonegotiation to be
> re-enabled in the PHY resulting in the link defaulting to half-duplex.
> The 82577-specific force_speed_duplex function also had an issue where
> it disabled Auto-MDI-X which caused the link to not come up.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox