* Re: [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Ivan Vecera @ 2013-10-15 14:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sathya Perla, netdev
In-Reply-To: <1381844840.2045.37.camel@edumazet-glaptop.roam.corp.google.com>
On 10/15/2013 03:47 PM, Eric Dumazet wrote:
> On Tue, 2013-10-15 at 17:26 +0530, Sathya Perla wrote:
>> From: Vasundhara Volam <vasundhara.volam@emulex.com>
>>
>> Pktgen can generate non-TSO frames of arbitrary length disregarding
>> the MTU value of the physical interface. Drop such frames in the driver
>> instead of sending them to HW as it cannot handle such frames.
>>
>> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
>> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
>> ---
>> drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
>> 1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
>> index 2c38cc4..76057b8 100644
>> --- a/drivers/net/ethernet/emulex/benet/be_main.c
>> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
>> @@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
>> unsigned int eth_hdr_len;
>> struct iphdr *ip;
>>
>> + /* Don't allow non-TSO packets longer than MTU */
>> + eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
>> + VLAN_ETH_HLEN : ETH_HLEN;
>> + if (!skb_is_gso(skb) &&
>> + (skb->len - eth_hdr_len) > adapter->netdev->mtu)
>> + goto tx_drop;
>> +
>
> When you say 'cannot handle them', is it some kind of nasty thing like
> hang / crash ?
AFAIK, the firmware in the card becomes unresponsive and reboot is
needed to make the NIC working.
Ivan
^ permalink raw reply
* Re: DomU's network interface will hung when Dom0 running 32bit
From: jianhai luan @ 2013-10-15 14:29 UTC (permalink / raw)
To: Wei Liu; +Cc: Ian Campbell, xen-devel, netdev, ANNIE LI
In-Reply-To: <20131015125802.GR11739@zion.uk.xensource.com>
On 2013-10-15 20:58, Wei Liu wrote:
> On Tue, Oct 15, 2013 at 07:26:31PM +0800, jianhai luan wrote:
> [...]
>>>>> Can you propose a patch?
>>>> Because credit_timeout.expire always after jiffies, i judge the
>>>> value over the range of time_after_eq() by time_before(now,
>>>> vif->credit_timeout.expires). please check the patch.
>>> I don't think this really fix the issue for you. You still have chance
>>> that now wraps around and falls between expires and next_credit. In that
>>> case it's stalled again.
>> if time_before(now, vif->credit_timeout.expires) is true, time wrap
>> and do operation. Otherwise time_before(now,
>> vif->credit_timeout.expires) isn't true, now -
>> vif->credit_timeout.expires should be letter than ULONG_MAX/2.
>> Because next_credit large than vif->credit_timeout.expires
>> (next_crdit = vif->credit_timeout.expires +
>> msecs_to_jiffies(vif->credit_usec/1000)), the delta between now and
>> next_credit should be in range of time_after_eq(). So
>> time_after_eq() do correctly judge.
>>
> Not sure I understand you. Consider "now" is placed like this:
>
> expires now next_credit
> ----time increases this direction--->
>
> * time_after_eq(now, next_credit) -> false
> * time_before(now, expires) -> false
If now is placed in above environment, the result will be correct
(Sending package will be not allowed until next_credit).
* time_after_eq(now, next_credit) --> false will include two environment:
expires now next_credit
-----------time increases this direction ---->
Or
expires next_credit next_credit + MAX_LONG/2 now
-----------time increases this direction ---->
the first environment should be correct to control transmit. the second
environment is our included environment.
Jason
>
> Then it's stuck again. You're merely narrowing the window, not fixing
> the real problem.
>
> Wei.
>
>> Jason
>>> Wei.
^ permalink raw reply
* [PATCH net 9/9] bnx2x: Set NETIF_F_HIGHDMA unconditionally
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Merav Sicron, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Merav Sicron <meravs@broadcom.com>
Current driver implementation incorrectly sets the flag only if 64-bit
DMA mask succeeded.
Signed-off-by: Merav Sicron <meravs@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 310c57a..c5e375d 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1528,7 +1528,6 @@ struct bnx2x {
#define PCI_32BIT_FLAG (1 << 1)
#define ONE_PORT_FLAG (1 << 2)
#define NO_WOL_FLAG (1 << 3)
-#define USING_DAC_FLAG (1 << 4)
#define USING_MSIX_FLAG (1 << 5)
#define USING_MSI_FLAG (1 << 6)
#define DISABLE_MSI_FLAG (1 << 7)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index fdc65e6..a3747d1 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12109,7 +12109,6 @@ static int bnx2x_set_coherency_mask(struct bnx2x *bp)
struct device *dev = &bp->pdev->dev;
if (dma_set_mask(dev, DMA_BIT_MASK(64)) == 0) {
- bp->flags |= USING_DAC_FLAG;
if (dma_set_coherent_mask(dev, DMA_BIT_MASK(64)) != 0) {
dev_err(dev, "dma_set_coherent_mask failed, aborting\n");
return -EIO;
@@ -12277,8 +12276,7 @@ static int bnx2x_init_dev(struct bnx2x *bp, struct pci_dev *pdev,
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_HIGHDMA;
dev->features |= dev->hw_features | NETIF_F_HW_VLAN_CTAG_RX;
- if (bp->flags & USING_DAC_FLAG)
- dev->features |= NETIF_F_HIGHDMA;
+ dev->features |= NETIF_F_HIGHDMA;
/* Add Loopback capability to the device */
dev->hw_features |= NETIF_F_LOOPBACK;
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 8/9] bnx2x: Don't pretend during register dump
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
As part of a register dump, the interface pretends to have the identity
of other interfaces of the same physical device in order to perform
HW configuration for them - specifically, it needs to prevent attentions
from generating on those functions as the register dump accesses registers
in common blocks which whose reading might generate an attention.
However, such pretension is unsafe - unlike other flows in which the driver
uses pretend, during register dump there is no guarantee no other HW access
will take place (by other flows). If such access will take place, the HW will
be accessed by the wrong interface, and leave both functions in an incorrect
state.
This patch removes all pretensions from the register dump flow. Instead, it
changes initial configuration of attentions such that no fatal attention will
be generated for other functions as a result of the register dump
(notice however, a debug print claiming an attention from other functions IS
possible during the register dump)
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
.../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 40 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h | 38 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 328 +++++++++++----------
3 files changed, 201 insertions(+), 205 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 324de5f..e8efa1c9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -891,17 +891,8 @@ static void bnx2x_get_regs(struct net_device *dev,
* will re-enable parity attentions right after the dump.
*/
- /* Disable parity on path 0 */
- bnx2x_pretend_func(bp, 0);
bnx2x_disable_blocks_parity(bp);
- /* Disable parity on path 1 */
- bnx2x_pretend_func(bp, 1);
- bnx2x_disable_blocks_parity(bp);
-
- /* Return to current function */
- bnx2x_pretend_func(bp, BP_ABS_FUNC(bp));
-
dump_hdr.header_size = (sizeof(struct dump_header) / 4) - 1;
dump_hdr.preset = DUMP_ALL_PRESETS;
dump_hdr.version = BNX2X_DUMP_VERSION;
@@ -928,18 +919,9 @@ static void bnx2x_get_regs(struct net_device *dev,
/* Actually read the registers */
__bnx2x_get_regs(bp, p);
- /* Re-enable parity attentions on path 0 */
- bnx2x_pretend_func(bp, 0);
+ /* Re-enable parity attentions */
bnx2x_clear_blocks_parity(bp);
bnx2x_enable_blocks_parity(bp);
-
- /* Re-enable parity attentions on path 1 */
- bnx2x_pretend_func(bp, 1);
- bnx2x_clear_blocks_parity(bp);
- bnx2x_enable_blocks_parity(bp);
-
- /* Return to current function */
- bnx2x_pretend_func(bp, BP_ABS_FUNC(bp));
}
static int bnx2x_get_preset_regs_len(struct net_device *dev, u32 preset)
@@ -993,17 +975,8 @@ static int bnx2x_get_dump_data(struct net_device *dev,
* will re-enable parity attentions right after the dump.
*/
- /* Disable parity on path 0 */
- bnx2x_pretend_func(bp, 0);
bnx2x_disable_blocks_parity(bp);
- /* Disable parity on path 1 */
- bnx2x_pretend_func(bp, 1);
- bnx2x_disable_blocks_parity(bp);
-
- /* Return to current function */
- bnx2x_pretend_func(bp, BP_ABS_FUNC(bp));
-
dump_hdr.header_size = (sizeof(struct dump_header) / 4) - 1;
dump_hdr.preset = bp->dump_preset_idx;
dump_hdr.version = BNX2X_DUMP_VERSION;
@@ -1032,19 +1005,10 @@ static int bnx2x_get_dump_data(struct net_device *dev,
/* Actually read the registers */
__bnx2x_get_preset_regs(bp, p, dump_hdr.preset);
- /* Re-enable parity attentions on path 0 */
- bnx2x_pretend_func(bp, 0);
+ /* Re-enable parity attentions */
bnx2x_clear_blocks_parity(bp);
bnx2x_enable_blocks_parity(bp);
- /* Re-enable parity attentions on path 1 */
- bnx2x_pretend_func(bp, 1);
- bnx2x_clear_blocks_parity(bp);
- bnx2x_enable_blocks_parity(bp);
-
- /* Return to current function */
- bnx2x_pretend_func(bp, BP_ABS_FUNC(bp));
-
return 0;
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
index 76df015..c2dfea7 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_init.h
@@ -640,23 +640,35 @@ static const struct {
* [30] MCP Latched ump_tx_parity
* [31] MCP Latched scpad_parity
*/
-#define MISC_AEU_ENABLE_MCP_PRTY_BITS \
+#define MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS \
(AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY | \
AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY | \
- AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY | \
+ AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY)
+
+#define MISC_AEU_ENABLE_MCP_PRTY_BITS \
+ (MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS | \
AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY)
/* Below registers control the MCP parity attention output. When
* MISC_AEU_ENABLE_MCP_PRTY_BITS are set - attentions are
* enabled, when cleared - disabled.
*/
-static const u32 mcp_attn_ctl_regs[] = {
- MISC_REG_AEU_ENABLE4_FUNC_0_OUT_0,
- MISC_REG_AEU_ENABLE4_NIG_0,
- MISC_REG_AEU_ENABLE4_PXP_0,
- MISC_REG_AEU_ENABLE4_FUNC_1_OUT_0,
- MISC_REG_AEU_ENABLE4_NIG_1,
- MISC_REG_AEU_ENABLE4_PXP_1
+static const struct {
+ u32 addr;
+ u32 bits;
+} mcp_attn_ctl_regs[] = {
+ { MISC_REG_AEU_ENABLE4_FUNC_0_OUT_0,
+ MISC_AEU_ENABLE_MCP_PRTY_BITS },
+ { MISC_REG_AEU_ENABLE4_NIG_0,
+ MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS },
+ { MISC_REG_AEU_ENABLE4_PXP_0,
+ MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS },
+ { MISC_REG_AEU_ENABLE4_FUNC_1_OUT_0,
+ MISC_AEU_ENABLE_MCP_PRTY_BITS },
+ { MISC_REG_AEU_ENABLE4_NIG_1,
+ MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS },
+ { MISC_REG_AEU_ENABLE4_PXP_1,
+ MISC_AEU_ENABLE_MCP_PRTY_SUB_BITS }
};
static inline void bnx2x_set_mcp_parity(struct bnx2x *bp, u8 enable)
@@ -665,14 +677,14 @@ static inline void bnx2x_set_mcp_parity(struct bnx2x *bp, u8 enable)
u32 reg_val;
for (i = 0; i < ARRAY_SIZE(mcp_attn_ctl_regs); i++) {
- reg_val = REG_RD(bp, mcp_attn_ctl_regs[i]);
+ reg_val = REG_RD(bp, mcp_attn_ctl_regs[i].addr);
if (enable)
- reg_val |= MISC_AEU_ENABLE_MCP_PRTY_BITS;
+ reg_val |= mcp_attn_ctl_regs[i].bits;
else
- reg_val &= ~MISC_AEU_ENABLE_MCP_PRTY_BITS;
+ reg_val &= ~mcp_attn_ctl_regs[i].bits;
- REG_WR(bp, mcp_attn_ctl_regs[i], reg_val);
+ REG_WR(bp, mcp_attn_ctl_regs[i].addr, reg_val);
}
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 173508c..fdc65e6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -4288,65 +4288,60 @@ static void _print_next_block(int idx, const char *blk)
pr_cont("%s%s", idx ? ", " : "", blk);
}
-static int bnx2x_check_blocks_with_parity0(struct bnx2x *bp, u32 sig,
- int par_num, bool print)
+static bool bnx2x_check_blocks_with_parity0(struct bnx2x *bp, u32 sig,
+ int *par_num, bool print)
{
- int i = 0;
- u32 cur_bit = 0;
+ u32 cur_bit;
+ bool res;
+ int i;
+
+ res = false;
+
for (i = 0; sig; i++) {
- cur_bit = ((u32)0x1 << i);
+ cur_bit = (0x1UL << i);
if (sig & cur_bit) {
- switch (cur_bit) {
- case AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "BRB");
+ res |= true; /* Each bit is real error! */
+
+ if (print) {
+ switch (cur_bit) {
+ case AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR:
+ _print_next_block((*par_num)++, "BRB");
_print_parity(bp,
BRB1_REG_BRB1_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "PARSER");
+ break;
+ case AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR:
+ _print_next_block((*par_num)++,
+ "PARSER");
_print_parity(bp, PRS_REG_PRS_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "TSDM");
+ break;
+ case AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR:
+ _print_next_block((*par_num)++, "TSDM");
_print_parity(bp,
TSDM_REG_TSDM_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++,
+ break;
+ case AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR:
+ _print_next_block((*par_num)++,
"SEARCHER");
_print_parity(bp, SRC_REG_SRC_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "TCM");
- _print_parity(bp,
- TCM_REG_TCM_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "TSEMI");
+ break;
+ case AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR:
+ _print_next_block((*par_num)++, "TCM");
+ _print_parity(bp, TCM_REG_TCM_PRTY_STS);
+ break;
+ case AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR:
+ _print_next_block((*par_num)++,
+ "TSEMI");
_print_parity(bp,
TSEM_REG_TSEM_PRTY_STS_0);
_print_parity(bp,
TSEM_REG_TSEM_PRTY_STS_1);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "XPB");
+ break;
+ case AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR:
+ _print_next_block((*par_num)++, "XPB");
_print_parity(bp, GRCBASE_XPB +
PB_REG_PB_PRTY_STS);
+ break;
}
- break;
}
/* Clear the bit */
@@ -4354,53 +4349,59 @@ static int bnx2x_check_blocks_with_parity0(struct bnx2x *bp, u32 sig,
}
}
- return par_num;
+ return res;
}
-static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
- int par_num, bool *global,
+static bool bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
+ int *par_num, bool *global,
bool print)
{
- int i = 0;
- u32 cur_bit = 0;
+ u32 cur_bit;
+ bool res;
+ int i;
+
+ res = false;
+
for (i = 0; sig; i++) {
- cur_bit = ((u32)0x1 << i);
+ cur_bit = (0x1UL << i);
if (sig & cur_bit) {
+ res |= true; /* Each bit is real error! */
switch (cur_bit) {
case AEU_INPUTS_ATTN_BITS_PBF_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "PBF");
+ _print_next_block((*par_num)++, "PBF");
_print_parity(bp, PBF_REG_PBF_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_QM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "QM");
+ _print_next_block((*par_num)++, "QM");
_print_parity(bp, QM_REG_QM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_TIMERS_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "TM");
+ _print_next_block((*par_num)++, "TM");
_print_parity(bp, TM_REG_TM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_XSDM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "XSDM");
+ _print_next_block((*par_num)++, "XSDM");
_print_parity(bp,
XSDM_REG_XSDM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_XCM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "XCM");
+ _print_next_block((*par_num)++, "XCM");
_print_parity(bp, XCM_REG_XCM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_XSEMI_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "XSEMI");
+ _print_next_block((*par_num)++,
+ "XSEMI");
_print_parity(bp,
XSEM_REG_XSEM_PRTY_STS_0);
_print_parity(bp,
@@ -4409,7 +4410,7 @@ static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
break;
case AEU_INPUTS_ATTN_BITS_DOORBELLQ_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++,
+ _print_next_block((*par_num)++,
"DOORBELLQ");
_print_parity(bp,
DORQ_REG_DORQ_PRTY_STS);
@@ -4417,7 +4418,7 @@ static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
break;
case AEU_INPUTS_ATTN_BITS_NIG_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "NIG");
+ _print_next_block((*par_num)++, "NIG");
if (CHIP_IS_E1x(bp)) {
_print_parity(bp,
NIG_REG_NIG_PRTY_STS);
@@ -4431,32 +4432,34 @@ static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
break;
case AEU_INPUTS_ATTN_BITS_VAUX_PCI_CORE_PARITY_ERROR:
if (print)
- _print_next_block(par_num++,
+ _print_next_block((*par_num)++,
"VAUX PCI CORE");
*global = true;
break;
case AEU_INPUTS_ATTN_BITS_DEBUG_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "DEBUG");
+ _print_next_block((*par_num)++,
+ "DEBUG");
_print_parity(bp, DBG_REG_DBG_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_USDM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "USDM");
+ _print_next_block((*par_num)++, "USDM");
_print_parity(bp,
USDM_REG_USDM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_UCM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "UCM");
+ _print_next_block((*par_num)++, "UCM");
_print_parity(bp, UCM_REG_UCM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_USEMI_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "USEMI");
+ _print_next_block((*par_num)++,
+ "USEMI");
_print_parity(bp,
USEM_REG_USEM_PRTY_STS_0);
_print_parity(bp,
@@ -4465,21 +4468,21 @@ static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
break;
case AEU_INPUTS_ATTN_BITS_UPB_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "UPB");
+ _print_next_block((*par_num)++, "UPB");
_print_parity(bp, GRCBASE_UPB +
PB_REG_PB_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_CSDM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "CSDM");
+ _print_next_block((*par_num)++, "CSDM");
_print_parity(bp,
CSDM_REG_CSDM_PRTY_STS);
}
break;
case AEU_INPUTS_ATTN_BITS_CCM_PARITY_ERROR:
if (print) {
- _print_next_block(par_num++, "CCM");
+ _print_next_block((*par_num)++, "CCM");
_print_parity(bp, CCM_REG_CCM_PRTY_STS);
}
break;
@@ -4490,80 +4493,73 @@ static int bnx2x_check_blocks_with_parity1(struct bnx2x *bp, u32 sig,
}
}
- return par_num;
+ return res;
}
-static int bnx2x_check_blocks_with_parity2(struct bnx2x *bp, u32 sig,
- int par_num, bool print)
+static bool bnx2x_check_blocks_with_parity2(struct bnx2x *bp, u32 sig,
+ int *par_num, bool print)
{
- int i = 0;
- u32 cur_bit = 0;
+ u32 cur_bit;
+ bool res;
+ int i;
+
+ res = false;
+
for (i = 0; sig; i++) {
- cur_bit = ((u32)0x1 << i);
+ cur_bit = (0x1UL << i);
if (sig & cur_bit) {
- switch (cur_bit) {
- case AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "CSEMI");
+ res |= true; /* Each bit is real error! */
+ if (print) {
+ switch (cur_bit) {
+ case AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR:
+ _print_next_block((*par_num)++,
+ "CSEMI");
_print_parity(bp,
CSEM_REG_CSEM_PRTY_STS_0);
_print_parity(bp,
CSEM_REG_CSEM_PRTY_STS_1);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "PXP");
+ break;
+ case AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR:
+ _print_next_block((*par_num)++, "PXP");
_print_parity(bp, PXP_REG_PXP_PRTY_STS);
_print_parity(bp,
PXP2_REG_PXP2_PRTY_STS_0);
_print_parity(bp,
PXP2_REG_PXP2_PRTY_STS_1);
- }
- break;
- case AEU_IN_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR:
- if (print)
- _print_next_block(par_num++,
- "PXPPCICLOCKCLIENT");
- break;
- case AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "CFC");
+ break;
+ case AEU_IN_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR:
+ _print_next_block((*par_num)++,
+ "PXPPCICLOCKCLIENT");
+ break;
+ case AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR:
+ _print_next_block((*par_num)++, "CFC");
_print_parity(bp,
CFC_REG_CFC_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "CDU");
+ break;
+ case AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR:
+ _print_next_block((*par_num)++, "CDU");
_print_parity(bp, CDU_REG_CDU_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "DMAE");
+ break;
+ case AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR:
+ _print_next_block((*par_num)++, "DMAE");
_print_parity(bp,
DMAE_REG_DMAE_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "IGU");
+ break;
+ case AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR:
+ _print_next_block((*par_num)++, "IGU");
if (CHIP_IS_E1x(bp))
_print_parity(bp,
HC_REG_HC_PRTY_STS);
else
_print_parity(bp,
IGU_REG_IGU_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "MISC");
+ break;
+ case AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR:
+ _print_next_block((*par_num)++, "MISC");
_print_parity(bp,
MISC_REG_MISC_PRTY_STS);
+ break;
}
- break;
}
/* Clear the bit */
@@ -4571,40 +4567,49 @@ static int bnx2x_check_blocks_with_parity2(struct bnx2x *bp, u32 sig,
}
}
- return par_num;
+ return res;
}
-static int bnx2x_check_blocks_with_parity3(u32 sig, int par_num,
- bool *global, bool print)
+static bool bnx2x_check_blocks_with_parity3(struct bnx2x *bp, u32 sig,
+ int *par_num, bool *global,
+ bool print)
{
- int i = 0;
- u32 cur_bit = 0;
+ bool res = false;
+ u32 cur_bit;
+ int i;
+
for (i = 0; sig; i++) {
- cur_bit = ((u32)0x1 << i);
+ cur_bit = (0x1UL << i);
if (sig & cur_bit) {
switch (cur_bit) {
case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY:
if (print)
- _print_next_block(par_num++, "MCP ROM");
+ _print_next_block((*par_num)++,
+ "MCP ROM");
*global = true;
+ res |= true;
break;
case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY:
if (print)
- _print_next_block(par_num++,
+ _print_next_block((*par_num)++,
"MCP UMP RX");
*global = true;
+ res |= true;
break;
case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY:
if (print)
- _print_next_block(par_num++,
+ _print_next_block((*par_num)++,
"MCP UMP TX");
*global = true;
+ res |= true;
break;
case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY:
if (print)
- _print_next_block(par_num++,
+ _print_next_block((*par_num)++,
"MCP SCPAD");
- *global = true;
+ /* clear latched SCPAD PATIRY from MCP */
+ REG_WR(bp, MISC_REG_AEU_CLR_LATCH_SIGNAL,
+ 1UL << 10);
break;
}
@@ -4613,45 +4618,50 @@ static int bnx2x_check_blocks_with_parity3(u32 sig, int par_num,
}
}
- return par_num;
+ return res;
}
-static int bnx2x_check_blocks_with_parity4(struct bnx2x *bp, u32 sig,
- int par_num, bool print)
+static bool bnx2x_check_blocks_with_parity4(struct bnx2x *bp, u32 sig,
+ int *par_num, bool print)
{
- int i = 0;
- u32 cur_bit = 0;
+ u32 cur_bit;
+ bool res;
+ int i;
+
+ res = false;
+
for (i = 0; sig; i++) {
- cur_bit = ((u32)0x1 << i);
+ cur_bit = (0x1UL << i);
if (sig & cur_bit) {
- switch (cur_bit) {
- case AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "PGLUE_B");
+ res |= true; /* Each bit is real error! */
+ if (print) {
+ switch (cur_bit) {
+ case AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR:
+ _print_next_block((*par_num)++,
+ "PGLUE_B");
_print_parity(bp,
- PGLUE_B_REG_PGLUE_B_PRTY_STS);
- }
- break;
- case AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR:
- if (print) {
- _print_next_block(par_num++, "ATC");
+ PGLUE_B_REG_PGLUE_B_PRTY_STS);
+ break;
+ case AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR:
+ _print_next_block((*par_num)++, "ATC");
_print_parity(bp,
ATC_REG_ATC_PRTY_STS);
+ break;
}
- break;
}
-
/* Clear the bit */
sig &= ~cur_bit;
}
}
- return par_num;
+ return res;
}
static bool bnx2x_parity_attn(struct bnx2x *bp, bool *global, bool print,
u32 *sig)
{
+ bool res = false;
+
if ((sig[0] & HW_PRTY_ASSERT_SET_0) ||
(sig[1] & HW_PRTY_ASSERT_SET_1) ||
(sig[2] & HW_PRTY_ASSERT_SET_2) ||
@@ -4668,23 +4678,22 @@ static bool bnx2x_parity_attn(struct bnx2x *bp, bool *global, bool print,
if (print)
netdev_err(bp->dev,
"Parity errors detected in blocks: ");
- par_num = bnx2x_check_blocks_with_parity0(bp,
- sig[0] & HW_PRTY_ASSERT_SET_0, par_num, print);
- par_num = bnx2x_check_blocks_with_parity1(bp,
- sig[1] & HW_PRTY_ASSERT_SET_1, par_num, global, print);
- par_num = bnx2x_check_blocks_with_parity2(bp,
- sig[2] & HW_PRTY_ASSERT_SET_2, par_num, print);
- par_num = bnx2x_check_blocks_with_parity3(
- sig[3] & HW_PRTY_ASSERT_SET_3, par_num, global, print);
- par_num = bnx2x_check_blocks_with_parity4(bp,
- sig[4] & HW_PRTY_ASSERT_SET_4, par_num, print);
+ res |= bnx2x_check_blocks_with_parity0(bp,
+ sig[0] & HW_PRTY_ASSERT_SET_0, &par_num, print);
+ res |= bnx2x_check_blocks_with_parity1(bp,
+ sig[1] & HW_PRTY_ASSERT_SET_1, &par_num, global, print);
+ res |= bnx2x_check_blocks_with_parity2(bp,
+ sig[2] & HW_PRTY_ASSERT_SET_2, &par_num, print);
+ res |= bnx2x_check_blocks_with_parity3(bp,
+ sig[3] & HW_PRTY_ASSERT_SET_3, &par_num, global, print);
+ res |= bnx2x_check_blocks_with_parity4(bp,
+ sig[4] & HW_PRTY_ASSERT_SET_4, &par_num, print);
if (print)
pr_cont("\n");
+ }
- return true;
- } else
- return false;
+ return res;
}
/**
@@ -7134,7 +7143,7 @@ static int bnx2x_init_hw_port(struct bnx2x *bp)
int port = BP_PORT(bp);
int init_phase = port ? PHASE_PORT1 : PHASE_PORT0;
u32 low, high;
- u32 val;
+ u32 val, reg;
DP(NETIF_MSG_HW, "starting port init port %d\n", port);
@@ -7279,6 +7288,17 @@ static int bnx2x_init_hw_port(struct bnx2x *bp)
val |= CHIP_IS_E1(bp) ? 0 : 0x10;
REG_WR(bp, MISC_REG_AEU_MASK_ATTN_FUNC_0 + port*4, val);
+ /* SCPAD_PARITY should NOT trigger close the gates */
+ reg = port ? MISC_REG_AEU_ENABLE4_NIG_1 : MISC_REG_AEU_ENABLE4_NIG_0;
+ REG_WR(bp, reg,
+ REG_RD(bp, reg) &
+ ~AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY);
+
+ reg = port ? MISC_REG_AEU_ENABLE4_PXP_1 : MISC_REG_AEU_ENABLE4_PXP_0;
+ REG_WR(bp, reg,
+ REG_RD(bp, reg) &
+ ~AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY);
+
bnx2x_init_block(bp, BLOCK_NIG, init_phase);
if (!CHIP_IS_E1x(bp)) {
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 7/9] bnx2x: Lock DMAE when used by statistic flow
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Ariel Elior <ariele@broadcom.com>
bnx2x has several clients to its DMAE machines - all of them with the exception
of the statistics flow used the same locking mechanisms to synchronize the DMAE
machines' usage.
Since statistics (which are periodically entered) use DMAE without taking the
locks, they may erase the commands which were previously set -
e.g., it may cause a VF to timeout while waiting for a PF answer on the VF-PF
channel as that command header would have been overwritten by the statistics'
header.
This patch makes certain that all flows utilizing DMAE will use the same
API, assuring that the locking scheme will be kept by all said flows.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 3 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++-------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 2 +-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 275b126..310c57a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -2073,7 +2073,8 @@ u32 bnx2x_dmae_opcode(struct bnx2x *bp, u8 src_type, u8 dst_type,
void bnx2x_prep_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae,
u8 src_type, u8 dst_type);
-int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae);
+int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae,
+ u32 *comp);
/* FLR related routines */
u32 bnx2x_flr_clnup_poll_count(struct bnx2x *bp);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 3fd76b9..173508c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -503,9 +503,9 @@ void bnx2x_prep_dmae_with_comp(struct bnx2x *bp,
}
/* issue a dmae command over the init-channel and wait for completion */
-int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae)
+int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae,
+ u32 *comp)
{
- u32 *wb_comp = bnx2x_sp(bp, wb_comp);
int cnt = CHIP_REV_IS_SLOW(bp) ? (400000) : 4000;
int rc = 0;
@@ -518,14 +518,14 @@ int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae)
spin_lock_bh(&bp->dmae_lock);
/* reset completion */
- *wb_comp = 0;
+ *comp = 0;
/* post the command on the channel used for initializations */
bnx2x_post_dmae(bp, dmae, INIT_DMAE_C(bp));
/* wait for completion */
udelay(5);
- while ((*wb_comp & ~DMAE_PCI_ERR_FLAG) != DMAE_COMP_VAL) {
+ while ((*comp & ~DMAE_PCI_ERR_FLAG) != DMAE_COMP_VAL) {
if (!cnt ||
(bp->recovery_state != BNX2X_RECOVERY_DONE &&
@@ -537,7 +537,7 @@ int bnx2x_issue_dmae_with_comp(struct bnx2x *bp, struct dmae_command *dmae)
cnt--;
udelay(50);
}
- if (*wb_comp & DMAE_PCI_ERR_FLAG) {
+ if (*comp & DMAE_PCI_ERR_FLAG) {
BNX2X_ERR("DMAE PCI error!\n");
rc = DMAE_PCI_ERROR;
}
@@ -574,7 +574,7 @@ void bnx2x_write_dmae(struct bnx2x *bp, dma_addr_t dma_addr, u32 dst_addr,
dmae.len = len32;
/* issue the command and wait for completion */
- rc = bnx2x_issue_dmae_with_comp(bp, &dmae);
+ rc = bnx2x_issue_dmae_with_comp(bp, &dmae, bnx2x_sp(bp, wb_comp));
if (rc) {
BNX2X_ERR("DMAE returned failure %d\n", rc);
bnx2x_panic();
@@ -611,7 +611,7 @@ void bnx2x_read_dmae(struct bnx2x *bp, u32 src_addr, u32 len32)
dmae.len = len32;
/* issue the command and wait for completion */
- rc = bnx2x_issue_dmae_with_comp(bp, &dmae);
+ rc = bnx2x_issue_dmae_with_comp(bp, &dmae, bnx2x_sp(bp, wb_comp));
if (rc) {
BNX2X_ERR("DMAE returned failure %d\n", rc);
bnx2x_panic();
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
index 86436c7..3b75070 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
@@ -196,7 +196,7 @@ static void bnx2x_hw_stats_post(struct bnx2x *bp)
} else if (bp->func_stx) {
*stats_comp = 0;
- bnx2x_post_dmae(bp, dmae, INIT_DMAE_C(bp));
+ bnx2x_issue_dmae_with_comp(bp, dmae, stats_comp);
}
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index da16953..28757df 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -980,7 +980,7 @@ static int bnx2x_copy32_vf_dmae(struct bnx2x *bp, u8 from_vf,
dmae.len = len32;
/* issue the command and wait for completion */
- return bnx2x_issue_dmae_with_comp(bp, &dmae);
+ return bnx2x_issue_dmae_with_comp(bp, &dmae, bnx2x_sp(bp, wb_comp));
}
static void bnx2x_vf_mbx_resp(struct bnx2x *bp, struct bnx2x_virtf *vf)
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net net 5/9] bnx2x: Fix config when SR-IOV and iSCSI are enabled
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Ariel Elior <ariele@broadcom.com>
Starting with commit b9871bc "bnx2x: VF RSS support - PF side", if a PF will
have SR-IOV supported in its PCI configuration space, storage drivers will not
work for that interface.
This patch fixes the resource calculation to allow such a configuration to
properly work.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 986edbf..275b126 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1197,8 +1197,9 @@ union cdu_context {
/* TM (timers) host DB constants */
#define TM_ILT_PAGE_SZ_HW 0
#define TM_ILT_PAGE_SZ (4096 << TM_ILT_PAGE_SZ_HW) /* 4K */
-/* #define TM_CONN_NUM (CNIC_STARTING_CID+CNIC_ISCSI_CXT_MAX) */
-#define TM_CONN_NUM 1024
+#define TM_CONN_NUM (BNX2X_FIRST_VF_CID + \
+ BNX2X_VF_CIDS + \
+ CNIC_ISCSI_CID_MAX)
#define TM_ILT_SZ (8 * TM_CONN_NUM)
#define TM_ILT_LINES DIV_ROUND_UP(TM_ILT_SZ, TM_ILT_PAGE_SZ)
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 6/9] bnx2x: Prevent null pointer dereference on error flow
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
If debug message is open and bnx2x_vfop_qdtor_cmd() were to fail,
the resulting print would have caused a null pointer dereference.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 997c661..bf08ad6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -470,10 +470,10 @@ static int bnx2x_vfop_qdtor_cmd(struct bnx2x *bp,
bnx2x_vfop_qdtor, cmd->done);
return bnx2x_vfop_transition(bp, vf, bnx2x_vfop_qdtor,
cmd->block);
+ } else {
+ BNX2X_ERR("VF[%d] failed to add a vfop\n", vf->abs_vfid);
+ return -ENOMEM;
}
- DP(BNX2X_MSG_IOV, "VF[%d] failed to add a vfop. rc %d\n",
- vf->abs_vfid, vfop->rc);
- return -ENOMEM;
}
static void
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 3/9] bnx2x: Unlock VF-PF channel on MAC/VLAN config error
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Ariel Elior <ariele@broadcom.com>
Current code returns upon failure, leaving the VF-PF in an unusable state;
This patch adds the missing release so further commands could pass between
PF and VF.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 9ad012b..997c661 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -3390,14 +3390,16 @@ int bnx2x_set_vf_mac(struct net_device *dev, int vfidx, u8 *mac)
rc = bnx2x_del_all_macs(bp, mac_obj, BNX2X_ETH_MAC, true);
if (rc) {
BNX2X_ERR("failed to delete eth macs\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* remove existing uc list macs */
rc = bnx2x_del_all_macs(bp, mac_obj, BNX2X_UC_LIST_MAC, true);
if (rc) {
BNX2X_ERR("failed to delete uc_list macs\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* configure the new mac to device */
@@ -3405,6 +3407,7 @@ int bnx2x_set_vf_mac(struct net_device *dev, int vfidx, u8 *mac)
bnx2x_set_mac_one(bp, (u8 *)&bulletin->mac, mac_obj, true,
BNX2X_ETH_MAC, &ramrod_flags);
+out:
bnx2x_unlock_vf_pf_channel(bp, vf, CHANNEL_TLV_PF_SET_MAC);
}
@@ -3467,7 +3470,8 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
&ramrod_flags);
if (rc) {
BNX2X_ERR("failed to delete vlans\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* send queue update ramrod to configure default vlan and silent
@@ -3501,7 +3505,8 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
rc = bnx2x_config_vlan_mac(bp, &ramrod_param);
if (rc) {
BNX2X_ERR("failed to configure vlan\n");
- return -EINVAL;
+ rc = -EINVAL;
+ goto out;
}
/* configure default vlan to vf queue and set silent
@@ -3519,18 +3524,18 @@ int bnx2x_set_vf_vlan(struct net_device *dev, int vfidx, u16 vlan, u8 qos)
rc = bnx2x_queue_state_change(bp, &q_params);
if (rc) {
BNX2X_ERR("Failed to configure default VLAN\n");
- return rc;
+ goto out;
}
/* clear the flag indicating that this VF needs its vlan
- * (will only be set if the HV configured th Vlan before vf was
- * and we were called because the VF came up later
+ * (will only be set if the HV configured the Vlan before vf was
+ * up and we were called because the VF came up later
*/
+out:
vf->cfg_flags &= ~VF_CFG_VLAN;
-
bnx2x_unlock_vf_pf_channel(bp, vf, CHANNEL_TLV_PF_SET_VLAN);
}
- return 0;
+ return rc;
}
/* crc is the first field in the bulletin board. Compute the crc over the
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 4/9] bnx2x: Fix Coalescing configuration
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
bnx2x drivers configure coalescing incorrectly (e.g., as a result of a call
to 'ethtool -c'). Although this is almost invisible to the user (due to NAPI)
designated tests will show the configuration is incorrect.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index d21742c..986edbf 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1621,7 +1621,7 @@ struct bnx2x {
u16 rx_ticks_int;
u16 rx_ticks;
/* Maximal coalescing timeout in us */
-#define BNX2X_MAX_COALESCE_TOUT (0xf0*12)
+#define BNX2X_MAX_COALESCE_TOUT (0xff*BNX2X_BTR)
u32 lin_cnt;
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 1/9] bnx2x: Fix Maximum CoS estimation for VFs
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
bnx2x VFs do not support Multi-CoS; Current implementation
erroneously sets the VFs maximal number of CoS to be > 1.
This will cause the driver to call alloc_etherdev_mqs() with
a number of queues it cannot possibly support and reflects
in 'odd' driver prints.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 82b658d..60f9e68 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12612,24 +12612,24 @@ static int set_max_cos_est(int chip_id)
return BNX2X_MULTI_TX_COS_E1X;
case BCM57712:
case BCM57712_MF:
- case BCM57712_VF:
return BNX2X_MULTI_TX_COS_E2_E3A0;
case BCM57800:
case BCM57800_MF:
- case BCM57800_VF:
case BCM57810:
case BCM57810_MF:
case BCM57840_4_10:
case BCM57840_2_20:
case BCM57840_O:
case BCM57840_MFO:
- case BCM57810_VF:
case BCM57840_MF:
- case BCM57840_VF:
case BCM57811:
case BCM57811_MF:
- case BCM57811_VF:
return BNX2X_MULTI_TX_COS_E3B0;
+ case BCM57712_VF:
+ case BCM57800_VF:
+ case BCM57810_VF:
+ case BCM57840_VF:
+ case BCM57811_VF:
return 1;
default:
pr_err("Unknown board_type (%d), aborting\n", chip_id);
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong, Dmitry Kravkov, Yuval Mintz
In-Reply-To: <1381847335-32662-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
During a panic, the driver tries to print the Management FW buffer of recent
commands. To do so, the driver reads the address of that buffer from a known
address. If the buffer is unavailable (e.g., PCI reads don't work, MCP is
failing, etc.), the driver will try to access the address it has read, possibly
causing a kernel panic.
This check 'sanitizes' the access, validating the read value is indeed a valid
address inside the management FW's buffers.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 4 ++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 19 ++++++++++++++-----
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 97b3d32..d21742c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -2498,4 +2498,8 @@ enum bnx2x_pci_bus_speed {
};
void bnx2x_set_local_cmng(struct bnx2x *bp);
+
+#define MCPR_SCRATCH_BASE(bp) \
+ (CHIP_IS_E1x(bp) ? MCP_REG_MCPR_SCRATCH : MCP_A_REG_MCPR_SCRATCH)
+
#endif /* bnx2x.h */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 60f9e68..3fd76b9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
trace_shmem_base = bp->common.shmem_base;
else
trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
+
+ /* sanity */
+ if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
+ trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
+ BNX2X_ERR("Unable to dump trace buffer (mark %x)\n",
+ trace_shmem_base);
+ return;
+ }
+
addr = trace_shmem_base - 0x800;
/* validate TRCB signature */
@@ -787,8 +796,7 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
/* read cyclic buffer pointer */
addr += 4;
mark = REG_RD(bp, addr);
- mark = (CHIP_IS_E1x(bp) ? MCP_REG_MCPR_SCRATCH : MCP_A_REG_MCPR_SCRATCH)
- + ((mark + 0x3) & ~0x3) - 0x08000000;
+ mark = MCPR_SCRATCH_BASE(bp) + ((mark + 0x3) & ~0x3) - 0x08000000;
printk("%s" "begin fw dump (mark 0x%x)\n", lvl, mark);
printk("%s", lvl);
@@ -11685,9 +11693,6 @@ static int bnx2x_init_bp(struct bnx2x *bp)
static int bnx2x_open(struct net_device *dev)
{
struct bnx2x *bp = netdev_priv(dev);
- bool global = false;
- int other_engine = BP_PATH(bp) ? 0 : 1;
- bool other_load_status, load_status;
int rc;
bp->stats_init = true;
@@ -11703,6 +11708,10 @@ static int bnx2x_open(struct net_device *dev)
* Parity recovery is only relevant for PF driver.
*/
if (IS_PF(bp)) {
+ int other_engine = BP_PATH(bp) ? 0 : 1;
+ bool other_load_status, load_status;
+ bool global = false;
+
other_load_status = bnx2x_get_load_status(bp, other_engine);
load_status = bnx2x_get_load_status(bp, BP_PATH(bp));
if (!bnx2x_reset_is_done(bp, BP_PATH(bp)) ||
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH] X.25: Fix address field length calculation
From: Kelleter, Günther @ 2013-10-15 14:29 UTC (permalink / raw)
To: andrew.hendry@gmail.com
Cc: davem@davemloft.net, linux-x25@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
Signed-off-by: Guenther Kelleter <gkelleter@datus.com>
---
Wrong length calculation leads to rejection of CALL ACCEPT packets.
net/x25/af_x25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 45a3ab5..2daf224 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -98,7 +98,7 @@ int x25_parse_address_block(struct sk_buff *skb,
}
len = *skb->data;
- needed = 1 + (len >> 4) + (len & 0x0f);
+ needed = 1 + ((len >> 4) + (len & 0x0f) + 1) / 2;
if (!pskb_may_pull(skb, needed)) {
/* packet is too short to hold the addresses it claims
--
1.8.3.4.71.g0878476
^ permalink raw reply related
* [PATCH net 0/9] bnx2x: Bug fixes patch series
From: Yuval Mintz @ 2013-10-15 14:28 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, eilong
Hi Dave,
This patch series contains fixes for various flows - several SR-IOV issues
are fixed, ethtool callbacks (coalescing and register dump) are corrected,
null pointer dereference on error flows is prevented, etc.
Please consider applying this series to 'net'.
Thanks,
Yuval Mintz
^ permalink raw reply
* Re: [PATCH] net: sctp: fix a cacc_saw_newack missetting issue
From: Chang @ 2013-10-15 14:27 UTC (permalink / raw)
To: Vlad Yasevich, nhorman; +Cc: davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <525D4D2D.8000506@gmail.com>
On 10/15/2013 04:11 PM, Vlad Yasevich wrote:
> On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
>> For for each TSN t being newly acked (Not only cumulatively,
>> but also SELECTIVELY) cacc_saw_newack should be set to 1.
>>
>> Signed-off-by: Xiangzhong Chang <changxiangzhong@gmail.com>
>> ---
>> net/sctp/outqueue.c | 42 +++++++++++++++++++++---------------------
>> 1 file changed, 21 insertions(+), 21 deletions(-)
>>
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index 94df758..d86032b 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -1398,6 +1398,27 @@ static void sctp_check_transmitted(struct
>> sctp_outq *q,
>> forward_progress = true;
>> }
>>
>> + if (!tchunk->tsn_gap_acked) {
>
> You can remove this test since the block just above already performs
> it. Just fold this code into the block above.
>
> -vlad
>
Sorry, I'm not sure if I fully understand you. There are code blocks
which checking the tchunk->tsn_gap_acked. In addition, they check other
states as well.
>> + /*
>> + * SFR-CACC algorithm:
>> + * 2) If the SACK contains gap acks
>> + * and the flag CHANGEOVER_ACTIVE is
>> + * set the receiver of the SACK MUST
>> + * take the following action:
>> + *
>> + * B) For each TSN t being acked that
>> + * has not been acked in any SACK so
>> + * far, set cacc_saw_newack to 1 for
>> + * the destination that the TSN was
>> + * sent to.
>> + */
>> + if (transport &&
>> + sack->num_gap_ack_blocks &&
>> + q->asoc->peer.primary_path->cacc.
>> + changeover_active)
>> + transport->cacc.cacc_saw_newack = 1;
>> + }
>> +
>> if (TSN_lte(tsn, sack_ctsn)) {
>> /* RFC 2960 6.3.2 Retransmission Timer Rules
>> *
>> @@ -1411,27 +1432,6 @@ static void sctp_check_transmitted(struct
>> sctp_outq *q,
>> restart_timer = 1;
>> forward_progress = true;
>>
>> - if (!tchunk->tsn_gap_acked) {
>> - /*
>> - * SFR-CACC algorithm:
>> - * 2) If the SACK contains gap acks
>> - * and the flag CHANGEOVER_ACTIVE is
>> - * set the receiver of the SACK MUST
>> - * take the following action:
>> - *
>> - * B) For each TSN t being acked that
>> - * has not been acked in any SACK so
>> - * far, set cacc_saw_newack to 1 for
>> - * the destination that the TSN was
>> - * sent to.
>> - */
>> - if (transport &&
>> - sack->num_gap_ack_blocks &&
>> - q->asoc->peer.primary_path->cacc.
>> - changeover_active)
>> - transport->cacc.cacc_saw_newack
>> - = 1;
>> - }
>>
>> list_add_tail(&tchunk->transmitted_list,
>> &q->sacked);
>>
>
^ permalink raw reply
* Re: [PATCH] net: sctp: fix a cacc_saw_newack missetting issue
From: Vlad Yasevich @ 2013-10-15 14:11 UTC (permalink / raw)
To: Chang Xiangzhong, nhorman; +Cc: davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <1381757623-12803-1-git-send-email-changxiangzhong@gmail.com>
On 10/14/2013 09:33 AM, Chang Xiangzhong wrote:
> For for each TSN t being newly acked (Not only cumulatively,
> but also SELECTIVELY) cacc_saw_newack should be set to 1.
>
> Signed-off-by: Xiangzhong Chang <changxiangzhong@gmail.com>
> ---
> net/sctp/outqueue.c | 42 +++++++++++++++++++++---------------------
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 94df758..d86032b 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1398,6 +1398,27 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> forward_progress = true;
> }
>
> + if (!tchunk->tsn_gap_acked) {
You can remove this test since the block just above already performs
it. Just fold this code into the block above.
-vlad
> + /*
> + * SFR-CACC algorithm:
> + * 2) If the SACK contains gap acks
> + * and the flag CHANGEOVER_ACTIVE is
> + * set the receiver of the SACK MUST
> + * take the following action:
> + *
> + * B) For each TSN t being acked that
> + * has not been acked in any SACK so
> + * far, set cacc_saw_newack to 1 for
> + * the destination that the TSN was
> + * sent to.
> + */
> + if (transport &&
> + sack->num_gap_ack_blocks &&
> + q->asoc->peer.primary_path->cacc.
> + changeover_active)
> + transport->cacc.cacc_saw_newack = 1;
> + }
> +
> if (TSN_lte(tsn, sack_ctsn)) {
> /* RFC 2960 6.3.2 Retransmission Timer Rules
> *
> @@ -1411,27 +1432,6 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> restart_timer = 1;
> forward_progress = true;
>
> - if (!tchunk->tsn_gap_acked) {
> - /*
> - * SFR-CACC algorithm:
> - * 2) If the SACK contains gap acks
> - * and the flag CHANGEOVER_ACTIVE is
> - * set the receiver of the SACK MUST
> - * take the following action:
> - *
> - * B) For each TSN t being acked that
> - * has not been acked in any SACK so
> - * far, set cacc_saw_newack to 1 for
> - * the destination that the TSN was
> - * sent to.
> - */
> - if (transport &&
> - sack->num_gap_ack_blocks &&
> - q->asoc->peer.primary_path->cacc.
> - changeover_active)
> - transport->cacc.cacc_saw_newack
> - = 1;
> - }
>
> list_add_tail(&tchunk->transmitted_list,
> &q->sacked);
>
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Vlad Yasevich @ 2013-10-15 13:55 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <1381680661.1831.16.camel@localhost.localdomain>
On 10/13/2013 12:11 PM, Toshiaki Makita wrote:
> On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
>> On 10/11/2013 03:34 AM, Toshiaki Makita wrote:
>>> On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote:
>>>> On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
>>>>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
>>>>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
>>>>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
>>>>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
>>>>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
>>>>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
>>>>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
>>>>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
>>>>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
>>>>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David
>>>>>>>>>>>>>>>>>>> Miller wrote:
>>>>>>>>>>>>>>>>>>>> From: Toshiaki Makita
>>>>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> Date: Tue,
>>>>>>>>>>>>>>>>>>>> 10 Sep 2013 19:27:54 +0900
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There seem to be some undesirable
>>>>>>>>>>>>>>>>>>>>> behaviors related with PVID. 1. It has no
>>>>>>>>>>>>>>>>>>>>> effect assigning PVID to a port. PVID
>>>>>>>>>>>>>>>>>>>>> cannot be applied to any frame regardless
>>>>>>>>>>>>>>>>>>>>> of whether we set it or not. 2. FDB
>>>>>>>>>>>>>>>>>>>>> entries learned via frames applied PVID
>>>>>>>>>>>>>>>>>>>>> are registered with VID 0 rather than VID
>>>>>>>>>>>>>>>>>>>>> value of PVID. 3. We can set 0 or 4095 as
>>>>>>>>>>>>>>>>>>>>> a PVID that are not allowed in IEEE
>>>>>>>>>>>>>>>>>>>>> 802.1Q. This leads interoperational
>>>>>>>>>>>>>>>>>>>>> problems such as sending frames with VID
>>>>>>>>>>>>>>>>>>>>> 4095, which is not allowed in IEEE
>>>>>>>>>>>>>>>>>>>>> 802.1Q, and treating frames with VID 0 as
>>>>>>>>>>>>>>>>>>>>> they belong to VLAN 0, which is expected
>>>>>>>>>>>>>>>>>>>>> to be handled as they have no VID
>>>>>>>>>>>>>>>>>>>>> according to IEEE 802.1Q.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential
>>>>>>>>>>>>>>>>>>>>> and not exposed unless 1st problem is
>>>>>>>>>>>>>>>>>>>>> fixed, because we cannot activate PVID
>>>>>>>>>>>>>>>>>>>>> due to it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please work out the issues in patch #2 with
>>>>>>>>>>>>>>>>>>>> Vlad and resubmit this series.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm hovering between whether we should fix
>>>>>>>>>>>>>>>>>>> the issue by changing vlan 0 interface
>>>>>>>>>>>>>>>>>>> behavior in 8021q module or enabling a bridge
>>>>>>>>>>>>>>>>>>> port to sending priority-tagged frames, or
>>>>>>>>>>>>>>>>>>> another better way.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you could comment it, I'd appreciate it
>>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW, I think what is discussed in patch #2 is
>>>>>>>>>>>>>>>>>>> another problem about handling priority-tags,
>>>>>>>>>>>>>>>>>>> and it exists without this patch set
>>>>>>>>>>>>>>>>>>> applied. It looks like that we should prepare
>>>>>>>>>>>>>>>>>>> another patch set than this to fix that
>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Should I include patches that fix the
>>>>>>>>>>>>>>>>>>> priority-tags problem in this patch set and
>>>>>>>>>>>>>>>>>>> resubmit them all together?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am thinking that we might need to do it in
>>>>>>>>>>>>>>>>>> bridge and it looks like the simplest way to do
>>>>>>>>>>>>>>>>>> it is to have default priority regeneration
>>>>>>>>>>>>>>>>>> table (table 6-5 from 802.1Q doc).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That way I think we would conform to the spec.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately I don't think the default priority
>>>>>>>>>>>>>>>>> regeneration table resolves the problem because
>>>>>>>>>>>>>>>>> IEEE 802.1Q says that a VLAN-aware bridge can
>>>>>>>>>>>>>>>>> transmit untagged or VLAN-tagged frames only (the
>>>>>>>>>>>>>>>>> end of section 7.5 and 8.1.7).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No mechanism to send priority-tagged frames is
>>>>>>>>>>>>>>>>> found as far as I can see the standard. I think
>>>>>>>>>>>>>>>>> the regenerated priority is used for outgoing
>>>>>>>>>>>>>>>>> PCP field only if egress policy is not untagged
>>>>>>>>>>>>>>>>> (i.e. transmitting as VLAN-tagged), and unused if
>>>>>>>>>>>>>>>>> untagged (Section 6.9.2 3rd/4th Paragraph).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If we want to transmit priority-tagged frames
>>>>>>>>>>>>>>>>> from a bridge port, I think we need to implement
>>>>>>>>>>>>>>>>> a new (optional) feature that is above the
>>>>>>>>>>>>>>>>> standard, as I stated previously.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How do you feel about adding a per-port policy
>>>>>>>>>>>>>>>>> that enables a bridge to send priority-tagged
>>>>>>>>>>>>>>>>> frames instead of untagged frames when egress
>>>>>>>>>>>>>>>>> policy for the port is untagged? With this
>>>>>>>>>>>>>>>>> change, we can transmit frames for a given vlan
>>>>>>>>>>>>>>>>> as either all untagged, all priority-tagged or
>>>>>>>>>>>>>>>>> all VLAN-tagged.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That would work. What I am thinking is that we do
>>>>>>>>>>>>>>>> it by special casing the vid 0 egress policy
>>>>>>>>>>>>>>>> specification. Let it be untagged by default and
>>>>>>>>>>>>>>>> if it is tagged, then we preserve the priority
>>>>>>>>>>>>>>>> field and forward it on.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This keeps the API stable and doesn't require
>>>>>>>>>>>>>>>> user/admin from knowing exactly what happens.
>>>>>>>>>>>>>>>> Default operation conforms to the spec and allows
>>>>>>>>>>>>>>>> simple change to make it backward-compatible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you think. I've done a simple prototype of
>>>>>>>>>>>>>>>> this an it seems to work with the VMs I am testing
>>>>>>>>>>>>>>>> with.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of
>>>>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and
>>>>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as
>>>>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If so, though it's attractive to keep current API,
>>>>>>>>>>>>>>> I'm worried about if it could be a bit confusing and
>>>>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID
>>>>>>>>>>>>>>> 0 has a special meaning only in the egress policy.
>>>>>>>>>>>>>>> Wouldn't it be better to adding a new member to
>>>>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of
>>>>>>>>>>>>>>> untagged_bitmap?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or are you saying that we use a new flag in struct
>>>>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED
>>>>>>>>>>>>>>> bit with VID 0 in netlink to set the flag?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Even in that case, I'm afraid that it might be
>>>>>>>>>>>>>>> confusing for developers for the same reason. We are
>>>>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in
>>>>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering
>>>>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a
>>>>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a
>>>>>>>>>>>>>>> new nlattr is a straightforward approach to
>>>>>>>>>>>>>>> configure it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a
>>>>>>>>>>>>>> special case for any automatic tool that would
>>>>>>>>>>>>>> provision such filtering. Seeing vid 0 would mean that
>>>>>>>>>>>>>> these tools would have to know that this would have to
>>>>>>>>>>>>>> be translated to a different attribute instead of
>>>>>>>>>>>>>> setting the policy values.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, I agree with you that we can do it by the way you
>>>>>>>>>>>>> explained. What I don't understand is the advantage of
>>>>>>>>>>>>> using vid 0 over another way such as adding a new
>>>>>>>>>>>>> nlattr. I think we can indicate transmitting
>>>>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0
>>>>>>>>>>>>> seems to be easier to implement than a new nlattr, but,
>>>>>>>>>>>>> for me, it looks less intuitive and more difficult to
>>>>>>>>>>>>> maintain because we have to care about vid 0 instead of
>>>>>>>>>>>>> simply ignoring it.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The point I am trying to make is that regardless of the
>>>>>>>>>>>> approach someone has to know what to do when enabling
>>>>>>>>>>>> priority tagged frames. You proposal would require the
>>>>>>>>>>>> administrator or config tool to have that knowledge.
>>>>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev
>>>>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority
>>>>>>>>>>>> tagged frame support */
>>>>>>>>>>>>
>>>>>>>>>>>> My proposal would require the bridge filtering
>>>>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0
>>>>>>>>>>>> tagged Automated app: No special case.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO its better to have 1 piece code handling the special
>>>>>>>>>>>> case then putting it multiple places.
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the detailed explanation. Now I understand your
>>>>>>>>>>> intention.
>>>>>>>>>>>
>>>>>>>>>>> I have one question about your proposal. I guess the way to
>>>>>>>>>>> enable priority-tagged is something like bridge vlan add vid
>>>>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub
>>>>>>>>>>> interface vnet0.0.
>>>>>>>>>>>
>>>>>>>>>>> Here the admin have to know the egress policy is applied to a
>>>>>>>>>>> frame twice in a certain order when it is transmitted from
>>>>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10
>>>>>>>>>>> get untagged, and then, an untagged frame get
>>>>>>>>>>> priority-tagged.
>>>>>>>>>>>
>>>>>>>>>>> This behavior looks difficult to know without previous
>>>>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's
>>>>>>>>>>> additional knowledge?
>>>>>>>>>>
>>>>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is
>>>>>>>>>> eth0.0 in the guest or on the remote host) already tells the
>>>>>>>>>> admin vlan 0 has to be tagged. The fact that we codify this in
>>>>>>>>>> the policy makes it explicit.
>>>>>>>>>
>>>>>>>>> My worry is that the admin might not be able to guess how to use
>>>>>>>>> bridge commands to enable priority-tag without any additional
>>>>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually
>>>>>>>>> couldn't hit upon such a usage before seeing example commands you
>>>>>>>>> gave, because I had never think the egress policy could be
>>>>>>>>> applied twice.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, I can see strong argument to be made for an addition
>>>>>>>>>> egress policy attribute that could be for instance:
>>>>>>>>>>
>>>>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev
>>>>>>>>>> vnet0 pvid untagged prio_tag
>>>>>>>>>>
>>>>>>>>>> But this has the same connotations as wrt to egress policy.
>>>>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add
>>>>>>>>>> priority_tag.
>>>>>>>>>>
>>>>>>>>>> (2) only happens if initial fame received on eth0 was priority
>>>>>>>>>> tagged.
>>>>>>>>>
>>>>>>>>> If we do so, we will not be able to communicate using vlan 0
>>>>>>>>> interface under a certain circumstance. Eth0 can be receive mixed
>>>>>>>>> untagged and priority-tagged frames according to the network
>>>>>>>>> element it is connected to: for example, Open vSwitch can send
>>>>>>>>> such two kinds of frames from the same port even if original
>>>>>>>>> incoming frames belong to the same vlan.
>>>>>>>>
>>>>>>>> Which priority would you assign to the frame that was received
>>>>>>>> untagged?
>>>>>>>
>>>>>>> Untagged frame's priority is by default 0, so I think 0 is likely.
>>>>>>>
>>>>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
>>>>>>> parameter value are the values in the M_UNITDATA.indication.
>>>>>>>
>>>>>>> M_UNITDATA is passed from ISS.
>>>>>>>
>>>>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
>>>>>>> primitive shall take the value of the Default User Priority parameter
>>>>>>> for the Port through which the MAC frame was received. The default
>>>>>>> value of this parameter is 0, it may be set by management in which
>>>>>>> case the capability to set it to any of the values 0 through 7 shall
>>>>>>> be provided.
>>>>>>>
>>>>>>>>
>>>>>>>>> In this situation, we can only receive frames that is
>>>>>>>>> priority-tagged when received on eth0.
>>>>>>>>
>>>>>>>> Not sure I understand. Let's look at this config: bridge vlan add
>>>>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>>>> prio_tag
>>>>>>>>
>>>>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and
>>>>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame
>>>>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was
>>>>>>>> untagged, it should probably be sent untagged. 2) if the frame had
>>>>>>>> a priority tag, it should probably be sent as such.
>>>>>>>>
>>>>>>>> Now, I think a case could be made that if the frame had any
>>>>>>>> priority markings in the vlan header, we should try to preserve
>>>>>>>> those markings if prio_tag is turned on. We can assume value of 0
>>>>>>>> means not set.
>>>>>>>
>>>>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
>>>>>>> priority-tagged and untagged frames on eth0.
>>>>>>
>>>>>> Right, and that's what you were trying to handle in your patch:
>>>>>>
>>>>>>> + /* PVID is set on this port. Any untagged or priority-tagged +
>>>>>>> * ingress frame is considered to belong to this vlan. */
>>>>>>
>>>>>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
>>>>>>
>>>>>>> Even if we are sending frames from eth0.0 with some priority other
>>>>>>> than 0, we could receive frames with priority 0 or untagged on the
>>>>>>> other side of the bridge.
>>>>>>> For example, if we receive untagged arp reply on the bridge port, we
>>>>>>> migit not be able to communicate with such an end station, because
>>>>>>> untagged reply will not be passed to eth0.0.
>>>>>>
>>>>>> So the ARP request was sent tagged, but the reply came back untagged?
>>>>>
>>>>> Yes, it can happen.
>>>>> These are problematic cases.
>>>>>
>>>>> Example 1:
>>>>> prio_tagged prio_tagged
>>>>> +------------+ ---> +------------+ ---> +----------+
>>>>> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
>>>>> +------------+ <--- +------------+ <--- +----------+
>>>>> untagged untagged
>>>>>
>>>>> Note: Host2 eth0, which is an interface on Linux, can receive
>>>>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
>>>>
>>>> Hmm.. Just to see if this works, I ran the this scenario with
>>>> a dumb switch in the middle, and it did not work as you noted.
>>>> I then realized that one of the kernels was rather old and after
>>>> updating it, behaved differently. The communication still didn't
>>>> work, but host2 behaved properly.
>>>>
>>>>>>
>>>>>> How does that work when the end station is attached directly to the
>>>>>> HW switch instead of a linux bridge?
>>>>>>
>>>>>> The station configures eth0.0 and sends priority-tagged traffic to
>>>>>> the HW switch. If the HW switch sends back untagged traffic, then
>>>>>> the untagged traffic will never reach eth0.0.
>>>>>
>>>>> Currently we cannot communicate using eth0.0 via directly connected
>>>>> 802.1Q conformed switch, because we never receive priority-tagged frames
>>>>> from the switch.
>>>>> It is not a problem of Linux bridge and is why I wondered whether it
>>>>> should be fixed by bridge or vlan 0 interface.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> IMO, if prio_tag is configured, the bridge should send any
>>>>>>>>> untagged frame as priority-tagged regardless of whatever it is on
>>>>>>>>> eth0.
>>>>>>>>
>>>>>>>> Which priority would you use, 0? You are not guaranteed to
>>>>>>>> properly deliver the traffic then for a configuration such as: VM:
>>>>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24
>>>>>>>
>>>>>>> I'd like to use priority 0 for untagged frames.
>>>>>>>
>>>>>>> I am assuming that one of our goals is at least that eth0.0 comes to
>>>>>>> be able to communicate with another end station. It seems to be hard
>>>>>>> to use both eth0 and eth0.0 simultaneously.
>>>>>>
>>>>>> I understand, but I don't agree that we should always tag.
>>>>>>
>>>>>> Consider config:
>>>>>>
>>>>>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
>>>>>>
>>>>>> If the end station sends priority-tagged traffic it should receive
>>>>>> priority tagged traffic back. Otherwise, untagged traffic may be
>>>>>> dropped by the end station. This is true whether it is connected to
>>>>>> the hw switch or Linux bridge.
>>>>>
>>>>> Though such a behavior is generally not necessary as far as I can read
>>>>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
>>>>> My proposal aims to resolve it at least when we use Linux bridge.
>>>>>
>>>>> Example configuration:
>>>>> bridge vlan add vid 10 dev eth1 pvid untagged
>>>>> bridge vlan add vid 10 dev eth0
>>>>> bridge vlan set prio_tag on dev eth1
>>>>>
>>>>> Intended behavior:
>>>>>
>>>>> VID10-tagged prio_tagged
>>>>> +---------+ <--- +------------------------+ <--- +-----------------+
>>>>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
>>>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>>>> VID10-tagged prio_tagged
>>>>> (always if egress policy untagged)
>>>>
>>>> Ok, I think you've convinced me that this is the right approach. The
>>>> only thing that I am not crazy about is the API. I'd almost want to
>>>> introduce a new flag that can be set in a 'vlan add' or 'vlan set'
>>>> command that communicates a new policy.
>>>
>>> I'm glad that we reached a consensus on the approach :)
>>>
>>> I agree with you that the API is flag based.
>>> I'm guessing your intention is that 'vlan add' means a per vlan per port
>>> policy and 'vlan set' means a per port one, that is,
>>> 'vlan add': bridge vlan add vid 10 dev eth1 prio_tag
>>> 'vlan set': bridge vlan set prio_tag on dev eth1
>>>
>>> I think they can behave differently only when we set untagged to
>>> multiple vlans on the same port.
>>>
>>> 'vlan add' example with vid 10 and 20:
>>> bridge vlan add vid 10 dev eth1 pvid untagged prio_tag
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 20 dev eth1 untagged
>>> bridge vlan add vid 20 dev eth2
>>>
>>> VID10-tagged prio_tagged (from eth0)
>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>> |hw switch|------|eth0 eth1|------|em1.0:end station|
>>> +---------+ | Linux Bridge | ---> +-----------------+
>>> +---------+ | | *untagged*
>>> |hw switch|------|eth2 | (from eth2)
>>> +---------+ ---> +------------------------+
>>> VID20-tagged
>>>
>>
>> This is what I was thinking of, but I was actually considering that
>> untagged and prio_tag can not co-exist for the same vlan as they don't
>> really make sence together anymore.
>
> You're right.
> In this case 'untagged' for 'vid 10' is no longer necessary.
>
>>
>> So one can do:
>> bridge vlan add vid 10 dev eth1 pvid prio_tag
>> bridge vlan add vid 20 dev eth1 untagged
>>
>> and recieve VLAN 10 as priority tagged and vlan 20 as untagged.
>
> Can you make a patch set implementing this?
>
> I'd like to re-send this patch set related to PVID with more comments
> about the unresolved vlan 0 interface problem and the prospect that it
> will be addressed by another patch set of yours.
>
> Is this procedure OK with you?
Sure. Can you re-send the patch series, since I think 3 of the paches
are really needed. I'll work on the prio_tag stuff.
-vlad
>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -vlad
>>
>>>
>>> 'vlan set' example with vid 10 and 20:
>>> bridge vlan add vid 10 dev eth1 pvid untagged
>>> bridge vlan add vid 10 dev eth0
>>> bridge vlan add vid 20 dev eth1 untagged
>>> bridge vlan add vid 20 dev eth2
>>> bridge vlan set prio_tag on dev eth1
>>>
>>> VID10-tagged prio_tagged (from eth0)
>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>> |hw switch|------|eth0 eth1|------|em1.0:end station|
>>> +---------+ | Linux Bridge | ---> +-----------------+
>>> +---------+ | | prio_tagged
>>> |hw switch|------|eth2 | (from eth2)
>>> +---------+ ---> +------------------------+
>>> VID20-tagged
>>>
>>> Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'.
>>> However, I cannot imagine when multiple untagged vlans is required, so
>>> cannot figure out whether 'vlan add' is useful or harmful.
>>> Anyway, both of approaches are OK with me.
>>>
>>> Thanks,
>>> Toshiaki Makita
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Toshiaki Makita
>>>>>
>>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Toshiaki Makita
>>>>>>>
>>>>>>>>
>>>>>>>> -vlad
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I am ok with either approach. Explicit vid 0 policy is
>>>>>>>>>> easier for automatic provisioning. The flag based one is
>>>>>>>>>> easier for admin/ manual provisioning.
>>>>>>>>>
>>>>>>>>> Supposing we have to add something to help or man in any case, I
>>>>>>>>> think flag based is better. The format below seems to suitable
>>>>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Toshiaki Makita
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -vlad.
>>>>>>>>>>
>>>>>>>>>> -vlad
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks -vlad
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How it is implemented internally in the kernel isn't as
>>>>>>>>>>>>>> big of an issue. We can do it as a separate flag or as
>>>>>>>>>>>>>> part of existing policy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -vlad
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -- To unsubscribe from this list: send the
>>>>>>>>>>>>>>>>>>>> line "unsubscribe netdev" in the body of a
>>>>>>>>>>>>>>>>>>>> message to majordomo@vger.kernel.org More
>>>>>>>>>>>>>>>>>>>> majordomo info at
>>>>>>>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- To unsubscribe from this list: send the line
>>>>>>>>>>>>>>>>> "unsubscribe netdev" in the body of a message to
>>>>>>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Eric Dumazet @ 2013-10-15 13:47 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <1381838188-9625-2-git-send-email-sathya.perla@emulex.com>
On Tue, 2013-10-15 at 17:26 +0530, Sathya Perla wrote:
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
>
> Pktgen can generate non-TSO frames of arbitrary length disregarding
> the MTU value of the physical interface. Drop such frames in the driver
> instead of sending them to HW as it cannot handle such frames.
>
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..76057b8 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
> unsigned int eth_hdr_len;
> struct iphdr *ip;
>
> + /* Don't allow non-TSO packets longer than MTU */
> + eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
> + VLAN_ETH_HLEN : ETH_HLEN;
> + if (!skb_is_gso(skb) &&
> + (skb->len - eth_hdr_len) > adapter->netdev->mtu)
> + goto tx_drop;
> +
When you say 'cannot handle them', is it some kind of nasty thing like
hang / crash ?
One could imagine gso_size + sizeof(headers) > mtu, and give the same
problem ?
AFAIK, we have no check in net/core/dev.c.
Maybe we should instead add them there (and in pktgen)
^ permalink raw reply
* Re: [PATCH 2/2] be2net: drop non-tso frames longer than mtu
From: Sergei Shtylyov @ 2013-10-15 13:45 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <1381838188-9625-2-git-send-email-sathya.perla@emulex.com>
Hello.
On 15-10-2013 15:56, Sathya Perla wrote:
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
> Pktgen can generate non-TSO frames of arbitrary length disregarding
> the MTU value of the physical interface. Drop such frames in the driver
> instead of sending them to HW as it cannot handle such frames.
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..76057b8 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -855,6 +855,13 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
> unsigned int eth_hdr_len;
> struct iphdr *ip;
>
> + /* Don't allow non-TSO packets longer than MTU */
> + eth_hdr_len = (ntohs(skb->protocol) == ETH_P_8021Q) ?
> + VLAN_ETH_HLEN : ETH_HLEN;
> + if (!skb_is_gso(skb) &&
> + (skb->len - eth_hdr_len) > adapter->netdev->mtu)
> + goto tx_drop;
This *goto* is indented one tab too much.
WBR, Sergei
^ permalink raw reply
* RE: [Ilw] drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
From: Grumbach, Emmanuel @ 2013-10-15 13:35 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: John W. Linville, Berg, Johannes, ilw@linux.intel.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1127865420.20131015151054@eikelenboom.it>
Please apply this:
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
index d131f85..5968f19 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -457,8 +457,8 @@ int iwlagn_tx_skb(struct iwl_priv *priv,
WARN_ON_ONCE(is_agg &&
priv->queue_to_mac80211[txq_id] != info->hw_queue);
- IWL_DEBUG_TX(priv, "TX to [%d|%d] Q:%d - seq: 0x%x\n", sta_id, tid,
- txq_id, seq_number);
+ IWL_DEBUG_TX(priv, "TX to [%d|%d] Q:%d info Q %d - seq: 0x%x\n", sta_id, tid,
+ txq_id, info->hw_queue, seq_number);
if (iwl_trans_tx(priv->trans, skb, dev_cmd, txq_id))
goto drop_unlock_sta;
and send the output back to me
Thanks.
>
> >>
> >> Hi,
> >>
> >> I'm having a:
> >>
> >> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235
> (rev
> >> 24)
> >>
> >> And i'm running into this warning on boot with a 3.11.2 and 3.12-rc5
> kernel.
> >>
> >> [ 23.904950] ------------[ cut here ]------------
> >> [ 23.904957] WARNING: CPU: 0 PID: 2531 at
> >> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
>
> > Can you reproduce easily?
> > If yes, please reproduce with debug parameters:
> > modprobe iwlwifi debug=0xC0800000
>
> > Also, please enable MAC80211_HT_DEBUG
>
> > Thanks
>
> It happens when starting hostapd:
>
> [ 7.101116] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
> [ 7.110722] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
> [ 7.154478] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 9 on FIFO 7 WrPtr: 0
> [ 7.157691] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 0 on FIFO 3 WrPtr: 0
> [ 7.160812] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 1 on FIFO 2 WrPtr: 0
> [ 7.164900] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 2 on FIFO 1 WrPtr: 0
> [ 7.165019] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 3 on FIFO 0 WrPtr: 0
> [ 7.165139] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 4 on FIFO 0 WrPtr: 0
> [ 7.165258] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 5 on FIFO 4 WrPtr: 0
> [ 7.165377] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 6 on FIFO 2 WrPtr: 0
> [ 7.165495] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 7 on FIFO 5 WrPtr: 0
> [ 7.165614] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 8 on FIFO 4 WrPtr: 0
> [ 7.165733] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 10 on FIFO 5 WrPtr: 0
> [ 7.404295] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
> [ 7.415368] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
> [ 7.462417] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 9 on FIFO 7 WrPtr: 0
> [ 7.466588] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 0 on FIFO 3 WrPtr: 0
> [ 7.470415] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 1 on FIFO 2 WrPtr: 0
> [ 7.474144] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 2 on FIFO 1 WrPtr: 0
> [ 7.477514] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 3 on FIFO 0 WrPtr: 0
> [ 7.480843] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 4 on FIFO 0 WrPtr: 0
> [ 7.484148] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 5 on FIFO 4 WrPtr: 0
> [ 7.487432] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 6 on FIFO 2 WrPtr: 0
> [ 7.490496] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 7 on FIFO 5 WrPtr: 0
> [ 7.493534] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 8 on FIFO 4 WrPtr: 0
> [ 7.496562] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate
> queue 10 on FIFO 5 WrPtr: 0
> [ 7.542143] device wlan0 entered promiscuous mode
> [ 7.544749] xen_bridge: port 2(wlan0) entered forwarding state
> [ 7.546915] xen_bridge: port 2(wlan0) entered forwarding state
> [ 7.548825] cfg80211: Pending regulatory request, waiting for it to be
> processed...
> [ 7.552798] ------------[ cut here ]------------
> [ 7.554821] WARNING: CPU: 1 PID: 2445 at
> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x776/0x979()
> [ 7.554824] Modules linked in: acpi_cpufreq
> [ 7.554827] CPU: 1 PID: 2445 Comm: hostapd Not tainted 3.12.0-rc5+ #1
> [ 7.554828] Hardware name: /D53427RKE, BIOS
> RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
> [ 7.554831] 0000000000000000 0000000000000009 ffffffff818a8082
> 0000000000000000
> [ 7.554833] ffffffff8105a4f2 0000000000000000 ffffffff815f440a
> ffff8800d6df1c80
> [ 7.554835] ffff8800d6cb1790 ffff8800d6df1c80 0000000000000007
> 0000000000000000
> [ 7.554835] Call Trace:
> [ 7.554842] [<ffffffff818a8082>] ? dump_stack+0x41/0x51
> [ 7.554845] [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
> [ 7.554850] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
> [ 7.554852] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
> [ 7.554855] [<ffffffff815f2407>] ? iwlagn_mac_tx+0x19/0x30
> [ 7.554858] [<ffffffff8187a259>] ? __ieee80211_tx+0x226/0x29b
> [ 7.554860] [<ffffffff8187bcd1>] ? ieee80211_tx+0xa6/0xb5
> [ 7.554865] [<ffffffff8187bf9f>] ?
> ieee80211_monitor_start_xmit+0x1e9/0x204
> [ 7.554867] [<ffffffff8172e1eb>] ? dev_hard_start_xmit+0x271/0x3ec
> [ 7.554871] [<ffffffff81746538>] ? sch_direct_xmit+0x66/0x164
> [ 7.554873] [<ffffffff8172e54b>] ? dev_queue_xmit+0x1e5/0x3c8
> [ 7.554876] [<ffffffff8180bfe6>] ? packet_sendmsg+0xac5/0xb3d
> [ 7.554881] [<ffffffff8171ad95>] ? sock_sendmsg+0x37/0x52
> [ 7.554884] [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
> [ 7.554886] [<ffffffff81724bac>] ? verify_iovec+0x44/0x94
> [ 7.554889] [<ffffffff8171b1ef>] ? ___sys_sendmsg+0x1f1/0x283
> [ 7.554893] [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
> [ 7.554895] [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
> [ 7.554897] [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
> [ 7.554900] [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
> [ 7.554902] [<ffffffff81132f6f>] ? dput+0xe5/0xef
> [ 7.554905] [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
> [ 7.554908] [<ffffffff8171c1ee>] ? __sys_sendmsg+0x39/0x57
> [ 7.554911] [<ffffffff818b5e39>] ? system_call_fastpath+0x16/0x1b
> [ 7.554912] ---[ end trace beb2b581b91027a7 ]---
> [ 7.554917] iwlwifi 0000:02:00.0: I iwlagn_tx_skb TX to [14|8] Q:7 - seq: 0x0
> [ 7.555036] device wlan0 left promiscuous mode
> [ 7.555042] xen_bridge: port 2(wlan0) entered disabled state
> [ 7.557861] iwlwifi 0000:02:00.0: I iwl_trans_pcie_reclaim [Q 7] 0 -> 1 (1)
> [ 7.557865] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx TXQ 7 status SUCCESS
> (0x00000201)
> [ 7.557867] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx
> initial_rate 0x820a retries 0, idx=0 ssn=1 seq_ctl=0x0
> [ 7.626274] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x23
> [ 7.670694] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x24
> [ 7.673864] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x25
> [ 7.677083] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x26
> [ 7.681410] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x27
> [ 7.684761] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x28
> [ 7.686906] iwlwifi 0000:02:00.0: I iwl_pcie_txq_unmap Q 9 Free 39
^ permalink raw reply related
* Re: [Ilw] drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
From: Sander Eikelenboom @ 2013-10-15 13:10 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: John W. Linville, Berg, Johannes, ilw@linux.intel.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DC46E5@HASMSX103.ger.corp.intel.com>
Tuesday, October 15, 2013, 12:52:04 PM, you wrote:
>>
>> Hi,
>>
>> I'm having a:
>>
>> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev
>> 24)
>>
>> And i'm running into this warning on boot with a 3.11.2 and 3.12-rc5 kernel.
>>
>> [ 23.904950] ------------[ cut here ]------------
>> [ 23.904957] WARNING: CPU: 0 PID: 2531 at
>> drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
> Can you reproduce easily?
> If yes, please reproduce with debug parameters:
> modprobe iwlwifi debug=0xC0800000
> Also, please enable MAC80211_HT_DEBUG
> Thanks
It happens when starting hostapd:
[ 7.101116] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 7.110722] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
[ 7.154478] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 9 on FIFO 7 WrPtr: 0
[ 7.157691] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 0 on FIFO 3 WrPtr: 0
[ 7.160812] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 1 on FIFO 2 WrPtr: 0
[ 7.164900] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 2 on FIFO 1 WrPtr: 0
[ 7.165019] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 3 on FIFO 0 WrPtr: 0
[ 7.165139] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 4 on FIFO 0 WrPtr: 0
[ 7.165258] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 5 on FIFO 4 WrPtr: 0
[ 7.165377] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 6 on FIFO 2 WrPtr: 0
[ 7.165495] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 7 on FIFO 5 WrPtr: 0
[ 7.165614] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 8 on FIFO 4 WrPtr: 0
[ 7.165733] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 10 on FIFO 5 WrPtr: 0
[ 7.404295] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 7.415368] iwlwifi 0000:02:00.0: Radio type=0x2-0x1-0x0
[ 7.462417] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 9 on FIFO 7 WrPtr: 0
[ 7.466588] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 0 on FIFO 3 WrPtr: 0
[ 7.470415] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 1 on FIFO 2 WrPtr: 0
[ 7.474144] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 2 on FIFO 1 WrPtr: 0
[ 7.477514] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 3 on FIFO 0 WrPtr: 0
[ 7.480843] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 4 on FIFO 0 WrPtr: 0
[ 7.484148] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 5 on FIFO 4 WrPtr: 0
[ 7.487432] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 6 on FIFO 2 WrPtr: 0
[ 7.490496] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 7 on FIFO 5 WrPtr: 0
[ 7.493534] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 8 on FIFO 4 WrPtr: 0
[ 7.496562] iwlwifi 0000:02:00.0: U iwl_trans_pcie_txq_enable Activate queue 10 on FIFO 5 WrPtr: 0
[ 7.542143] device wlan0 entered promiscuous mode
[ 7.544749] xen_bridge: port 2(wlan0) entered forwarding state
[ 7.546915] xen_bridge: port 2(wlan0) entered forwarding state
[ 7.548825] cfg80211: Pending regulatory request, waiting for it to be processed...
[ 7.552798] ------------[ cut here ]------------
[ 7.554821] WARNING: CPU: 1 PID: 2445 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x776/0x979()
[ 7.554824] Modules linked in: acpi_cpufreq
[ 7.554827] CPU: 1 PID: 2445 Comm: hostapd Not tainted 3.12.0-rc5+ #1
[ 7.554828] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
[ 7.554831] 0000000000000000 0000000000000009 ffffffff818a8082 0000000000000000
[ 7.554833] ffffffff8105a4f2 0000000000000000 ffffffff815f440a ffff8800d6df1c80
[ 7.554835] ffff8800d6cb1790 ffff8800d6df1c80 0000000000000007 0000000000000000
[ 7.554835] Call Trace:
[ 7.554842] [<ffffffff818a8082>] ? dump_stack+0x41/0x51
[ 7.554845] [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
[ 7.554850] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
[ 7.554852] [<ffffffff815f440a>] ? iwlagn_tx_skb+0x776/0x979
[ 7.554855] [<ffffffff815f2407>] ? iwlagn_mac_tx+0x19/0x30
[ 7.554858] [<ffffffff8187a259>] ? __ieee80211_tx+0x226/0x29b
[ 7.554860] [<ffffffff8187bcd1>] ? ieee80211_tx+0xa6/0xb5
[ 7.554865] [<ffffffff8187bf9f>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
[ 7.554867] [<ffffffff8172e1eb>] ? dev_hard_start_xmit+0x271/0x3ec
[ 7.554871] [<ffffffff81746538>] ? sch_direct_xmit+0x66/0x164
[ 7.554873] [<ffffffff8172e54b>] ? dev_queue_xmit+0x1e5/0x3c8
[ 7.554876] [<ffffffff8180bfe6>] ? packet_sendmsg+0xac5/0xb3d
[ 7.554881] [<ffffffff8171ad95>] ? sock_sendmsg+0x37/0x52
[ 7.554884] [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
[ 7.554886] [<ffffffff81724bac>] ? verify_iovec+0x44/0x94
[ 7.554889] [<ffffffff8171b1ef>] ? ___sys_sendmsg+0x1f1/0x283
[ 7.554893] [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
[ 7.554895] [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
[ 7.554897] [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
[ 7.554900] [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
[ 7.554902] [<ffffffff81132f6f>] ? dput+0xe5/0xef
[ 7.554905] [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
[ 7.554908] [<ffffffff8171c1ee>] ? __sys_sendmsg+0x39/0x57
[ 7.554911] [<ffffffff818b5e39>] ? system_call_fastpath+0x16/0x1b
[ 7.554912] ---[ end trace beb2b581b91027a7 ]---
[ 7.554917] iwlwifi 0000:02:00.0: I iwlagn_tx_skb TX to [14|8] Q:7 - seq: 0x0
[ 7.555036] device wlan0 left promiscuous mode
[ 7.555042] xen_bridge: port 2(wlan0) entered disabled state
[ 7.557861] iwlwifi 0000:02:00.0: I iwl_trans_pcie_reclaim [Q 7] 0 -> 1 (1)
[ 7.557865] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx TXQ 7 status SUCCESS (0x00000201)
[ 7.557867] iwlwifi 0000:02:00.0: I iwlagn_rx_reply_tx initial_rate 0x820a retries 0, idx=0 ssn=1 seq_ctl=0x0
[ 7.626274] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x23
[ 7.670694] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x24
[ 7.673864] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x25
[ 7.677083] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x26
[ 7.681410] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x27
[ 7.684761] iwlwifi 0000:02:00.0: I iwl_pcie_txq_inc_wr_ptr Q:9 WR: 0x28
[ 7.686906] iwlwifi 0000:02:00.0: I iwl_pcie_txq_unmap Q 9 Free 39
^ permalink raw reply
* [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: Enrico Mioso @ 2013-10-15 13:06 UTC (permalink / raw)
To: gregkh, davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel
Cc: Enrico Mioso, Antonella Pellizzari
In-Reply-To: <1381842408-10800-1-git-send-email-mrkiko.rs@gmail.com>
This is a QMI device, manufactured by TCT Mobile Phones.
A companion patch blacklisting this device's QMI interface in the option.c
driver has been sent.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3d6aaf7..818ce90 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -714,6 +714,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
+ {QMI_FIXED_INTF(0x0b3c, 0xc005, 6)}, /* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
/* 4. Gobi 1000 devices */
--
1.8.4
^ permalink raw reply related
* [PATCH] usb: serial: option: blacklist Olivetti Olicard200
From: Enrico Mioso @ 2013-10-15 13:06 UTC (permalink / raw)
To: gregkh, davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel
Cc: Enrico Mioso, Antonella Pellizzari
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 80a7104..d7c10d6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1257,7 +1257,9 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
- { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
+ .driver_info = (kernel_ulong_t)&net_intf6_blacklist
+ },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
--
1.8.4
^ permalink raw reply related
* Re: DomU's network interface will hung when Dom0 running 32bit
From: Wei Liu @ 2013-10-15 12:58 UTC (permalink / raw)
To: jianhai luan; +Cc: Wei Liu, Ian Campbell, xen-devel, netdev, ANNIE LI
In-Reply-To: <525D2667.6040102@oracle.com>
On Tue, Oct 15, 2013 at 07:26:31PM +0800, jianhai luan wrote:
[...]
> >>>Can you propose a patch?
> >>Because credit_timeout.expire always after jiffies, i judge the
> >>value over the range of time_after_eq() by time_before(now,
> >>vif->credit_timeout.expires). please check the patch.
> >I don't think this really fix the issue for you. You still have chance
> >that now wraps around and falls between expires and next_credit. In that
> >case it's stalled again.
>
> if time_before(now, vif->credit_timeout.expires) is true, time wrap
> and do operation. Otherwise time_before(now,
> vif->credit_timeout.expires) isn't true, now -
> vif->credit_timeout.expires should be letter than ULONG_MAX/2.
> Because next_credit large than vif->credit_timeout.expires
> (next_crdit = vif->credit_timeout.expires +
> msecs_to_jiffies(vif->credit_usec/1000)), the delta between now and
> next_credit should be in range of time_after_eq(). So
> time_after_eq() do correctly judge.
>
Not sure I understand you. Consider "now" is placed like this:
expires now next_credit
----time increases this direction--->
* time_after_eq(now, next_credit) -> false
* time_before(now, expires) -> false
Then it's stuck again. You're merely narrowing the window, not fixing
the real problem.
Wei.
> Jason
> >
> >Wei.
^ permalink raw reply
* How to filter and intercept packets by using net_dev_add api?
From: Milad khajavi @ 2013-10-15 12:04 UTC (permalink / raw)
To: netdev
I'm writing ethernet network driver for linux. I want to receive
packets, edit and resend them. I know how to edit the packet in
packet_interceptor function, but how can I drop incoming packets in
this function??
Yesterday I've asked this question in stackoverflow [1], but since
now, no one reply that.
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <linux/ip.h>
struct packet_type my_proto;
int packet_interceptor(struct sk_buff *skb,
struct net_device *dev,
struct packet_type *pt,
struct net_device *orig_dev) {
//// I don't want certain packets go to upper in net_devices for
further processing.
//// How can I drop sk_buff here?!
return 0;
}
static int hello_init( void ) {
printk(KERN_INFO "Hello, world!\n");
my_proto.type = htons(ETH_P_ALL);
my_proto.dev = NULL;
my_proto.func = packet_interceptor;
dev_add_pack(&my_proto);
return 0;
}
static void hello_exit(void) {
dev_remove_pack(&my_proto);
printk(KERN_INFO "Bye, world\n");
}
module_init(hello_init);
module_exit(hello_exit);
[1] - http://stackoverflow.com/questions/19342252/how-to-filter-and-intercept-linux-packets-by-using-net-dev-add-api
--
Milād Khājavi
http://blog.khajavi.ir
Having the source means you can do it yourself.
I tried to change the world, but I couldn’t find the source code.
^ permalink raw reply
* [PATCH 13/18] net: ppp: use wrapper functions of net_ratelimit() to simplify code
From: Kefeng Wang @ 2013-10-15 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, David S. Miller, Pablo Neira Ayuso,
Stephen Hemminger, Johannes Berg, John W. Linville,
Stanislaw Gruszka, Johannes Berg, Francois Romieu, Ben Hutchings,
Chas Williams, Marc Kleine-Budde, Samuel Ortiz, Paul Mackerras,
Oliver Neukum, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Rusty Russell, Michael S. Tsirkin, netfilter,
netdev
In-Reply-To: <1381837514-50660-1-git-send-email-wangkefeng.wang@huawei.com>
net_ratelimited_function() is called to simplify code.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/net/ppp/ppp_generic.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 72ff14b..53900cd 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1125,8 +1125,8 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
ppp->xcomp->comp_extra + PPP_HDRLEN;
new_skb = alloc_skb(new_skb_size, GFP_ATOMIC);
if (!new_skb) {
- if (net_ratelimit())
- netdev_err(ppp->dev, "PPP: no memory (comp pkt)\n");
+ net_ratelimited_function(netdev_err, ppp->dev,
+ "PPP: no memory (comp pkt)\n");
return NULL;
}
if (ppp->dev->hard_header_len > PPP_HDRLEN)
@@ -1155,8 +1155,8 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
* the compress_proto because MPPE and MPPC share
* the same number.
*/
- if (net_ratelimit())
- netdev_err(ppp->dev, "ppp: compressor dropped pkt\n");
+ net_ratelimited_function(netdev_err, ppp->dev,
+ "ppp: compressor dropped pkt\n");
kfree_skb(skb);
consume_skb(new_skb);
new_skb = NULL;
@@ -1251,8 +1251,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
if ((ppp->xstate & SC_COMP_RUN) && ppp->xc_state &&
proto != PPP_LCP && proto != PPP_CCP) {
if (!(ppp->flags & SC_CCP_UP) && (ppp->flags & SC_MUST_COMP)) {
- if (net_ratelimit())
- netdev_err(ppp->dev,
+ net_ratelimited_function(netdev_err, ppp->dev,
"ppp: compression required but "
"down - pkt dropped.\n");
goto drop;
--
1.8.2.1
^ 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