* [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
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-31 12:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090731013017.GB25895@gondor.apana.org.au>
On Fri, Jul 31, 2009 at 09:30:17AM +0800, Herbert Xu wrote:
> On Wed, Jul 29, 2009 at 09:06:39PM -0400, Neil Horman wrote:
> >
> > but nothing in that path takes the xmit_lock. The poll_lock is taken in that
> > patch, but thats for recieve_side syncronization, not transmit side. Nothing in
> > the tg3 driver (to use your example), that I can see takes the xmit_lock in the
> > rx path either, so I'm not really sure where you comming from here.
>
> 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.
Neil
> --
> 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: neigh_periodic_timer expires too often
From: Eric Dumazet @ 2009-07-31 12:50 UTC (permalink / raw)
To: Luciano Coelho; +Cc: netdev@vger.kernel.org, Kristo Tero (Nokia-D/Tampere)
In-Reply-To: <4A72E204.3050704@nokia.com>
Luciano Coelho a écrit :
> Coelho Luciano (Nokia-D/Helsinki) wrote:
>> ext Eric Dumazet wrote:
>>
>>> So please test it and tell me/us you like it :)
>>>
>>
>> I applied your patch on top of the 2.6.28 I'm using and will start
>> testing it now. I can also try to test it on top of 2.6.31-rc4 plus
>> wireless-testing stuff, if needed.
>>
>> I'll tell you that I liked your patch in a moment (I actually already
>> liked it, but I'll wait until I know it works before I tell you ;)
>>
>
> Just a small update. We have run some very basic tests with 2.6.28.
> The patch seems to work fine and we don't see excessive wake-ups from
> neigh anymore (thanks Tero for helping with the tests). We will still
> run one of our full release test rounds in order to make sure that there
> are no regressions. I'll let you know when we have some more results.
>
Thanks for the update, I am running this patch on net-next-2.6 with no problem.
An 'easy' way to count how many time gc fired is to look at 10th columns of /proc/net/stat/arp_cache :
$ cat /proc/net/stat/arp_cache ; cat /proc/uptime ; sleep 150 ; cat /proc/net/stat/arp_cache
entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs unresolved_discards
000000fd 00000059 0000050e 00000001 00004552 0000032b 00000022 00000000 00000000 000013e5 00000000 00000000
000000fd 000000df 00000003 00000002 000005a5 0000014d 00000010 00000000 00000000 00000000 00000000 00000000
000000fd 000000cb 00000000 00000000 0000054f 00000141 00000011 00000000 00000000 00000000 00000000 00000000
000000fd 000000b2 00000000 00000001 000005ec 000001d7 0000001d 00000000 00000000 00000000 00000000 00000004
000000fd 000000de 00000000 00000001 000005f7 0000019b 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000e5 00000000 00000000 000005db 0000018e 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000d3 00000000 00000002 000005e4 0000018a 00000024 00000000 00000000 00000000 00000000 00000000
000000fd 000000c3 00000000 00000000 000005ba 000001a0 00000025 00000000 00000000 00000000 00000000 00000000
79173.78 0.31
entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs unresolved_discards
000000fd 00000059 0000050f 00000001 00004569 00000342 00000022 00000000 00000000 000013ee 00000000 00000000
000000fd 000000df 00000003 00000002 000005a8 00000150 00000010 00000000 00000000 00000000 00000000 00000000
000000fd 000000cb 00000000 00000000 00000550 00000142 00000011 00000000 00000000 00000000 00000000 00000000
000000fd 000000b2 00000000 00000001 000005ed 000001d8 0000001d 00000000 00000000 00000000 00000000 00000004
000000fd 000000de 00000000 00000001 000005f8 0000019c 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000e6 00000000 00000000 000005df 00000190 00000027 00000000 00000000 00000000 00000000 00000000
000000fd 000000d3 00000000 00000002 000005e6 0000018c 00000024 00000000 00000000 00000000 00000000 00000000
000000fd 000000c3 00000000 00000000 000005bc 000001a1 00000025 00000000 00000000 00000000 00000000 00000000
In a 150 second interval, it was fired 10 times, even with a 256 slots hash table,
instead of 2560 times with pristine kernel.
On my dev machine, neigh_timer_handler is now at the bottom of powertop :)
Wakeups-from-idle per second : 2.5 interval: 10.0s
no ACPI power usage estimate available
Top causes for wakeups:
24.0% ( 4.0) <kernel core> : usb_hcd_poll_rh_status (rh_timer_func)
18.6% ( 3.1) <kernel core> : bnx2_timer (bnx2_timer)
12.0% ( 2.0) <kernel core> : clocksource_watchdog (clocksource_watchdog)
6.0% ( 1.0) <kernel core> : tg3_timer (tg3_timer)
6.0% ( 1.0) bond0 : queue_delayed_work (delayed_work_timer_fn)
6.0% ( 1.0) ntpd : hrtimer_start_range_ns (it_real_fn)
6.0% ( 1.0) <kernel core> : run_timer_softirq (htable_gc)
5.4% ( 0.9) hpsmhd : hrtimer_start_range_ns (hrtimer_wakeup)
3.0% ( 0.5) <interrupt> : cciss0
2.4% ( 0.4) <kernel core> : dev_watchdog (dev_watchdog)
1.8% ( 0.3) <kernel core> : queue_delayed_work (delayed_work_timer_fn)
1.2% ( 0.2) <(null)> : (hrtimer_wakeup)
1.2% ( 0.2) master : start_this_handle (commit_timeout)
1.2% ( 0.2) snmptrapd : hrtimer_start_range_ns (hrtimer_wakeup)
1.2% ( 0.2) pdflush : wb_kupdate (wb_timer_fn)
0.6% ( 0.1) <interrupt> : eth0
0.6% ( 0.1) master : hrtimer_start_range_ns (hrtimer_wakeup)
0.6% ( 0.1) ntpd : blk_plug_device (blk_unplug_timeout)
0.6% ( 0.1) syslogd : hrtimer_start (it_real_fn)
0.6% ( 0.1) init : hrtimer_start_range_ns (hrtimer_wakeup)
0.6% ( 0.1) ntpd : start_this_handle (commit_timeout)
0.6% ( 0.1) <kernel core> : neigh_timer_handler (neigh_timer_handler)
^ permalink raw reply
* Re: neigh_periodic_timer expires too often
From: Luciano Coelho @ 2009-07-31 12:22 UTC (permalink / raw)
To: ext Eric Dumazet; +Cc: netdev@vger.kernel.org, Kristo Tero (Nokia-D/Tampere)
In-Reply-To: <4A71AF1D.9020000@nokia.com>
Coelho Luciano (Nokia-D/Helsinki) wrote:
> ext Eric Dumazet wrote:
>
>> So please test it and tell me/us you like it :)
>>
>>
>
> I applied your patch on top of the 2.6.28 I'm using and will start
> testing it now. I can also try to test it on top of 2.6.31-rc4 plus
> wireless-testing stuff, if needed.
>
> I'll tell you that I liked your patch in a moment (I actually already
> liked it, but I'll wait until I know it works before I tell you ;)
>
Just a small update. We have run some very basic tests with 2.6.28.
The patch seems to work fine and we don't see excessive wake-ups from
neigh anymore (thanks Tero for helping with the tests). We will still
run one of our full release test rounds in order to make sure that there
are no regressions. I'll let you know when we have some more results.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] vlan: allow creating vlan when real device is not up
From: Patrick McHardy @ 2009-07-31 12:16 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20090730.131710.208062164.davem@davemloft.net>
David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 30 Jul 2009 11:23:21 -0700
>
>> There is no reason for the arbitrary restriction that device must be
>> up to create a vlan. This patch was added to Vyatta kernel to resolve startup
>> ordering issues where vlan's are created but real device was disabled.
>>
>> Note: the vlan already correctly inherits the operstate from real device; so
>> if vlan is created and real device is marked down, the vlan is marked
>> down.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Looks fine, added to net-next-2.6
>
> We can revert if Patrick or someone else finds a potential problem
> with allowing this.
It seems perfectly fine to me, we can get to the same state by
setting the lower device down after creating the VLAN device.
^ 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