* [PATCH 06/10] bnx2x: fix MB index for 4-port devices
From: Dmitry Kravkov @ 2011-07-19 11:42 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org; +Cc: Eilon Greenstein
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 333f5d6..4b255e5 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1104,7 +1104,7 @@ struct bnx2x {
#define BP_VN(bp) (BP_E1HVN(bp)) /*remove when approved*/
#define BP_L_ID(bp) (BP_E1HVN(bp) << 2)
#define BP_FW_MB_IDX(bp) (BP_PORT(bp) +\
- BP_VN(bp) * (CHIP_IS_E1x(bp) ? 2 : 1))
+ BP_VN(bp) * ((CHIP_IS_E1x(bp) || (CHIP_MODE_IS_4_PORT(bp))) ? 2 : 1))
struct net_device *dev;
struct pci_dev *pdev;
--
1.7.2.2
^ permalink raw reply related
* [PATCH 07/10] bnx2x: disable loacal BH when scheduling FCOE napi
From: Dmitry Kravkov @ 2011-07-19 11:43 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
Cc: Eilon Greenstein, Vladislav Zolotarov
From: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index a86517c..b8f8793 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -4520,8 +4520,15 @@ static void bnx2x_sp_task(struct work_struct *work)
struct bnx2x_fastpath *fp = bnx2x_fcoe_fp(bp);
if ((!NO_FCOE(bp)) &&
- (bnx2x_has_rx_work(fp) || bnx2x_has_tx_work(fp)))
+ (bnx2x_has_rx_work(fp) || bnx2x_has_tx_work(fp))) {
+ /*
+ * Prevent local bottom-halves from running as
+ * we are going to change the local NAPI list.
+ */
+ local_bh_disable();
napi_schedule(&bnx2x_fcoe(bp, napi));
+ local_bh_enable();
+ }
#endif
/* Handle EQ completions */
bnx2x_eq_int(bp);
--
1.7.2.2
^ permalink raw reply related
* [PATCH 08/10] bnx2x: use BNX2X_Q_FLG_TPA_IPV6 for TPA queue configuration
From: Dmitry Kravkov @ 2011-07-19 11:44 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org
Cc: Vladislav Zolotarov, Eilon Greenstein
From: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 4 +++-
drivers/net/bnx2x/bnx2x_sp.c | 2 +-
drivers/net/bnx2x/bnx2x_sp.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index b8f8793..7a89182 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2699,8 +2699,10 @@ static inline unsigned long bnx2x_get_q_flags(struct bnx2x *bp,
if (IS_FCOE_FP(fp))
__set_bit(BNX2X_Q_FLG_FCOE, &flags);
- if (!fp->disable_tpa)
+ if (!fp->disable_tpa) {
__set_bit(BNX2X_Q_FLG_TPA, &flags);
+ __set_bit(BNX2X_Q_FLG_TPA_IPV6, &flags);
+ }
if (leading) {
__set_bit(BNX2X_Q_FLG_LEADING_RSS, &flags);
diff --git a/drivers/net/bnx2x/bnx2x_sp.c b/drivers/net/bnx2x/bnx2x_sp.c
index 6306ff5..5a213e4 100644
--- a/drivers/net/bnx2x/bnx2x_sp.c
+++ b/drivers/net/bnx2x/bnx2x_sp.c
@@ -4240,7 +4240,7 @@ static void bnx2x_q_fill_setup_data_e2(struct bnx2x *bp,
/* Rx data */
/* IPv6 TPA supported for E2 and above only */
- data->rx.tpa_en |= test_bit(BNX2X_Q_FLG_TPA, ¶ms->flags) *
+ data->rx.tpa_en |= test_bit(BNX2X_Q_FLG_TPA_IPV6, ¶ms->flags) *
CLIENT_INIT_RX_DATA_TPA_EN_IPV6;
}
diff --git a/drivers/net/bnx2x/bnx2x_sp.h b/drivers/net/bnx2x/bnx2x_sp.h
index 73400dd..9a517c2 100644
--- a/drivers/net/bnx2x/bnx2x_sp.h
+++ b/drivers/net/bnx2x/bnx2x_sp.h
@@ -749,6 +749,7 @@ enum bnx2x_queue_cmd {
/* queue SETUP + INIT flags */
enum {
BNX2X_Q_FLG_TPA,
+ BNX2X_Q_FLG_TPA_IPV6,
BNX2X_Q_FLG_STATS,
BNX2X_Q_FLG_ZERO_STATS,
BNX2X_Q_FLG_ACTIVE,
--
1.7.2.2
^ permalink raw reply related
* [PATCH 10/10] bnx2x: disable FCoE for 578xx devices since not yet supported
From: Dmitry Kravkov @ 2011-07-19 11:46 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org; +Cc: Eilon Greenstein, mchan
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index e4dea11..28ef7fa 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -10575,8 +10575,8 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
bp->qm_cid_count = bnx2x_set_qm_cid_count(bp);
#ifdef BCM_CNIC
- /* disable FCOE L2 queue for E1x*/
- if (CHIP_IS_E1x(bp))
+ /* disable FCOE L2 queue for E1x and E3*/
+ if (CHIP_IS_E1x(bp) || CHIP_IS_E3(bp))
bp->flags |= NO_FCOE_FLAG;
#endif
--
1.7.2.2
^ permalink raw reply related
* [PATCH 09/10] bnx2x: fix memory barriers
From: Dmitry Kravkov @ 2011-07-19 11:45 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
Cc: Vladislav Zolotarov, Eilon Greenstein
From: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 8 +++-
drivers/net/bnx2x/bnx2x_sp.c | 86 ++++++++++++++++++++++++++++++++--------
2 files changed, 75 insertions(+), 19 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 7a89182..e4dea11 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2984,8 +2984,12 @@ static inline void bnx2x_sp_prod_update(struct bnx2x *bp)
{
int func = BP_FUNC(bp);
- /* Make sure that BD data is updated before writing the producer */
- wmb();
+ /*
+ * Make sure that BD data is updated before writing the producer:
+ * BD data is written to the memory, the producer is read from the
+ * memory, thus we need a full memory barrier to ensure the ordering.
+ */
+ mb();
REG_WR16(bp, BAR_XSTRORM_INTMEM + XSTORM_SPQ_PROD_OFFSET(func),
bp->spq_prod_idx);
diff --git a/drivers/net/bnx2x/bnx2x_sp.c b/drivers/net/bnx2x/bnx2x_sp.c
index 5a213e4..cce87d5 100644
--- a/drivers/net/bnx2x/bnx2x_sp.c
+++ b/drivers/net/bnx2x/bnx2x_sp.c
@@ -1563,8 +1563,13 @@ static int bnx2x_execute_vlan_mac(struct bnx2x *bp,
idx++;
}
- /* Commit the data writes towards the memory */
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
rc = bnx2x_sp_post(bp, o->ramrod_cmd, r->cid,
U64_HI(r->rdata_mapping),
@@ -2224,8 +2229,13 @@ static int bnx2x_set_rx_mode_e2(struct bnx2x *bp,
data->header.rule_cnt, p->rx_accept_flags,
p->tx_accept_flags);
- /* Commit writes towards the memory before sending a ramrod */
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
/* Send a ramrod */
rc = bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_FILTER_RULES, p->cid,
@@ -2918,16 +2928,22 @@ static int bnx2x_mcast_setup_e2(struct bnx2x *bp,
if (!o->total_pending_num)
bnx2x_mcast_refresh_registry_e2(bp, o);
- /* Commit writes towards the memory before sending a ramrod */
- mb();
-
- /* If CLEAR_ONLY was requested - don't send a ramrod and clear
+ /*
+ * If CLEAR_ONLY was requested - don't send a ramrod and clear
* RAMROD_PENDING status immediately.
*/
if (test_bit(RAMROD_DRV_CLR_ONLY, &p->ramrod_flags)) {
raw->clear_pending(raw);
return 0;
} else {
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
+
/* Send a ramrod */
rc = bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_MULTICAST_RULES,
raw->cid, U64_HI(raw->rdata_mapping),
@@ -3404,16 +3420,22 @@ static int bnx2x_mcast_setup_e1(struct bnx2x *bp,
if (rc)
return rc;
- /* Commit writes towards the memory before sending a ramrod */
- mb();
-
- /* If CLEAR_ONLY was requested - don't send a ramrod and clear
+ /*
+ * If CLEAR_ONLY was requested - don't send a ramrod and clear
* RAMROD_PENDING status immediately.
*/
if (test_bit(RAMROD_DRV_CLR_ONLY, &p->ramrod_flags)) {
raw->clear_pending(raw);
return 0;
} else {
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
+
/* Send a ramrod */
rc = bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, raw->cid,
U64_HI(raw->rdata_mapping),
@@ -4038,8 +4060,13 @@ static int bnx2x_setup_rss(struct bnx2x *bp,
data->capabilities |= ETH_RSS_UPDATE_RAMROD_DATA_UPDATE_RSS_KEY;
}
- /* Commit writes towards the memory before sending a ramrod */
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
/* Send a ramrod */
rc = bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_RSS_UPDATE, r->cid,
@@ -4505,7 +4532,13 @@ static inline int bnx2x_q_send_setup_e1x(struct bnx2x *bp,
/* Fill the ramrod data */
bnx2x_q_fill_setup_data_cmn(bp, params, rdata);
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
return bnx2x_sp_post(bp, ramrod, o->cids[BNX2X_PRIMARY_CID_INDEX],
U64_HI(data_mapping),
@@ -4528,6 +4561,13 @@ static inline int bnx2x_q_send_setup_e2(struct bnx2x *bp,
bnx2x_q_fill_setup_data_cmn(bp, params, rdata);
bnx2x_q_fill_setup_data_e2(bp, params, rdata);
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
return bnx2x_sp_post(bp, ramrod, o->cids[BNX2X_PRIMARY_CID_INDEX],
U64_HI(data_mapping),
@@ -4665,7 +4705,13 @@ static inline int bnx2x_q_send_update(struct bnx2x *bp,
/* Fill the ramrod data */
bnx2x_q_fill_update_data(bp, o, update_params, rdata);
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
return bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_CLIENT_UPDATE,
o->cids[cid_index], U64_HI(data_mapping),
@@ -5484,7 +5530,13 @@ static inline int bnx2x_func_send_start(struct bnx2x *bp,
rdata->path_id = BP_PATH(bp);
rdata->network_cos_mode = start_params->network_cos_mode;
- mb();
+ /*
+ * No need for an explicit memory barrier here as long we would
+ * need to ensure the ordering of writing to the SPQ element
+ * and updating of the SPQ producer which involves a memory
+ * read and we will have to put a full memory barrier there
+ * (inside bnx2x_sp_post()).
+ */
return bnx2x_sp_post(bp, RAMROD_CMD_ID_COMMON_FUNCTION_START, 0,
U64_HI(data_mapping),
--
1.7.2.2
^ permalink raw reply related
* [PATCH 00/10] bnx2x series
From: Dmitry Kravkov @ 2011-07-19 11:49 UTC (permalink / raw)
To: David Miller
Cc: Eilon Greenstein, Vladislav Zolotarov, netdev@vger.kernel.org
Hi Dave,
Please consider applying following series to the net-next.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH] net: ibm_newemac: Don't start autonegotiation when disabled in BMCR (genmii)
From: Stefan Roese @ 2011-07-19 11:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, netdev
In-Reply-To: <1311075322.25044.418.camel@pasglop>
Hi Ben,
On Tuesday 19 July 2011 13:35:22 Benjamin Herrenschmidt wrote:
> On Tue, 2011-07-19 at 12:50 +0200, Stefan Roese wrote:
> > As noticed on a custom 440GX board using the Micrel KSZ8041 PHY in
> > fiber mode, a strapped fixed PHY configuration will currently restart
> > the autonegotiation. This patch checks the BMCR_ANENABLE bit and
> > skips this autonegotiation if its disabled.
>
> Won't that just break aneg on everything else ?
>
> IE, most other PHYs rely on ANENABLE being set further down this same
> function (especially if the FW doesn't do it but even then, we may reset
> PHYs along the way etc...)
If aneg is enabled for a PHY (e.g. not strapped to fixed configuration), I
don't see how this patch will change the current aneg behaviour. Perhaps I'm
missing something, but I tested this on some boards with aneg enabled (Sequoia
etc). And I didn't notice any problems.
> This is something that really a case where the device-tree should
> indicate that aneg shall not be performed and from there don't call
> setup_aneg at all.
I feel that this BMCR_ANENABLE bit should be evaluated, but I have no strong
preference here. If you prefer that this should be handled via a new dt
property (phy-aneg = "disabled" ?), I can implement it this way. Just let me
know.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] net: ibm_newemac: Don't start autonegotiation when disabled in BMCR (genmii)
From: Benjamin Herrenschmidt @ 2011-07-19 12:29 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <201107191359.57421.sr@denx.de>
On Tue, 2011-07-19 at 13:59 +0200, Stefan Roese wrote:
> Hi Ben,
>
> On Tuesday 19 July 2011 13:35:22 Benjamin Herrenschmidt wrote:
> > On Tue, 2011-07-19 at 12:50 +0200, Stefan Roese wrote:
> > > As noticed on a custom 440GX board using the Micrel KSZ8041 PHY in
> > > fiber mode, a strapped fixed PHY configuration will currently restart
> > > the autonegotiation. This patch checks the BMCR_ANENABLE bit and
> > > skips this autonegotiation if its disabled.
> >
> > Won't that just break aneg on everything else ?
> >
> > IE, most other PHYs rely on ANENABLE being set further down this same
> > function (especially if the FW doesn't do it but even then, we may reset
> > PHYs along the way etc...)
>
> If aneg is enabled for a PHY (e.g. not strapped to fixed configuration), I
> don't see how this patch will change the current aneg behaviour. Perhaps I'm
> missing something, but I tested this on some boards with aneg enabled (Sequoia
> etc). And I didn't notice any problems.
But is aneg always enabled via straps ? The whole point of this function
is that aneg can be enabled or disabled via the ethtool API (thus
overriding whatever strapping)... I may be missing something but this
patch looks like it would break this no ?
> > This is something that really a case where the device-tree should
> > indicate that aneg shall not be performed and from there don't call
> > setup_aneg at all.
>
> I feel that this BMCR_ANENABLE bit should be evaluated, but I have no strong
> preference here. If you prefer that this should be handled via a new dt
> property (phy-aneg = "disabled" ?), I can implement it this way. Just let me
> know.
Don't we already have some bindings for PHY with a fixed setting ? I
don't remember off hand, we need to dbl check.
I don't like looking at BMCR because BCMR is a -control- register,
something that we can (and will) whack with anything ourselves, which
can be reset or reconfigured and I have learned to never trust board
straps :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ping6
From: Krzysztof Olędzki @ 2011-07-19 13:53 UTC (permalink / raw)
To: Jérôme Poulin; +Cc: eric, netdev
In-Reply-To: <CALJXSJpJmyLLDEs0aLxQ8-4r+mr6y9m+wuinQsxmn+1FNYUdLQ@mail.gmail.com>
On 2011-07-19 04:06, Jérôme Poulin wrote:
> On Mon, Jul 18, 2011 at 4:23 PM,<eric@certus.bz> wrote:
>>
>> I've found what I think is a bug in the ping6 tool. Without the -n option,
>> it puts the hostname inside the parenthesis instead of the resolved ip
>
> I guess this is on purpose as IPv6 has very long IP and hostnames
> should be used when possible, also, it does not show the hostname you
> typed but the resolved RDNS of the IP as in:
>
> jerome@MobileCPU ~ $ ping6 www.google.ca
> PING www.google.ca(iad04s01-in-x63.1e100.net) 56 data bytes
> 64 bytes from iad04s01-in-x63.1e100.net: icmp_seq=1 ttl=55 time=57.7 ms
Hello,
Even if so it makes no sense to me. You end up without knowing which
host you are pinging and a typical terminal is wide enough to display
even longest IPv6 addresses.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* [PATCH RFC] vhost: optimize interrupt enable/disable
From: Michael S. Tsirkin @ 2011-07-19 15:04 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
As we now only update used ring after enabling
the backend, we can write flags with __put_user:
as that's done on data path, it matters.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
It seems an obvious optimization so I queued this up
already.
drivers/vhost/vhost.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c16d225..c14c42b 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -998,7 +998,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
static int vhost_update_used_flags(struct vhost_virtqueue *vq)
{
void __user *used;
- if (put_user(vq->used_flags, &vq->used->flags) < 0)
+ if (__put_user(vq->used_flags, &vq->used->flags) < 0)
return -EFAULT;
if (unlikely(vq->log_used)) {
/* Make sure the flag is seen before log. */
@@ -1016,7 +1016,7 @@ static int vhost_update_used_flags(struct vhost_virtqueue *vq)
static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16 avail_event)
{
- if (put_user(vq->avail_idx, vhost_avail_event(vq)))
+ if (__put_user(vq->avail_idx, vhost_avail_event(vq)))
return -EFAULT;
if (unlikely(vq->log_used)) {
void __user *used;
--
1.7.5.53.gc233e
^ permalink raw reply related
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Justin P. Mattock @ 2011-07-19 15:25 UTC (permalink / raw)
To: Mohammed Shafi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAD2nsn3ifSMa_eFr2vQ0VVF9Ga-0VD3YB_beb28r+eoAHKv4kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 07/18/2011 11:46 PM, Mohammed Shafi wrote:
> On Tue, Jul 19, 2011 at 12:05 PM, Justin P. Mattock
> <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 07/18/2011 11:25 PM, Mohammed Shafi wrote:
>>>
>>> On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
>>> <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>
>>>> seems with the latest Mainline I am getting the ath9k carpping out after
>>>> a
>>>> while of streaming(dmesg below)..:
>>>> http://fpaste.org/D7wM/
>>>>
>>>> will try a bisect if I have the time..
>>>
>>> I will try to recreate here with 3.0.0-rc7-wl, we can get more
>>> information by ath9k debug=0xffffffff.
>>> thanks.
>>>
>>
>> cool!
>> seems to fire off randomly over here.
>
> I have got AR5416, will try with that.
>
I can try the bisect, but might take a while, since external
activities(job). Seems this is just starting i.g. with
3.0.0-rc1 I never saw this, but with 3.0.0-rc7-00125-gf560f66
its making noise.
Justin P. Mattock
--
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] slcan: remove unused 'leased', 'line' and 'pid' fields from the 'slcan' structure
From: Oliver Hartkopp @ 2011-07-19 15:27 UTC (permalink / raw)
To: matvejchikov; +Cc: netdev
In-Reply-To: <CAKh5naa=x13=wUE+MLAYv0XQ4OhuY5G47ZDmFz0vbkibNtoz-A@mail.gmail.com>
On 19.07.2011 09:58, Matvejchikov Ilya wrote:
> Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
> ---
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks Ilya!
Your cleanup is obviously fixing some fallout from this patch
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5342b77c4123ba39f911d92a813295fb3bb21f69
which emerged in 2.6.32 for slip.c .
Best regards,
Oliver
> drivers/net/can/slcan.c | 10 +---------
> 1 files changed, 1 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
> index 1b49df6..805ee29 100644
> --- a/drivers/net/can/slcan.c
> +++ b/drivers/net/can/slcan.c
> @@ -95,10 +95,6 @@ struct slcan {
> unsigned long flags; /* Flag values/ mode etc */
> #define SLF_INUSE 0 /* Channel in use */
> #define SLF_ERROR 1 /* Parity, etc. error */
> -
> - unsigned char leased;
> - dev_t line;
> - pid_t pid;
> };
>
> static struct net_device **slcan_devs;
> @@ -462,7 +458,7 @@ static void slc_sync(void)
> break;
>
> sl = netdev_priv(dev);
> - if (sl->tty || sl->leased)
> + if (sl->tty)
> continue;
> if (dev->flags & IFF_UP)
> dev_close(dev);
> @@ -565,8 +561,6 @@ static int slcan_open(struct tty_struct *tty)
>
> sl->tty = tty;
> tty->disc_data = sl;
> - sl->line = tty_devnum(tty);
> - sl->pid = current->pid;
>
> if (!test_bit(SLF_INUSE, &sl->flags)) {
> /* Perform the low-level SLCAN initialization. */
> @@ -617,8 +611,6 @@ static void slcan_close(struct tty_struct *tty)
>
> tty->disc_data = NULL;
> sl->tty = NULL;
> - if (!sl->leased)
> - sl->line = 0;
>
> /* Flush network side */
> unregister_netdev(sl->dev);
^ permalink raw reply
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Mohammed Shafi @ 2011-07-19 15:49 UTC (permalink / raw)
To: Justin P. Mattock
Cc: netdev@vger.kernel.org, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <4E25A1E3.9080707@gmail.com>
On Tue, Jul 19, 2011 at 8:55 PM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 07/18/2011 11:46 PM, Mohammed Shafi wrote:
>>
>> On Tue, Jul 19, 2011 at 12:05 PM, Justin P. Mattock
>> <justinmattock@gmail.com> wrote:
>>>
>>> On 07/18/2011 11:25 PM, Mohammed Shafi wrote:
>>>>
>>>> On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
>>>> <justinmattock@gmail.com> wrote:
>>>>>
>>>>> seems with the latest Mainline I am getting the ath9k carpping out
>>>>> after
>>>>> a
>>>>> while of streaming(dmesg below)..:
>>>>> http://fpaste.org/D7wM/
>>>>>
>>>>> will try a bisect if I have the time..
>>>>
>>>> I will try to recreate here with 3.0.0-rc7-wl, we can get more
>>>> information by ath9k debug=0xffffffff.
>>>> thanks.
>>>>
>>>
>>> cool!
>>> seems to fire off randomly over here.
>>
>> I have got AR5416, will try with that.
>>
>
> I can try the bisect, but might take a while, since external
> activities(job). Seems this is just starting i.g. with
> 3.0.0-rc1 I never saw this, but with 3.0.0-rc7-00125-gf560f66
> its making noise.
I am unable to get this problem in my AR5416 :( will also try
tomorrow. I am using the card for browsing etc.
recently there were patches for hardware code changes.
just a guess, please check does this patch helps(or is it already
there). i think this will be called via
ath_set_channel->ath9k_hw_reset->ath9k_hw_init_bb and may be
https://patchwork.kernel.org/patch/957902/
>
> Justin P. Mattock
>
--
shafi
^ permalink raw reply
* [PATCH] r8169: fix sticky accepts packet bits in RxConfig.
From: Francois Romieu @ 2011-07-19 15:40 UTC (permalink / raw)
To: davem; +Cc: netdev, Hayes Wang
Please pull from branch 'davem-next.r8169' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git davem-next.r8169
to get the change below.
NB: it is related to but it does not solve BZ 39252.
Distance from 'davem-next' (81fc70d86527a1450560709500ca5f52e661da1f)
---------------------------------------------------------------------
1687b56679880a47164ae149530abee543f9d6b1
Diffstat
--------
drivers/net/r8169.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
Shortlog
--------
Francois Romieu (1):
r8169: fix sticky accepts packet bits in RxConfig.
Patch
-----
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3ddd339..40bcb82 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -435,6 +435,7 @@ enum rtl_register_content {
AcceptMulticast = 0x04,
AcceptMyPhys = 0x02,
AcceptAllPhys = 0x01,
+#define RX_CONFIG_ACCEPT_MASK 0x3f
/* TxConfigBits */
TxInterFrameGapShift = 24,
@@ -3943,11 +3944,8 @@ err_pm_runtime_put:
static void rtl_rx_close(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- u32 rxcfg = RTL_R32(RxConfig);
- rxcfg &= ~(AcceptErr | AcceptRunt | AcceptBroadcast | AcceptMulticast |
- AcceptMyPhys | AcceptAllPhys);
- RTL_W32(RxConfig, rxcfg);
+ RTL_W32(RxConfig, RTL_R32(RxConfig) & ~RX_CONFIG_ACCEPT_MASK);
}
static void rtl8169_hw_reset(struct rtl8169_private *tp)
@@ -5586,7 +5584,7 @@ static void rtl_set_rx_mode(struct net_device *dev)
spin_lock_irqsave(&tp->lock, flags);
- tmp = RTL_R32(RxConfig) | rx_mode;
+ tmp = (RTL_R32(RxConfig) & ~RX_CONFIG_ACCEPT_MASK) | rx_mode;
if (tp->mac_version > RTL_GIGA_MAC_VER_06) {
u32 data = mc_filter[0];
--
Ueimor
^ permalink raw reply related
* Re: ath: Unable to reset channel (2412 MHz), reset status -5
From: Justin P. Mattock @ 2011-07-19 16:01 UTC (permalink / raw)
To: Mohammed Shafi
Cc: netdev@vger.kernel.org, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <CAD2nsn1xEB-e33_wrGqLETZ4MwFy12gtyawtg5XHLH0=-9vs2w@mail.gmail.com>
On 07/19/2011 08:49 AM, Mohammed Shafi wrote:
> On Tue, Jul 19, 2011 at 8:55 PM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> On 07/18/2011 11:46 PM, Mohammed Shafi wrote:
>>>
>>> On Tue, Jul 19, 2011 at 12:05 PM, Justin P. Mattock
>>> <justinmattock@gmail.com> wrote:
>>>>
>>>> On 07/18/2011 11:25 PM, Mohammed Shafi wrote:
>>>>>
>>>>> On Tue, Jul 19, 2011 at 11:43 AM, Justin P. Mattock
>>>>> <justinmattock@gmail.com> wrote:
>>>>>>
>>>>>> seems with the latest Mainline I am getting the ath9k carpping out
>>>>>> after
>>>>>> a
>>>>>> while of streaming(dmesg below)..:
>>>>>> http://fpaste.org/D7wM/
>>>>>>
>>>>>> will try a bisect if I have the time..
>>>>>
>>>>> I will try to recreate here with 3.0.0-rc7-wl, we can get more
>>>>> information by ath9k debug=0xffffffff.
>>>>> thanks.
>>>>>
>>>>
>>>> cool!
>>>> seems to fire off randomly over here.
>>>
>>> I have got AR5416, will try with that.
>>>
>>
>> I can try the bisect, but might take a while, since external
>> activities(job). Seems this is just starting i.g. with
>> 3.0.0-rc1 I never saw this, but with 3.0.0-rc7-00125-gf560f66
>> its making noise.
>
> I am unable to get this problem in my AR5416 :( will also try
> tomorrow. I am using the card for browsing etc.
> recently there were patches for hardware code changes.
> just a guess, please check does this patch helps(or is it already
> there). i think this will be called via
> ath_set_channel->ath9k_hw_reset->ath9k_hw_init_bb and may be
> https://patchwork.kernel.org/patch/957902/
I am not seeing this in: ar5008_hw_init_bb
will apply this to the current Mainline when I get the chance and run
the system to see if I get this firing off.
(as for what I have, and was doing:(OS fedora 15)simply streaming radio
with clients running in the background twitter, facebook, thunderbird
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 00/10] bnx2x series
From: David Miller @ 2011-07-19 17:05 UTC (permalink / raw)
To: dmitry; +Cc: eilong, vladz, netdev
In-Reply-To: <1311076147.30287.16.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 19 Jul 2011 14:49:07 +0300
> Please consider applying following series to the net-next.
All applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next-2.6 0/2] Automatic XPS mapping
From: Tom Herbert @ 2011-07-19 17:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, sf-linux-drivers
In-Reply-To: <1298045607.2570.17.camel@bwh-desktop>
Hi Ben,
I've finally gotten around to looking at how XPS interacts with the HW
priority queues...
On Fri, Feb 18, 2011 at 8:13 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> In the same way that we maintain a mapping CPUs to RX queues for RFS
> acceleration based on current IRQ affinity and the CPU topology, we can
> maintain a mapping of CPUs to TX queues for queue selection in XPS. (In
> fact this may be the same mapping.)
>
Any more progress on this? It seem like a good way to provide default
configuration for XPS that is usable.
> Questions:
> - Does this make a real difference to performance?
XPS seems to when configured correctly :-)
> (I've only barely tested this.)
> - Should there be a way to disable it?
> - Should the automatic mapping be made visible?
Yes, would be nice for this to be readable in the tx-<n> directory for
the queue. Same thing for rmap in RFS acceleration.
> (This applies RFS acceleration too.)
> - Should different mappings be allowed for different traffic classes,
> in case they have separate sets of TX interrupts with different
> affinity?
> (This applies to manual XPS configuration too.)
>
Yes. Looking at XPS and the HW traffic class support, I realized that
they don't seem to play together at all. If XPS is enabled, we don't
do the skb_tx_hash which is where the priority is taken into account.
It's probably worse than that, AFAICT XPS could be configured so that
packets are inadvertently sent on arbitrary priority queues.
I think the correct approach is to first choose a set of queues by
priority, and then among those queues perform XPS. Probably requires
some new configuration to make this hierarchy visible.
Tom
> Ben Hutchings (2):
> net: XPS: Allow driver to provide a default mapping of CPUs to TX
> queues
> sfc: Add CPU queue mapping for XPS
>
> drivers/net/sfc/efx.c | 59 +++++++++++++++++++++++++++++++-------------
> include/linux/netdevice.h | 10 +++++--
> net/Kconfig | 17 +++++++++----
> net/core/dev.c | 41 +++++++++++++++++-------------
> 4 files changed, 83 insertions(+), 44 deletions(-)
>
> --
> 1.7.3.4
>
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* Re: [PATCH] r8169: fix sticky accepts packet bits in RxConfig.
From: David Miller @ 2011-07-19 17:11 UTC (permalink / raw)
To: romieu; +Cc: netdev, hayeswang
In-Reply-To: <20110719154025.GA7667@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 19 Jul 2011 17:40:25 +0200
> Please pull from branch 'davem-next.r8169' in repository
>
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git davem-next.r8169
>
> to get the change below.
Pulled, thanks!
^ permalink raw reply
* Re: [PULL net-next] vhost-net fixes for 3.1
From: David Miller @ 2011-07-19 17:15 UTC (permalink / raw)
To: mst; +Cc: netdev, jasowang, mashirle
In-Reply-To: <20110719114741.GA5827@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 19 Jul 2011 14:47:41 +0300
> Here's Jason's fix for a theoretical event loss
> on migration (tweaked by me to update the test
> module as well), and a refcounting fix by me
> for a bug in the new zerocopy mode.
>
> I thought hard about merging Jason's patches for 3.0
> as well, but in the end I think it's not worth
> the risk of breaking something at this stage.
>
> Please pull for 3.1, thanks a lot!
Pulled, thanks!
^ permalink raw reply
* Re: [PATCH] slcan: remove unused 'leased', 'line' and 'pid' fields from the 'slcan' structure
From: Matvejchikov Ilya @ 2011-07-19 17:18 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: netdev
In-Reply-To: <4E25A267.4030005@hartkopp.net>
Well, it seems that it is.
2011/7/19 Oliver Hartkopp <socketcan@hartkopp.net>:
> On 19.07.2011 09:58, Matvejchikov Ilya wrote:
>> Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
>> ---
>
> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks Ilya!
>
> Your cleanup is obviously fixing some fallout from this patch
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5342b77c4123ba39f911d92a813295fb3bb21f69
>
> which emerged in 2.6.32 for slip.c .
>
> Best regards,
> Oliver
>
>
>> drivers/net/can/slcan.c | 10 +---------
>> 1 files changed, 1 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
>> index 1b49df6..805ee29 100644
>> --- a/drivers/net/can/slcan.c
>> +++ b/drivers/net/can/slcan.c
>> @@ -95,10 +95,6 @@ struct slcan {
>> unsigned long flags; /* Flag values/ mode etc */
>> #define SLF_INUSE 0 /* Channel in use */
>> #define SLF_ERROR 1 /* Parity, etc. error */
>> -
>> - unsigned char leased;
>> - dev_t line;
>> - pid_t pid;
>> };
>>
>> static struct net_device **slcan_devs;
>> @@ -462,7 +458,7 @@ static void slc_sync(void)
>> break;
>>
>> sl = netdev_priv(dev);
>> - if (sl->tty || sl->leased)
>> + if (sl->tty)
>> continue;
>> if (dev->flags & IFF_UP)
>> dev_close(dev);
>> @@ -565,8 +561,6 @@ static int slcan_open(struct tty_struct *tty)
>>
>> sl->tty = tty;
>> tty->disc_data = sl;
>> - sl->line = tty_devnum(tty);
>> - sl->pid = current->pid;
>>
>> if (!test_bit(SLF_INUSE, &sl->flags)) {
>> /* Perform the low-level SLCAN initialization. */
>> @@ -617,8 +611,6 @@ static void slcan_close(struct tty_struct *tty)
>>
>> tty->disc_data = NULL;
>> sl->tty = NULL;
>> - if (!sl->leased)
>> - sl->line = 0;
>>
>> /* Flush network side */
>> unregister_netdev(sl->dev);
>
>
^ permalink raw reply
* [BUG] ipv6: all routes share same inetpeer
From: Eric Dumazet @ 2011-07-19 17:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi David
While polishing a patch and testing it, I found that all ipv6 routes
shared the same inetpeer ! Oh well...
Apparently we call rt6_bind_peer() at wrong time, providing NULL
addresses.
Maybe you can find the bug before me ?
With following quick/dirty/debugging patch :
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 39d1230..f24391c 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -88,6 +88,7 @@ static inline struct inet_peer *inet_getpeer_v6(const struct in6_addr *v6daddr,
ipv6_addr_copy((struct in6_addr *)daddr.addr.a6, v6daddr);
daddr.family = AF_INET6;
+ WARN_ON(daddr.addr.a6[0] == 0 && daddr.addr.a6[1] == 0 && daddr.addr.a6[2] == 0 && daddr.addr.a6[3] == 0);
return inet_getpeer(&daddr, create);
}
I get for example :
[ 299.024117] ------------[ cut here ]------------
[ 299.024176] WARNING: at include/net/inetpeer.h:91 rt6_bind_peer+0x84/0xb0()
[ 299.024234] Hardware name: ProLiant BL460c G1
[ 299.024287] Modules linked in: xt_hashlimit ipmi_devintf ipmi_si ipmi_msghandler tg3 bonding
[ 299.024583] Pid: 7119, comm: ping6 Tainted: G W 3.0.0-rc7-03555-ge798b6e-dirty #1048
[ 299.024657] Call Trace:
[ 299.024709] [<c1042b4d>] warn_slowpath_common+0x6d/0xa0
[ 299.024765] [<c1373104>] ? rt6_bind_peer+0x84/0xb0
[ 299.024820] [<c1373104>] ? rt6_bind_peer+0x84/0xb0
[ 299.024875] [<c1042b9d>] warn_slowpath_null+0x1d/0x20
[ 299.024931] [<c1373104>] rt6_bind_peer+0x84/0xb0
[ 299.024985] [<c13731ec>] ipv6_cow_metrics+0xbc/0xe0
[ 299.025046] [<c13722a8>] ip6_rt_copy+0x1e8/0x210
[ 299.025101] [<c1372a70>] rt6_alloc_cow.isra.32+0x10/0x1d0
[ 299.025158] [<c1048fb9>] ? local_bh_enable_ip+0x59/0xc0
[ 299.025213] [<c137356b>] ip6_pol_route.isra.37+0x29b/0x2a0
[ 299.025270] [<c13735a1>] ip6_pol_route_output+0x31/0x40
[ 299.025325] [<c1376277>] fib6_rule_lookup+0x17/0x20
[ 299.025380] [<c137238c>] ip6_route_output+0x5c/0xa0
[ 299.025436] [<c1373570>] ? ip6_pol_route.isra.37+0x2a0/0x2a0
[ 299.025492] [<c1365004>] ip6_dst_lookup_tail+0xd4/0xe0
[ 299.025548] [<c136519f>] ip6_dst_lookup_flow+0x2f/0x90
[ 299.025604] [<c1048fb9>] ? local_bh_enable_ip+0x59/0xc0
[ 299.025660] [<c1390ef4>] ip6_datagram_connect+0x174/0x490
[ 299.025717] [<c12bdd42>] ? release_sock+0xf2/0x150
[ 299.025772] [<c137d9a7>] ? udp_v6_get_port+0x47/0x60
[ 299.025829] [<c132f838>] inet_dgram_connect+0x28/0x70
[ 299.025884] [<c12bc5c0>] sys_connect+0x60/0xa0
[ 299.025939] [<c10d239e>] ? might_fault+0x2e/0x80
[ 299.026001] [<c13c438d>] ? _raw_spin_unlock+0x1d/0x20
[ 299.026057] [<c10d239e>] ? might_fault+0x2e/0x80
[ 299.026117] [<c10d23e4>] ? might_fault+0x74/0x80
[ 299.026172] [<c12bcfeb>] sys_socketcall+0xbb/0x2e0
[ 299.026227] [<c13c4fc3>] ? sysenter_exit+0xf/0x18
[ 299.026282] [<c11a3ec0>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 299.026338] [<c13c4f90>] sysenter_do_call+0x12/0x36
[ 299.026393] ---[ end trace 53d11c892332cf99 ]---
or :
[ 299.032017] ------------[ cut here ]------------
[ 299.032072] WARNING: at include/net/inetpeer.h:91 rt6_bind_peer+0x84/0xb0()
[ 299.032130] Hardware name: ProLiant BL460c G1
[ 299.032183] Modules linked in: xt_hashlimit ipmi_devintf ipmi_si ipmi_msghandler tg3 bonding
[ 299.032482] Pid: 0, comm: kworker/0:1 Tainted: G W 3.0.0-rc7-03555-ge798b6e-dirty #1048
[ 299.032557] Call Trace:
[ 299.032614] [<c1042b4d>] warn_slowpath_common+0x6d/0xa0
[ 299.032671] [<c1373104>] ? rt6_bind_peer+0x84/0xb0
[ 299.032725] [<c1373104>] ? rt6_bind_peer+0x84/0xb0
[ 299.032780] [<c1042b9d>] warn_slowpath_null+0x1d/0x20
[ 299.032835] [<c1373104>] rt6_bind_peer+0x84/0xb0
[ 299.032890] [<c13731ec>] ipv6_cow_metrics+0xbc/0xe0
[ 299.032945] [<c1373a90>] icmp6_dst_alloc+0x1a0/0x2a0
[ 299.033001] [<c13738f0>] ? ip6_blackhole_route+0x240/0x240
[ 299.033058] [<c137a0bf>] ndisc_send_skb+0x4f/0x310
[ 299.033113] [<c137957b>] ? ndisc_fill_addr_option+0x5b/0x90
[ 299.033169] [<c137a3d2>] __ndisc_send+0x52/0x60
[ 299.033224] [<c137ad5d>] ndisc_send_ns+0x5d/0x90
[ 299.033279] [<c136b559>] ? ipv6_chk_addr+0x119/0x130
[ 299.033335] [<c137ae2f>] ndisc_solicit+0x9f/0x130
[ 299.033391] [<c12d8b8e>] neigh_timer_handler+0x10e/0x2a0
[ 299.033447] [<c105168a>] run_timer_softirq+0x13a/0x370
[ 299.033503] [<c1051608>] ? run_timer_softirq+0xb8/0x370
[ 299.033558] [<c12d8a80>] ? neigh_update+0x4c0/0x4c0
[ 299.033614] [<c1049577>] __do_softirq+0x97/0x1f0
[ 299.033674] [<c10494e0>] ? remote_softirq_receive+0x60/0x60
^ permalink raw reply related
* Re: [BUG] ipv6: all routes share same inetpeer
From: David Miller @ 2011-07-19 17:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311096229.2375.49.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Jul 2011 19:23:49 +0200
> Maybe you can find the bug before me ?
I think when we add the route we cow the metrics almost immediately.
The daddr is, unfortunately, fully prefixed at that point.
^ permalink raw reply
* [PATCH] vhost: clean up outstanding buffers before setting vring
From: Shirley Ma @ 2011-07-19 18:02 UTC (permalink / raw)
To: David Miller, mst; +Cc: netdev, jasowang
The outstanding DMA buffers need to be clean up before setting vring in
vhost. Otherwise the vring would be out of sync.
Signed-off-by: Shirley Ma<xma@us.ibm.com>
---
drivers/vhost/vhost.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c14c42b..d6315b4 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -445,8 +445,10 @@ void vhost_dev_cleanup(struct vhost_dev *dev)
vhost_poll_flush(&dev->vqs[i].poll);
}
/* Wait for all lower device DMAs done. */
- if (dev->vqs[i].ubufs)
+ if (dev->vqs[i].ubufs) {
vhost_ubuf_put_and_wait(dev->vqs[i].ubufs);
+ kfree(dev->vqs[i].ubufs);
+ }
/* Signal guest as appropriate. */
vhost_zerocopy_signal_used(&dev->vqs[i]);
@@ -651,6 +653,12 @@ static long vhost_set_vring(struct vhost_dev *d, int ioctl, void __user *argp)
vq = d->vqs + idx;
mutex_lock(&vq->mutex);
+ /* Wait for all lower device DMAs done. */
+ if (vq->ubufs)
+ vhost_ubuf_put_and_wait(vq->ubufs);
+
+ /* Signal guest as appropriate. */
+ vhost_zerocopy_signal_used(vq);
switch (ioctl) {
case VHOST_SET_VRING_NUM:
@@ -1592,7 +1600,6 @@ void vhost_ubuf_put_and_wait(struct vhost_ubuf_ref *ubufs)
{
kref_put(&ubufs->kref, vhost_zerocopy_done_signal);
wait_event(ubufs->wait, !atomic_read(&ubufs->kref.refcount));
- kfree(ubufs);
}
void vhost_zerocopy_callback(void *arg)
^ permalink raw reply related
* IPv6: autoconfiguration and suspend/resume or link down/up
From: Jiri Bohac @ 2011-07-19 18:02 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu, David S. Miller, stephen hemminger
Hi,
I came over a surprising behaviour with IPv6 autoconfiguration,
which I think is a bug, but I would first like to hear other
people's opinions before trying to fix this:
Problem 1: all the address/route lifetimes are kept in jiffies
and jiffies don't get incremented on resume. So when a
route/address lifetime is 30 minutes and the system resumes after
1 hour, the route/address should be considered expired, but it is
not.
Problem 2: when a system is moved to a new network a RS is not
sent. Thus, IPv6 does not autoconfigure until the router sends a
periodic RA. This can occur both while the system is alive and
while it is suspended. I think the autoconfigured state should be
discarded when the kernel suspects the system could have been
moved to a different network.
When the cable is unplugged and plugged in again, we already get
notified through linkwatch -> netdev_state_change ->
-> call_netdevice_notifiers(NETDEV_CHANGE, ...)
However, if the device has already been autoconfigured,
addrconf_notify() only handles this event by printing a
message.
So my idea was to:
- handle link up/down in addrconf_notify() similarly to
NETDEV_UP/NETDEV_DOWN
- on suspend, faking a link down event; on resume, faking a link up event
(or better, having a special event type for suspend/resume)
This would cause autoconfiguration to be restarted on resume as
well as cable plug/unplug, solving both the above problems.
Or do we want to completely rely on userspace tools
(networkmanager/ifplug) and expect them to do NETDEV_DOWN on
unplug/suspend and NETDEV_UP on plug/resume?
Any thoughts?
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [BUG] ipv6: all routes share same inetpeer
From: Eric Dumazet @ 2011-07-19 18:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110719.103724.1461298517132188126.davem@davemloft.net>
Le mardi 19 juillet 2011 à 10:37 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 19 Jul 2011 19:23:49 +0200
>
> > Maybe you can find the bug before me ?
>
> I think when we add the route we cow the metrics almost immediately.
> The daddr is, unfortunately, fully prefixed at that point.
Yes, we shall provide a second ip6_rt_copy() argument, with the
destination address.
I am testing :
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ddef80f..2a6d70a 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -72,7 +72,7 @@
#define RT6_TRACE(x...) do { ; } while (0)
#endif
-static struct rt6_info * ip6_rt_copy(struct rt6_info *ort);
+static struct rt6_info * ip6_rt_copy(struct rt6_info *ort, const struct in6_addr *dest);
static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie);
static unsigned int ip6_default_advmss(const struct dst_entry *dst);
static unsigned int ip6_default_mtu(const struct dst_entry *dst);
@@ -699,7 +699,7 @@ static struct rt6_info *rt6_alloc_cow(struct rt6_info *ort, const struct in6_add
* Clone the route.
*/
- rt = ip6_rt_copy(ort);
+ rt = ip6_rt_copy(ort, daddr);
if (rt) {
struct neighbour *neigh;
@@ -712,7 +712,6 @@ static struct rt6_info *rt6_alloc_cow(struct rt6_info *ort, const struct in6_add
ipv6_addr_copy(&rt->rt6i_gateway, daddr);
}
- ipv6_addr_copy(&rt->rt6i_dst.addr, daddr);
rt->rt6i_dst.plen = 128;
rt->rt6i_flags |= RTF_CACHE;
rt->dst.flags |= DST_HOST;
@@ -761,9 +760,9 @@ static struct rt6_info *rt6_alloc_cow(struct rt6_info *ort, const struct in6_add
static struct rt6_info *rt6_alloc_clone(struct rt6_info *ort, const struct in6_addr *daddr)
{
- struct rt6_info *rt = ip6_rt_copy(ort);
+ struct rt6_info *rt = ip6_rt_copy(ort, daddr);
+
if (rt) {
- ipv6_addr_copy(&rt->rt6i_dst.addr, daddr);
rt->rt6i_dst.plen = 128;
rt->rt6i_flags |= RTF_CACHE;
rt->dst.flags |= DST_HOST;
@@ -1584,7 +1583,7 @@ void rt6_redirect(const struct in6_addr *dest, const struct in6_addr *src,
if (neigh == dst_get_neighbour(&rt->dst))
goto out;
- nrt = ip6_rt_copy(rt);
+ nrt = ip6_rt_copy(rt, dest);
if (nrt == NULL)
goto out;
@@ -1592,7 +1591,6 @@ void rt6_redirect(const struct in6_addr *dest, const struct in6_addr *src,
if (on_link)
nrt->rt6i_flags &= ~RTF_GATEWAY;
- ipv6_addr_copy(&nrt->rt6i_dst.addr, dest);
nrt->rt6i_dst.plen = 128;
nrt->dst.flags |= DST_HOST;
@@ -1730,7 +1728,7 @@ void rt6_pmtu_discovery(const struct in6_addr *daddr, const struct in6_addr *sad
* Misc support functions
*/
-static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
+static struct rt6_info * ip6_rt_copy(struct rt6_info *ort, const struct in6_addr *dest)
{
struct net *net = dev_net(ort->rt6i_dev);
struct rt6_info *rt = ip6_dst_alloc(&net->ipv6.ip6_dst_ops,
@@ -1740,6 +1738,8 @@ static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
rt->dst.input = ort->dst.input;
rt->dst.output = ort->dst.output;
+ ipv6_addr_copy(&rt->rt6i_dst.addr, dest);
+ rt->rt6i_dst.plen = ort->rt6i_dst.plen;
dst_copy_metrics(&rt->dst, &ort->dst);
rt->dst.error = ort->dst.error;
rt->rt6i_idev = ort->rt6i_idev;
@@ -1752,7 +1752,6 @@ static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
rt->rt6i_flags = ort->rt6i_flags & ~RTF_EXPIRES;
rt->rt6i_metric = 0;
- memcpy(&rt->rt6i_dst, &ort->rt6i_dst, sizeof(struct rt6key));
#ifdef CONFIG_IPV6_SUBTREES
memcpy(&rt->rt6i_src, &ort->rt6i_src, sizeof(struct rt6key));
#endif
^ permalink raw reply related
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