* Re: [PATCH] can: ti_hecc: Fix unintialized variable
From: David Miller @ 2011-08-26 16:51 UTC (permalink / raw)
To: abhilash.kv; +Cc: netdev, wg, linux-kernel, =linux-omap
In-Reply-To: <1314104748-16424-1-git-send-email-abhilash.kv@ti.com>
From: Abhilash K V <abhilash.kv@ti.com>
Date: Tue, 23 Aug 2011 18:35:48 +0530
> In ti_hecc_xmit(), local variable "data" is not initialized before
> being used.
> This initialization got inadvertently removed in the following patch:
>
> can: Unify droping of invalid tx skbs and netdev stats
>
> Acked-by: Anant Gole <anantgole@ti.com>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2x: resurrect RX hashing
From: David Miller @ 2011-08-26 16:51 UTC (permalink / raw)
To: mschmidt; +Cc: netdev, vladz, eilong, dmitry, mirq-linux
In-Reply-To: <20110823161530.24707.67923.stgit@dhcp-29-224.brq.redhat.com>
From: Michal Schmidt <mschmidt@redhat.com>
Date: Tue, 23 Aug 2011 18:15:32 +0200
> bnx2x used to be able to set rxhash, but this was lost in the conversion
> to hw_features (commit 66371c441).
> Restore it and enable it by default.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add new PHY BCM54616
From: David Miller @ 2011-08-26 16:51 UTC (permalink / raw)
To: yanivr; +Cc: eilong, netdev
In-Reply-To: <1314117204.28819.13.camel@lb-tlvb-dmitry>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Tue, 23 Aug 2011 19:33:24 +0300
> The BCM54616 PHY is very similar to the 54618SE, only without EEE support, which will not be activated due to querying the actual PHY type.
> This check is already done by reading a dedicated PHY register.
>
> Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [patch -next] bna: unlock on error path in pnad_pci_probe()
From: David Miller @ 2011-08-26 16:51 UTC (permalink / raw)
To: error27; +Cc: rmody, ddutt, netdev, kernel-janitors
In-Reply-To: <20110824112922.GC5975@shale.localdomain>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 24 Aug 2011 14:29:22 +0300
> We introduced a new lock here, so there was error path which needs
> an unlock now.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] cassini: init before use in cas_interruptN.
From: David Miller @ 2011-08-26 16:52 UTC (permalink / raw)
To: romieu; +Cc: thomas.jarosch, netdev
In-Reply-To: <20110825150249.GA21897@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 25 Aug 2011 17:02:49 +0200
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Spotted-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Applied, thanks!
> David, any opinion regarding the removal of the USE_NAPI #ifdef
> in this driver ?
No objections to removing it.
^ permalink raw reply
* Re: [patch -next] bna: off by one in bfa_msgq_rspq_pi_update()
From: David Miller @ 2011-08-26 16:51 UTC (permalink / raw)
To: error27; +Cc: rmody, ddutt, netdev, kernel-janitors
In-Reply-To: <20110824113028.GD5975@shale.localdomain>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 24 Aug 2011 14:30:28 +0300
> The rspq->rsphdlr[] array has BFI_MC_MAX elements, so this test was
> off by one.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net_sched: sfb: optimize enqueue on full queue
From: David Miller @ 2011-08-26 16:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1314289292.2387.45.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 25 Aug 2011 18:21:32 +0200
> In case SFB queue is full (hard limit reached), there is no point
> spending time to compute hash and maximum qlen/p_mark.
>
> We instead just early drop packet.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: Traffic shaping - class ID 16bit limit?
From: David Miller @ 2011-08-26 16:53 UTC (permalink / raw)
To: exa.exa; +Cc: shemminger, netdev
In-Reply-To: <CAO0uZ+_6xC0gymfbu28PRK4SaVgkGaSbbe-PgXvZ4h-cPp8k2A@mail.gmail.com>
From: Miroslav Kratochvil <exa.exa@gmail.com>
Date: Thu, 25 Aug 2011 19:06:58 +0200
>>> Technically the ClassID seems to be "hardcoded" as a 16bit value, but
>>> after some source searching, I haven't found any good reason for it to
>>> be 16-bit only.
>>
>> Granted it was a poor choice in the initial design.
>> It is wired into the API and changing it would be quite painful.
>>
>
> I was feeling something like that would come.
>
> If I get it correctly, the API change would consist of:
>
> - some netlink protocol change
> - slight modification of qdisc_class_hash
> - modifications in all (four?) hierarchical schedulers
> - tiny expansion of userspace tc utility
There is precedence as we had to make the routing table rule ID larger
and were successfully able to do so using netlink attributes.
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000: save skb counts in TX to avoid cache misses
From: David Miller @ 2011-08-26 16:55 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: dnelson, netdev, andy
In-Reply-To: <1314330760.2097.39.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Aug 2011 20:52:39 -0700
> On Thu, 2011-08-25 at 17:39 -0700, Dean Nelson wrote:
>> Virtual Machines with emulated e1000 network adapter running on
>> Parallels'
>> server were seeing kernel panics due to the e1000 driver dereferencing
>> an
>> unexpected NULL pointer retrieved from buffer_info->skb.
>>
>> The problem has been addressed for the e1000e driver, but not for the
>> e1000.
>> Since the two drivers share similar code in the affected area, a port
>> of the
>> following e1000e driver commit solves the issue for the e1000 driver:
>>
>> commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
>> Author: Tom Herbert <therbert@google.com>
>> Date: Wed May 5 14:02:27 2010 +0000
>>
>> e1000e: save skb counts in TX to avoid cache misses
>>
>> In e1000_tx_map, precompute number of segements and bytecounts
>> which
>> are derived from fields in skb; these are stored in buffer_info.
>> When
>> cleaning tx in e1000_clean_tx_irq use the values in the associated
>> buffer_info for statistics counting, this eliminates cache misses
>> on skb fields.
>>
>>
>> Signed-off-by: Dean Nelson <dnelson@redhat.com>
>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* [patch 1/2] 9p: move dereference after NULL check
From: Dan Carpenter @ 2011-08-26 16:55 UTC (permalink / raw)
To: Eric Van Hensbergen
Cc: David S. Miller, Venkateswararao Jujjuri, Aneesh Kumar K.V,
M. Mohan Kumar, open list:NETWORKING [GENERAL], kernel-janitors
We dereferenced "req->tc" and "req->rc" before checking for NULL.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/9p/client.c b/net/9p/client.c
index 3f8c046..b0bcace 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -248,10 +248,8 @@ static struct p9_req_t *p9_tag_alloc(struct p9_client *c, u16 tag, int max_size)
init_waitqueue_head(req->wq);
req->tc = kmalloc(sizeof(struct p9_fcall) + alloc_msize,
GFP_NOFS);
- req->tc->capacity = alloc_msize;
req->rc = kmalloc(sizeof(struct p9_fcall) + alloc_msize,
GFP_NOFS);
- req->rc->capacity = alloc_msize;
if ((!req->tc) || (!req->rc)) {
printk(KERN_ERR "Couldn't grow tag array\n");
kfree(req->tc);
@@ -261,6 +259,8 @@ static struct p9_req_t *p9_tag_alloc(struct p9_client *c, u16 tag, int max_size)
req->wq = NULL;
return ERR_PTR(-ENOMEM);
}
+ req->tc->capacity = alloc_msize;
+ req->rc->capacity = alloc_msize;
req->tc->sdata = (char *) req->tc + sizeof(struct p9_fcall);
req->rc->sdata = (char *) req->rc + sizeof(struct p9_fcall);
}
^ permalink raw reply related
* [patch 2/2] 9p: change an int to unsigned int
From: Dan Carpenter @ 2011-08-26 16:57 UTC (permalink / raw)
To: Eric Van Hensbergen
Cc: David S. Miller, Venkateswararao Jujjuri (JV), Aneesh Kumar K.V,
M. Mohan Kumar, Stephen Hemminger, open list:NETWORKING [GENERAL],
kernel-janitors
The size of things should be unsigned because negative sizes are
silly. My concern is the the limit checks don't take negative values
into consideration in p9_client_create()
if (clnt->msize > clnt->trans_mod->maxsize)
clnt->msize = clnt->trans_mod->maxsize;
and in p9_tag_alloc()
int alloc_msize = min(c->msize, max_size);
I don't know if this is exported to user space? Hopefully it's not
too late to change this.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/include/net/9p/client.h b/include/net/9p/client.h
index 55ce72c..d479d7d 100644
--- a/include/net/9p/client.h
+++ b/include/net/9p/client.h
@@ -151,7 +151,7 @@ struct p9_req_t {
struct p9_client {
spinlock_t lock; /* protect client structure */
- int msize;
+ unsigned int msize;
unsigned char proto_version;
struct p9_trans_module *trans_mod;
enum p9_trans_status status;
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Duplication of #define with mii.h.
From: David Miller @ 2011-08-26 17:13 UTC (permalink / raw)
To: romieu; +Cc: netdev
In-Reply-To: <20110825092019.GA21777@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 25 Aug 2011 11:20:19 +0200
> Please pull from branch 'davem-next.mii' in repository
>
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git davem-next.mii
>
> to get the changes below.
>
> The sunbmac changes are not compile tested. Sunbmac changeset is on top of the
> stack so it can be instantly removed if untrusted. Building a packaged rpm for a
> cross sparc-linux compiler quickly turned more interesting than expected.
I'll pull this and sanity check the build on sparc, thanks!
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Michał Mirosław @ 2011-08-26 18:41 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, David S. Miller, Ben Hutchings, Jeff Kirsher
In-Reply-To: <4E569CC8.9040605@candelatech.com>
On Thu, Aug 25, 2011 at 12:04:40PM -0700, Ben Greear wrote:
> On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> >v3 of a feature handling cleanup and extension series. For testing, you
> >might want user-space ethtool patched with:
> >http://patchwork.ozlabs.org/patch/96374/
> It looks like this is not in net-next yet...any hope of this
> going in soon?
It's because the series depends on finishing conversions of all drivers
to ndo_fix/set_features. e1000e, igbvf, ixgb, ixgbevf are pending.
BTW, Jeff, what is the status of those conversions? Last version of ixgbe
patch from Donald Skidmore (sent about a month ago) was mostly ready IIUC.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC PATCH] common receive API + r8169 use
From: Michał Mirosław @ 2011-08-26 18:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1312822029.2531.5.camel@edumazet-laptop>
On Mon, Aug 08, 2011 at 06:47:09PM +0200, Eric Dumazet wrote:
> Le mardi 02 août 2011 à 23:43 +0200, Michał Mirosław a écrit :
> > I don't have fast enough transmitter yet, so have no real data. Eric's
> > testing showed dramatic reduction in CPU usage after changing igb to use
> > build_skb(). Inlined version of this patch should give similar results.
> >
> > Eric: can you share the igb changes? I have no hardware for it, but could
> > merge our changes for you to test.
> I am just coming back from one vacation period, I'll send patches before
> another one, maybe tomorrow, stay tuned ;)
Still tuned in, but receiving no signal. ;-)
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH 2/3 net-next] cnic: Add timeout for ramrod replies.
From: Michael Chan @ 2011-08-26 19:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan
In-Reply-To: <1314387941-2126-1-git-send-email-mchan@broadcom.com>
If the bnx2x device has encountered parity errors, the chip will not DMA
any replies. Using wait_event_timeout() will allow us to make forward
progress and let bnx2x reset the chip.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
---
drivers/net/ethernet/broadcom/cnic.c | 17 ++++++++++-------
drivers/net/ethernet/broadcom/cnic.h | 2 ++
drivers/net/ethernet/broadcom/cnic_defs.h | 1 +
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 73060f4..6f10c69 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -1875,12 +1875,12 @@ static int cnic_bnx2x_destroy_ramrod(struct cnic_dev *dev, u32 l5_cid)
hw_cid, NONE_CONNECTION_TYPE, &l5_data);
if (ret == 0) {
- wait_event(ctx->waitq, ctx->wait_cond);
+ wait_event_timeout(ctx->waitq, ctx->wait_cond, CNIC_RAMROD_TMO);
if (unlikely(test_bit(CTX_FL_CID_ERROR, &ctx->ctx_flags)))
return -EBUSY;
}
- return ret;
+ return 0;
}
static int cnic_bnx2x_iscsi_destroy(struct cnic_dev *dev, struct kwqe *kwqe)
@@ -2428,17 +2428,20 @@ static int cnic_bnx2x_fcoe_destroy(struct cnic_dev *dev, struct kwqe *kwqe)
init_waitqueue_head(&ctx->waitq);
ctx->wait_cond = 0;
+ memset(&kcqe, 0, sizeof(kcqe));
+ kcqe.completion_status = FCOE_KCQE_COMPLETION_STATUS_ERROR;
memset(&l5_data, 0, sizeof(l5_data));
ret = cnic_submit_kwqe_16(dev, FCOE_RAMROD_CMD_ID_TERMINATE_CONN, cid,
FCOE_CONNECTION_TYPE, &l5_data);
if (ret == 0) {
- wait_event(ctx->waitq, ctx->wait_cond);
- set_bit(CTX_FL_DELETE_WAIT, &ctx->ctx_flags);
- queue_delayed_work(cnic_wq, &cp->delete_task,
- msecs_to_jiffies(2000));
+ wait_event_timeout(ctx->waitq, ctx->wait_cond, CNIC_RAMROD_TMO);
+ if (ctx->wait_cond)
+ kcqe.completion_status = 0;
}
- memset(&kcqe, 0, sizeof(kcqe));
+ set_bit(CTX_FL_DELETE_WAIT, &ctx->ctx_flags);
+ queue_delayed_work(cnic_wq, &cp->delete_task, msecs_to_jiffies(2000));
+
kcqe.op_code = FCOE_KCQE_OPCODE_DESTROY_CONN;
kcqe.fcoe_conn_id = req->conn_id;
kcqe.fcoe_conn_context_id = cid;
diff --git a/drivers/net/ethernet/broadcom/cnic.h b/drivers/net/ethernet/broadcom/cnic.h
index 15b1c09..3032809 100644
--- a/drivers/net/ethernet/broadcom/cnic.h
+++ b/drivers/net/ethernet/broadcom/cnic.h
@@ -474,5 +474,7 @@ struct bnx2x_bd_chain_next {
MAX_STAT_COUNTER_ID_E1))
#endif
+#define CNIC_RAMROD_TMO (HZ / 4)
+
#endif
diff --git a/drivers/net/ethernet/broadcom/cnic_defs.h b/drivers/net/ethernet/broadcom/cnic_defs.h
index e47d210..239de89 100644
--- a/drivers/net/ethernet/broadcom/cnic_defs.h
+++ b/drivers/net/ethernet/broadcom/cnic_defs.h
@@ -67,6 +67,7 @@
#define FCOE_KWQE_OPCODE_DESTROY (10)
#define FCOE_KWQE_OPCODE_STAT (11)
+#define FCOE_KCQE_COMPLETION_STATUS_ERROR (0x1)
#define FCOE_KCQE_COMPLETION_STATUS_CTX_ALLOC_FAILURE (0x3)
/* KCQ (kernel completion queue) response op codes */
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3 net-next] net: Define NETDEV_FCOE_WWNN, NETDEV_FCOE_WWPN only when CONFIG_LIBFCOE is enabled
From: Michael Chan @ 2011-08-26 19:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan, Yi Zou, Bhanu Prakash Gollapudi
In-Reply-To: <1314387941-2126-2-git-send-email-mchan@broadcom.com>
From: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
bnx2fc driver calls netdev->netdev_ops->ndo_fcoe_get_wwn() and it may not
be defined with the current Kconfig dependencies. ndo_fcoe_get_wwn is
dependent on CONFIG_FCOE, but bnx2fc does not select CONFIG_FCOE, as it does
not depend on fcoe driver. Since both fcoe and bnx2fc drivers select
CONFIG_LIBFCOE, define NETDEV_FCOE_WWNN and NETDEV_FCOE_WWPN when
CONFIG_LIBFCOE is defined.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Yi Zou <yi.zou@intel.com>
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
include/linux/netdevice.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 125f9fb..0a7f619 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -922,11 +922,15 @@ struct net_device_ops {
u16 xid,
struct scatterlist *sgl,
unsigned int sgc);
+#endif
+
+#if defined(CONFIG_LIBFCOE) || defined(CONFIG_LIBFCOE_MODULE)
#define NETDEV_FCOE_WWNN 0
#define NETDEV_FCOE_WWPN 1
int (*ndo_fcoe_get_wwn)(struct net_device *dev,
u64 *wwn, int type);
#endif
+
#ifdef CONFIG_RFS_ACCEL
int (*ndo_rx_flow_steer)(struct net_device *dev,
const struct sk_buff *skb,
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3 net-next] cnic, bnx2fc: Increase maximum FCoE sessions.
From: Michael Chan @ 2011-08-26 19:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan, Bhanu Prakash Gollapudi
Increase it to NVRAM configured limit or 1024 whichever is less.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
---
drivers/net/ethernet/broadcom/cnic.c | 14 ++++++++------
drivers/net/ethernet/broadcom/cnic.h | 2 +-
drivers/scsi/bnx2fc/bnx2fc.h | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 7698161..73060f4 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -1177,7 +1177,7 @@ static int cnic_alloc_bnx2x_resc(struct cnic_dev *dev)
cp->fcoe_start_cid = start_cid + MAX_ISCSI_TBL_SZ;
if (BNX2X_CHIP_IS_E2_PLUS(cp->chip_id)) {
- cp->max_cid_space += BNX2X_FCOE_NUM_CONNECTIONS;
+ cp->max_cid_space += dev->max_fcoe_conn;
cp->fcoe_init_cid = ethdev->fcoe_init_cid;
if (!cp->fcoe_init_cid)
cp->fcoe_init_cid = 0x10;
@@ -2280,7 +2280,7 @@ static int cnic_bnx2x_fcoe_ofld1(struct cnic_dev *dev, struct kwqe *wqes[],
*work = 4;
l5_cid = req1->fcoe_conn_id;
- if (l5_cid >= BNX2X_FCOE_NUM_CONNECTIONS)
+ if (l5_cid >= dev->max_fcoe_conn)
goto err_reply;
l5_cid += BNX2X_FCOE_L5_CID_BASE;
@@ -2384,7 +2384,7 @@ static int cnic_bnx2x_fcoe_disable(struct cnic_dev *dev, struct kwqe *kwqe)
req = (struct fcoe_kwqe_conn_enable_disable *) kwqe;
cid = req->context_id;
l5_cid = req->conn_id;
- if (l5_cid >= BNX2X_FCOE_NUM_CONNECTIONS)
+ if (l5_cid >= dev->max_fcoe_conn)
return -EINVAL;
l5_cid += BNX2X_FCOE_L5_CID_BASE;
@@ -2418,7 +2418,7 @@ static int cnic_bnx2x_fcoe_destroy(struct cnic_dev *dev, struct kwqe *kwqe)
req = (struct fcoe_kwqe_conn_destroy *) kwqe;
cid = req->context_id;
l5_cid = req->conn_id;
- if (l5_cid >= BNX2X_FCOE_NUM_CONNECTIONS)
+ if (l5_cid >= dev->max_fcoe_conn)
return -EINVAL;
l5_cid += BNX2X_FCOE_L5_CID_BASE;
@@ -4850,8 +4850,7 @@ static int cnic_start_bnx2x_hw(struct cnic_dev *dev)
return -ENOMEM;
if (BNX2X_CHIP_IS_E2_PLUS(cp->chip_id)) {
- ret = cnic_init_id_tbl(&cp->fcoe_cid_tbl,
- BNX2X_FCOE_NUM_CONNECTIONS,
+ ret = cnic_init_id_tbl(&cp->fcoe_cid_tbl, dev->max_fcoe_conn,
cp->fcoe_start_cid, 0);
if (ret)
@@ -5292,6 +5291,9 @@ static struct cnic_dev *init_bnx2x_cnic(struct net_device *dev)
!(ethdev->drv_state & CNIC_DRV_STATE_NO_FCOE))
cdev->max_fcoe_conn = ethdev->max_fcoe_conn;
+ if (cdev->max_fcoe_conn > BNX2X_FCOE_NUM_CONNECTIONS)
+ cdev->max_fcoe_conn = BNX2X_FCOE_NUM_CONNECTIONS;
+
memcpy(cdev->mac_addr, ethdev->iscsi_mac, 6);
cp->cnic_ops = &cnic_bnx2x_ops;
diff --git a/drivers/net/ethernet/broadcom/cnic.h b/drivers/net/ethernet/broadcom/cnic.h
index 7a2928f..15b1c09 100644
--- a/drivers/net/ethernet/broadcom/cnic.h
+++ b/drivers/net/ethernet/broadcom/cnic.h
@@ -373,7 +373,7 @@ struct bnx2x_bd_chain_next {
#define BNX2X_ISCSI_PBL_NOT_CACHED 0xff
#define BNX2X_ISCSI_PDU_HEADER_NOT_CACHED 0xff
-#define BNX2X_FCOE_NUM_CONNECTIONS 128
+#define BNX2X_FCOE_NUM_CONNECTIONS 1024
#define BNX2X_FCOE_L5_CID_BASE MAX_ISCSI_TBL_SZ
diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index 5613e8a..dd335a2 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++ b/drivers/scsi/bnx2fc/bnx2fc.h
@@ -81,7 +81,7 @@
#define BNX2FC_RQ_WQES_MAX 16
#define BNX2FC_CQ_WQES_MAX (BNX2FC_SQ_WQES_MAX + BNX2FC_RQ_WQES_MAX)
-#define BNX2FC_NUM_MAX_SESS 128
+#define BNX2FC_NUM_MAX_SESS 1024
#define BNX2FC_NUM_MAX_SESS_LOG (ilog2(BNX2FC_NUM_MAX_SESS))
#define BNX2FC_MAX_OUTSTANDING_CMNDS 2048
--
1.7.1
^ permalink raw reply related
* [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: Maciej Żenczykowski @ 2011-08-26 21:56 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller
Cc: netdev, Hideaki YOSHIFUJI, Maciej Żenczykowski, Erik Kline,
Lorenzo Colitti
From: Maciej Żenczykowski <maze@google.com>
Allow transparent sockets to be less restrictive about
the source ip of ipv6 udp packets being sent.
Google-Bug-Id: 5018138
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: "Erik Kline" <ek@google.com>
CC: "Lorenzo Colitti" <lorenzo@google.com>
---
include/net/transp_v6.h | 1 +
net/ipv6/datagram.c | 5 +++--
net/ipv6/ip6_flowlabel.c | 2 +-
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/raw.c | 2 +-
net/ipv6/udp.c | 2 +-
6 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 5271a74..498433d 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -39,6 +39,7 @@ extern int datagram_recv_ctl(struct sock *sk,
struct sk_buff *skb);
extern int datagram_send_ctl(struct net *net,
+ struct sock *sk,
struct msghdr *msg,
struct flowi6 *fl6,
struct ipv6_txoptions *opt,
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 9ef1831..03e20fa 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -599,7 +599,7 @@ int datagram_recv_ctl(struct sock *sk, struct msghdr *msg, struct sk_buff *skb)
return 0;
}
-int datagram_send_ctl(struct net *net,
+int datagram_send_ctl(struct net *net, struct sock *sk,
struct msghdr *msg, struct flowi6 *fl6,
struct ipv6_txoptions *opt,
int *hlimit, int *tclass, int *dontfrag)
@@ -658,7 +658,8 @@ int datagram_send_ctl(struct net *net,
if (addr_type != IPV6_ADDR_ANY) {
int strict = __ipv6_addr_src_scope(addr_type) <= IPV6_ADDR_SCOPE_LINKLOCAL;
- if (!ipv6_chk_addr(net, &src_info->ipi6_addr,
+ if (!(sk && inet_sk(sk)->transparent) &&
+ !ipv6_chk_addr(net, &src_info->ipi6_addr,
strict ? dev : NULL, 0))
err = -EINVAL;
else
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index f3caf1b..a896987 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -360,7 +360,7 @@ fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
msg.msg_control = (void*)(fl->opt+1);
memset(&flowi6, 0, sizeof(flowi6));
- err = datagram_send_ctl(net, &msg, &flowi6, fl->opt, &junk,
+ err = datagram_send_ctl(net, NULL, &msg, &flowi6, fl->opt, &junk,
&junk, &junk);
if (err)
goto done;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 147ede38..2fbda5f 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -475,7 +475,7 @@ sticky_done:
msg.msg_controllen = optlen;
msg.msg_control = (void*)(opt+1);
- retv = datagram_send_ctl(net, &msg, &fl6, opt, &junk, &junk,
+ retv = datagram_send_ctl(net, sk, &msg, &fl6, opt, &junk, &junk,
&junk);
if (retv)
goto done;
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index f34902f..131be5e 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -817,7 +817,7 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(struct ipv6_txoptions);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt, &hlimit,
&tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 35bbdc4..b0fb25c 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1090,7 +1090,7 @@ do_udp_sendmsg:
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(*opt);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt, &hlimit,
&tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
--
1.7.3.1
^ permalink raw reply related
* Re: [Bugme-new] [Bug 40372] New: Driver pegasus freeze networking very often so one must reboot to get it to work again
From: Andrew Morton @ 2011-08-26 22:00 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r, Petko Manolov,
csanyipal-Re5JQEeQqe8AvxtiuMwx3w, jmm-8fiUuRrzOP0dnm+yROfE0A
In-Reply-To: <bug-40372-10286-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 31 Jul 2011 20:05:09 GMT
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=40372
>
> Summary: Driver pegasus freeze networking very often so one
> must reboot to get it to work again
> Product: Drivers
> Version: 2.5
> Kernel Version: Linux 2.6.38-2-486 #1 Sun May 8 14:04:15 UTC 2011 i586
> GNU/Linux
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: blocking
> Priority: P1
> Component: Network
> AssignedTo: drivers_network-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
> ReportedBy: csanyipal-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> CC: jmm-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org
> Regression: No
>
>
> Hi,
>
> the driver pegasus freezes networking often so one must to reboot to get
> networking work again.
>
> At reboot the system hang.
>
> At this point one must press the Reset button of the PC Box because
> the system hangs forever. I can't see any messages on the console screen when I
> want to reboot at point when system freezes.
>
> I'm interested to solve this problem.
> Bellow are the informations that I collect but I'm waiting for advices how to
> add more informations here too.
>
> ** In the kern.log I can see followings:
>
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.112136] usb 1-1: new full speed USB
> device using ohci_hcd and address 2
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.330106] usb 1-1: New USB device found,
> idVendor=07a6, idProduct=8515
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.330138] usb 1-1: New USB device
> strings: Mfr=1, Product=2, SerialNumber=3
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.330160] usb 1-1: Product: USB To LAN
> Converter
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.330178] usb 1-1: Manufacturer: ADMtek
> Jul 31 18:25:22 cspdebsid kernel: [ 1033.330195] usb 1-1: SerialNumber: 0001
> Jul 31 18:25:26 cspdebsid kernel: [ 1037.203598] pegasus: v0.6.14 (2006/09/27),
> Pegasus/Pegasus II USB Ethernet driver
> Jul 31 18:25:26 cspdebsid kernel: [ 1037.238457] pegasus 1-1:1.0: setup Pegasus
> II specific registers
> Jul 31 18:25:26 cspdebsid kernel: [ 1037.407345] pegasus 1-1:1.0: eth0, ADMtek
> ADM8515 "Pegasus II" USB-2.0 Ethernet, 00:0
> 0:70:01:11:f1
> Jul 31 18:25:26 cspdebsid kernel: [ 1037.413433] usbcore: registered new
> interface driver pegasus
> Jul 31 18:25:30 cspdebsid kernel: [ 1041.036887] pegasus 1-1:1.0: eth0:
> update_eth_regs_async, status -22
> Jul 31 18:25:30 cspdebsid kernel: [ 1041.037045] pegasus 1-1:1.0: eth0:
> update_eth_regs_async, status -22
> Jul 31 18:25:30 cspdebsid kernel: [ 1041.037558] pegasus 1-1:1.0: eth0:
> update_eth_regs_async, status -22
> Jul 31 18:25:40 cspdebsid kernel: [ 1051.616109] eth0: no IPv6 routers present
>
> ** Loaded modules:
> Module Size Used by
> pegasus 17683 0
> mii 12562 1 pegasus
> act_police 12592 0
> cls_flow 12970 0
> cls_fw 12775 0
> cls_u32 12816 0
> sch_tbf 12812 0
> sch_prio 12971 0
> sch_htb 17475 0
> sch_hfsc 21835 0
> sch_ingress 12648 0
> sch_sfq 12910 0
> xt_time 12419 0
> xt_connlimit 12498 0
> xt_realm 12391 0
> iptable_raw 12476 0
> xt_comment 12395 19
> xt_recent 12862 0
> xt_policy 12458 0
> ipt_ULOG 12561 0
> ipt_REJECT 12425 4
> ipt_REDIRECT 12431 0
> ipt_NETMAP 12425 0
> ipt_MASQUERADE 12530 0
> ipt_ECN 12416 0
> ipt_ecn 12416 0
> ipt_CLUSTERIP 12835 0
> ipt_ah 12413 0
> ipt_addrtype 12473 3
> nf_nat_tftp 12390 0
> nf_nat_snmp_basic 16793 0
> nf_nat_sip 12788 0
> nf_nat_pptp 12506 0
> nf_nat_proto_gre 12469 1 nf_nat_pptp
> nf_nat_irc 12414 0
> nf_nat_h323 12719 0
> nf_nat_ftp 12420 0
> nf_nat_amanda 12392 0
> ts_kmp 12479 5
> nf_conntrack_amanda 12405 1 nf_nat_amanda
> nf_conntrack_sane 12396 0
> nf_conntrack_tftp 12401 1 nf_nat_tftp
> nf_conntrack_sip 17500 1 nf_nat_sip
> nf_conntrack_proto_sctp 12734 0
> nf_conntrack_pptp 12620 1 nf_nat_pptp
> nf_conntrack_proto_gre 12803 1 nf_conntrack_pptp
> nf_conntrack_netlink 22091 0
> nf_conntrack_netbios_ns 12402 0
> nf_conntrack_irc 12395 1 nf_nat_irc
> nf_conntrack_h323 37918 1 nf_nat_h323
> nf_conntrack_ftp 12508 1 nf_nat_ftp
> xt_TPROXY 12702 0
> nf_tproxy_core 12380 1 xt_TPROXY,[permanent]
> ip6_tables 17069 1 xt_TPROXY
> nf_defrag_ipv6 12661 1 xt_TPROXY
> xt_tcpmss 12393 0
> xt_pkttype 12395 0
> xt_physdev 12428 0
> xt_owner 12391 0
> xt_NFQUEUE 12461 0
> xt_NFLOG 12422 0
> nfnetlink_log 12891 1 xt_NFLOG
> xt_multiport 12470 4
> xt_mark 12413 1
> xt_mac 12387 0
> xt_limit 12484 0
> xt_length 12420 0
> xt_iprange 12456 0
> xt_helper 12459 0
> xt_hashlimit 12948 0
> xt_DSCP 12491 0
> xt_dscp 12467 0
> xt_dccp 12450 0
> xt_conntrack 12535 8
> xt_connmark 12565 0
> xt_CLASSIFY 12397 0
> ipt_LOG 12533 7
> xt_tcpudp 12471 18
> xt_state 12455 0
> iptable_nat 12800 0
> nf_nat 17708 12
> ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,iptable_nat
> nf_conntrack_ipv4 13649 11 iptable_nat,nf_nat
> nf_defrag_ipv4 12443 2 xt_TPROXY,nf_conntrack_ipv4
> nf_conntrack 42383 30
> xt_connlimit,ipt_MASQUERADE,ipt_CLUSTERIP,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_conntrack_amanda,nf_conntrack_sane,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,xt_helper,xt_conntrack,xt_connmark,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
> iptable_mangle 12488 1
> nfnetlink 12786 2 nf_conntrack_netlink,nfnetlink_log
> iptable_filter 12488 1
> ip_tables 16998 4
> iptable_raw,iptable_nat,iptable_mangle,iptable_filter
> x_tables 17967 46
> xt_time,xt_connlimit,xt_realm,iptable_raw,xt_comment,xt_recent,xt_policy,ipt_ULOG,ipt_REJECT,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ipt_ECN,ipt_ecn,ipt_CLUSTERIP,ipt_ah,ipt_addrtype,xt_TPROXY,ip6_tables,xt_tcpmss,xt_pkttype,xt_physdev,xt_owner,xt_NFQUEUE,xt_NFLOG,xt_multiport,xt_mark,xt_mac,xt_limit,xt_length,xt_iprange,xt_helper,xt_hashlimit,xt_DSCP,xt_dscp,xt_dccp,xt_conntrack,xt_connmark,xt_CLASSIFY,ipt_LOG,xt_tcpudp,xt_state,iptable_nat,iptable_mangle,iptable_filter,ip_tables
> nfsd 196026 2
> exportfs 12506 1 nfsd
> nfs 209548 0
> lockd 60854 2 nfsd,nfs
> fscache 31368 1 nfs
> nfs_acl 12463 2 nfsd,nfs
> auth_rpcgss 31708 2 nfsd,nfs
> sunrpc 132703 6 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
> snd_opl3sa2 17489 1
> snd_wss_lib 22401 1 snd_opl3sa2
> snd_pcm_oss 35824 0
> snd_mixer_oss 17649 2 snd_pcm_oss
> snd_pcm 52718 2 snd_wss_lib,snd_pcm_oss
> snd_page_alloc 12841 2 snd_wss_lib,snd_pcm
> snd_opl3_lib 13141 1 snd_opl3sa2
> snd_hwdep 12906 1 snd_opl3_lib
> snd_mpu401_uart 13299 1 snd_opl3sa2
> snd_seq_midi 12744 0
> snd_rawmidi 18311 2 snd_mpu401_uart,snd_seq_midi
> snd_seq_midi_event 13124 1 snd_seq_midi
> snd_seq 39027 2 snd_seq_midi,snd_seq_midi_event
> pcmcia 32024 0
> snd_timer 22133 4 snd_wss_lib,snd_pcm,snd_opl3_lib,snd_seq
> snd_seq_device 12995 4 snd_opl3_lib,snd_seq_midi,snd_rawmidi,snd_seq
> donauboe 16937 0
> yenta_socket 22152 0
> evdev 13015 8
> snd 38112 12
> snd_opl3sa2,snd_wss_lib,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_opl3_lib,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> psmouse 50618 0
> irda 78083 1 donauboe
> pcmcia_rsrc 17314 1 yenta_socket
> pcmcia_core 17973 3 pcmcia,yenta_socket,pcmcia_rsrc
> serio_raw 12758 0
> pcspkr 12515 0
> crc_ccitt 12331 2 donauboe,irda
> soundcore 12878 2 snd
> parport_pc 21895 0
> toshiba_acpi 13159 0
> parport 26994 1 parport_pc
> sparse_keymap 12680 1 toshiba_acpi
> battery 12957 0
> rfkill 18476 1 toshiba_acpi
> processor 22676 1
> ac 12552 0
> power_supply 13283 2 battery,ac
> button 12866 0
> container 12525 0
> ext3 97893 1
> jbd 36657 1 ext3
> mbcache 12810 1 ext3
> sg 21324 0
> sd_mod 34940 3
> crc_t10dif 12332 1 sd_mod
> ata_generic 12439 0
> pata_piccolo 12466 2
> libata 131830 2 ata_generic,pata_piccolo
> ohci_hcd 21928 0
> ehci_hcd 34862 0
> usbcore 98954 4 pegasus,ohci_hcd,ehci_hcd
> scsi_mod 134369 3 sg,sd_mod,libata
> thermal 13058 0
> fan 12594 0
> floppy 47855 0
> thermal_sys 17667 3 processor,fan,thermal
> nls_base 12649 1 usbcore
>
> ** Network interface configuration:
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
>
> NOTE!
> I'm using network-manager application to setup my networking.
>
> ** Network status:
> *** IP interfaces and addresses:
> eth0 Link encap:Ethernet HWaddr 00:00:70:01:11:f1
> inet addr:192.168.10.92 Bcast:192.168.10.255 Mask:255.255.255.0
> inet6 addr: fe80::200:70ff:fe01:11f1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2340 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2272 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1102571 (1.0 MiB) TX bytes:231106 (225.6 KiB)
>
> irda0 Link encap:IrLAP HWaddr 78:22:90:17
> UP RUNNING NOARP MTU:2048 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:8
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:153 errors:0 dropped:0 overruns:0 frame:0
> TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:22449 (21.9 KiB) TX bytes:22449 (21.9 KiB)
>
> ** PCI devices:
> 00:00.0 Host bridge: Toshiba America Info Systems CPU to PCI bridge (rev a2)
> 00:07.0 Communication controller: Agere Systems 56k WinModem (rev 01)
> 00:08.0 VGA compatible controller: S3 Inc. ViRGE/MX (rev 06)
> 00:0b.0 USB Controller: NEC Corporation USB (rev 02)
> 00:10.0 IDE interface: Toshiba America Info Systems Extended IDE Controller
> (rev 34)
> 00:11.0 Communication controller: Toshiba America Info Systems FIR Port Type-O
> (rev 23)
> 00:13.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 07)
> 00:13.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 07)
>
> --
> Best Regards,
> Csanyi Pal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 3/3 net-next] net: Define NETDEV_FCOE_WWNN, NETDEV_FCOE_WWPN only when CONFIG_LIBFCOE is enabled
From: Zou, Yi @ 2011-08-26 22:11 UTC (permalink / raw)
To: Michael Chan, davem@davemloft.net
Cc: netdev@vger.kernel.org, Bhanu Prakash Gollapudi
In-Reply-To: <1314387941-2126-3-git-send-email-mchan@broadcom.com>
> From: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
>
> bnx2fc driver calls netdev->netdev_ops->ndo_fcoe_get_wwn() and it may not
> be defined with the current Kconfig dependencies. ndo_fcoe_get_wwn is
> dependent on CONFIG_FCOE, but bnx2fc does not select CONFIG_FCOE, as it
> does
> not depend on fcoe driver. Since both fcoe and bnx2fc drivers select
> CONFIG_LIBFCOE, define NETDEV_FCOE_WWNN and NETDEV_FCOE_WWPN when
> CONFIG_LIBFCOE is defined.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> ---
> include/linux/netdevice.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 125f9fb..0a7f619 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -922,11 +922,15 @@ struct net_device_ops {
> u16 xid,
> struct scatterlist *sgl,
> unsigned int sgc);
> +#endif
> +
> +#if defined(CONFIG_LIBFCOE) || defined(CONFIG_LIBFCOE_MODULE)
> #define NETDEV_FCOE_WWNN 0
> #define NETDEV_FCOE_WWPN 1
> int (*ndo_fcoe_get_wwn)(struct net_device *dev,
> u64 *wwn, int type);
> #endif
> +
> #ifdef CONFIG_RFS_ACCEL
> int (*ndo_rx_flow_steer)(struct net_device *dev,
> const struct sk_buff *skb,
> --
> 1.7.1
>
Thanks,
Reviewed-by: Yi Zou <yi.zou@intel.com>
^ permalink raw reply
* Re: [PATCH 3/3 net-next] net: Define NETDEV_FCOE_WWNN, NETDEV_FCOE_WWPN only when CONFIG_LIBFCOE is enabled
From: Randy Dunlap @ 2011-08-26 22:17 UTC (permalink / raw)
To: Zou, Yi
Cc: Michael Chan, davem@davemloft.net, netdev@vger.kernel.org,
Bhanu Prakash Gollapudi
In-Reply-To: <5A9BD224CEA58D4CB62235967D650C160A06D10A@orsmsx509.amr.corp.intel.com>
On Fri, 26 Aug 2011 15:11:17 -0700 Zou, Yi wrote:
> > From: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> >
> > bnx2fc driver calls netdev->netdev_ops->ndo_fcoe_get_wwn() and it may not
> > be defined with the current Kconfig dependencies. ndo_fcoe_get_wwn is
> > dependent on CONFIG_FCOE, but bnx2fc does not select CONFIG_FCOE, as it
> > does
> > not depend on fcoe driver. Since both fcoe and bnx2fc drivers select
> > CONFIG_LIBFCOE, define NETDEV_FCOE_WWNN and NETDEV_FCOE_WWPN when
> > CONFIG_LIBFCOE is defined.
> >
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> > Cc: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
> > ---
> > include/linux/netdevice.h | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 125f9fb..0a7f619 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -922,11 +922,15 @@ struct net_device_ops {
> > u16 xid,
> > struct scatterlist *sgl,
> > unsigned int sgc);
> > +#endif
> > +
> > +#if defined(CONFIG_LIBFCOE) || defined(CONFIG_LIBFCOE_MODULE)
> > #define NETDEV_FCOE_WWNN 0
> > #define NETDEV_FCOE_WWPN 1
> > int (*ndo_fcoe_get_wwn)(struct net_device *dev,
> > u64 *wwn, int type);
> > #endif
> > +
> > #ifdef CONFIG_RFS_ACCEL
> > int (*ndo_rx_flow_steer)(struct net_device *dev,
> > const struct sk_buff *skb,
> > --
> > 1.7.1
> >
> Thanks,
>
> Reviewed-by: Yi Zou <yi.zou@intel.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
This one fixes lots of build errors, like:
drivers/scsi/fcoe/fcoe_transport.c:152: error: 'const struct net_device_ops' has no member named 'ndo_fcoe_get_wwn'
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN' undeclared (first use in this function)
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN' undeclared (first use in this function)
drivers/scsi/fcoe/fcoe_transport.c:152: error: 'const struct net_device_ops' has no member named 'ndo_fcoe_get_wwn'
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Jeff Kirsher @ 2011-08-26 23:17 UTC (permalink / raw)
To: Michał Mirosław
Cc: Ben Greear, netdev@vger.kernel.org, David S. Miller,
Ben Hutchings
In-Reply-To: <20110826184155.GA14744@rere.qmqm.pl>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
On Fri, 2011-08-26 at 11:41 -0700, Michał Mirosław wrote:
> On Thu, Aug 25, 2011 at 12:04:40PM -0700, Ben Greear wrote:
> > On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> > >v3 of a feature handling cleanup and extension series. For testing, you
> > >might want user-space ethtool patched with:
> > >http://patchwork.ozlabs.org/patch/96374/
> > It looks like this is not in net-next yet...any hope of this
> > going in soon?
>
> It's because the series depends on finishing conversions of all drivers
> to ndo_fix/set_features. e1000e, igbvf, ixgb, ixgbevf are pending.
>
> BTW, Jeff, what is the status of those conversions? Last version of ixgbe
> patch from Donald Skidmore (sent about a month ago) was mostly ready IIUC.
>
> Best Regards,
> Michał Mirosław
e1000e patch just completed testing, I will be pushing that tonight.
ixgbe got pushed back in June, but there some suggested changes you had
made with Don and that patch has been in/out of testing due to issues
found.
It also appears that the ixgbevf patch has completed testing. The only
remaining patch which is left to complete is igbvf.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* BQL crap and wireless
From: Luis R. Rodriguez @ 2011-08-26 23:27 UTC (permalink / raw)
To: Tom Herbert
Cc: linux-wireless, Andrew McGregor, Matt Smith, Kevin Hayes,
Dave Taht, Derek Smithies, netdev-u79uwXL29TY76Z2rM5mHXA
I've just read this thread:
http://marc.info/?t=131277868500001&r=1&w=2
Since its not linux-wireless I'll chime in here. It seems that you are
trying to write an algorithm that will work for all networking and
802.11 devices. For networking is seems tough given driver
architecture and structure and the hope that all drivers will report
things in a fairly similar way. For 802.11 it was pointed out how we
have varying bandwidths and depending on the technology used for
connection (AP, 802.11s, IBSS) a different number of possible peers
need to be considered. 802.11 faced similar algorithmic complexities
with rate control and the way Andrew and Derek resolved this was to
not assume you could solve this problem and simply test out the water
by trial and error, that gave birth to the minstrel rate control
algorithm which Felix later rewrote for mac80211 with 802.11n support
[1]. Can the BQL algorithm make use of the same trial and error
mechanism and simply try different values and and use EWMA [2] to pick
the best size for the queue ?
[1] http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel
[2] http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] sunrpc: use better NUMA affinities
From: J. Bruce Fields @ 2011-08-27 0:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: NeilBrown, Greg Banks, Christoph Hellwig,
linux-nfs@vger.kernel.org, David Miller, linux-kernel, netdev
In-Reply-To: <1312095534.2873.108.camel@edumazet-laptop>
On Sun, Jul 31, 2011 at 08:58:54AM +0200, Eric Dumazet wrote:
> Le samedi 30 juillet 2011 à 08:23 +0200, Eric Dumazet a écrit :
> > Le samedi 30 juillet 2011 à 16:06 +1000, NeilBrown a écrit :
> > > umount /proc/fs/nfsd
> > >
> > >
> >
> > Thans a lot, this was the thing I missed !
> >
> >
>
> Hmm, after this, I left things as the were (nfsd module loaded, but a 0
> use count )
>
> I got a BUG while updatedb was running,
> (I tried this on a debian machine/kernel)
>
> Same bug on :
>
> cat /proc/self/mounts
Any luck figuring this out?
I tried reproducing, by stopping everything to get nfsd refcount to
zero:
# lsmod | grep '^nfsd'
nfsd 300025 0
then running 'cat /proc/self/mounts'.
But I don't see any crash.
This is only 3.1.0-rc1 plus some nfsd patches.
--b.
>
> I'll take a look at this issue later, after my vacations, unless someone
> wants to take a look before me ;)
>
> [1020029.301174] BUG: unable to handle kernel paging request at ffffffffa03da0d0
> [1020029.301318] IP: [<ffffffff811105bd>] show_type+0x17/0x5a
> [1020029.301436] PGD 1605067 PUD 1609063 PMD 127353067 PTE 0
> [1020029.301574] Oops: 0000 [#1] SMP
> [1020029.301637] last sysfs file: /sys/module/nfsd/initstate
> [1020029.301722] CPU 6
> [1020029.301765] Modules linked in: nfsd fuse btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reiserfs ext4 jbd2 crc16 ext2 dm_mod nls_utf8 isofs lockd fscache auth_rpcgss nfs_acl sunrpc loop i5000_edac radeon edac_core ttm drm_kms_helper snd_pcm drm snd_timer snd i2c_algo_bit soundcore i2c_core snd_page_alloc i5k_amb power_supply ipmi_si evdev psmouse rng_core ipmi_msghandler hpilo hpwdt shpchp processor button pcspkr serio_raw pci_hotplug container ext3 jbd mbcache hpsa usbhid hid uhci_hcd cciss scsi_mod ehci_hcd usbcore bnx2 thermal thermal_sys [last unloaded: nfsd]
> [1020029.303561]
> [1020029.303588] Pid: 23460, comm: updatedb.mlocat Tainted: G R 2.6.39-2-amd64 #1 HP ProLiant BL460c G1
> [1020029.303751] RIP: 0010:[<ffffffff811105bd>] [<ffffffff811105bd>] show_type+0x17/0x5a
> [1020029.303866] RSP: 0018:ffff880011da7e48 EFLAGS: 00010296
> [1020029.303953] RAX: ffffffffa03da0d0 RBX: ffff8801288a4a80 RCX: 0000000000007774
> [1020029.304061] RDX: ffffffff814c9935 RSI: ffff880129ea3800 RDI: ffff8801288a4a80
> [1020029.304169] RBP: ffff880129ea3800 R08: ffff880011da7e68 R09: ffffffffffffffff
> [1020029.304263] R10: ffff880011d883b2 R11: 0000000000000007 R12: ffff88012794a2c0
> [1020029.304263] R13: ffff8801288a4a80 R14: ffff88012794a338 R15: 0000000000000000
> [1020029.304263] FS: 00007f9cf0dec700(0000) GS:ffff88012fd80000(0000) knlGS:0000000000000000
> [1020029.304263] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [1020029.304263] CR2: ffffffffa03da0d0 CR3: 0000000058f90000 CR4: 00000000000006e0
> [1020029.304263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [1020029.304263] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [1020029.304263] Process updatedb.mlocat (pid: 23460, threadinfo ffff880011da6000, task ffff88002741a440)
> [1020029.304263] Stack:
> [1020029.304263] ffff8801288a4a80 ffff8801288a4a80 ffff88012794a338 ffffffff81110abf
> [1020029.304263] ffff88012794a2c0 ffff88010d992440 0000000000000400 00007f9cf0df3000
> [1020029.304263] ffff880127960cc0 ffff8801288a4a80 ffff88012794a338 ffffffff8111427a
> [1020029.304263] Call Trace:
> [1020029.304263] [<ffffffff81110abf>] ? show_vfsmnt+0x9b/0x134
> [1020029.304263] [<ffffffff8111427a>] ? seq_read+0x276/0x350
> [1020029.304263] [<ffffffff810fc207>] ? vfs_read+0xa1/0xfb
> [1020029.304263] [<ffffffff810d8052>] ? sys_mmap_pgoff+0x127/0x15a
> [1020029.304263] [<ffffffff810fc317>] ? sys_read+0x45/0x6e
> [1020029.304263] [<ffffffff81338e52>] ? system_call_fastpath+0x16/0x1b
> [1020029.304263] Code: 01 00 65 48 03 14 25 20 dc 00 00 66 ff 02 c3 f0 ff 47 38 c3 55 48 89 f5 48 c7 c2 35 99 4c 81 53 48 89 fb 48 83 ec 08 48 8b 46 28
> [1020029.304263] 8b 30 e8 c7 36 00 00 48 8b 85 b8 02 00 00 48 85 c0 74 2b 80
> [1020029.304263] RIP [<ffffffff811105bd>] show_type+0x17/0x5a
> [1020029.304263] RSP <ffff880011da7e48>
> [1020029.304263] CR2: ffffffffa03da0d0
> [1020029.311417] ---[ end trace ebf19aff1e083659 ]---
>
>
^ permalink raw reply
* Mellanox mlx4_en update
From: Jim Lieb @ 2011-08-27 0:09 UTC (permalink / raw)
To: netdev
I am having trouble getting the mlx4_en driver to work on 3.0.1 kernels. On
the advice of Yevgeny, I have pulled patches from net-next and applied them to
a 3.0.1 stable tree which compiles and runs just fine except for the driver.
What I know so far:
* The driver in the mlnx_en-1.5.6.tgz tarball from the Mellanox download site
works just fine with Fedora 12/RHEL6 and earlier kernels.
* Mainline and stable + patches don't on 3.0.1. See commands and logs below.
* A diff between the two (~15k lines) shows significant differences (mlx4_en is a
newer version, 1.5.6)
* udev seems to want to install mlx4_core alone but removing and re-installing
via modprobe of mlx4_en does the loading properly but the driver doesn't init
properly as shown in the logs.
See the end of the log for a git log short of the patches on top of 3.0.1.
post-boot, the driver had not fully loaded so I removed the only module that
did load. I did not show the boot time dmesg but it is identical to the first
part in the modprobe install log below.
The base install is Fedora 12 with updates on an x86_64 Westmere class server.
Everything minus 10Ge worked for extensive internal testing.
Am I missing patches? Might the firmware be out of date? Note that it works
w/ F12|RHEL[4-6].
If I can get working patches/firmware/??? I can repackage kernel RPMs so our
lab folks can deploy this.
Thanks
Jim
Please CC me on the reply.
[root@ca-twin-22a-boot ~]# modprobe -r mlx4_core
[root@ca-twin-22a-boot ~]# cat /proc/modules |grep mlx
[root@ca-twin-22a-boot ~]# tail /var/log/messages
Aug 25 16:13:18 ca-twin-22a-boot sudo: jlieb : TTY=pts/0 ;
PWD=/net/nfs.panwest.panasas.com/home/jlieb ; USER=root ; COMMAND=/bin/bash
Aug 25 16:13:56 ca-twin-22a-boot kernel: [ 219.388210] mlx4_core
0000:08:00.0: PCI INT A disabled
Aug 25 16:13:56 ca-twin-22a-boot kernel: [ 219.402558] mlx4_core
0000:0a:00.0: PCI INT A disabled
[root@ca-twin-22a-boot ~]# modprobe mlx4_en
Aug 25 16:15:17 ca-twin-22a-boot kernel: [ 300.481764] mlx4_core: Mellanox
ConnectX core driver v1.0 (July 14, 2011)
Aug 25 16:15:17 ca-twin-22a-boot kernel: [ 300.481769] mlx4_core:
Initializing 0000:0a:00.0
Aug 25 16:15:17 ca-twin-22a-boot kernel: [ 300.481789] mlx4_core
0000:0a:00.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26
Aug 25 16:15:19 ca-twin-22a-boot kernel: [ 302.511615] mlx4_core
0000:0a:00.0: Sense command failed for port: 1
Aug 25 16:15:19 ca-twin-22a-boot kernel: [ 302.511856] mlx4_core:
Initializing 0000:08:00.0
Aug 25 16:15:19 ca-twin-22a-boot kernel: [ 302.511874] mlx4_core
0000:08:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.045626] mlx4_core
0000:08:00.0: Sense command failed for port: 1
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.045829] mlx4_core
0000:08:00.0: Sense command failed for port: 2
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.104652] mlx4_en: Mellanox
ConnectX HCA Ethernet driver v1.5.4.1 (March 2011)
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.105401] mlx4_en 0000:0a:00.0:
UDP RSS is not supported on this device.
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.105784] mlx4_en 0000:08:00.0:
UDP RSS is not supported on this device.
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.105838] mlx4_en 0000:08:00.0:
Activating port:1
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.107174] mlx4_en: 0000:08:00.0:
Port 1: Using 8 TX rings
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.107177] mlx4_en: 0000:08:00.0:
Port 1: Using 16 RX rings
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.107319] mlx4_en: 0000:08:00.0:
Port 1: Initializing port
Aug 25 16:15:21 ca-twin-22a-boot kernel: [ 305.129594] udev: renamed network
interface eth2 to eth3
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.594246] mlx4_en 0000:08:00.0:
Activating port:2
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.953213] mlx4_en: eth3: Failed
to allocate RSS indirection QP
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.954608] mlx4_en: eth3: Failed
configuring rss steering
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.988594] mlx4_en: eth3: Failed
starting port:1
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.989008] mlx4_en: 0000:08:00.0:
Port 2: Using 8 TX rings
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.989012] mlx4_en: 0000:08:00.0:
Port 2: Using 16 RX rings
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 305.989107] mlx4_en: 0000:08:00.0:
Port 2: Initializing port
Aug 25 16:15:22 ca-twin-22a-boot kernel: [ 306.022225] udev: renamed network
interface eth2 to eth4
[root@ca-twin-22a-boot ~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr E0:CB:4E:64:EA:89
inet addr:10.6.2.143 Bcast:10.6.2.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:16 Memory:fbce0000-fbd00000
eth1 Link encap:Ethernet HWaddr E0:CB:4E:64:EA:88
inet addr:10.6.1.143 Bcast:10.6.1.255 Mask:255.255.255.0
inet6 addr: fe80::e2cb:4eff:fe64:ea88/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2066 errors:0 dropped:0 overruns:0 frame:0
TX packets:1558 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:560875 (547.7 KiB) TX bytes:160892 (157.1 KiB)
Interrupt:17 Memory:fbbe0000-fbc00000
eth3 Link encap:Ethernet HWaddr 00:02:C9:08:14:B6
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth4 Link encap:Ethernet HWaddr 00:02:C9:08:14:B7
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:82 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5500 (5.3 KiB) TX bytes:5500 (5.3 KiB)
Scripts etc. in the fedora install:
[root@ca-twin-22a-boot network-scripts]# less ifcfg-eth3
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
GATEWAY=10.6.2.254
DNS1=172.17.132.60
DEVICE=eth3
BOOTPROTO=static
NETMASK=255.255.255.0
DNS2=172.17.132.29
TYPE=Ethernet
HWADDR=00:02:c9:08:14:b6
IPADDR=10.6.2.143
[root@ca-twin-22a-boot network-scripts]# host ca-twin-22a
ca-twin-22a.calab.panasas.com has address 10.6.2.143
restart the network
[root@ca-twin-22a-boot network-scripts]# service network restart
Shutting down interface eth0: [ OK ]
Shutting down interface eth1: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]
Bringing up interface eth1: [ OK ]
Bringing up interface eth3: RTNETLINK answers: Bad file descriptor
Failed to bring up eth3.
[FAILED]
What the log shows during the restart:
Aug 25 16:17:26 ca-twin-22a-boot ntpd[2586]: Deleting interface #2 eth1,
fe80::e2cb:4eff:fe64:ea88#123, interface stats: received=0, sent=0, dropped=0,
active_time=273 secs
Aug 25 16:17:26 ca-twin-22a-boot ntpd[2586]: Deleting interface #5 eth0,
10.6.2.143#123, interface stats: received=0, sent=0, dropped=0,
active_time=273 secs
Aug 25 16:17:26 ca-twin-22a-boot ntpd[2586]: Deleting interface #6 eth1,
10.6.1.143#123, interface stats: received=14, sent=14, dropped=0,
active_time=273 secs
Aug 25 16:17:30 ca-twin-22a-boot avahi-daemon[2237]: Joining mDNS multicast
group on interface eth0.IPv4 with address 10.6.2.143.
Aug 25 16:17:30 ca-twin-22a-boot avahi-daemon[2237]: New relevant interface
eth0.IPv4 for mDNS.
Aug 25 16:17:30 ca-twin-22a-boot avahi-daemon[2237]: Registering new address
record for 10.6.2.143 on eth0.IPv4.
Aug 25 16:17:30 ca-twin-22a-boot kernel: [ 433.835452] ADDRCONF(NETDEV_UP):
eth1: link is not ready
Aug 25 16:17:31 ca-twin-22a-boot ntpd[2586]: Listening on interface #7 eth0,
10.6.2.143#123 Enabled
Aug 25 16:17:33 ca-twin-22a-boot kernel: [ 436.917985] e1000e: eth1 NIC Link
is Up 1000 Mbps Full Duplex, Flow Control: None
Aug 25 16:17:33 ca-twin-22a-boot kernel: [ 436.919503]
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Aug 25 16:17:35 ca-twin-22a-boot avahi-daemon[2237]: Registering new address
record for fe80::e2cb:4eff:fe64:ea88 on eth1.*.
Aug 25 16:17:35 ca-twin-22a-boot avahi-daemon[2237]: Joining mDNS multicast
group on interface eth1.IPv4 with address 10.6.1.143.
Aug 25 16:17:35 ca-twin-22a-boot avahi-daemon[2237]: New relevant interface
eth1.IPv4 for mDNS.
Aug 25 16:17:35 ca-twin-22a-boot avahi-daemon[2237]: Registering new address
record for 10.6.1.143 on eth1.IPv4.
Aug 25 16:17:35 ca-twin-22a-boot kernel: [ 438.989438] mlx4_core
0000:08:00.0: Failed to bring QP to state: 1 with error: -9
Aug 25 16:17:35 ca-twin-22a-boot kernel: [ 438.990609] mlx4_en: eth3: Failed
configuring rss steering
Aug 25 16:17:35 ca-twin-22a-boot kernel: [ 439.026160] mlx4_en: eth3: Failed
starting port:1
Aug 25 16:17:37 ca-twin-22a-boot ntpd[2586]: Listening on interface #8 eth1,
fe80::e2cb:4eff:fe64:ea88#123 Enabled
Aug 25 16:17:37 ca-twin-22a-boot ntpd[2586]: Listening on interface #9 eth1,
10.6.1.143#123 Enabled
git short log...
commit 31a5037e908bf73ac8c185ebd58727ed4af50785
Author: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
mlx4: decreasing ref count when removing mac
commit 2c0ff8f3327ec1fcf4d184ea49281559955ffa59
Author: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
mlx4: Fixing Ethernet unicast packet steering
commit d540b5c19da7e3e3fb17dcf508fe4674d915bb76
Author: Dotan Barak <dotanb@dev.mellanox.co.il>
mlx4_core: Bump the driver version to 1.0
commit f2a0b4681c54bf7915e3ce65f1496eef9792fe00
Author: Jiri Pirko <jpirko@redhat.com>
mlx4: do vlan cleanup
commit 9a3d46b2b017fface2355d150fb5cbf798066dd0
Author: Or Gerlitz <ogerlitz@mellanox.com>
mlx4_core: Add network flow counters
commit ac7af6feb51a5d5243e306b7ab1ef89436aa1756
Author: Or Gerlitz <ogerlitz@mellanox.com>
mlx4_core: Read extended capabilities into the flags field
commit 878184cd92ee22314f489392698972f8167ccd5d
Author: Or Gerlitz <ogerlitz@mellanox.com>
mlx4_core: Extend capability flags to 64 bits
commit 348a8184aaad001bf85d7be4ae5d9bd4a176aae3
Author: Jon Mason <jdmason@kudzu.us>
mlx4: remove unnecessary read of PCI_CAP_ID_EXP
commit c27c320827959efd1caf2f89c7991bffe5051d13
Author: Sergei Shtylyov <sshtylyov@ru.mvista.com>
mlx4: use pci_dev->revision
commit e2074fa29c96b799dc9db0880c7bb6a850b77220
Author: Joe Perches <joe@perches.com>
drivers/net: Remove casts of void *
commit 94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
Author: Greg Kroah-Hartman <gregkh@suse.de>
Linux 3.0.1
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
^ 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