* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-08-01 3:17 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4A72D373.7080802-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Fri, Jul 31, 2009 at 01:20:19PM +0200, Oliver Hartkopp wrote:
> Dave Young wrote:
> > On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
> >>> Dave Young wrote:
> >>>> On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
> >>>>> Hi Dave,
> >>>>>
> >>>>> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> >>>>> attached screenshot).
> >>>> Weird, the oops occurs between sock init and tty init routines. Could
> >>>> you tell your bluez version and your configuration?
> >>>>
> >>> No problem:
> >> Thanks.
> >>
> >> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
> >>
> >> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
> >>
> >> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
> >> +++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
> >> @@ -36,6 +36,7 @@
> >> #include <linux/net.h>
> >> #include <linux/mutex.h>
> >> #include <linux/kthread.h>
> >> +#include <linux/nmi.h>
> >>
> >> #include <net/sock.h>
> >> #include <asm/uaccess.h>
> >> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
> >> /* ---- Initialization ---- */
> >> static int __init rfcomm_init(void)
> >> {
> >> - int ret;
> >> + int ret, i;
> >>
> >> l2cap_load();
> >>
> >> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
> >> if (ret)
> >> goto out_sock;
> >>
> >> + /* delay 5 seconds to trigger the tty bug */
> >> + for (i = 0; i < 50; i++) {
> >> + touch_nmi_watchdog();
> >> + mdelay(100);
> >
> > Hi, for this case, msleep is better, you can just replace the above
> > two lines with msleep(100)
> >
>
> Hi Dave,
>
> applied this patch and replaced mdelay(100) with msleep(100).
>
> I got two crashes and three proper boots.
>
> The crashes look like the formerly posted screenshots.
> When it boots properly i can see the delay in the boot process.
>
> Does this help?
Yes, I think so.
Please unapply the before two patch, try the following v2 patch instead.
Changes from v1: fixes 'goto' path again, make tty init before sock init.
Thanks.
---
rfcomm tty may be used before rfcomm_tty_driver initilized,
The problem is that now socket layer init before tty layer, if userspace
program do socket callback right here then oops will happen.
reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
make 3 changes:
1. remove #ifdef in rfcomm/core.c,
make it blank function when rfcomm tty not selected in rfcomm.h
2. tune the rfcomm_init error patch to ensure
tty driver initilized before rfcomm socket usage.
3. remove __exit for rfcomm_cleanup_sockets
because above change need call it in a __init function.
CC: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Reported-by: Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Signed-off-by: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
include/net/bluetooth/rfcomm.h | 13 ++++++++++++-
net/bluetooth/rfcomm/core.c | 29 ++++++++++++++++++++---------
net/bluetooth/rfcomm/sock.c | 2 +-
3 files changed, 33 insertions(+), 11 deletions(-)
--- linux-2.6.orig/include/net/bluetooth/rfcomm.h 2009-08-01 10:53:18.000000000 +0800
+++ linux-2.6/include/net/bluetooth/rfcomm.h 2009-08-01 10:55:29.000000000 +0800
@@ -355,7 +355,18 @@ struct rfcomm_dev_list_req {
};
int rfcomm_dev_ioctl(struct sock *sk, unsigned int cmd, void __user *arg);
+
+#ifdef CONFIG_BT_RFCOMM_TTY
int rfcomm_init_ttys(void);
void rfcomm_cleanup_ttys(void);
-
+#else
+static inline int rfcomm_init_ttys(void)
+{
+ return 0;
+}
+static inline int rfcomm_cleanup_ttys(void)
+{
+ return 0;
+}
+#endif
#endif /* __RFCOMM_H */
--- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-08-01 10:53:18.000000000 +0800
+++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-08-01 11:03:24.000000000 +0800
@@ -2080,28 +2080,41 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
/* ---- Initialization ---- */
static int __init rfcomm_init(void)
{
+ int ret;
+
l2cap_load();
hci_register_cb(&rfcomm_cb);
rfcomm_thread = kthread_run(rfcomm_run, NULL, "krfcommd");
if (IS_ERR(rfcomm_thread)) {
- hci_unregister_cb(&rfcomm_cb);
- return PTR_ERR(rfcomm_thread);
+ ret = PTR_ERR(rfcomm_thread);
+ goto out_thread;
}
if (class_create_file(bt_class, &class_attr_rfcomm_dlc) < 0)
BT_ERR("Failed to create RFCOMM info file");
- rfcomm_init_sockets();
-
-#ifdef CONFIG_BT_RFCOMM_TTY
- rfcomm_init_ttys();
-#endif
+ ret = rfcomm_init_ttys();
+ if (ret)
+ goto out_tty;
+
+ ret = rfcomm_init_sockets();
+ if (ret)
+ goto out_sock;
BT_INFO("RFCOMM ver %s", VERSION);
return 0;
+
+out_sock:
+ rfcomm_cleanup_ttys();
+out_tty:
+ kthread_stop(rfcomm_thread);
+out_thread:
+ hci_unregister_cb(&rfcomm_cb);
+
+ return ret;
}
static void __exit rfcomm_exit(void)
@@ -2112,9 +2125,7 @@ static void __exit rfcomm_exit(void)
kthread_stop(rfcomm_thread);
-#ifdef CONFIG_BT_RFCOMM_TTY
rfcomm_cleanup_ttys();
-#endif
rfcomm_cleanup_sockets();
}
--- linux-2.6.orig/net/bluetooth/rfcomm/sock.c 2009-08-01 10:53:18.000000000 +0800
+++ linux-2.6/net/bluetooth/rfcomm/sock.c 2009-08-01 10:55:29.000000000 +0800
@@ -1132,7 +1132,7 @@ error:
return err;
}
-void __exit rfcomm_cleanup_sockets(void)
+void rfcomm_cleanup_sockets(void)
{
class_remove_file(bt_class, &class_attr_rfcomm);
^ permalink raw reply
* Re: [net-next-2.6 PATCH 6/9] ixgb: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Waskiewicz Jr, Peter P @ 2009-07-31 19:44 UTC (permalink / raw)
To: Dean Nelson
Cc: netdev@vger.kernel.org, Waskiewicz Jr, Peter P, Brandeburg, Jesse,
Kirsher, Jeffrey T
In-Reply-To: <20090731191340.5470.79342.send-patch@aqua>
On Fri, 31 Jul 2009, Dean Nelson wrote:
> PCI drivers that implement the struct pci_error_handlers' error_detected
> callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
> pci_channel_io_perm_failure. This patch fixes the issue for ixgb.
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
>
> ---
>
> This patch has not been tested, since I don't have the hardware to test it.
> It is based on a few recent patches. See the following commits:
>
> http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
> http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
> http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
> http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
> http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
>
> drivers/net/ixgb/ixgb_main.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
> index eb917f1..fad08ce 100644
> --- a/drivers/net/ixgb/ixgb_main.c
> +++ b/drivers/net/ixgb/ixgb_main.c
> @@ -2227,6 +2227,11 @@ static pci_ers_result_t ixgb_io_error_detected(struct pci_dev *pdev,
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct ixgb_adapter *adapter = netdev_priv(netdev);
>
> + netif_device_detach(netdev);
> +
> + if (state == pci_channel_io_perm_failure)
> + return PCI_ERS_RESULT_DISCONNECT;
> +
> if (netif_running(netdev))
> ixgb_down(adapter, true);
Seems reasonable, especially since the same logic works fine on our other
drivers. The hardware for this driver is somewhat difficult to get our
hands on, but we'll definately give this a spot test once we can locate
one of these NICs.
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: Dan Smith @ 2009-07-31 19:40 UTC (permalink / raw)
To: John Dykstra; +Cc: containers, netdev, Oren Laaden, Alexey Dobriyan
In-Reply-To: <1249068948.1104.0.camel@Maple>
>> + CKPT_COPY(op, hh->tcp.last_synq_overflow, sk->last_synq_overflow);
JD> This sock field was removed from the mainline kernel by commit
JD> a0f82f64e26929776c58a5c93c2ecb38e3d82815.
Ah, thanks for this. I'm trying to get the UNIX patch updated with
the latest round of feedback and then I'll take this and the other
comments forward with the INET patch.
Thanks!
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: John Dykstra @ 2009-07-31 19:35 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev, Oren Laaden, Alexey Dobriyan
In-Reply-To: <1246994776-1882-3-git-send-email-danms@us.ibm.com>
On Tue, 2009-07-07 at 12:26 -0700, Dan Smith wrote:
> + CKPT_COPY(op, hh->tcp.last_synq_overflow, sk->last_synq_overflow);
This sock field was removed from the mainline kernel by commit
a0f82f64e26929776c58a5c93c2ecb38e3d82815.
-- John
^ permalink raw reply
* [net-next-2.6 PATCH 9/9] vxge: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:14 UTC (permalink / raw)
To: netdev; +Cc: Ramkrishna Vepa
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for vxge.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/vxge/vxge-main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 7b5402b..335140d 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -3956,6 +3956,9 @@ static pci_ers_result_t vxge_io_error_detected(struct pci_dev *pdev,
netif_device_detach(netdev);
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev)) {
/* Bring down the card, while avoiding PCI I/O */
do_vxge_close(netdev, 0);
^ permalink raw reply related
* [net-next-2.6 PATCH 8/9] s2io: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: Ramkrishna Vepa, Sreenivasa Honnur
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for s2io.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/s2io.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index d4df933..bd6d713 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -8636,6 +8636,9 @@ static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
netif_device_detach(netdev);
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev)) {
/* Bring down the card, while avoiding PCI I/O */
do_s2io_card_down(sp, 0);
^ permalink raw reply related
* [net-next-2.6 PATCH 2/9] atl1e: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: roel kluin, Jay Cliburn, Jie Yang
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for atl1e.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/atl1e/atl1e_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/atl1e/atl1e_main.c b/drivers/net/atl1e/atl1e_main.c
index 9fc6d6d..4570749 100644
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -2497,6 +2497,9 @@ atl1e_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
netif_device_detach(netdev);
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev))
atl1e_down(adapter);
^ permalink raw reply related
* [net-next-2.6 PATCH 7/9] qlge: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: linux-driver, Ron Mercer
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for qlge.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/qlge/qlge_main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 5768af1..3a271af 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -4076,6 +4076,11 @@ static pci_ers_result_t qlge_io_error_detected(struct pci_dev *pdev,
struct net_device *ndev = pci_get_drvdata(pdev);
struct ql_adapter *qdev = netdev_priv(ndev);
+ netif_device_detach(ndev);
+
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(ndev))
ql_adapter_down(qdev);
^ permalink raw reply related
* [net-next-2.6 PATCH 1/9] atl1c: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: roel kluin, Jay Cliburn, Jie Yang
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for atl1c.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/atl1c/atl1c_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index cd547a2..7426053 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -2678,6 +2678,9 @@ static pci_ers_result_t atl1c_io_error_detected(struct pci_dev *pdev,
netif_device_detach(netdev);
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev))
atl1c_down(adapter);
^ permalink raw reply related
* [net-next-2.6 PATCH 6/9] ixgb: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: PJ Waskiewicz, Jesse Brandeburg, Jeff Kirsher
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for ixgb.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/ixgb/ixgb_main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index eb917f1..fad08ce 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -2227,6 +2227,11 @@ static pci_ers_result_t ixgb_io_error_detected(struct pci_dev *pdev,
struct net_device *netdev = pci_get_drvdata(pdev);
struct ixgb_adapter *adapter = netdev_priv(netdev);
+ netif_device_detach(netdev);
+
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev))
ixgb_down(adapter, true);
^ permalink raw reply related
* [net-next-2.6 PATCH 5/9] igbvf: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: Alexander Duyck, Jeff Kirsher
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for igbvf.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/igbvf/netdev.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 2bc9d63..dba360d 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -2512,6 +2512,9 @@ static pci_ers_result_t igbvf_io_error_detected(struct pci_dev *pdev,
netif_device_detach(netdev);
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
if (netif_running(netdev))
igbvf_down(adapter);
pci_disable_device(pdev);
^ permalink raw reply related
* [net-next-2.6 PATCH 4/9] bnx2x: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: Eilon Greenstein
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for bnx2x.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/bnx2x_main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index 6c67be6..086eaaa 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -11553,6 +11553,11 @@ static pci_ers_result_t bnx2x_io_error_detected(struct pci_dev *pdev,
netif_device_detach(dev);
+ if (state == pci_channel_io_perm_failure) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
if (netif_running(dev))
bnx2x_eeh_nic_unload(bp);
^ permalink raw reply related
* [net-next-2.6 PATCH 3/9] bnx2: return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:13 UTC (permalink / raw)
To: netdev; +Cc: Michael Chan
In-Reply-To: <20090731191254.5470.99642.send-patch@aqua>
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for bnx2.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
This patch has not been tested, since I don't have the hardware to test it.
It is based on a few recent patches. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
drivers/net/bnx2.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index b70cc99..7bdefe2 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -8188,6 +8188,11 @@ static pci_ers_result_t bnx2_io_error_detected(struct pci_dev *pdev,
rtnl_lock();
netif_device_detach(dev);
+ if (state == pci_channel_io_perm_failure) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
if (netif_running(dev)) {
bnx2_netif_stop(bp);
del_timer_sync(&bp->timer);
^ permalink raw reply related
* [net-next-2.6 PATCH 0/9] return PCI_ERS_RESULT_DISCONNECT on permanent failure
From: Dean Nelson @ 2009-07-31 19:12 UTC (permalink / raw)
To: netdev
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure.
There have been a few of this type of net driver that have recently been
modified to address this issue. See the following commits:
http://git.kernel.org/linus/c93b5a76d58656158d195a7df507ebc660010969
http://git.kernel.org/linus/eab633021c26025b34f36f79f0311d3d99f40ceb
http://git.kernel.org/linus/ef681ce1e8b3e63317cd724c200b2fd39286c005
http://git.kernel.org/linus/59ed6eecff4aa00c5c5d18ffd180acac108d596e
http://git.kernel.org/linus/3044b8d1ff8c05237652a692fb572a34e4d70146
This patchset is an attempt to address the remaining net drivers of this type.
None of the patches in this patchset have been tested, since I don't have the
hardware to test any of them. I'm simply making these patches available for
whomever is interested and able to test them, to do so. Perhaps the individual
patches can be committed as they get tested, reviewed and ACK'd.
Apologies in advance if I'm not Cc'ng the correct maintainers of these drivers.
Thanks,
Dean
^ permalink raw reply
* Re: Short Notices
From: Werley David @ 2009-07-31 19:00 UTC (permalink / raw)
To: lg
You have just been awarded, 950.000.00 in the LG UK,send us your
Names
Address
Sex/Tel
^ permalink raw reply
* Re: [PATCH] pcnet32: VLB support fixes
From: Don Fry @ 2009-07-31 18:45 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: netdev, linux-kernel, Dan Carpenter, corbet, eteo, Julia Lawall
In-Reply-To: <200907302317.52648.bzolnier@gmail.com>
Acked-by: Don Fry <pcnet32@verizon.net>
---
I do not have any VLB hardware to test this, which is why I probably
introduced the error in 2004/5.
-----Original Message-----
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Don Fry <pcnet32@verizon.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Dan Carpenter
<error27@gmail.com>, corbet@lwn.net, eteo@redhat.com, Julia Lawall
<julia@diku.dk>
Subject: [PATCH] pcnet32: VLB support fixes
Date: Thu, 30 Jul 2009 23:17:52 +0200
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pcnet32: VLB support fixes
VLB support has been broken since at least 2004-2005 period as some
changes introduced back then assumed that ->pci_dev is always valid,
lets try to fix it:
- remove duplicated SET_NETDEV_DEV() call
- call SET_NETDEV_DEV() only for PCI devices
- check for ->pci_dev validity in pcnet32_open()
[ Alternatively we may consider removing VLB support but there would not
be much gain in it since an extra driver code needed for VLB support is
minimal and quite simple. ]
This takes care of the following entry from Dan's list:
drivers/net/pcnet32.c +1889 pcnet32_probe1(298) warning: variable derefenced before check 'pdev'
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: corbet@lwn.net
Cc: eteo@redhat.com
Cc: Julia Lawall <julia@diku.dk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
PS I still keep the original cc: list from the smatch thread -- please let
me know if you don't want to be spammed.. ;-)
drivers/net/pcnet32.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
Index: b/drivers/net/pcnet32.c
===================================================================
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -1719,7 +1719,9 @@ pcnet32_probe1(unsigned long ioaddr, int
ret = -ENOMEM;
goto err_release_region;
}
- SET_NETDEV_DEV(dev, &pdev->dev);
+
+ if (pdev)
+ SET_NETDEV_DEV(dev, &pdev->dev);
if (pcnet32_debug & NETIF_MSG_PROBE)
printk(KERN_INFO PFX "%s at %#3lx,", chipname, ioaddr);
@@ -1818,7 +1820,6 @@ pcnet32_probe1(unsigned long ioaddr, int
spin_lock_init(&lp->lock);
- SET_NETDEV_DEV(dev, &pdev->dev);
lp->name = chipname;
lp->shared_irq = shared;
lp->tx_ring_size = TX_RING_SIZE; /* default tx ring size */
@@ -2089,6 +2090,7 @@ static void pcnet32_free_ring(struct net
static int pcnet32_open(struct net_device *dev)
{
struct pcnet32_private *lp = netdev_priv(dev);
+ struct pci_dev *pdev = lp->pci_dev;
unsigned long ioaddr = dev->base_addr;
u16 val;
int i;
@@ -2149,9 +2151,9 @@ static int pcnet32_open(struct net_devic
lp->a.write_csr(ioaddr, 124, val);
/* Allied Telesyn AT 2700/2701 FX are 100Mbit only and do not negotiate */
- if (lp->pci_dev->subsystem_vendor == PCI_VENDOR_ID_AT &&
- (lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2700FX ||
- lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2701FX)) {
+ if (pdev && pdev->subsystem_vendor == PCI_VENDOR_ID_AT &&
+ (pdev->subsystem_device == PCI_SUBDEVICE_ID_AT_2700FX ||
+ pdev->subsystem_device == PCI_SUBDEVICE_ID_AT_2701FX)) {
if (lp->options & PCNET32_PORT_ASEL) {
lp->options = PCNET32_PORT_FD | PCNET32_PORT_100;
if (netif_msg_link(lp))
^ permalink raw reply
* Re: [PATCH] pcnet32: remove superfluous NULL pointer check in pcnet32_probe1()
From: Don Fry @ 2009-07-31 18:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: netdev, linux-kernel, Dan Carpenter, corbet, eteo, Julia Lawall
In-Reply-To: <200907302319.18150.bzolnier@gmail.com>
Acked-by: Don Fry <pcnet32@verizon.net>
-----Original Message-----
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Don Fry <pcnet32@verizon.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Dan Carpenter
<error27@gmail.com>, corbet@lwn.net, eteo@redhat.com, Julia Lawall
<julia@diku.dk>
Subject: [PATCH] pcnet32: remove superfluous NULL pointer check in
pcnet32_probe1()
Date: Thu, 30 Jul 2009 23:19:17 +0200
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pcnet32: remove superfluous NULL pointer check in pcnet32_probe1()
Move the debug printk() into the proper place and remove superfluous
NULL pointer check in pcnet32_probe1().
This takes care of the following entry from Dan's list:
drivers/net/pcnet32.c +1889 pcnet32_probe1(298) warning: variable derefenced before check 'pdev'
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: corbet@lwn.net
Cc: eteo@redhat.com
Cc: Julia Lawall <julia@diku.dk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/net/pcnet32.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
Index: b/drivers/net/pcnet32.c
===================================================================
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -1611,8 +1611,11 @@ pcnet32_probe1(unsigned long ioaddr, int
if (pcnet32_dwio_read_csr(ioaddr, 0) == 4
&& pcnet32_dwio_check(ioaddr)) {
a = &pcnet32_dwio;
- } else
+ } else {
+ if (pcnet32_debug & NETIF_MSG_PROBE)
+ printk(KERN_ERR PFX "No access methods\n");
goto err_release_region;
+ }
}
chip_version =
@@ -1853,12 +1856,6 @@ pcnet32_probe1(unsigned long ioaddr, int
((cards_found >= MAX_UNITS) || full_duplex[cards_found]))
lp->options |= PCNET32_PORT_FD;
- if (!a) {
- if (pcnet32_debug & NETIF_MSG_PROBE)
- printk(KERN_ERR PFX "No access methods\n");
- ret = -ENODEV;
- goto err_free_consistent;
- }
lp->a = *a;
/* prior to register_netdev, dev->name is not yet correct */
@@ -1974,14 +1971,13 @@ pcnet32_probe1(unsigned long ioaddr, int
return 0;
- err_free_ring:
+err_free_ring:
pcnet32_free_ring(dev);
- err_free_consistent:
pci_free_consistent(lp->pci_dev, sizeof(*lp->init_block),
lp->init_block, lp->init_dma_addr);
- err_free_netdev:
+err_free_netdev:
free_netdev(dev);
- err_release_region:
+err_release_region:
release_region(ioaddr, PCNET32_TOTAL_SIZE);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-31 18:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090731130243.GA31058@gondor.apana.org.au>
On Fri, Jul 31, 2009 at 09:02:43PM +0800, Herbert Xu wrote:
> On Fri, Jul 31, 2009 at 08:56:54AM -0400, Neil Horman wrote:
> >
> > > tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
> >
> > Oh, goodness, thats just asking for disaster. Setting asside the netpoll issue
> > for the moment, what if we take an rx interrupt on a cpu while in the middle of
> > sending a frame? Whats to stop the NET_RX_SOFTIRQ after the hard interrupt and
> > recursively taking the _xmit_lock? With or without netpoll, that seems prone to
> > deadlock.
>
> No that can't happen because BH is disabled in the xmit function.
>
> This problem is specific to netpoll because it does things that
> normally can't happen with BH off.
>
Ugh, you're right, my bad.
In fact, looking back, we had a similar problem (but not identical) in RHEL, in
which the netpoll path was removing the device from the poll_list from a
different cpu, leading to a double free. I fixed it by adding a state bit to
the napi flags that let helper functions know that we were in a netpoll context,
which let us avoid doing stupid things. Perhaps such a solution might be
usefull here. Set the flag when calling the poll routine from a netpoll
context, so napi_tx_lock, would know to do a trylock and always return success
or something of that nature.
I'd also be up for simply ripping out netpoll entirely..... ;)
Neil
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: Bandwidth of NIC bonding/trunking
From: Jay Vosburgh @ 2009-07-31 17:29 UTC (permalink / raw)
To: Sumedha Gupta; +Cc: netdev
In-Reply-To: <869c36e20907310640m41163a2j57198d8ea5e91ba0@mail.gmail.com>
Sumedha Gupta <2sumedha@gmail.com> wrote:
>I configured bonding/trunking on a Netgear GS724TR switch. I am using
>a 4-port NIC card using Intel Corporation 82571EB ethernet controller
>on machine X with all four ports connected to the switch. There are
>four client machines (A, B, C, D) also connected to the switch.
>iperf is running on machine X as a server and machines A, B, C, D are
>running as iperf clients:
A lot of this is explained in the bonding.txt documentation that
comes with the kernel source; there's probably more detail there on some
of this.
>With round robin, I consistently get:
> Interval Transfer Bandwidth
> 0.0-10.0 sec 992 MBytes 831 Mbits/sec
> 0.0-10.0 sec 989 MBytes 828 Mbits/sec
> 0.0-10.0 sec 1019 MBytes 854 Mbits/sec
> 0.0-10.0 sec 965 MBytes 808 Mbits/sec
The danger of round-robin (balance-rr mode) is that it generally
delivers packets out of order. This will irritate TCP's congestion
control (which can be moderated via the net.ipv6.tcp_reordering sysctl),
causing reduced throughput and inefficient use of the media. Also, UDP
or other protocol users must be able to tolerate out of order delivery.
>However with XOR, I am not getting enough bandwidth:
> 0.0-10.0 sec 619 MBytes 519 Mbits/sec
> 0.0-10.0 sec 398 MBytes 333 Mbits/sec
> 0.0-10.0 sec 338 MBytes 283 Mbits/sec
> 0.0-10.0 sec 612 MBytes 513 Mbits/sec
The xor (balance-xor mode) selects the slave to use according to
a hash. There are several hash algorithms available, the best is
generally the layer3+4, but, again, it's just math, and with a small
number of destinations relative to the number of slaves, you're fairly
likely to get traffic doubled up on the slaves. The available hashes
are described in detail in the bonding.txt file.
On the positive side, the balance-xor mode will not deliver
packets out of order.
>Similar results with transmit load balancing (tlb), 802.3ad, active
>backup and broadcast:
> 0.0-10.5 sec 421 MBytes 336 Mbits/sec
> 0.0-10.1 sec 323 MBytes 269 Mbits/sec
> 0.0-10.0 sec 301 MBytes 252 Mbits/sec
> 0.0-10.0 sec 405 MBytes 339 Mbits/sec
The balance-tlb mode does some semi-intelligent selection of the
transmitting slave according to the load. However, all reply traffic
comes in to one slave. Nothing is reordered.
The 802.3ad mode uses the same selection algorithms as
balance-xor, so again, you can select the best transmit hash policy.
Don't use broadcast. It just sends everything to every slave,
and I've never really figured out a rational use for it. Somebody,
somewhere, probably has some obscure use for it.
>Although, with adaptive load balancing I was constantly getting
>perfect bandwidth:
> 0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
> 0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
> 0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
> 0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
The balance-alb mode does the same thing as balance-tlb for
transmit, but it also uses tailored ARP messages to direct slaves to
respond to particular slaves. In your case, each peer (there are four)
is effectively assigned its own slave interface, so there's no
contention for the bandwidth.
Note that for -alb (and -tlb) the balancing is done according to
MAC address, so any hosts beyond a router will all be balanced together.
>I wanted to know if so much change with mode change in bonding is
>expected or did I configure something wrong in the switch which is
>causing xor, tlb, 802.3ad etc. to not work properly?
Variation is expected depending upon the workload; if one mode
was perfect for every configuration there wouldn't be so many.
Another factor for all modes is the switch's balancing of
traffic when sending back to the bond. For the balance-tlb and -alb
modes, the switch isn't involved. However, for the balance-rr,
balance-xor or 802.3ad modes, the switch has its own algorithm, usually
a hash of some kind, to direct packets to a particular port of the
etherchannel group (for -rr and -xor modes) or aggregator (for 802.3ad
mode, perhaps called LACP on the switch).
If the switch isn't configured for Etherchannel or 802.3ad /
LACP when running the equivalent bonding modes, then the return traffic
from the switch will not be balanced correctly.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] mISDN: Read buffer overflow
From: Karsten Keil @ 2009-07-31 14:28 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev, Andrew Morton, Andreas Eversberg
In-Reply-To: <4A72F51F.3000503@gmail.com>
On Freitag, 31. Juli 2009 15:43:59 Roel Kluin wrote:
Ouch !
Acked-by: Karsten Keil <keil@b1-systems.de>
> Check whether index is within bounds before testing the element.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> diff --git a/drivers/isdn/mISDN/l1oip_core.c
> b/drivers/isdn/mISDN/l1oip_core.c index c3b661a..7e5f30d 100644
> --- a/drivers/isdn/mISDN/l1oip_core.c
> +++ b/drivers/isdn/mISDN/l1oip_core.c
> @@ -1480,7 +1480,7 @@ l1oip_init(void)
> return -ENOMEM;
>
> l1oip_cnt = 0;
> - while (type[l1oip_cnt] && l1oip_cnt < MAX_CARDS) {
> + while (l1oip_cnt < MAX_CARDS && type[l1oip_cnt]) {
> switch (type[l1oip_cnt] & 0xff) {
> case 1:
> pri = 0;
^ permalink raw reply
* Confirmed Receipt
From: galecki @ 2009-07-31 13:57 UTC (permalink / raw)
To: uncl
Verify this mail by sending in your details.example your name, address, age, phone number etc to agentcharlie2@btinternet.com
^ permalink raw reply
* Confirmed Receipt
From: galecki @ 2009-07-31 13:57 UTC (permalink / raw)
To: uncl
Verify this mail by sending in your details.example your name, address, age, phone number etc to agentcharlie2@btinternet.com
^ permalink raw reply
* [PATCH] mISDN: Read buffer overflow
From: Roel Kluin @ 2009-07-31 13:43 UTC (permalink / raw)
To: isdn, netdev, Andrew Morton
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/isdn/mISDN/l1oip_core.c b/drivers/isdn/mISDN/l1oip_core.c
index c3b661a..7e5f30d 100644
--- a/drivers/isdn/mISDN/l1oip_core.c
+++ b/drivers/isdn/mISDN/l1oip_core.c
@@ -1480,7 +1480,7 @@ l1oip_init(void)
return -ENOMEM;
l1oip_cnt = 0;
- while (type[l1oip_cnt] && l1oip_cnt < MAX_CARDS) {
+ while (l1oip_cnt < MAX_CARDS && type[l1oip_cnt]) {
switch (type[l1oip_cnt] & 0xff) {
case 1:
pri = 0;
^ permalink raw reply related
* Bandwidth of NIC bonding/trunking
From: Sumedha Gupta @ 2009-07-31 13:40 UTC (permalink / raw)
To: netdev
I configured bonding/trunking on a Netgear GS724TR switch. I am using
a 4-port NIC card using Intel Corporation 82571EB ethernet controller
on machine X with all four ports connected to the switch. There are
four client machines (A, B, C, D) also connected to the switch.
iperf is running on machine X as a server and machines A, B, C, D are
running as iperf clients:
With round robin, I consistently get:
Interval Transfer Bandwidth
0.0-10.0 sec 992 MBytes 831 Mbits/sec
0.0-10.0 sec 989 MBytes 828 Mbits/sec
0.0-10.0 sec 1019 MBytes 854 Mbits/sec
0.0-10.0 sec 965 MBytes 808 Mbits/sec
However with XOR, I am not getting enough bandwidth:
0.0-10.0 sec 619 MBytes 519 Mbits/sec
0.0-10.0 sec 398 MBytes 333 Mbits/sec
0.0-10.0 sec 338 MBytes 283 Mbits/sec
0.0-10.0 sec 612 MBytes 513 Mbits/sec
Similar results with transmit load balancing (tlb), 802.3ad, active
backup and broadcast:
0.0-10.5 sec 421 MBytes 336 Mbits/sec
0.0-10.1 sec 323 MBytes 269 Mbits/sec
0.0-10.0 sec 301 MBytes 252 Mbits/sec
0.0-10.0 sec 405 MBytes 339 Mbits/sec
Although, with adaptive load balancing I was constantly getting
perfect bandwidth:
0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
0.0-10.0 sec 1.09 GBytes 937 Mbits/sec
I wanted to know if so much change with mode change in bonding is
expected or did I configure something wrong in the switch which is
causing xor, tlb, 802.3ad etc. to not work properly?
Thanks,
Sumedha
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 13:02 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090731125654.GB18303@hmsreliant.think-freely.org>
On Fri, Jul 31, 2009 at 08:56:54AM -0400, Neil Horman wrote:
>
> > tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
>
> Oh, goodness, thats just asking for disaster. Setting asside the netpoll issue
> for the moment, what if we take an rx interrupt on a cpu while in the middle of
> sending a frame? Whats to stop the NET_RX_SOFTIRQ after the hard interrupt and
> recursively taking the _xmit_lock? With or without netpoll, that seems prone to
> deadlock.
No that can't happen because BH is disabled in the xmit function.
This problem is specific to netpoll because it does things that
normally can't happen with BH off.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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