* [PATCH 4/6] bnx2x: enable internal target-read for 57712 and up only
From: Dmitry Kravkov @ 2011-07-24 13:57 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller; +Cc: Eilon Greenstein, shmulikr
From: Shmulik Ravid <shmulikr@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 9c146f7..9c62092 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -10242,11 +10242,14 @@ static int __devinit bnx2x_init_dev(struct pci_dev *pdev,
REG_WR(bp, PXP2_REG_PGL_ADDR_90_F0 + BP_PORT(bp)*16, 0);
REG_WR(bp, PXP2_REG_PGL_ADDR_94_F0 + BP_PORT(bp)*16, 0);
- /**
+ /*
* Enable internal target-read (in case we are probed after PF FLR).
- * Must be done prior to any BAR read access
+ * Must be done prior to any BAR read access. Only for 57712 and up
*/
- REG_WR(bp, PGLUE_B_REG_INTERNAL_PFID_ENABLE_TARGET_READ, 1);
+ if (board_type != BCM57710 &&
+ board_type != BCM57711 &&
+ board_type != BCM57711E)
+ REG_WR(bp, PGLUE_B_REG_INTERNAL_PFID_ENABLE_TARGET_READ, 1);
/* Reset the load counter */
bnx2x_clear_load_cnt(bp);
--
1.7.2.2
^ permalink raw reply related
* [PATCH 3/6] bnx2x: count statistic ramrods on EQ to prevent MC assert
From: Dmitry Kravkov @ 2011-07-24 13:54 UTC (permalink / raw)
To: davem, netdev@vger.kernel.org; +Cc: Vladislav Zolotarov, Eilon Greenstein
From: Vladislav Zolotarov <vladz@broadcom.com>
This patch includes:
- Counting statistics ramrods as EQ ramrods the way they should be. This
accounting is meant to prevent MC asserts in case of software bugs.
- Fixes in debug facilities which were added while working on one of such
bugs.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 63 ++++++++++++++++++++-------------------
1 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 48490da..9c146f7 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -1671,11 +1671,12 @@ void bnx2x_sp_event(struct bnx2x_fastpath *fp, union eth_rx_cqe *rr_cqe)
switch (command) {
case (RAMROD_CMD_ID_ETH_CLIENT_UPDATE):
- DP(NETIF_MSG_IFUP, "got UPDATE ramrod. CID %d\n", cid);
+ DP(BNX2X_MSG_SP, "got UPDATE ramrod. CID %d\n", cid);
drv_cmd = BNX2X_Q_CMD_UPDATE;
break;
+
case (RAMROD_CMD_ID_ETH_CLIENT_SETUP):
- DP(NETIF_MSG_IFUP, "got MULTI[%d] setup ramrod\n", cid);
+ DP(BNX2X_MSG_SP, "got MULTI[%d] setup ramrod\n", cid);
drv_cmd = BNX2X_Q_CMD_SETUP;
break;
@@ -1685,17 +1686,17 @@ void bnx2x_sp_event(struct bnx2x_fastpath *fp, union eth_rx_cqe *rr_cqe)
break;
case (RAMROD_CMD_ID_ETH_HALT):
- DP(NETIF_MSG_IFDOWN, "got MULTI[%d] halt ramrod\n", cid);
+ DP(BNX2X_MSG_SP, "got MULTI[%d] halt ramrod\n", cid);
drv_cmd = BNX2X_Q_CMD_HALT;
break;
case (RAMROD_CMD_ID_ETH_TERMINATE):
- DP(NETIF_MSG_IFDOWN, "got MULTI[%d] teminate ramrod\n", cid);
+ DP(BNX2X_MSG_SP, "got MULTI[%d] teminate ramrod\n", cid);
drv_cmd = BNX2X_Q_CMD_TERMINATE;
break;
case (RAMROD_CMD_ID_ETH_EMPTY):
- DP(NETIF_MSG_IFDOWN, "got MULTI[%d] empty ramrod\n", cid);
+ DP(BNX2X_MSG_SP, "got MULTI[%d] empty ramrod\n", cid);
drv_cmd = BNX2X_Q_CMD_EMPTY;
break;
@@ -1725,6 +1726,8 @@ void bnx2x_sp_event(struct bnx2x_fastpath *fp, union eth_rx_cqe *rr_cqe)
/* push the change in bp->spq_left and towards the memory */
smp_mb__after_atomic_inc();
+ DP(BNX2X_MSG_SP, "bp->cq_spq_left %x\n", atomic_read(&bp->cq_spq_left));
+
return;
}
@@ -3089,26 +3092,23 @@ int bnx2x_sp_post(struct bnx2x *bp, int command, int cid,
spe->data.update_data_addr.hi = cpu_to_le32(data_hi);
spe->data.update_data_addr.lo = cpu_to_le32(data_lo);
- /* stats ramrod has it's own slot on the spq */
- if (command != RAMROD_CMD_ID_COMMON_STAT_QUERY) {
- /*
- * It's ok if the actual decrement is issued towards the memory
- * somewhere between the spin_lock and spin_unlock. Thus no
- * more explict memory barrier is needed.
- */
- if (common)
- atomic_dec(&bp->eq_spq_left);
- else
- atomic_dec(&bp->cq_spq_left);
- }
+ /*
+ * It's ok if the actual decrement is issued towards the memory
+ * somewhere between the spin_lock and spin_unlock. Thus no
+ * more explict memory barrier is needed.
+ */
+ if (common)
+ atomic_dec(&bp->eq_spq_left);
+ else
+ atomic_dec(&bp->cq_spq_left);
DP(BNX2X_MSG_SP/*NETIF_MSG_TIMER*/,
- "SPQE[%x] (%x:%x) command %d hw_cid %x data (%x:%x) "
- "type(0x%x) left (ETH, COMMON) (%x,%x)\n",
+ "SPQE[%x] (%x:%x) (cmd, common?) (%d,%d) hw_cid %x data (%x:%x) "
+ "type(0x%x) left (CQ, EQ) (%x,%x)\n",
bp->spq_prod_idx, (u32)U64_HI(bp->spq_mapping),
(u32)(U64_LO(bp->spq_mapping) +
- (void *)bp->spq_prod_bd - (void *)bp->spq), command,
+ (void *)bp->spq_prod_bd - (void *)bp->spq), command, common,
HW_CID(bp, cid), data_hi, data_lo, type,
atomic_read(&bp->cq_spq_left), atomic_read(&bp->eq_spq_left));
@@ -3465,6 +3465,7 @@ static inline void bnx2x_attn_int_deasserted3(struct bnx2x *bp, u32 attn)
} else if (attn & BNX2X_MC_ASSERT_BITS) {
BNX2X_ERR("MC assert!\n");
+ bnx2x_mc_assert(bp);
REG_WR(bp, MISC_REG_AEU_GENERAL_ATTN_10, 0);
REG_WR(bp, MISC_REG_AEU_GENERAL_ATTN_9, 0);
REG_WR(bp, MISC_REG_AEU_GENERAL_ATTN_8, 0);
@@ -4424,7 +4425,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
sw_cons = bp->eq_cons;
sw_prod = bp->eq_prod;
- DP(BNX2X_MSG_SP, "EQ: hw_cons %u sw_cons %u bp->cq_spq_left %u\n",
+ DP(BNX2X_MSG_SP, "EQ: hw_cons %u sw_cons %u bp->eq_spq_left %x\n",
hw_cons, sw_cons, atomic_read(&bp->eq_spq_left));
for (; sw_cons != hw_cons;
@@ -4443,7 +4444,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
DP(NETIF_MSG_TIMER, "got statistics comp event %d\n",
bp->stats_comp++);
/* nothing to do with stats comp */
- continue;
+ goto next_spqe;
case EVENT_RING_OPCODE_CFC_DEL:
/* handle according to cid range */
@@ -4451,7 +4452,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
* we may want to verify here that the bp state is
* HALTING
*/
- DP(NETIF_MSG_IFDOWN,
+ DP(BNX2X_MSG_SP,
"got delete ramrod for MULTI[%d]\n", cid);
#ifdef BCM_CNIC
if (!bnx2x_cnic_handle_cfc_del(bp, cid, elem))
@@ -4467,7 +4468,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
goto next_spqe;
case EVENT_RING_OPCODE_STOP_TRAFFIC:
- DP(NETIF_MSG_IFUP, "got STOP TRAFFIC\n");
+ DP(BNX2X_MSG_SP, "got STOP TRAFFIC\n");
if (f_obj->complete_cmd(bp, f_obj,
BNX2X_F_CMD_TX_STOP))
break;
@@ -4475,21 +4476,21 @@ static void bnx2x_eq_int(struct bnx2x *bp)
goto next_spqe;
case EVENT_RING_OPCODE_START_TRAFFIC:
- DP(NETIF_MSG_IFUP, "got START TRAFFIC\n");
+ DP(BNX2X_MSG_SP, "got START TRAFFIC\n");
if (f_obj->complete_cmd(bp, f_obj,
BNX2X_F_CMD_TX_START))
break;
bnx2x_dcbx_set_params(bp, BNX2X_DCBX_STATE_TX_RELEASED);
goto next_spqe;
case EVENT_RING_OPCODE_FUNCTION_START:
- DP(NETIF_MSG_IFUP, "got FUNC_START ramrod\n");
+ DP(BNX2X_MSG_SP, "got FUNC_START ramrod\n");
if (f_obj->complete_cmd(bp, f_obj, BNX2X_F_CMD_START))
break;
goto next_spqe;
case EVENT_RING_OPCODE_FUNCTION_STOP:
- DP(NETIF_MSG_IFDOWN, "got FUNC_STOP ramrod\n");
+ DP(BNX2X_MSG_SP, "got FUNC_STOP ramrod\n");
if (f_obj->complete_cmd(bp, f_obj, BNX2X_F_CMD_STOP))
break;
@@ -4503,7 +4504,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
BNX2X_STATE_OPENING_WAIT4_PORT):
cid = elem->message.data.eth_event.echo &
BNX2X_SWCID_MASK;
- DP(NETIF_MSG_IFUP, "got RSS_UPDATE ramrod. CID %d\n",
+ DP(BNX2X_MSG_SP, "got RSS_UPDATE ramrod. CID %d\n",
cid);
rss_raw->clear_pending(rss_raw);
break;
@@ -4518,7 +4519,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
BNX2X_STATE_DIAG):
case (EVENT_RING_OPCODE_CLASSIFICATION_RULES |
BNX2X_STATE_CLOSING_WAIT4_HALT):
- DP(NETIF_MSG_IFUP, "got (un)set mac ramrod\n");
+ DP(BNX2X_MSG_SP, "got (un)set mac ramrod\n");
bnx2x_handle_classification_eqe(bp, elem);
break;
@@ -4528,7 +4529,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
BNX2X_STATE_DIAG):
case (EVENT_RING_OPCODE_MULTICAST_RULES |
BNX2X_STATE_CLOSING_WAIT4_HALT):
- DP(NETIF_MSG_IFUP, "got mcast ramrod\n");
+ DP(BNX2X_MSG_SP, "got mcast ramrod\n");
bnx2x_handle_mcast_eqe(bp);
break;
@@ -4538,7 +4539,7 @@ static void bnx2x_eq_int(struct bnx2x *bp)
BNX2X_STATE_DIAG):
case (EVENT_RING_OPCODE_FILTERS_RULES |
BNX2X_STATE_CLOSING_WAIT4_HALT):
- DP(NETIF_MSG_IFUP, "got rx_mode ramrod\n");
+ DP(BNX2X_MSG_SP, "got rx_mode ramrod\n");
bnx2x_handle_rx_mode_eqe(bp);
break;
default:
--
1.7.2.2
^ permalink raw reply related
* [PATCH 2/6] bnx2x: fix loopback for non 10G link
From: Dmitry Kravkov @ 2011-07-24 13:53 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller; +Cc: eilon Greenstein, "; yanivr"
From: Yaniv Rosner <yanivr@broadcom.com>
Also fixes minor formatting in that function.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index e1ec1a3..48490da 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2151,10 +2151,12 @@ u8 bnx2x_initial_phy_init(struct bnx2x *bp, int load_mode)
u8 rc;
int cfx_idx = bnx2x_get_link_cfg_idx(bp);
u16 req_line_speed = bp->link_params.req_line_speed[cfx_idx];
- /* Initialize link parameters structure variables */
- /* It is recommended to turn off RX FC for jumbo frames
- for better performance */
- if ((CHIP_IS_E1x(bp)) && (bp->dev->mtu > 5000))
+ /*
+ * Initialize link parameters structure variables
+ * It is recommended to turn off RX FC for jumbo frames
+ * for better performance
+ */
+ if (CHIP_IS_E1x(bp) && (bp->dev->mtu > 5000))
bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_TX;
else
bp->link_params.req_fc_auto_adv = BNX2X_FLOW_CTRL_BOTH;
@@ -2162,8 +2164,18 @@ u8 bnx2x_initial_phy_init(struct bnx2x *bp, int load_mode)
bnx2x_acquire_phy_lock(bp);
if (load_mode == LOAD_DIAG) {
- bp->link_params.loopback_mode = LOOPBACK_XGXS;
- bp->link_params.req_line_speed[cfx_idx] = SPEED_10000;
+ struct link_params *lp = &bp->link_params;
+ lp->loopback_mode = LOOPBACK_XGXS;
+ /* do PHY loopback at 10G speed, if possible */
+ if (lp->req_line_speed[cfx_idx] < SPEED_10000) {
+ if (lp->speed_cap_mask[cfx_idx] &
+ PORT_HW_CFG_SPEED_CAPABILITY_D0_10G)
+ lp->req_line_speed[cfx_idx] =
+ SPEED_10000;
+ else
+ lp->req_line_speed[cfx_idx] =
+ SPEED_1000;
+ }
}
rc = bnx2x_phy_init(&bp->link_params, &bp->link_vars);
--
1.7.2.2
^ permalink raw reply related
* Re: LInux kernel 3.0 sit creation bug report
From: Jay Rouman @ 2011-07-24 12:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1311496931.6669.16.camel@edumazet-laptop>
Thank you for the reply. I was not aware that sit0 was deprecated,
but something has changed in 3.0. The "SIOCSIFDSTADDR: No buffer
space available" error does not happen in 2.6.39. The Linux-net-tools
command creates a working tunnel to Hurricane Electric's tunnel broker,
even though the error message is generated. I have tried the route-2
commands and while they work without error, I can't get the tunnel to
function. I get I never tried the route-2 (/bin/ip) setup in 2.6.39.
--
Jay Rouman (jsr@dexter.mi.org jsr@edzone.net)
/sbin/ifconfig sit0 inet6 tunnel ::<ip address>
> Le samedi 23 juillet 2011 ? 12:27 -0400, Jay Rouman a ?crit :
> > Kernel 3.0 (release version)
> > Summary: sit tunnel creation fails with "No buffer space available"
> >
> > Example:
> >
> > icebox:/home/u/jsr(3)# /sbin/ip tunnel add sit0 mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
> > add tunnel sit0 failed: No buffer space available
> >
> > icebox:/home/u/jsr(8)# /sbin/ifconfig sit0 inet6 tunnel ::209.51.18.1
> > SIOCSIFDSTADDR: No buffer space available
> >
> > Notes:
> >
> > Oddly, the ifconfig example creates a working sit0. The "ip" example
> > does not. The problem existed in rc1 but unfortunately I did not test
> > sit creation then. This was discovered when I upgraded a machine with
> > an HE tunnel to the 3.0 kernel. I am happy to do further testing or
> > provide whatever additional info I can.
> >
>
> I believe you use a deprecated (~10 years ago ?) way to setup your
> tunnel, its not a linux-3.0 new behavior.
>
> sit0 is reserved (fall back tunnel), you should use a different name.
>
> Try :
>
> # ip tunnel add aster mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
> # ifconfig aster up
>
> # ip tunnel
> sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
> aster: ipv6/ip remote 209.51.18.1 local 216.111.203.89 ttl 255
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-07-22
From: David Miller @ 2011-07-24 10:09 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110722.171635.1154932336401179368.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Fri, 22 Jul 2011 17:16:35 -0700 (PDT)
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Fri, 22 Jul 2011 18:23:09 -0400
>
>> Here is the last big pull request of new wireless bits intended
>> for 3.1. This includes the usual big batch of updates to iwlagn,
>> a number of updates to ath9k, mwifiex, carl9170, libertas, and other
>> drivers, and soem updates to mac80211 and cfg80211 from Johannes.
>> The most noteworth bits are most of the final push from Rafał for
>> supporting current Broadcom wireless hardware in b43.
>>
>> Please let me know if there are problems!
>
> A little late to be submitting this since the merge window is
> already open, but I pulled anyways.
>
> Thanks!
Please fix this build regression, the suspend/resume ops are only
available when CONFIG_PM is defined.
drivers/net/wireless/iwlwifi/iwl-agn.c:3464: error: unknown field 'suspend' specified in initializer
drivers/net/wireless/iwlwifi/iwl-agn.c:3464: warning: initialization from incompatible pointer type
drivers/net/wireless/iwlwifi/iwl-agn.c:3465: error: unknown field 'resume' specified in initializer
drivers/net/wireless/iwlwifi/iwl-agn.c:3465: warning: initialization from incompatible pointer type
--
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: LInux kernel 3.0 sit creation bug report
From: Eric Dumazet @ 2011-07-24 8:42 UTC (permalink / raw)
To: jsr; +Cc: netdev, davem
In-Reply-To: <E1Qkf2u-0007ZF-DS@dex.edzone.net>
Le samedi 23 juillet 2011 à 12:27 -0400, Jay Rouman a écrit :
> Kernel 3.0 (release version)
> Summary: sit tunnel creation fails with "No buffer space available"
>
> Example:
>
> icebox:/home/u/jsr(3)# /sbin/ip tunnel add sit0 mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
> add tunnel sit0 failed: No buffer space available
>
> icebox:/home/u/jsr(8)# /sbin/ifconfig sit0 inet6 tunnel ::209.51.18.1
> SIOCSIFDSTADDR: No buffer space available
>
> Notes:
>
> Oddly, the ifconfig example creates a working sit0. The "ip" example
> does not. The problem existed in rc1 but unfortunately I did not test
> sit creation then. This was discovered when I upgraded a machine with
> an HE tunnel to the 3.0 kernel. I am happy to do further testing or
> provide whatever additional info I can.
>
I believe you use a deprecated (~10 years ago ?) way to setup your
tunnel, its not a linux-3.0 new behavior.
sit0 is reserved (fall back tunnel), you should use a different name.
Try :
# ip tunnel add aster mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
# ifconfig aster up
# ip tunnel
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
aster: ipv6/ip remote 209.51.18.1 local 216.111.203.89 ttl 255
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Nicolas de Pesloüan @ 2011-07-24 8:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: Stephen Hemminger, David Miller, jbohac, netdev
In-Reply-To: <20110724001816.GA14051@gondor.apana.org.au>
Le 24/07/2011 02:18, Herbert Xu a écrit :
> On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
>>
>> Would it be possible to do live migration without dropping carrier
>> or setting interface down?
>
> I think LM uses the same mechanism as suspend and resume so whatever
> happens in one case will happen in the other case as well.
So we need to distinguish between two kind of link events:
1/ Really having the link goes down then up. This should trigger a renegotiation.
2/ Having the system suspend then resume :
2a/ This should trigger link down/link up events to force a renegotiation, for normal suspend/resume
where the network might have changed between suspend and resume.
2/ This should *not* trigger link down/link up events to avoid a renegotiation (for live migration)
because it is assumed that the network didn't change while suspended.
Can't we allow the user to set a global "link-down-link-up-timeout" and only force a renegotiation
if the time between link down and link up events is longer than this timeout? Normal user would set
this timeout close to 0 (default value). Live migration user would set this timeout to about twice
the time it normally takes to do a live migration. That way, in a VM environment, if the
suspend/resume cycle happens to take far more than a normal live migration time, the kernel would
renegotiate, which sounds reasonable, from my point of view.
Does this make sense?
Nicolas.
^ permalink raw reply
* Re: write() udp socket
From: Huajun Li @ 2011-07-24 8:33 UTC (permalink / raw)
To: ZHOU Xiaobo; +Cc: netdev
In-Reply-To: <tencent_287F494544728EDB6DA9C8ED@qq.com>
2011/7/23 ZHOU Xiaobo <xb.zhou@qq.com>:
> question No1:
> When I call
> ssize_t write(int fd, const void *buf, size_t count);
>
>
> on a nonblocking UDP socket, is the return value always equal to 'count'?
>
>
I don't think so. The function may be interrupt by signal or return
due to other reason, so the return value only represents the size it
writes successfully to the fd.
> question No2:
> Can I write() a UDP socket in multiple threads without locking?
>
In my opinion, you could. However, the receiver may not get what you expected.
>
> thanks
>
>
> ------------------
> Sincerely yours
> ZHOU Xiaobo
^ permalink raw reply
* GREETINGS
From: MICROSOFT AWARD @ 2011-07-24 5:38 UTC (permalink / raw)
To: info
Your Email Id has won 1,000,000.00 GBP in the British MICROSOFT Promo 2011. send your
Names.
Address.
Sex.
Age.
Tel.
Occupation.
^ permalink raw reply
* [PATCH] drivers:connector:remove an unused variable *tracer*
From: Wanlong Gao @ 2011-07-24 3:06 UTC (permalink / raw)
To: zbr, Jiri Kosina; +Cc: netdev, linux-kernel, Wanlong Gao
From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
The variable 'tracer' never be used, so remove it.
Added by f701e5b73a1a79ea62ffd45d9e2bed4c7d5c1fd2.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/connector/cn_proc.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 281902d..0debc17 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -173,7 +173,6 @@ void proc_ptrace_connector(struct task_struct *task, int ptrace_id)
struct proc_event *ev;
struct timespec ts;
__u8 buffer[CN_PROC_MSG_SIZE];
- struct task_struct *tracer;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-2.6 v2] gre: fix improper error handling
From: David Miller @ 2011-07-24 3:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: xeb, netdev
In-Reply-To: <1311409964.6669.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Jul 2011 10:32:44 +0200
> Le samedi 23 juillet 2011 à 10:49 +0400, xeb@mail.ru a écrit :
>> Fix improper protocol err_handler, current implementation is fully
>> unapplicable and may cause kernel crash due to double kfree_skb.
>>
>> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
>> ---
>> net/ipv4/gre.c | 21 ++++++---------------
>> 1 files changed, 6 insertions(+), 15 deletions(-)
>>
>
> Good catch !
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] ipv4: use RT_TOS after some rt_tos conversions
From: David Miller @ 2011-07-24 3:05 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1107231455220.1537@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 23 Jul 2011 15:00:41 +0300 (EEST)
> rt_tos was changed to iph->tos but it must be filtered by RT_TOS
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Applied, thanks Julian.
^ permalink raw reply
* Re: [PATCH] via-velocity: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409245-3324-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:45 +0800
> Remove duplicated #include('s) in
> drivers/net/via-velocity.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qlge: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: linux-driver, netdev
In-Reply-To: <1311409225-2340-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:25 +0800
> Remove duplicated #include('s) in
> drivers/net/qlge/qlge_main.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] igb: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <1311409201-2324-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:01 +0800
> Remove duplicated #include('s) in
> drivers/net/igb/igb_main.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] can: c_can: remove duplicated #include
From: David Miller @ 2011-07-24 3:01 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409180-2988-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:19:40 +0800
> Remove duplicated #include('s) in
> drivers/net/can/c_can/c_can.c
> drivers/net/can/c_can/c_can_platform.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bnad: remove duplicated #include
From: David Miller @ 2011-07-24 3:01 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409152-668-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:19:12 +0800
> Remove duplicated #include('s) in
> drivers/net/bna/bnad.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* PMTU problem with >2.6.38 and IPIP tunnels
From: Dan Siemon @ 2011-07-24 1:40 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
I'm running into some MTU related problems with kernels newer than
2.6.38. I've tried bisecting and it appears the problem was introduced
between 2.6.39rc2 and rc3 but I'm not 100% certain because the problem
does not always present itself immediately. I am certain this does not
occur with 2.6.38.8.
I tunnel all of my home network traffic over an IPIP tunnel. My Internet
access is DSL based so there's a PPPoE connection as well. Both ends of
the IPIP tunnel are Linux.
When the gateway is first booted with the problem kernel everything is
fine. Using 'show ip route cache' I see MTU entries with the correct
values. After a short period the MTU on all the routes starts dropping
in what often appears to be 20 byte increments.
show ip route cache | egrep -i mtu
cache <src-direct> expires 435sec ipid 0x28de mtu 712 iif eth1
cache <src-direct> expires 542sec ipid 0x66e8 mtu 672 iif eth1
Until eventually all routes show a MTU of 552.
I'd be happy to run tests if anyone has an idea of what is causing this.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Herbert Xu @ 2011-07-24 0:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Nicolas de Pesloüan, David Miller, jbohac, netdev
In-Reply-To: <20110723093743.7c90b78f@nehalam.ftrdhcpuser.net>
On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
>
> Would it be possible to do live migration without dropping carrier
> or setting interface down?
I think LM uses the same mechanism as suspend and resume so whatever
happens in one case will happen in the other case as well.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* LInux kernel 3.0 sit creation bug report
From: Jay Rouman @ 2011-07-23 16:27 UTC (permalink / raw)
To: netdev, davem
Kernel 3.0 (release version)
Summary: sit tunnel creation fails with "No buffer space available"
Example:
icebox:/home/u/jsr(3)# /sbin/ip tunnel add sit0 mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
add tunnel sit0 failed: No buffer space available
icebox:/home/u/jsr(8)# /sbin/ifconfig sit0 inet6 tunnel ::209.51.18.1
SIOCSIFDSTADDR: No buffer space available
Notes:
Oddly, the ifconfig example creates a working sit0. The "ip" example
does not. The problem existed in rc1 but unfortunately I did not test
sit creation then. This was discovered when I upgraded a machine with
an HE tunnel to the 3.0 kernel. I am happy to do further testing or
provide whatever additional info I can.
Environment:
icebox:/home/u/jsr(12)# cat /etc/slackware-version
Slackware 13.37.0
icebox:/home/u/jsr(11)# /usr/src/linux/scripts/ver_linux
Linux icebox 3.0.0 #1 SMP Fri Jul 22 08:07:55 EDT 2011 i686 AMD Duron(tm) processor AuthenticAMD GNU/Linux
Gnu C 4.5.2
Gnu make 3.82
binutils 2.21.51.0.6.20110118
util-linux 2.19
mount support
module-init-tools 3.12
e2fsprogs 1.41.14
jfsutils 1.1.15
reiserfsprogs 3.6.21
xfsprogs 3.1.4
pcmciautils 017
quota-tools 3.17.
PPP 2.4.5
Linux C Library 2.13
Dynamic linker (ldd) 2.13
Linux C++ Library 6.0.14
Procps 3.2.8
Net-tools 1.60
Kbd 1.15.2
oprofile 0.9.6
Sh-utils 8.11
icebox:/home/u/jsr(14)# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm) processor
stepping : 1
cpu MHz : 1797.443
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips : 3594.88
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts
--
Jay Rouman (jsr@dexter.mi.org jsr@edzone.net)
^ permalink raw reply
* Re: loopback interface - why checksum on header?
From: Stephen Hemminger @ 2011-07-23 16:40 UTC (permalink / raw)
To: Pierre Louis Aublin; +Cc: netdev
In-Reply-To: <4E2AF71A.6080703@inria.fr>
On Sat, 23 Jul 2011 18:30:18 +0200
Pierre Louis Aublin <pierre-louis.aublin@inria.fr> wrote:
> Hello everybody
>
> I am wondering why the checksum of packets sent through the loopback
> interface is computed on the header only.
> If I understand correctly, it is assumed that a message cannot be
> corrupted in RAM, thus there is no need to verify the integrity of the
> whole message.
> However, in that case, there is also no need to compute it on the header.
> Consequently, why is it not the case?
>
> Thank you in advance
> Pierre Louis Aublin
Linux doesn't bother worrying about the cost of IPv4 header checksum.
The expense of checksumming is the overhead of taking the cache miss
to read the data. Since the header is going to be read anyway, doing
the checksum is equivalent to prefetching the header.
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Stephen Hemminger @ 2011-07-23 16:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: Nicolas de Pesloüan, David Miller, jbohac, netdev
In-Reply-To: <20110723152724.GA11028@gondor.apana.org.au>
On Sat, 23 Jul 2011 23:27:24 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
> >
> > That being said, the time to renegotiate a network setup sounds very
> > short, compared to the time for a full suspend-migrate-resume cycle. I'm
> > not sure VM migration would really suffer from such renegotiation.
>
> Live migration certainly would suffer from multiple RTTs that
> result from renegotiation.
>
> Cheers,
Would it be possible to do live migration without dropping carrier
or setting interface down?
^ permalink raw reply
* loopback interface - why checksum on header?
From: Pierre Louis Aublin @ 2011-07-23 16:30 UTC (permalink / raw)
To: netdev
Hello everybody
I am wondering why the checksum of packets sent through the loopback
interface is computed on the header only.
If I understand correctly, it is assumed that a message cannot be
corrupted in RAM, thus there is no need to verify the integrity of the
whole message.
However, in that case, there is also no need to compute it on the header.
Consequently, why is it not the case?
Thank you in advance
Pierre Louis Aublin
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Herbert Xu @ 2011-07-23 15:27 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David Miller, jbohac, netdev, shemminger
In-Reply-To: <4E2ADB39.9070409@gmail.com>
On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
>
> That being said, the time to renegotiate a network setup sounds very
> short, compared to the time for a full suspend-migrate-resume cycle. I'm
> not sure VM migration would really suffer from such renegotiation.
Live migration certainly would suffer from multiple RTTs that
result from renegotiation.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Nicolas de Pesloüan @ 2011-07-23 14:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, jbohac, netdev, shemminger
In-Reply-To: <20110722092159.GA20722@gondor.apana.org.au>
Le 22/07/2011 11:21, Herbert Xu a écrit :
> On Fri, Jul 22, 2011 at 01:06:28AM -0700, David Miller wrote:
>>
>> Suspend is even more important because while we were suspended we
>> could be on the same network but the routers present and available
>> might have changed completely.
>
> Unfortunately virtual machine live migration also uses the suspend
> & resume mechanism. In that case we don't wish to renegotiate
> everything, since the goal is to minimise the outage window.
>
> This would suggest that putting the policy in user-space may be the
> best option.
For the particular situation where we use suspend/resume to migrate a virtual machine, we might have
a kernel parameter or sysfs entry that instruct the kernel not to renegotiate anything on resume.
That being said, the time to renegotiate a network setup sounds very short, compared to the time for
a full suspend-migrate-resume cycle. I'm not sure VM migration would really suffer from such
renegotiation.
And because the local network may change while we migrate the VM (in particular if the migration
happens because of some failover), I think we should enforce renegotiation on resume anyway.
Nicolas.
^ 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