* [PATCHv2 NEXT 5/8] qlcnic: fix vlan TSO on big endian machine
From: Amit Kumar Salecha @ 2010-10-04 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sucheta Chakraborty
In-Reply-To: <1286205297-23214-1-git-send-email-amit.salecha@qlogic.com>
From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
o desc->vlan_tci is in __le16 format. Doing htons and
cpu_to_le64 again on vlan_tci, result in invalid value on ppc.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 7 ++++++-
drivers/net/qlcnic/qlcnic_hw.c | 6 ++++--
drivers/net/qlcnic/qlcnic_main.c | 15 ++++++++++-----
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 7af3c6c..9d80171 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -898,6 +898,11 @@ struct qlcnic_mac_req {
u8 mac_addr[6];
};
+struct qlcnic_vlan_req {
+ __le16 vlan_id;
+ __le16 rsvd[3];
+};
+
struct qlcnic_ipaddr {
__be32 ipv4;
__be32 ipv6[4];
@@ -940,7 +945,7 @@ struct qlcnic_ipaddr {
struct qlcnic_filter {
struct hlist_node fnode;
u8 faddr[ETH_ALEN];
- u16 vlan_id;
+ __le16 vlan_id;
unsigned long ftime;
};
diff --git a/drivers/net/qlcnic/qlcnic_hw.c b/drivers/net/qlcnic/qlcnic_hw.c
index 68d5693..712cfab 100644
--- a/drivers/net/qlcnic/qlcnic_hw.c
+++ b/drivers/net/qlcnic/qlcnic_hw.c
@@ -375,10 +375,11 @@ qlcnic_send_cmd_descs(struct qlcnic_adapter *adapter,
static int
qlcnic_sre_macaddr_change(struct qlcnic_adapter *adapter, u8 *addr,
- u16 vlan_id, unsigned op)
+ __le16 vlan_id, unsigned op)
{
struct qlcnic_nic_req req;
struct qlcnic_mac_req *mac_req;
+ struct qlcnic_vlan_req *vlan_req;
u64 word;
memset(&req, 0, sizeof(struct qlcnic_nic_req));
@@ -391,7 +392,8 @@ qlcnic_sre_macaddr_change(struct qlcnic_adapter *adapter, u8 *addr,
mac_req->op = op;
memcpy(mac_req->mac_addr, addr, 6);
- req.words[1] = cpu_to_le64(vlan_id);
+ vlan_req = (struct qlcnic_vlan_req *)&req.words[1];
+ vlan_req->vlan_id = vlan_id;
return qlcnic_send_cmd_descs(adapter, (struct cmd_desc_type0 *)&req, 1);
}
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index a3d7705..6001f41 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -28,6 +28,7 @@
#include "qlcnic.h"
+#include <linux/swab.h>
#include <linux/dma-mapping.h>
#include <linux/if_vlan.h>
#include <net/ip.h>
@@ -1834,11 +1835,12 @@ static void qlcnic_free_lb_filters_mem(struct qlcnic_adapter *adapter)
}
static void qlcnic_change_filter(struct qlcnic_adapter *adapter,
- u64 uaddr, u16 vlan_id, struct qlcnic_host_tx_ring *tx_ring)
+ u64 uaddr, __le16 vlan_id, struct qlcnic_host_tx_ring *tx_ring)
{
struct cmd_desc_type0 *hwdesc;
struct qlcnic_nic_req *req;
struct qlcnic_mac_req *mac_req;
+ struct qlcnic_vlan_req *vlan_req;
u32 producer;
u64 word;
@@ -1856,7 +1858,8 @@ static void qlcnic_change_filter(struct qlcnic_adapter *adapter,
mac_req->op = vlan_id ? QLCNIC_MAC_VLAN_ADD : QLCNIC_MAC_ADD;
memcpy(mac_req->mac_addr, &uaddr, ETH_ALEN);
- req->words[1] = cpu_to_le64(vlan_id);
+ vlan_req = (struct qlcnic_vlan_req *)&req->words[1];
+ vlan_req->vlan_id = vlan_id;
tx_ring->producer = get_next_index(producer, tx_ring->num_desc);
}
@@ -1875,7 +1878,7 @@ qlcnic_send_filter(struct qlcnic_adapter *adapter,
struct hlist_node *tmp_hnode, *n;
struct hlist_head *head;
u64 src_addr = 0;
- u16 vlan_id = 0;
+ __le16 vlan_id = 0;
u8 hindex;
if (!compare_ether_addr(phdr->h_source, adapter->mac_addr))
@@ -1928,7 +1931,8 @@ qlcnic_tso_check(struct net_device *netdev,
struct vlan_ethhdr *vh;
struct qlcnic_adapter *adapter = netdev_priv(netdev);
u32 producer = tx_ring->producer;
- int vlan_oob = first_desc->flags_opcode & cpu_to_le16(FLAGS_VLAN_OOB);
+ __le16 vlan_oob = first_desc->flags_opcode &
+ cpu_to_le16(FLAGS_VLAN_OOB);
if (*(skb->data) & BIT_0) {
flags |= BIT_0;
@@ -1999,7 +2003,8 @@ qlcnic_tso_check(struct net_device *netdev,
vh = (struct vlan_ethhdr *)((char *)hwdesc + 2);
skb_copy_from_linear_data(skb, vh, 12);
vh->h_vlan_proto = htons(ETH_P_8021Q);
- vh->h_vlan_TCI = htons(first_desc->vlan_TCI);
+ vh->h_vlan_TCI = (__be16)swab16((u16)first_desc->vlan_TCI);
+
skb_copy_from_linear_data_offset(skb, 12,
(char *)vh + 16, copy_len - 16);
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 NEXT 2/8] qlcnic: fix eswitch stats
From: Amit Kumar Salecha @ 2010-10-04 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1286205297-23214-1-git-send-email-amit.salecha@qlogic.com>
Some of the counters are not implemented in fw.
Fw return NOT AVAILABLE VALUE as (0xffffffffffffffff).
Adding these counters, result in invalid value.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 12 ++++++++++++
drivers/net/qlcnic/qlcnic_ctx.c | 31 ++++++++++++++++++++++---------
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 714ddf4..4667463 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1169,6 +1169,18 @@ struct qlcnic_esw_func_cfg {
#define QLCNIC_STATS_ESWITCH 2
#define QLCNIC_QUERY_RX_COUNTER 0
#define QLCNIC_QUERY_TX_COUNTER 1
+#define QLCNIC_ESW_STATS_NOT_AVAIL 0xffffffffffffffffULL
+
+#define QLCNIC_ADD_ESW_STATS(VAL1, VAL2)\
+do { \
+ if (((VAL1) == QLCNIC_ESW_STATS_NOT_AVAIL) && \
+ ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
+ (VAL1) = (VAL2); \
+ else if (((VAL1) != QLCNIC_ESW_STATS_NOT_AVAIL) && \
+ ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
+ (VAL1) += (VAL2); \
+} while (0)
+
struct __qlcnic_esw_statistics {
__le16 context_id;
__le16 version;
diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
index 95a821e..a4c4d09 100644
--- a/drivers/net/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/qlcnic/qlcnic_ctx.c
@@ -1016,7 +1016,14 @@ int qlcnic_get_eswitch_stats(struct qlcnic_adapter *adapter, const u8 eswitch,
if (adapter->npars == NULL)
return -EIO;
- memset(esw_stats, 0, sizeof(struct __qlcnic_esw_statistics));
+ memset(esw_stats, 0, sizeof(u64));
+ esw_stats->unicast_frames = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->multicast_frames = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->broadcast_frames = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->dropped_frames = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->errors = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->local_frames = QLCNIC_ESW_STATS_NOT_AVAIL;
+ esw_stats->numbytes = QLCNIC_ESW_STATS_NOT_AVAIL;
esw_stats->context_id = eswitch;
for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
@@ -1029,14 +1036,20 @@ int qlcnic_get_eswitch_stats(struct qlcnic_adapter *adapter, const u8 eswitch,
esw_stats->size = port_stats.size;
esw_stats->version = port_stats.version;
- esw_stats->unicast_frames += port_stats.unicast_frames;
- esw_stats->multicast_frames += port_stats.multicast_frames;
- esw_stats->broadcast_frames += port_stats.broadcast_frames;
- esw_stats->dropped_frames += port_stats.dropped_frames;
- esw_stats->errors += port_stats.errors;
- esw_stats->local_frames += port_stats.local_frames;
- esw_stats->numbytes += port_stats.numbytes;
-
+ QLCNIC_ADD_ESW_STATS(esw_stats->unicast_frames,
+ port_stats.unicast_frames);
+ QLCNIC_ADD_ESW_STATS(esw_stats->multicast_frames,
+ port_stats.multicast_frames);
+ QLCNIC_ADD_ESW_STATS(esw_stats->broadcast_frames,
+ port_stats.broadcast_frames);
+ QLCNIC_ADD_ESW_STATS(esw_stats->dropped_frames,
+ port_stats.dropped_frames);
+ QLCNIC_ADD_ESW_STATS(esw_stats->errors,
+ port_stats.errors);
+ QLCNIC_ADD_ESW_STATS(esw_stats->local_frames,
+ port_stats.local_frames);
+ QLCNIC_ADD_ESW_STATS(esw_stats->numbytes,
+ port_stats.numbytes);
ret = 0;
}
return ret;
--
1.6.3.3
^ permalink raw reply related
* [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Amit Kumar Salecha @ 2011-03-11 10:44 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1299840277-30591-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
o Allow setting speed and auto negotiation parameters for GbE ports.
o Log an error message to indicate duplex setting is not supported in
the hardware currently.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 6 ++-
drivers/net/netxen/netxen_nic_ctx.c | 15 +++++++
drivers/net/netxen/netxen_nic_ethtool.c | 69 ++++++++++--------------------
3 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index a113805..d7299f1 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -739,7 +739,8 @@ struct netxen_recv_context {
#define NX_CDRP_CMD_READ_PEXQ_PARAMETERS 0x0000001c
#define NX_CDRP_CMD_GET_LIC_CAPABILITIES 0x0000001d
#define NX_CDRP_CMD_READ_MAX_LRO_PER_BOARD 0x0000001e
-#define NX_CDRP_CMD_MAX 0x0000001f
+#define NX_CDRP_CMD_CONFIG_GBE_PORT 0x0000001f
+#define NX_CDRP_CMD_MAX 0x00000020
#define NX_RCODE_SUCCESS 0
#define NX_RCODE_NO_HOST_MEM 1
@@ -1054,6 +1055,7 @@ typedef struct {
#define NX_FW_CAPABILITY_BDG (1 << 8)
#define NX_FW_CAPABILITY_FVLANTX (1 << 9)
#define NX_FW_CAPABILITY_HW_LRO (1 << 10)
+#define NX_FW_CAPABILITY_GBE_LINK_CFG (1 << 11)
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -1349,6 +1351,8 @@ void netxen_advert_link_change(struct netxen_adapter *adapter, int linkup);
void netxen_pci_camqm_read_2M(struct netxen_adapter *, u64, u64 *);
void netxen_pci_camqm_write_2M(struct netxen_adapter *, u64, u64);
+int nx_fw_cmd_set_gbe_port(struct netxen_adapter *adapter,
+ u32 speed, u32 duplex, u32 autoneg);
int nx_fw_cmd_set_mtu(struct netxen_adapter *adapter, int mtu);
int netxen_nic_change_mtu(struct net_device *netdev, int new_mtu);
int netxen_config_hw_lro(struct netxen_adapter *adapter, int enable);
diff --git a/drivers/net/netxen/netxen_nic_ctx.c b/drivers/net/netxen/netxen_nic_ctx.c
index f7d06cb..f16966a 100644
--- a/drivers/net/netxen/netxen_nic_ctx.c
+++ b/drivers/net/netxen/netxen_nic_ctx.c
@@ -112,6 +112,21 @@ nx_fw_cmd_set_mtu(struct netxen_adapter *adapter, int mtu)
return 0;
}
+int
+nx_fw_cmd_set_gbe_port(struct netxen_adapter *adapter,
+ u32 speed, u32 duplex, u32 autoneg)
+{
+
+ return netxen_issue_cmd(adapter,
+ adapter->ahw.pci_func,
+ NXHAL_VERSION,
+ speed,
+ duplex,
+ autoneg,
+ NX_CDRP_CMD_CONFIG_GBE_PORT);
+
+}
+
static int
nx_fw_cmd_create_rx_ctx(struct netxen_adapter *adapter)
{
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index 587498e..481f331 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -214,7 +214,6 @@ skip:
check_sfp_module = netif_running(dev) &&
adapter->has_link_events;
} else {
- ecmd->autoneg = AUTONEG_ENABLE;
ecmd->supported |= (SUPPORTED_TP |SUPPORTED_Autoneg);
ecmd->advertising |=
(ADVERTISED_TP | ADVERTISED_Autoneg);
@@ -252,53 +251,31 @@ static int
netxen_nic_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
{
struct netxen_adapter *adapter = netdev_priv(dev);
- __u32 status;
+ int ret;
- /* read which mode */
- if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
- /* autonegotiation */
- if (adapter->phy_write &&
- adapter->phy_write(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_AUTONEG,
- ecmd->autoneg) != 0)
- return -EIO;
- else
- adapter->link_autoneg = ecmd->autoneg;
+ if (adapter->ahw.port_type != NETXEN_NIC_GBE)
+ return -EOPNOTSUPP;
- if (adapter->phy_read &&
- adapter->phy_read(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
- &status) != 0)
- return -EIO;
+ if (!(adapter->capabilities & NX_FW_CAPABILITY_GBE_LINK_CFG)) {
+ netdev_info(dev, "Firmware upgrade required to "
+ "support this operation\n");
+ return -EOPNOTSUPP;
+ }
- /* speed */
- switch (ecmd->speed) {
- case SPEED_10:
- netxen_set_phy_speed(status, 0);
- break;
- case SPEED_100:
- netxen_set_phy_speed(status, 1);
- break;
- case SPEED_1000:
- netxen_set_phy_speed(status, 2);
- break;
- }
- /* set duplex mode */
- if (ecmd->duplex == DUPLEX_HALF)
- netxen_clear_phy_duplex(status);
- if (ecmd->duplex == DUPLEX_FULL)
- netxen_set_phy_duplex(status);
- if (adapter->phy_write &&
- adapter->phy_write(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
- *((int *)&status)) != 0)
- return -EIO;
- else {
- adapter->link_speed = ecmd->speed;
- adapter->link_duplex = ecmd->duplex;
- }
- } else
+ ret = nx_fw_cmd_set_gbe_port(adapter, ecmd->speed, ecmd->duplex,
+ ecmd->autoneg);
+ if (ret == NX_RCODE_NOT_SUPPORTED && ecmd->duplex == DUPLEX_HALF) {
+ netdev_info(dev, "Speed and autoneg mode settings supported, "
+ "half duplex mode not supported\n");
return -EOPNOTSUPP;
+ } else if (ret) {
+ netdev_info(dev, "Setting speed, duplex or autoneg failed\n");
+ return -EIO;
+ }
+
+ adapter->link_speed = ecmd->speed;
+ adapter->link_duplex = ecmd->duplex;
+ adapter->link_autoneg = ecmd->autoneg;
if (!netif_running(dev))
return 0;
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 NEXT 7/8] qlcnic: cleanup port mode setting
From: Amit Kumar Salecha @ 2010-10-04 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sritej Velaga
In-Reply-To: <1286205297-23214-1-git-send-email-amit.salecha@qlogic.com>
From: Sritej Velaga <sritej.velaga@qlogic.com>
Port mode setting is not required for Qlogic CNA adapters.
Signed-off-by: Sritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 40 --------------------------------------
1 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 59a2138..4757908 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -46,11 +46,6 @@ char qlcnic_driver_name[] = "qlcnic";
static const char qlcnic_driver_string[] = "QLogic 1/10 GbE "
"Converged/Intelligent Ethernet Driver v" QLCNIC_LINUX_VERSIONID;
-static int port_mode = QLCNIC_PORT_MODE_AUTO_NEG;
-
-/* Default to restricted 1G auto-neg mode */
-static int wol_port_mode = 5;
-
static int qlcnic_mac_learn;
module_param(qlcnic_mac_learn, int, 0644);
MODULE_PARM_DESC(qlcnic_mac_learn, "Mac Filter (0=disabled, 1=enabled)");
@@ -264,40 +259,6 @@ static void qlcnic_clear_stats(struct qlcnic_adapter *adapter)
memset(&adapter->stats, 0, sizeof(adapter->stats));
}
-static void qlcnic_set_port_mode(struct qlcnic_adapter *adapter)
-{
- u32 val, data;
-
- val = adapter->ahw.board_type;
- if ((val == QLCNIC_BRDTYPE_P3_HMEZ) ||
- (val == QLCNIC_BRDTYPE_P3_XG_LOM)) {
- if (port_mode == QLCNIC_PORT_MODE_802_3_AP) {
- data = QLCNIC_PORT_MODE_802_3_AP;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_XG) {
- data = QLCNIC_PORT_MODE_XG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_AUTO_NEG_1G) {
- data = QLCNIC_PORT_MODE_AUTO_NEG_1G;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_AUTO_NEG_XG) {
- data = QLCNIC_PORT_MODE_AUTO_NEG_XG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else {
- data = QLCNIC_PORT_MODE_AUTO_NEG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- }
-
- if ((wol_port_mode != QLCNIC_PORT_MODE_802_3_AP) &&
- (wol_port_mode != QLCNIC_PORT_MODE_XG) &&
- (wol_port_mode != QLCNIC_PORT_MODE_AUTO_NEG_1G) &&
- (wol_port_mode != QLCNIC_PORT_MODE_AUTO_NEG_XG)) {
- wol_port_mode = QLCNIC_PORT_MODE_AUTO_NEG;
- }
- QLCWR32(adapter, QLCNIC_WOL_PORT_MODE, wol_port_mode);
- }
-}
-
static void qlcnic_set_msix_bit(struct pci_dev *pdev, int enable)
{
u32 control;
@@ -1032,7 +993,6 @@ qlcnic_start_firmware(struct qlcnic_adapter *adapter)
err = qlcnic_pinit_from_rom(adapter);
if (err)
goto err_out;
- qlcnic_set_port_mode(adapter);
err = qlcnic_load_firmware(adapter);
if (err)
--
1.6.3.3
^ permalink raw reply related
* [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: Amit Kumar Salecha @ 2011-04-11 18:52 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Cc: stable@kernel.org
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
drivers/net/netxen/netxen_nic_main.c | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index d7299f1..679dc85 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -174,7 +174,7 @@
#define MAX_NUM_CARDS 4
-#define MAX_BUFFERS_PER_CMD 32
+#define NETXEN_MAX_FRAGS_PER_TX 14
#define MAX_TSO_HEADER_DESC 2
#define MGMT_CMD_DESC_RESV 4
#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
@@ -558,7 +558,7 @@ struct netxen_recv_crb {
*/
struct netxen_cmd_buffer {
struct sk_buff *skb;
- struct netxen_skb_frag frag_array[MAX_BUFFERS_PER_CMD + 1];
+ struct netxen_skb_frag frag_array[MAX_SKB_FRAGS + 1];
u32 frag_count;
};
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 83348dc..e8a4b66 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1844,6 +1844,8 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct cmd_desc_type0 *hwdesc, *first_desc;
struct pci_dev *pdev;
int i, k;
+ int delta = 0;
+ struct skb_frag_struct *frag;
u32 producer;
int frag_count, no_of_desc;
@@ -1851,6 +1853,21 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
frag_count = skb_shinfo(skb)->nr_frags + 1;
+ /* 14 frags supported for normal packet and
+ * 32 frags supported for TSO packet
+ */
+ if (!skb_is_gso(skb) && frag_count > NETXEN_MAX_FRAGS_PER_TX) {
+
+ for (i = 0; i < (frag_count - NETXEN_MAX_FRAGS_PER_TX); i++) {
+ frag = &skb_shinfo(skb)->frags[i];
+ delta += frag->size;
+ }
+
+ if (!__pskb_pull_tail(skb, delta))
+ goto drop_packet;
+
+ frag_count = 1 + skb_shinfo(skb)->nr_frags;
+ }
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
--
1.7.3.2
^ permalink raw reply related
* [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: Amit Kumar Salecha @ 2011-04-11 18:50 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Cc: stable@kernel.org
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
drivers/net/netxen/netxen_nic_main.c | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index d7299f1..679dc85 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -174,7 +174,7 @@
#define MAX_NUM_CARDS 4
-#define MAX_BUFFERS_PER_CMD 32
+#define NETXEN_MAX_FRAGS_PER_TX 14
#define MAX_TSO_HEADER_DESC 2
#define MGMT_CMD_DESC_RESV 4
#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
@@ -558,7 +558,7 @@ struct netxen_recv_crb {
*/
struct netxen_cmd_buffer {
struct sk_buff *skb;
- struct netxen_skb_frag frag_array[MAX_BUFFERS_PER_CMD + 1];
+ struct netxen_skb_frag frag_array[MAX_SKB_FRAGS + 1];
u32 frag_count;
};
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 83348dc..e8a4b66 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1844,6 +1844,8 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct cmd_desc_type0 *hwdesc, *first_desc;
struct pci_dev *pdev;
int i, k;
+ int delta = 0;
+ struct skb_frag_struct *frag;
u32 producer;
int frag_count, no_of_desc;
@@ -1851,6 +1853,21 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
frag_count = skb_shinfo(skb)->nr_frags + 1;
+ /* 14 frags supported for normal packet and
+ * 32 frags supported for TSO packet
+ */
+ if (!skb_is_gso(skb) && frag_count > NETXEN_MAX_FRAGS_PER_TX) {
+
+ for (i = 0; i < (frag_count - NETXEN_MAX_FRAGS_PER_TX); i++) {
+ frag = &skb_shinfo(skb)->frags[i];
+ delta += frag->size;
+ }
+
+ if (!__pskb_pull_tail(skb, delta))
+ goto drop_packet;
+
+ frag_count = 1 + skb_shinfo(skb)->nr_frags;
+ }
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCHv2 NEXT 2/8] qlcnic: fix eswitch stats
From: David Miller @ 2011-04-11 22:55 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1286205297-23214-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 4 Oct 2010 08:14:51 -0700
> Some of the counters are not implemented in fw.
> Fw return NOT AVAILABLE VALUE as (0xffffffffffffffff).
> Adding these counters, result in invalid value.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Why are patches being posted from back in October 4, 2010?
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-04-11 22:56 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1299840277-30591-3-git-send-email-amit.salecha@qlogic.com>
On Fri, 2011-03-11 at 02:44 -0800, Amit Kumar Salecha wrote:
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> o Allow setting speed and auto negotiation parameters for GbE ports.
> o Log an error message to indicate duplex setting is not supported in
> the hardware currently.
[...]
> + ret = nx_fw_cmd_set_gbe_port(adapter, ecmd->speed, ecmd->duplex,
> + ecmd->autoneg);
> + if (ret == NX_RCODE_NOT_SUPPORTED && ecmd->duplex == DUPLEX_HALF) {
> + netdev_info(dev, "Speed and autoneg mode settings supported, "
> + "half duplex mode not supported\n");
> return -EOPNOTSUPP;
[...]
Should be -EINVAL.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: David Miller @ 2011-04-11 22:57 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
In-Reply-To: <1302547974-7310-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 11 Apr 2011 11:52:54 -0700
> Machines are getting deadlock in four node cluster environment.
> All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
> 200 GB storage on a GFS2 filesystem.
> This result in memory fragmentation and driver receives 18 frags for
> 1448 byte packets.
> For non tso packet, fw drops the tx request, if it has >14 frags.
>
> Fixing it by pulling extra frags.
>
> Cc: stable@kernel.org
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
I applied this to net-2.6 earlier today, so:
1) Why are you sending it again?
2) On top of that, why are you sending two copies?
^ permalink raw reply
* Re: [PATCHv2 NEXT 6/8] qlcnic: sparse warning fixes
From: Ben Hutchings @ 2011-04-11 23:00 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, anirban.chakraborty,
Sucheta Chakraborty
In-Reply-To: <1286205297-23214-6-git-send-email-amit.salecha@qlogic.com>
On Mon, 2010-10-04 at 08:14 -0700, Amit Kumar Salecha wrote:
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> ---
> drivers/net/qlcnic/qlcnic_ctx.c | 12 ++++++------
> drivers/net/qlcnic/qlcnic_main.c | 10 +++++-----
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
> index a4c4d09..75e3b19 100644
> --- a/drivers/net/qlcnic/qlcnic_ctx.c
> +++ b/drivers/net/qlcnic/qlcnic_ctx.c
> @@ -742,15 +742,15 @@ int qlcnic_get_pci_info(struct qlcnic_adapter *adapter,
>
> if (err == QLCNIC_RCODE_SUCCESS) {
> for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++, npar++, pci_info++) {
> - pci_info->id = le32_to_cpu(npar->id);
> - pci_info->active = le32_to_cpu(npar->active);
> - pci_info->type = le32_to_cpu(npar->type);
> + pci_info->id = le16_to_cpu(npar->id);
> + pci_info->active = le16_to_cpu(npar->active);
> + pci_info->type = le16_to_cpu(npar->type);
> pci_info->default_port =
> - le32_to_cpu(npar->default_port);
> + le16_to_cpu(npar->default_port);
> pci_info->tx_min_bw =
> - le32_to_cpu(npar->tx_min_bw);
> + le16_to_cpu(npar->tx_min_bw);
> pci_info->tx_max_bw =
> - le32_to_cpu(npar->tx_max_bw);
> + le16_to_cpu(npar->tx_max_bw);
[...]
It looks like this function was broken on big-endian systems. The
commit message should say that you are fixing a bug, not just that some
unspecified 'sparse warning[s]' (that alerted you to the bug) were
fixed.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] s2io: Fix warnings due to -Wunused-but-set-variable.
From: David Miller @ 2011-04-11 23:01 UTC (permalink / raw)
To: netdev
Most of these are cases where we are trying to read back a register
after a write to ensure completion.
Simply pre-fixing the readl() or readq() with "(void)" is sufficient
because these are volatile operations and the compiler cannot eliminate
them just because no real assignment takes place.
The case of free_rxd_blk()'s assignments to "struct buffAdd *ba" is a
real spurious assignment as this variable is completely otherwise
unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/s2io.c | 5 +----
drivers/net/s2io.h | 10 ++++------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index ca8e75e..2d5cc61 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -2244,13 +2244,12 @@ static int verify_xena_quiescence(struct s2io_nic *sp)
static void fix_mac_address(struct s2io_nic *sp)
{
struct XENA_dev_config __iomem *bar0 = sp->bar0;
- u64 val64;
int i = 0;
while (fix_mac[i] != END_SIGN) {
writeq(fix_mac[i++], &bar0->gpio_control);
udelay(10);
- val64 = readq(&bar0->gpio_control);
+ (void) readq(&bar0->gpio_control);
}
}
@@ -2727,7 +2726,6 @@ static void free_rxd_blk(struct s2io_nic *sp, int ring_no, int blk)
int j;
struct sk_buff *skb;
struct RxD_t *rxdp;
- struct buffAdd *ba;
struct RxD1 *rxdp1;
struct RxD3 *rxdp3;
struct mac_info *mac_control = &sp->mac_control;
@@ -2751,7 +2749,6 @@ static void free_rxd_blk(struct s2io_nic *sp, int ring_no, int blk)
memset(rxdp, 0, sizeof(struct RxD1));
} else if (sp->rxd_mode == RXD_MODE_3B) {
rxdp3 = (struct RxD3 *)rxdp;
- ba = &mac_control->rings[ring_no].ba[blk][j];
pci_unmap_single(sp->pdev,
(dma_addr_t)rxdp3->Buffer0_ptr,
BUF0_LEN,
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index 628fd27..800b3a4 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -1002,18 +1002,16 @@ static inline void writeq(u64 val, void __iomem *addr)
#define LF 2
static inline void SPECIAL_REG_WRITE(u64 val, void __iomem *addr, int order)
{
- u32 ret;
-
if (order == LF) {
writel((u32) (val), addr);
- ret = readl(addr);
+ (void) readl(addr);
writel((u32) (val >> 32), (addr + 4));
- ret = readl(addr + 4);
+ (void) readl(addr + 4);
} else {
writel((u32) (val >> 32), (addr + 4));
- ret = readl(addr + 4);
+ (void) readl(addr + 4);
writel((u32) (val), addr);
- ret = readl(addr);
+ (void) readl(addr);
}
}
--
1.7.4.3
^ permalink raw reply related
* [net-next-2.6 PATCH] ethtool: time to blink provided in seconds not jiffies
From: Bruce Allan @ 2011-04-11 23:01 UTC (permalink / raw)
To: netdev
When blinking for a duration set by the user, the value specified is in
seconds but it is used as the number of jiffies in the timeout after which
the Physical ID indicator is deactivated. Fix by converting the timeout
to seconds.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
---
net/core/ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 704e176..43ef09f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1653,7 +1653,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
if (rc == 0) {
/* Driver will handle this itself */
schedule_timeout_interruptible(
- id.data ? id.data : MAX_SCHEDULE_TIMEOUT);
+ id.data ? (id.data * HZ) : MAX_SCHEDULE_TIMEOUT);
} else {
/* Driver expects to be called periodically */
do {
^ permalink raw reply related
* Re: [PATCHv2 NEXT 2/8] qlcnic: fix eswitch stats
From: Stephen Hemminger @ 2011-04-11 23:09 UTC (permalink / raw)
To: Amit Kumar Salecha; +Cc: davem, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1286205297-23214-2-git-send-email-amit.salecha@qlogic.com>
On Mon, 4 Oct 2010 08:14:51 -0700
Amit Kumar Salecha <amit.salecha@qlogic.com> wrote:
> +
> +#define QLCNIC_ADD_ESW_STATS(VAL1, VAL2)\
> +do { \
> + if (((VAL1) == QLCNIC_ESW_STATS_NOT_AVAIL) && \
> + ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
> + (VAL1) = (VAL2); \
> + else if (((VAL1) != QLCNIC_ESW_STATS_NOT_AVAIL) && \
> + ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
> + (VAL1) += (VAL2); \
> +} while (0)
Fugly macro. Make it an inline function?
^ permalink raw reply
* [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Bruce Allan @ 2011-04-11 23:16 UTC (permalink / raw)
To: netdev
When physical identification of an adapter is done by toggling the
mechanism on and off through software utilizing the .set_phys_id operation,
it is done with a fixed duration for both on and off states. Some drivers
may want to set a custom duration for the on/off intervals. This patch
changes the API so the return code from the driver's entry point can
specify the interval duration as a positive number; -EINVAL is still
allowed in order to use the default single on/off interval per second.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
---
net/core/ethtool.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 43ef09f..02db945 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1640,7 +1640,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->phys_id(dev, id.data);
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_ACTIVE);
- if (rc && rc != -EINVAL)
+ if (rc < 0 && rc != -EINVAL)
return rc;
/* Drop the RTNL lock while waiting, but prevent reentry or
@@ -1656,22 +1656,25 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
id.data ? (id.data * HZ) : MAX_SCHEDULE_TIMEOUT);
} else {
/* Driver expects to be called periodically */
+ int i = 0, interval = ((rc > 0) ? rc : (HZ / 2));
+
do {
rtnl_lock();
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_ON);
rtnl_unlock();
if (rc)
break;
- schedule_timeout_interruptible(HZ / 2);
+ schedule_timeout_interruptible(interval);
rtnl_lock();
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_OFF);
rtnl_unlock();
if (rc)
break;
- schedule_timeout_interruptible(HZ / 2);
+ schedule_timeout_interruptible(interval);
} while (!signal_pending(current) &&
- (id.data == 0 || --id.data != 0));
+ (id.data == 0 ||
+ (++i * 2 * interval) < (id.data * HZ)));
}
rtnl_lock();
^ permalink raw reply related
* Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Stephen Hemminger @ 2011-04-11 23:26 UTC (permalink / raw)
To: Bruce Allan; +Cc: netdev
In-Reply-To: <20110411231635.9339.36369.stgit@gitlad.jf.intel.com>
On Mon, 11 Apr 2011 16:16:35 -0700
Bruce Allan <bruce.w.allan@intel.com> wrote:
> When physical identification of an adapter is done by toggling the
> mechanism on and off through software utilizing the .set_phys_id operation,
> it is done with a fixed duration for both on and off states. Some drivers
> may want to set a custom duration for the on/off intervals. This patch
> changes the API so the return code from the driver's entry point can
> specify the interval duration as a positive number; -EINVAL is still
> allowed in order to use the default single on/off interval per second.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
IMHO this is -EOVERKILL.
--
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Allan, Bruce W @ 2011-04-11 23:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110411162601.6686f169@nehalam>
>-----Original Message-----
>From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>Sent: Monday, April 11, 2011 4:26 PM
>To: Allan, Bruce W
>Cc: netdev@vger.kernel.org
>Subject: Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
>physical identification
>
>On Mon, 11 Apr 2011 16:16:35 -0700
>Bruce Allan <bruce.w.allan@intel.com> wrote:
>
>> When physical identification of an adapter is done by toggling the
>> mechanism on and off through software utilizing the .set_phys_id operation,
>> it is done with a fixed duration for both on and off states. Some drivers
>> may want to set a custom duration for the on/off intervals. This patch
>> changes the API so the return code from the driver's entry point can
>> specify the interval duration as a positive number; -EINVAL is still
>> allowed in order to use the default single on/off interval per second.
>>
>> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
>
>IMHO this is -EOVERKILL.
I realize it does seem like that, but we have OEMs that expect the LEDs to
blink a certain way during a physical identification (twice a second vs.
once a second per the original .set_phys_id patchset). There may be other
drivers from different hardware vendors that have similar but different
requirements.
^ permalink raw reply
* Re: Kernel panic when using bridge
From: Scot Doyle @ 2011-04-11 23:48 UTC (permalink / raw)
To: Hiroaki SHIMODA, Stephen Hemminger
Cc: netdev, Sebastian Nickel, Pallai Roland
In-Reply-To: <20110409161908.a2aca120.shimoda.hiroaki@gmail.com>
On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote:
>
> It seems that the bug trap is occurred in ip_options_compile() due to
> rt is NULL.
>
> 8b 96 cc 00 00 00 mov 0xcc(%rsi),%edx
> rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit
> the bug trap.
>
> 332 if (skb) {
> 333 memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here
> 334 opt->is_changed = 1;
> 335 }
>
> And call trace seems as follows.
> __netif_receive_skb()
> -> br_handle_frame()
> -> NF_HOOK()
> -> br_nf_pre_routing()
> -> br_parse_ip_options()
> -> ip_options_compile()
>
> br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize
> skb before it enters the IP stack) but ip_options_compile() or
> ip_options_rcv_srr() seems to be called with no rt info.
Thanks to a tip from Sebastian, I can now reproduce this panic by
running "IP Stack Integrity Checker v0.07" from another machine on the
same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a"
is IP address of the other machine and "x.y.z.b" is the IP address of
the target. When I enable iptables logging on the target machine, no
panic occurs. When I disable iptables logging (but otherwise leave the
same iptables rules) a panic occurs within a few seconds.
Thanks Hiroaki for the analysis of the kernel panic output. I've
confirmed that you are correct by placing a printk just before those two
lines. In every panic, the printk was triggered on line 333 of
net/ipv4/ip_options.c
The kernel panic does not occur after applying the following patch.
# diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix
332c332
< if (skb) {
---
> if (skb && rt) {
374c374
< if (skb) {
---
> if (skb && rt) {
What do you all think? Will it cause other problems?
^ permalink raw reply
* Re: [Bugme-new] [Bug 32872] New: LLC PDU is dropped if skb is not linear
From: Andrew Morton @ 2011-04-11 23:48 UTC (permalink / raw)
To: vitalyb; +Cc: bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <bug-32872-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 8 Apr 2011 09:52:34 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=32872
>
> Summary: LLC PDU is dropped if skb is not linear
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: vitalyb@telenet.dn.ua
> Regression: No
>
>
> If skb consists of several fragments this check fails
> net/llc/llc_input.c:
> =============================================
> llc_fixup_skb()
> ...
> pdu = (struct llc_pdu_un *)skb->data;
> ...
> __be16 pdulen = eth_hdr(skb)->h_proto;
> s32 data_size = ntohs(pdulen) - llc_len;
>
> if (data_size < 0 ||
> ((skb_tail_pointer(skb) -
> (u8 *)pdu) - llc_len) < data_size)
> return 0;
> =============================================
>
> and packet is silently dropped.
>
> This breaks GVRP protocol if received packet is large ( > 512 bytes on my
> system) and contains a Leave All message. Since Leave All is missed,
> corresponding JoinIns are not sent and switch unregisters VLANs from port.
>
> Attached patch seems to resolve this issue, but I don't know if it's a correct
> solution.
--- linux-2.6.32.36/net/llc/llc_input.c.orig 2009-12-03 05:51:21.000000000 +0200
+++ linux-2.6.32.36/net/llc/llc_input.c 2011-04-08 08:57:29.000000000 +0300
@@ -105,6 +105,11 @@
if (unlikely(!pskb_may_pull(skb, sizeof(*pdu))))
return 0;
+ if (skb->data_len != 0){
+ if (unlikely(skb_linearize(skb)))
+ return 0;
+ }
+
pdu = (struct llc_pdu_un *)skb->data;
if ((pdu->ctrl_1 & LLC_PDU_TYPE_MASK) == LLC_PDU_TYPE_U)
llc_len = 1;
2.6.32 is a pretty old kernel - we'll need to verify if current kernels
have the same problem.
Please don't send patches via bugzilla - it causes lots of problems
with our usual patch management and review processes. It's preferred
that patches be sent via email as per Documentation/SubmittingPatches,
and that they include a Signed-off-by:, as described in that file.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ethtool: time to blink provided in seconds not jiffies
From: Ben Hutchings @ 2011-04-11 23:57 UTC (permalink / raw)
To: Bruce Allan; +Cc: netdev
In-Reply-To: <20110411230159.6727.91380.stgit@gitlad.jf.intel.com>
On Mon, 2011-04-11 at 16:01 -0700, Bruce Allan wrote:
> When blinking for a duration set by the user, the value specified is in
> seconds but it is used as the number of jiffies in the timeout after which
> the Physical ID indicator is deactivated. Fix by converting the timeout
> to seconds.
D'oh.
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Ben Hutchings @ 2011-04-12 0:00 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90018A2A30A9@orsmsx509.amr.corp.intel.com>
On Mon, 2011-04-11 at 16:30 -0700, Allan, Bruce W wrote:
> >-----Original Message-----
> >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> >Sent: Monday, April 11, 2011 4:26 PM
> >To: Allan, Bruce W
> >Cc: netdev@vger.kernel.org
> >Subject: Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
> >physical identification
> >
> >On Mon, 11 Apr 2011 16:16:35 -0700
> >Bruce Allan <bruce.w.allan@intel.com> wrote:
> >
> >> When physical identification of an adapter is done by toggling the
> >> mechanism on and off through software utilizing the .set_phys_id operation,
> >> it is done with a fixed duration for both on and off states. Some drivers
> >> may want to set a custom duration for the on/off intervals. This patch
> >> changes the API so the return code from the driver's entry point can
> >> specify the interval duration as a positive number; -EINVAL is still
> >> allowed in order to use the default single on/off interval per second.
> >>
> >> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> >
> >IMHO this is -EOVERKILL.
>
> I realize it does seem like that, but we have OEMs that expect the LEDs to
> blink a certain way during a physical identification (twice a second vs.
> once a second per the original .set_phys_id patchset). There may be other
> drivers from different hardware vendors that have similar but different
> requirements.
I noticed that some drivers did this. Do you know if these OEMs expect
this of all hardware, or do they actually want different vendors'
hardware to blink in different ways? If it's a common requirement to
blink at 2 Hz then let's use that frequency for all the drivers that
want to be called periodically.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [Bugme-new] [Bug 33102] New: File's copied from client->linux server only copy 1st 64K data; rest is lost
From: Steve French @ 2011-04-12 0:06 UTC (permalink / raw)
To: Linda Walsh
Cc: Andrew Morton, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
In-Reply-To: <4DA3839B.1050102-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org>
On Mon, Apr 11, 2011 at 5:41 PM, Linda Walsh <lkml-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org> wrote:
>
> Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Mon, 11 Apr 2011 22:12:41 GMT
>> bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=33102
>>>
>>> Summary: File's copied from client->linux server only copy 1st
>>> 64K data;rest is lost
>>> Product: Networking
>>> Version: 2.5
>>> Kernel Version: 2.6.38.2
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: blocking
>>> Priority: P1
>>> Component: IPV4
>>> AssignedTo: shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
>>> ReportedBy: lkml-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org
>>> Regression: Yes
>>>
>>
>> Seems to be a 2.6.37->2.6.38 regression.
>>
>> ----------
>
> Not exactly -- Please note -- I tried both 2.6.38(.0) and 2.6.38.1.
>
> They both work.
Any chance that we could get a wireshark trace of the failure?
https://wiki.samba.org/index.php/Capture_Packets
gives instructions. There may also be useful information on
network stack failures returned in the samba log
(often named smbd.log).
--
Thanks,
Steve
^ permalink raw reply
* Re: Race condition when creating multiple namespaces?
From: Eric W. Biederman @ 2011-04-12 0:27 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: netdev, Daniel Lezcano
In-Reply-To: <201104112301.46776.hans@schillstrom.com>
Hans Schillstrom <hans@schillstrom.com> writes:
> Hello
> I'v been strugling with this for some time now
>
> When creating multiple namespaces using lxc-start, un-initialized network namespace parts will be called by the new process in the namespace.
> ex. when using conntrack or ipvsadm to quickly, (a sleep 2 "solves" the problem).
> (From what I can see syscall clone() is used in lx-start i.e. do_fork will be called later on.)
> Actually I was debugging ip_vs when closing multiple ns when I fell into this one.
>
> I have a loop that create 33 containers whith lxc-start ... -- test.sh
> the first thing the new conatiner does in test.sh is
> #!/bin/bash
> iptables -t mangle -A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark
> nc -l -p1234
>
> This results in NULL ptr in ip_conntrack_net_init(struct *net)
Ouch!
> and in anoither test test.sh looks like this
> #!/bin/bash
> ipvsadm --start-daemon=master --mcast-interface=lo
> nc -l -p1234
>
> And this results in an uniitialized spinlock in ip_vs_sync
>
> I put a printk in nsproxy: copy_namespaces() and could see a dozens of them
> before anything appears from ipvs or conntrack.
>
> My feeling is that when you start up user processes in a new name space,
> all kernel related init should have been done (you should not need to add a sleep to get it working)
>
> All test made by using todays net-next-2.6 (2.6.39-rc1)
>
> Note:
> That neither conntrack or ip_vs modules where loaded,
> if modules where loaded before creating new namespaces it all works...
>
> Finally the question,
> Should it really work to load modules within a namespace ,
> that is a part of netns ?
>From an implementation point of view kernel modules are not in a
namespace, so there should be no difference between being in a namespace
and loading a kernel networking module and not being in a namespace and
loading in a kernel module.
It does sound like you have hit a module loading race, and perhaps
a race that is confined to network namespaces.
My head is in another problem so I won't be able to look at this for
a bit. But if you are getting into ip_conntrack_net_init with
a NULL network namespace something spectacularly bad is happening.
In particular it looks like you must be hitting a bug in for_each_net.
Which would pretty much have to be a race in adding or removing from
net_namespace_list.
I took a quick skim through the code and whenever we modify the
net_namespace we hold but the net_mutex and inside it the rtnl_lock so I
don't immediate see how you could be getting a NULL net into
ip_conntrack_net_init.
Is there a codepath besides register_pernet_subsys that is calling
ip_conntrack_net_init?
Do you have any local modifications that could be messing up register_pernet_subsys?
Eric
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Allan, Bruce W @ 2011-04-12 1:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <1302566453.5282.585.camel@localhost>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Monday, April 11, 2011 5:01 PM
>To: Allan, Bruce W
>Cc: Stephen Hemminger; netdev@vger.kernel.org
>Subject: RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
>physical identification
>
>I noticed that some drivers did this. Do you know if these OEMs expect
>this of all hardware, or do they actually want different vendors'
>hardware to blink in different ways? If it's a common requirement to
>blink at 2 Hz then let's use that frequency for all the drivers that
>want to be called periodically.
>
>Ben.
Sorry, I don't know. I'll ask around, but doubt I will get a definitive
answer.
FWIW, without digging too deep into how other drivers identify their
respective ports through software, it appears it was split:
* bnx2*, cxgb3, niu, s2io, sfc, sky2, tg3 - once per second
* e100*, igb, ixgb*, pcnet32, ewrk3, cxgb4 - approx. twice per second
AFAIK for parts that can set the physical identification through hardware,
the Intel drivers set the on/off intervals to approximately twice/second;
I don't know what other drivers do in that situation.
So, I would guess it is not a common requirement to blink at a specific Hz.
I have no problem with changing the hard-coded blink frequency to what our
OEMs expect, but that might be an issue for those other vendors; I was just
trying to make it flexible.
Thanks,
Bruce.
^ permalink raw reply
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Wei Gu @ 2011-04-12 1:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, Kirsher, Jeffrey T
In-Reply-To: <1302536577.4605.1.camel@edumazet-laptop>
I was not stress the NIC/CPU, since I only send 290Kpps 400byte packets towards eth10. the CPU load almost 100%IDEL.
BTW, there are some problem with perf tool on 2.6.35.2, I will try to get you the top offenders if possible.
Thanks
WeiGu
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Monday, April 11, 2011 11:43 PM
To: Wei Gu
Cc: Alexander Duyck; netdev; Kirsher, Jeffrey T
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Le lundi 11 avril 2011 à 23:14 +0800, Wei Gu a écrit :
> I tried the ixgbe-3.3.8 (insmod ixgbe.ko RSS=8,8,8,8,8,8,8,8 FdirMode=0,0,0,0,0,0,0,0 Node=0,0,1,1,2,2,3,3) from e1000.sf.net both on 2.6.35.1 and 2.6.35.2, same observation as 3.2.10 ixgbe driver, On 2.6.35.2 it have high rx errors:
> Ethtool -S eth10 |grep error
> rx_errors: 0
> tx_errors: 0
> rx_over_errors: 0
> rx_crc_errors: 0
> rx_frame_errors: 0
> rx_fifo_errors: 0
> rx_missed_errors: 2263088
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_csum_offload_errors: 0
> fcoe_last_errors: 0
>
It would be nice you post perf record / perf report results
During your stress , do
perf record -a -g sleep 10
perf report
And post "top offenders"
Thanks
^ permalink raw reply
* Re: Kernel panic when using bridge
From: Stephen Hemminger @ 2011-04-12 1:31 UTC (permalink / raw)
To: Scot Doyle; +Cc: Hiroaki SHIMODA, netdev, Sebastian Nickel, Pallai Roland
In-Reply-To: <4DA39330.2030102@scotdoyle.com>
On Mon, 11 Apr 2011 18:48:00 -0500
Scot Doyle <lkml@scotdoyle.com> wrote:
> On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote:
> >
> > It seems that the bug trap is occurred in ip_options_compile() due to
> > rt is NULL.
> >
> > 8b 96 cc 00 00 00 mov 0xcc(%rsi),%edx
> > rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit
> > the bug trap.
> >
> > 332 if (skb) {
> > 333 memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here
> > 334 opt->is_changed = 1;
> > 335 }
> >
> > And call trace seems as follows.
> > __netif_receive_skb()
> > -> br_handle_frame()
> > -> NF_HOOK()
> > -> br_nf_pre_routing()
> > -> br_parse_ip_options()
> > -> ip_options_compile()
> >
> > br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize
> > skb before it enters the IP stack) but ip_options_compile() or
> > ip_options_rcv_srr() seems to be called with no rt info.
>
> Thanks to a tip from Sebastian, I can now reproduce this panic by
> running "IP Stack Integrity Checker v0.07" from another machine on the
> same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a"
> is IP address of the other machine and "x.y.z.b" is the IP address of
> the target. When I enable iptables logging on the target machine, no
> panic occurs. When I disable iptables logging (but otherwise leave the
> same iptables rules) a panic occurs within a few seconds.
>
> Thanks Hiroaki for the analysis of the kernel panic output. I've
> confirmed that you are correct by placing a printk just before those two
> lines. In every panic, the printk was triggered on line 333 of
> net/ipv4/ip_options.c
>
> The kernel panic does not occur after applying the following patch.
>
> # diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix
> 332c332
> < if (skb) {
> ---
> > if (skb && rt) {
> 374c374
> < if (skb) {
> ---
> > if (skb && rt) {
>
> What do you all think? Will it cause other problems?
It would help if you gave a little more context (like diff -up)
next time.
I think the correct fix is for the skb handed to ip_compile_options
to match the layout expected by ip_compile_options.
This patch is compile tested only, please validate.
Subject: [PATCH] bridge: set pseudo-route table before calling ip_comple_options
For some ip options, ip_compile_options assumes it can find the associated
route table. The bridge to iptables code doesn't supply the necessary
reference causing NULL dereference.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Patch against net-next-2.6, but if validated should go to net-2.6
and stable.
--- a/net/bridge/br_netfilter.c 2011-04-11 18:18:22.534837859 -0700
+++ b/net/bridge/br_netfilter.c 2011-04-11 18:25:15.427244826 -0700
@@ -221,6 +221,7 @@ static int br_parse_ip_options(struct sk
struct ip_options *opt;
struct iphdr *iph;
struct net_device *dev = skb->dev;
+ struct rtable *rt;
u32 len;
iph = ip_hdr(skb);
@@ -255,6 +256,14 @@ static int br_parse_ip_options(struct sk
return 0;
}
+ /* Associate bogus bridge route table */
+ rt = bridge_parent_rtable(dev);
+ if (!rt) {
+ kfree_skb(skb);
+ return 0;
+ }
+ skb_dst_set(skb, &rt->dst);
+
opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
if (ip_options_compile(dev_net(dev), opt, skb))
goto inhdr_error;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox