* [net-next.git 3/4 (v5)] stmmac: add the Energy Efficient Ethernet support
From: Giuseppe CAVALLARO @ 2012-06-18 6:49 UTC (permalink / raw)
To: netdev
Cc: eric.dumazet, bhutchings, rayagond, davem, yuvalmin,
Giuseppe Cavallaro
In-Reply-To: <1340002187-9248-1-git-send-email-peppe.cavallaro@st.com>
This patch adds the Energy Efficient Ethernet support to the stmmac.
Please see the driver's documentation for further details about this support
in the driver.
Thanks also goes to Rayagond Kokatanur for his first implementation.
Note:
to clearly manage and expose the lpi interrupt status and eee ethtool
stats I've had to do some modifications to the driver's design and I
found really useful to move other parts of the code (e.g. mmc irq stat)
in the main directly. So this means that some core has been reworked
to introduce the EEE.
v1: initial patch
v2: fixed some sparse issues (typos)
v3: erroneously sent the v2 renamed as v3
v4:
o Fixed the return value of the stmmac_eee_init as suggested by D.Miller
o Totally reviewed the ethtool support for EEE
o Added a new internal parameter to tune the SW timer for TX LPI.
v5: do not change any eee setting in case of the stmmac_ethtool_op_set_eee fails
(it has to return -EOPNOTSUPP in that case).
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 31 ++++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 20 +++
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 101 +++++++++++-
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 4 +-
drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 8 +
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 57 +++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 166 +++++++++++++++++++-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +
9 files changed, 372 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index bcd54d6..e2d0832 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -95,6 +95,16 @@ struct stmmac_extra_stats {
unsigned long poll_n;
unsigned long sched_timer_n;
unsigned long normal_irq_n;
+ unsigned long mmc_tx_irq_n;
+ unsigned long mmc_rx_irq_n;
+ unsigned long mmc_rx_csum_offload_irq_n;
+ /* EEE */
+ unsigned long irq_receive_pmt_irq_n;
+ unsigned long irq_tx_path_in_lpi_mode_n;
+ unsigned long irq_tx_path_exit_lpi_mode_n;
+ unsigned long irq_rx_path_in_lpi_mode_n;
+ unsigned long irq_rx_path_exit_lpi_mode_n;
+ unsigned long phy_eee_wakeup_error_n;
};
/* CSR Frequency Access Defines*/
@@ -162,6 +172,17 @@ enum tx_dma_irq_status {
handle_tx_rx = 3,
};
+enum core_specific_irq_mask {
+ core_mmc_tx_irq = 1,
+ core_mmc_rx_irq = 2,
+ core_mmc_rx_csum_offload_irq = 4,
+ core_irq_receive_pmt_irq = 8,
+ core_irq_tx_path_in_lpi_mode = 16,
+ core_irq_tx_path_exit_lpi_mode = 32,
+ core_irq_rx_path_in_lpi_mode = 64,
+ core_irq_rx_path_exit_lpi_mode = 128,
+};
+
/* DMA HW capabilities */
struct dma_features {
unsigned int mbps_10_100;
@@ -208,6 +229,10 @@ struct dma_features {
#define MAC_ENABLE_TX 0x00000008 /* Transmitter Enable */
#define MAC_RNABLE_RX 0x00000004 /* Receiver Enable */
+/* Default LPI timers */
+#define STMMAC_DEFAULT_LIT_LS_TIMER 0x3E8
+#define STMMAC_DEFAULT_TWT_LS_TIMER 0x0
+
struct stmmac_desc_ops {
/* DMA RX descriptor ring initialization */
void (*init_rx_desc) (struct dma_desc *p, unsigned int ring_size,
@@ -278,7 +303,7 @@ struct stmmac_ops {
/* Dump MAC registers */
void (*dump_regs) (void __iomem *ioaddr);
/* Handle extra events on specific interrupts hw dependent */
- void (*host_irq_status) (void __iomem *ioaddr);
+ int (*host_irq_status) (void __iomem *ioaddr);
/* Multicast filter setting */
void (*set_filter) (struct net_device *dev, int id);
/* Flow control setting */
@@ -291,6 +316,10 @@ struct stmmac_ops {
unsigned int reg_n);
void (*get_umac_addr) (void __iomem *ioaddr, unsigned char *addr,
unsigned int reg_n);
+ void (*set_eee_mode) (void __iomem *ioaddr);
+ void (*reset_eee_mode) (void __iomem *ioaddr);
+ void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
+ void (*set_eee_pls) (void __iomem *ioaddr, int link);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index 23478bf..f90fcb5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -36,6 +36,7 @@
#define GMAC_INT_STATUS 0x00000038 /* interrupt status register */
enum dwmac1000_irq_status {
+ lpiis_irq = 0x400,
time_stamp_irq = 0x0200,
mmc_rx_csum_offload_irq = 0x0080,
mmc_tx_irq = 0x0040,
@@ -60,6 +61,25 @@ enum power_event {
power_down = 0x00000001,
};
+/* Energy Efficient Ethernet (EEE)
+ *
+ * LPI status, timer and control register offset
+ */
+#define LPI_CTRL_STATUS 0x0030
+#define LPI_TIMER_CTRL 0x0034
+
+/* LPI control and status defines */
+#define LPI_CTRL_STATUS_LPITXA 0x00080000 /* Enable LPI TX Automate */
+#define LPI_CTRL_STATUS_PLSEN 0x00040000 /* Enable PHY Link Status */
+#define LPI_CTRL_STATUS_PLS 0x00020000 /* PHY Link Status */
+#define LPI_CTRL_STATUS_LPIEN 0x00010000 /* LPI Enable */
+#define LPI_CTRL_STATUS_RLPIST 0x00000200 /* Receive LPI state */
+#define LPI_CTRL_STATUS_TLPIST 0x00000100 /* Transmit LPI state */
+#define LPI_CTRL_STATUS_RLPIEX 0x00000008 /* Receive LPI Exit */
+#define LPI_CTRL_STATUS_RLPIEN 0x00000004 /* Receive LPI Entry */
+#define LPI_CTRL_STATUS_TLPIEX 0x00000002 /* Transmit LPI Exit */
+#define LPI_CTRL_STATUS_TLPIEN 0x00000001 /* Transmit LPI Entry */
+
/* GMAC HW ADDR regs */
#define GMAC_ADDR_HIGH(reg) (((reg > 15) ? 0x00000800 : 0x00000040) + \
(reg * 8))
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index b5e4d02..bfe0226 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -194,26 +194,107 @@ static void dwmac1000_pmt(void __iomem *ioaddr, unsigned long mode)
}
-static void dwmac1000_irq_status(void __iomem *ioaddr)
+static int dwmac1000_irq_status(void __iomem *ioaddr)
{
u32 intr_status = readl(ioaddr + GMAC_INT_STATUS);
+ int status = 0;
/* Not used events (e.g. MMC interrupts) are not handled. */
- if ((intr_status & mmc_tx_irq))
- CHIP_DBG(KERN_DEBUG "GMAC: MMC tx interrupt: 0x%08x\n",
+ if ((intr_status & mmc_tx_irq)) {
+ CHIP_DBG(KERN_INFO "GMAC: MMC tx interrupt: 0x%08x\n",
readl(ioaddr + GMAC_MMC_TX_INTR));
- if (unlikely(intr_status & mmc_rx_irq))
- CHIP_DBG(KERN_DEBUG "GMAC: MMC rx interrupt: 0x%08x\n",
+ status |= core_mmc_tx_irq;
+ }
+ if (unlikely(intr_status & mmc_rx_irq)) {
+ CHIP_DBG(KERN_INFO "GMAC: MMC rx interrupt: 0x%08x\n",
readl(ioaddr + GMAC_MMC_RX_INTR));
- if (unlikely(intr_status & mmc_rx_csum_offload_irq))
- CHIP_DBG(KERN_DEBUG "GMAC: MMC rx csum offload: 0x%08x\n",
+ status |= core_mmc_rx_irq;
+ }
+ if (unlikely(intr_status & mmc_rx_csum_offload_irq)) {
+ CHIP_DBG(KERN_INFO "GMAC: MMC rx csum offload: 0x%08x\n",
readl(ioaddr + GMAC_MMC_RX_CSUM_OFFLOAD));
+ status |= core_mmc_rx_csum_offload_irq;
+ }
if (unlikely(intr_status & pmt_irq)) {
- CHIP_DBG(KERN_DEBUG "GMAC: received Magic frame\n");
+ CHIP_DBG(KERN_INFO "GMAC: received Magic frame\n");
/* clear the PMT bits 5 and 6 by reading the PMT
* status register. */
readl(ioaddr + GMAC_PMT);
+ status |= core_irq_receive_pmt_irq;
}
+ /* MAC trx/rx EEE LPI entry/exit interrupts */
+ if (intr_status & lpiis_irq) {
+ /* Clean LPI interrupt by reading the Reg 12 */
+ u32 lpi_status = readl(ioaddr + LPI_CTRL_STATUS);
+
+ if (lpi_status & LPI_CTRL_STATUS_TLPIEN) {
+ CHIP_DBG(KERN_INFO "GMAC TX entered in LPI\n");
+ status |= core_irq_tx_path_in_lpi_mode;
+ }
+ if (lpi_status & LPI_CTRL_STATUS_TLPIEX) {
+ CHIP_DBG(KERN_INFO "GMAC TX exit from LPI\n");
+ status |= core_irq_tx_path_exit_lpi_mode;
+ }
+ if (lpi_status & LPI_CTRL_STATUS_RLPIEN) {
+ CHIP_DBG(KERN_INFO "GMAC RX entered in LPI\n");
+ status |= core_irq_rx_path_in_lpi_mode;
+ }
+ if (lpi_status & LPI_CTRL_STATUS_RLPIEX) {
+ CHIP_DBG(KERN_INFO "GMAC RX exit from LPI\n");
+ status |= core_irq_rx_path_exit_lpi_mode;
+ }
+ }
+
+ return status;
+}
+
+static void dwmac1000_set_eee_mode(void __iomem *ioaddr)
+{
+ u32 value;
+
+ /* Enable the link status receive on RGMII, SGMII ore SMII
+ * receive path and instruct the transmit to enter in LPI
+ * state. */
+ value = readl(ioaddr + LPI_CTRL_STATUS);
+ value |= LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA;
+ writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void dwmac1000_reset_eee_mode(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + LPI_CTRL_STATUS);
+ value &= ~(LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA);
+ writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void dwmac1000_set_eee_pls(void __iomem *ioaddr, int link)
+{
+ u32 value;
+
+ value = readl(ioaddr + LPI_CTRL_STATUS);
+
+ if (link)
+ value |= LPI_CTRL_STATUS_PLS;
+ else
+ value &= ~LPI_CTRL_STATUS_PLS;
+
+ writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void dwmac1000_set_eee_timer(void __iomem *ioaddr, int ls, int tw)
+{
+ int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
+
+ /* Program the timers in the LPI timer control register:
+ * LS: minimum time (ms) for which the link
+ * status from PHY should be ok before transmitting
+ * the LPI pattern.
+ * TW: minimum time (us) for which the core waits
+ * after it has stopped transmitting the LPI pattern.
+ */
+ writel(value, ioaddr + LPI_TIMER_CTRL);
}
static const struct stmmac_ops dwmac1000_ops = {
@@ -226,6 +307,10 @@ static const struct stmmac_ops dwmac1000_ops = {
.pmt = dwmac1000_pmt,
.set_umac_addr = dwmac1000_set_umac_addr,
.get_umac_addr = dwmac1000_get_umac_addr,
+ .set_eee_mode = dwmac1000_set_eee_mode,
+ .reset_eee_mode = dwmac1000_reset_eee_mode,
+ .set_eee_timer = dwmac1000_set_eee_timer,
+ .set_eee_pls = dwmac1000_set_eee_pls,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 19e0f4e..f83210e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -72,9 +72,9 @@ static int dwmac100_rx_ipc_enable(void __iomem *ioaddr)
return 0;
}
-static void dwmac100_irq_status(void __iomem *ioaddr)
+static int dwmac100_irq_status(void __iomem *ioaddr)
{
- return;
+ return 0;
}
static void dwmac100_set_umac_addr(void __iomem *ioaddr, unsigned char *addr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
index 6e0360f..e678ce3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
@@ -70,6 +70,7 @@
#define DMA_INTR_DEFAULT_MASK (DMA_INTR_NORMAL | DMA_INTR_ABNORMAL)
/* DMA Status register defines */
+#define DMA_STATUS_GLPII 0x40000000 /* GMAC LPI interrupt */
#define DMA_STATUS_GPI 0x10000000 /* PMT interrupt */
#define DMA_STATUS_GMI 0x08000000 /* MMC interrupt */
#define DMA_STATUS_GLI 0x04000000 /* GMAC Line interface int */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index dc20c56..ab4c376 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -87,6 +87,12 @@ struct stmmac_priv {
#endif
int clk_csr;
int synopsys_id;
+ struct timer_list eee_ctrl_timer;
+ bool tx_path_in_lpi_mode;
+ int lpi_irq;
+ int eee_enabled;
+ int eee_active;
+ int tx_lpi_timer;
};
extern int phyaddr;
@@ -104,6 +110,8 @@ int stmmac_dvr_remove(struct net_device *ndev);
struct stmmac_priv *stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
void __iomem *addr);
+void stmmac_disable_eee_mode(struct stmmac_priv *priv);
+bool stmmac_eee_init(struct stmmac_priv *priv);
#ifdef CONFIG_HAVE_CLK
static inline int stmmac_clk_enable(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index ce43184..76fd61a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -93,6 +93,16 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
STMMAC_STAT(poll_n),
STMMAC_STAT(sched_timer_n),
STMMAC_STAT(normal_irq_n),
+ STMMAC_STAT(normal_irq_n),
+ STMMAC_STAT(mmc_tx_irq_n),
+ STMMAC_STAT(mmc_rx_irq_n),
+ STMMAC_STAT(mmc_rx_csum_offload_irq_n),
+ STMMAC_STAT(irq_receive_pmt_irq_n),
+ STMMAC_STAT(irq_tx_path_in_lpi_mode_n),
+ STMMAC_STAT(irq_tx_path_exit_lpi_mode_n),
+ STMMAC_STAT(irq_rx_path_in_lpi_mode_n),
+ STMMAC_STAT(irq_rx_path_exit_lpi_mode_n),
+ STMMAC_STAT(phy_eee_wakeup_error_n),
};
#define STMMAC_STATS_LEN ARRAY_SIZE(stmmac_gstrings_stats)
@@ -366,6 +376,11 @@ static void stmmac_get_ethtool_stats(struct net_device *dev,
(*(u32 *)p);
}
}
+ if (priv->eee_enabled) {
+ int val = phy_get_eee_err(priv->phydev);
+ if (val)
+ priv->xstats.phy_eee_wakeup_error_n = val;
+ }
}
for (i = 0; i < STMMAC_STATS_LEN; i++) {
char *p = (char *)priv + stmmac_gstrings_stats[i].stat_offset;
@@ -464,6 +479,46 @@ static int stmmac_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
return 0;
}
+static int stmmac_ethtool_op_get_eee(struct net_device *dev,
+ struct ethtool_eee *edata)
+{
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ if (!priv->dma_cap.eee)
+ return -EOPNOTSUPP;
+
+ edata->eee_enabled = priv->eee_enabled;
+ edata->eee_active = priv->eee_active;
+ edata->tx_lpi_timer = priv->tx_lpi_timer;
+
+ return phy_ethtool_get_eee(priv->phydev, edata);
+}
+
+static int stmmac_ethtool_op_set_eee(struct net_device *dev,
+ struct ethtool_eee *edata)
+{
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ priv->eee_enabled = edata->eee_enabled;
+
+ if (!priv->eee_enabled)
+ stmmac_disable_eee_mode(priv);
+ else {
+ /* We are asking for enabling the EEE but it is safe
+ * to verify all by invoking the eee_init function.
+ * In case of failure it will return an error.
+ */
+ priv->eee_enabled = stmmac_eee_init(priv);
+ if (!priv->eee_enabled)
+ return -EOPNOTSUPP;
+
+ /* Do not change tx_lpi_timer in case of failure */
+ priv->tx_lpi_timer = edata->tx_lpi_timer;
+ }
+
+ return phy_ethtool_set_eee(priv->phydev, edata);
+}
+
static const struct ethtool_ops stmmac_ethtool_ops = {
.begin = stmmac_check_if_running,
.get_drvinfo = stmmac_ethtool_getdrvinfo,
@@ -480,6 +535,8 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
.get_strings = stmmac_get_strings,
.get_wol = stmmac_get_wol,
.set_wol = stmmac_set_wol,
+ .get_eee = stmmac_ethtool_op_get_eee,
+ .set_eee = stmmac_ethtool_op_set_eee,
.get_sset_count = stmmac_get_sset_count,
.get_ts_info = ethtool_op_get_ts_info,
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index eba49cb..ea3bc09 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -133,6 +133,12 @@ static const u32 default_msg_level = (NETIF_MSG_DRV | NETIF_MSG_PROBE |
NETIF_MSG_LINK | NETIF_MSG_IFUP |
NETIF_MSG_IFDOWN | NETIF_MSG_TIMER);
+#define STMMAC_DEFAULT_LPI_TIMER 1000
+static int eee_timer = STMMAC_DEFAULT_LPI_TIMER;
+module_param(eee_timer, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(eee_timer, "LPI tx expiration time in msec");
+#define STMMAC_LPI_TIMER(x) (jiffies + msecs_to_jiffies(x))
+
static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
#ifdef CONFIG_STMMAC_DEBUG_FS
@@ -161,6 +167,8 @@ static void stmmac_verify_args(void)
flow_ctrl = FLOW_OFF;
if (unlikely((pause < 0) || (pause > 0xffff)))
pause = PAUSE_TIME;
+ if (eee_timer < 0)
+ eee_timer = STMMAC_DEFAULT_LPI_TIMER;
}
static void stmmac_clk_csr_set(struct stmmac_priv *priv)
@@ -229,6 +237,85 @@ static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
phydev->speed);
}
+static void stmmac_enable_eee_mode(struct stmmac_priv *priv)
+{
+ /* Check and enter in LPI mode */
+ if ((priv->dirty_tx == priv->cur_tx) &&
+ (priv->tx_path_in_lpi_mode == false))
+ priv->hw->mac->set_eee_mode(priv->ioaddr);
+}
+
+void stmmac_disable_eee_mode(struct stmmac_priv *priv)
+{
+ /* Exit and disable EEE in case of we are are in LPI state. */
+ priv->hw->mac->reset_eee_mode(priv->ioaddr);
+ del_timer_sync(&priv->eee_ctrl_timer);
+ priv->tx_path_in_lpi_mode = false;
+}
+
+/**
+ * stmmac_eee_ctrl_timer
+ * @arg : data hook
+ * Description:
+ * If there is no data transfer and if we are not in LPI state,
+ * then MAC Transmitter can be moved to LPI state.
+ */
+static void stmmac_eee_ctrl_timer(unsigned long arg)
+{
+ struct stmmac_priv *priv = (struct stmmac_priv *)arg;
+
+ stmmac_enable_eee_mode(priv);
+ mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_TIMER(eee_timer));
+}
+
+/**
+ * stmmac_eee_init
+ * @priv: private device pointer
+ * Description:
+ * If the EEE support has been enabled while configuring the driver,
+ * if the GMAC actually supports the EEE (from the HW cap reg) and the
+ * phy can also manage EEE, so enable the LPI state and start the timer
+ * to verify if the tx path can enter in LPI state.
+ */
+bool stmmac_eee_init(struct stmmac_priv *priv)
+{
+ bool ret = false;
+
+ /* MAC core supports the EEE feature. */
+ if (priv->dma_cap.eee) {
+ /* Check if the PHY supports EEE */
+ if (phy_init_eee(priv->phydev, 1))
+ goto out;
+
+ priv->eee_active = 1;
+ init_timer(&priv->eee_ctrl_timer);
+ priv->eee_ctrl_timer.function = stmmac_eee_ctrl_timer;
+ priv->eee_ctrl_timer.data = (unsigned long)priv;
+ priv->eee_ctrl_timer.expires = STMMAC_LPI_TIMER(eee_timer);
+ add_timer(&priv->eee_ctrl_timer);
+
+ priv->hw->mac->set_eee_timer(priv->ioaddr,
+ STMMAC_DEFAULT_LIT_LS_TIMER,
+ priv->tx_lpi_timer);
+
+ pr_info("stmmac: Energy-Efficient Ethernet initialized\n");
+
+ ret = true;
+ }
+out:
+ return ret;
+}
+
+static void stmmac_eee_adjust(struct stmmac_priv *priv)
+{
+ /* When the EEE has been already initialised we have to
+ * modify the PLS bit in the LPI ctrl & status reg according
+ * to the PHY link status. For this reason.
+ */
+ if (priv->eee_enabled)
+ priv->hw->mac->set_eee_pls(priv->ioaddr, priv->phydev->link);
+}
+
/**
* stmmac_adjust_link
* @dev: net device structure
@@ -249,6 +336,7 @@ static void stmmac_adjust_link(struct net_device *dev)
phydev->addr, phydev->link);
spin_lock_irqsave(&priv->lock, flags);
+
if (phydev->link) {
u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
@@ -315,6 +403,8 @@ static void stmmac_adjust_link(struct net_device *dev)
if (new_state && netif_msg_link(priv))
phy_print_status(phydev);
+ stmmac_eee_adjust(priv);
+
spin_unlock_irqrestore(&priv->lock, flags);
DBG(probe, DEBUG, "stmmac_adjust_link: exiting\n");
@@ -332,7 +422,7 @@ static int stmmac_init_phy(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
struct phy_device *phydev;
- char phy_id[MII_BUS_ID_SIZE + 3];
+ char phy_id_fmt[MII_BUS_ID_SIZE + 3];
char bus_id[MII_BUS_ID_SIZE];
int interface = priv->plat->interface;
priv->oldlink = 0;
@@ -346,11 +436,12 @@ static int stmmac_init_phy(struct net_device *dev)
snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
priv->plat->bus_id);
- snprintf(phy_id, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
+ snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
priv->plat->phy_addr);
- pr_debug("stmmac_init_phy: trying to attach to %s\n", phy_id);
+ pr_debug("stmmac_init_phy: trying to attach to %s\n", phy_id_fmt);
- phydev = phy_connect(dev, phy_id, &stmmac_adjust_link, 0, interface);
+ phydev = phy_connect(dev, phy_id_fmt, &stmmac_adjust_link, 0,
+ interface);
if (IS_ERR(phydev)) {
pr_err("%s: Could not attach to PHY\n", dev->name);
@@ -689,6 +780,11 @@ static void stmmac_tx(struct stmmac_priv *priv)
}
netif_tx_unlock(priv->dev);
}
+
+ if ((priv->eee_enabled) && (!priv->tx_path_in_lpi_mode)) {
+ stmmac_enable_eee_mode(priv);
+ mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_TIMER(eee_timer));
+ }
spin_unlock(&priv->tx_lock);
}
@@ -1027,6 +1123,17 @@ static int stmmac_open(struct net_device *dev)
}
}
+ /* Request the IRQ lines */
+ if (priv->lpi_irq != -ENXIO) {
+ ret = request_irq(priv->lpi_irq, stmmac_interrupt, IRQF_SHARED,
+ dev->name, dev);
+ if (unlikely(ret < 0)) {
+ pr_err("%s: ERROR: allocating the LPI IRQ %d (%d)\n",
+ __func__, priv->lpi_irq, ret);
+ goto open_error_lpiirq;
+ }
+ }
+
/* Enable the MAC Rx/Tx */
stmmac_set_mac(priv->ioaddr, true);
@@ -1062,12 +1169,19 @@ static int stmmac_open(struct net_device *dev)
if (priv->phydev)
phy_start(priv->phydev);
+ priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS_TIMER;
+ priv->eee_enabled = stmmac_eee_init(priv);
+
napi_enable(&priv->napi);
skb_queue_head_init(&priv->rx_recycle);
netif_start_queue(dev);
return 0;
+open_error_lpiirq:
+ if (priv->wol_irq != dev->irq)
+ free_irq(priv->wol_irq, dev);
+
open_error_wolirq:
free_irq(dev->irq, dev);
@@ -1093,6 +1207,9 @@ static int stmmac_release(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
+ if (priv->eee_enabled)
+ del_timer_sync(&priv->eee_ctrl_timer);
+
/* Stop and disconnect the PHY */
if (priv->phydev) {
phy_stop(priv->phydev);
@@ -1115,6 +1232,8 @@ static int stmmac_release(struct net_device *dev)
free_irq(dev->irq, dev);
if (priv->wol_irq != dev->irq)
free_irq(priv->wol_irq, dev);
+ if (priv->lpi_irq != -ENXIO)
+ free_irq(priv->lpi_irq, dev);
/* Stop TX/RX DMA and clear the descriptors */
priv->hw->dma->stop_tx(priv->ioaddr);
@@ -1164,6 +1283,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock(&priv->tx_lock);
+ if (priv->tx_path_in_lpi_mode)
+ stmmac_disable_eee_mode(priv);
+
entry = priv->cur_tx % txsize;
#ifdef STMMAC_XMIT_DEBUG
@@ -1540,10 +1662,37 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
return IRQ_NONE;
}
- if (priv->plat->has_gmac)
- /* To handle GMAC own interrupts */
- priv->hw->mac->host_irq_status((void __iomem *) dev->base_addr);
+ /* To handle GMAC own interrupts */
+ if (priv->plat->has_gmac) {
+ int status = priv->hw->mac->host_irq_status((void __iomem *)
+ dev->base_addr);
+ if (unlikely(status)) {
+ if (status & core_mmc_tx_irq)
+ priv->xstats.mmc_tx_irq_n++;
+ if (status & core_mmc_rx_irq)
+ priv->xstats.mmc_rx_irq_n++;
+ if (status & core_mmc_rx_csum_offload_irq)
+ priv->xstats.mmc_rx_csum_offload_irq_n++;
+ if (status & core_irq_receive_pmt_irq)
+ priv->xstats.irq_receive_pmt_irq_n++;
+
+ /* For LPI we need to save the tx status */
+ if (status & core_irq_tx_path_in_lpi_mode) {
+ priv->xstats.irq_tx_path_in_lpi_mode_n++;
+ priv->tx_path_in_lpi_mode = true;
+ }
+ if (status & core_irq_tx_path_exit_lpi_mode) {
+ priv->xstats.irq_tx_path_exit_lpi_mode_n++;
+ priv->tx_path_in_lpi_mode = false;
+ }
+ if (status & core_irq_rx_path_in_lpi_mode)
+ priv->xstats.irq_rx_path_in_lpi_mode_n++;
+ if (status & core_irq_rx_path_exit_lpi_mode)
+ priv->xstats.irq_rx_path_exit_lpi_mode_n++;
+ }
+ }
+ /* To handle DMA interrupts */
stmmac_dma_interrupt(priv);
return IRQ_HANDLED;
@@ -2155,6 +2304,9 @@ static int __init stmmac_cmdline_opt(char *str)
} else if (!strncmp(opt, "pause:", 6)) {
if (kstrtoint(opt + 6, 0, &pause))
goto err;
+ } else if (!strncmp(opt, "eee_timer:", 6)) {
+ if (kstrtoint(opt + 10, 0, &eee_timer))
+ goto err;
#ifdef CONFIG_STMMAC_TIMER
} else if (!strncmp(opt, "tmrate:", 7)) {
if (kstrtoint(opt + 7, 0, &tmrate))
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 20eb502..7d36163 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -156,6 +156,8 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (priv->wol_irq == -ENXIO)
priv->wol_irq = priv->dev->irq;
+ priv->lpi_irq = platform_get_irq_byname(pdev, "eth_lpi");
+
platform_set_drvdata(pdev, priv->dev);
pr_debug("STMMAC platform driver registration completed");
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Oliver Neukum @ 2012-06-18 7:23 UTC (permalink / raw)
To: David Miller
Cc: huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w,
tom.leiming-Re5JQEeQqe8AvxtiuMwx3w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120617.163017.1067800063889498786.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Am Montag, 18. Juni 2012, 01:30:17 schrieb David Miller:
> From: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 13 Jun 2012 20:50:31 +0800
>
> > intr_complete() submits URB even the interrupt endpoint stalls.
> > This patch will try to activate the endpoint once the exception
> > occurs, and then re-submit the URB if the endpoint works again.
> >
> > Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Review from USB experts would be appreciated.
The code implements a minimum error handler correctly.
Did you observe a stall in actual hardware or is this a just
in case patch?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] bnx2x: fix panic when TX ring is full
From: Eric Dumazet @ 2012-06-18 7:38 UTC (permalink / raw)
To: Dmitry Kravkov
Cc: 'David Miller', netdev@vger.kernel.org,
therbert@google.com, evansr@google.com, Eilon Greenstein,
Merav Sicron, Yaniv Rosner, willemb@google.com, thruby@google.com
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1CF19E@SJEXCHMB06.corp.ad.broadcom.com>
On Sat, 2012-06-16 at 07:40 +0000, Dmitry Kravkov wrote:
> Hi Eric and Tomas
>
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of David Miller
> > Sent: Saturday, June 16, 2012 1:31 AM
> > To: eric.dumazet@gmail.com
> > Cc: netdev@vger.kernel.org; therbert@google.com; evansr@google.com;
> > Eilon Greenstein; Merav Sicron; Yaniv Rosner; willemb@google.com;
> > thruby@google.com
> > Subject: Re: [PATCH] bnx2x: fix panic when TX ring is full
> >
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 13 Jun 2012 21:45:16 +0200
> >
> > > From: Eric Dumazet <edumazet@google.com>
> > >
> > > There is a off by one error in the minimal number of BD in
> > > bnx2x_start_xmit() and bnx2x_tx_int() before stopping/resuming tx
> > queue.
> > >
> > > A full size GSO packet, with data included in skb->head really needs
> > > (MAX_SKB_FRAGS + 4) BDs, because of bnx2x_tx_split()
> > >
> > > This error triggers if BQL is disabled and heavy TCP transmit traffic
> > > occurs.
> > >
> > > bnx2x_tx_split() definitely can be called, remove a wrong comment.
> > >
> > > Reported-by: Tomas Hruby <thruby@google.com>
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Theoretically a can't see how we can reach the case with 4 BDs required apart of frags,
> Usually we need 2, when split invoked 3:
> 1.Start
> 2.Start(split)
> 3.Parsing
> + Frags
>
> Next pages descriptors and 2 extras for full indication are not counted as available.
>
> Practically I'm running the traffic for more then a day without hitting the panic.
>
> Can you describe the scenario you reproduced this in details? And which code has paniced?
Thats pretty immediate.
Disable bql on your NIC.
Say you have 4 queues :
for q in 0 1 2 3
do
echo max >/sys/class/net/eth0/queues/tx-$q/byte_queue_limits/limit_min
done
Then start 40 netperf
for i in `seq 1 40`
do
netperf -H 192.168.1.4 &
done
[ 811.369026] bnx2x: [bnx2x_attn_int_deasserted3:3647(eth0)]MC assert!
[ 811.369030] bnx2x:
[bnx2x_mc_assert:597(eth0)]XSTORM_ASSERT_LIST_INDEX 0x2
[ 811.369036] bnx2x: [bnx2x_mc_assert:614(eth0)]XSTORM_ASSERT_INDEX 0x0
= 0x00110000 0x00000042 0x06981000 0x0001003a
[ 811.369052] bnx2x: [bnx2x_attn_int_deasserted3:3653(eth0)]driver
assert
[ 811.369054] bnx2x: [bnx2x_panic_dump:773(eth0)]begin crash dump
-----------------
[ 811.369056] bnx2x: [bnx2x_panic_dump:780(eth0)]def_idx(0x327)
def_att_idx(0x4) attn_state(0x1) spq_prod_idx(0x2f)
next_stats_cnt(0x31c)
[ 811.369058] bnx2x: [bnx2x_panic_dump:785(eth0)]DSB: attn bits(0x0)
ack(0x1) id(0x0) idx(0x4)
[ 811.369060] bnx2x: [bnx2x_panic_dump:786(eth0)] def (0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x32a 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0) igu_sb_id(0x0)
igu_seg_id(0x1) pf_id(0x0) vnic_id(0x0) vf_id(0xff) vf_valid (0x0)
state(0x1)
[ 811.369073] bnx2x: [bnx2x_panic_dump:830(eth0)]fp0:
rx_bd_prod(0xdfae) rx_bd_cons(0xfb0) rx_comp_prod(0xe86f)
rx_comp_cons(0xd86f) *rx_cons_sb(0xd86f)
[ 811.369076] bnx2x: [bnx2x_panic_dump:834(eth0)]
rx_sge_prod(0x400) last_max_sge(0x2b) fp_hc_idx(0x6a2f)
[ 811.369078] bnx2x: [bnx2x_panic_dump:846(eth0)]fp0:
tx_pkt_prod(0xb184) tx_pkt_cons(0xb088) tx_bd_prod(0xa48)
tx_bd_cons(0xf943) *tx_cons_sb(0xb088)
[ 811.369080] bnx2x: [bnx2x_panic_dump:846(eth0)]fp0: tx_pkt_prod(0x0)
tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[ 811.369082] bnx2x: [bnx2x_panic_dump:858(eth0)] run indexes
(0x6a2f 0x0)
[ 811.369084] bnx2x: [bnx2x_panic_dump:864(eth0)] indexes (0x0
0xd86f 0x0 0x0 0x0 0xb088 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0)
vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[ 811.369103] SM[0] __flags (0x0) igu_sb_id (0x1) igu_seg_id(0x0)
time_to_expire (0x2f68cf91) timer_value(0xff)
[ 811.369104] SM[1] __flags (0x0) igu_sb_id (0x1) igu_seg_id(0x0)
time_to_expire (0x2f68cfc0) timer_value(0xff)
[ 811.369106] INDEX[0] flags (0x0) timeout (0x0)
[ 811.369107] INDEX[1] flags (0x2) timeout (0x6)
[ 811.369108] INDEX[2] flags (0x0) timeout (0x0)
[ 811.369110] INDEX[3] flags (0x0) timeout (0x0)
[ 811.369111] INDEX[4] flags (0x1) timeout (0x0)
[ 811.369112] INDEX[5] flags (0x3) timeout (0xc)
[ 811.369113] INDEX[6] flags (0x1) timeout (0x0)
[ 811.369114] INDEX[7] flags (0x1) timeout (0x0)
[ 811.369116] bnx2x: [bnx2x_panic_dump:830(eth0)]fp1:
rx_bd_prod(0x11ee) rx_bd_cons(0x1f0) rx_comp_prod(0x1e54)
rx_comp_cons(0xe54) *rx_cons_sb(0xe54)
[ 811.369119] bnx2x: [bnx2x_panic_dump:834(eth0)]
rx_sge_prod(0x400) last_max_sge(0x29) fp_hc_idx(0x969d)
[ 811.369121] bnx2x: [bnx2x_panic_dump:846(eth0)]fp1:
tx_pkt_prod(0xba3f) tx_pkt_cons(0xb92f) tx_bd_prod(0x1aee)
tx_bd_cons(0xb18) *tx_cons_sb(0xb92f)
[ 811.369123] bnx2x: [bnx2x_panic_dump:846(eth0)]fp1: tx_pkt_prod(0x0)
tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[ 811.369125] bnx2x: [bnx2x_panic_dump:858(eth0)] run indexes
(0x969d 0x0)
[ 811.369128] bnx2x: [bnx2x_panic_dump:864(eth0)] indexes (0x0
0xe54 0x0 0x0 0x0 0xb92f 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0)
vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[ 811.369146] SM[0] __flags (0x0) igu_sb_id (0x2) igu_seg_id(0x0)
time_to_expire (0x2f68cf8a) timer_value(0xff)
[ 811.369148] SM[1] __flags (0x1) igu_sb_id (0x2) igu_seg_id(0x0)
time_to_expire (0x2f68cfc4) timer_value(0xc)
[ 811.369150] INDEX[0] flags (0x0) timeout (0x0)
[ 811.369151] INDEX[1] flags (0x2) timeout (0x6)
[ 811.369152] INDEX[2] flags (0x0) timeout (0x0)
[ 811.369153] INDEX[3] flags (0x0) timeout (0x0)
[ 811.369154] INDEX[4] flags (0x1) timeout (0x0)
[ 811.369156] INDEX[5] flags (0x3) timeout (0xc)
[ 811.369157] INDEX[6] flags (0x1) timeout (0x0)
[ 811.369158] INDEX[7] flags (0x1) timeout (0x0)
[ 811.369160] bnx2x: [bnx2x_panic_dump:830(eth0)]fp2:
rx_bd_prod(0xa84f) rx_bd_cons(0x851) rx_comp_prod(0xb367)
rx_comp_cons(0xa367) *rx_cons_sb(0xa367)
[ 811.369162] bnx2x: [bnx2x_panic_dump:834(eth0)]
rx_sge_prod(0x400) last_max_sge(0x1f) fp_hc_idx(0x2bf7)
[ 811.369164] bnx2x: [bnx2x_panic_dump:846(eth0)]fp2:
tx_pkt_prod(0xb38d) tx_pkt_cons(0xb296) tx_bd_prod(0x1947)
tx_bd_cons(0xb59) *tx_cons_sb(0xb296)
[ 811.369166] bnx2x: [bnx2x_panic_dump:846(eth0)]fp2: tx_pkt_prod(0x0)
tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[ 811.369168] bnx2x: [bnx2x_panic_dump:858(eth0)] run indexes
(0x2bf7 0x0)
[ 811.369170] bnx2x: [bnx2x_panic_dump:864(eth0)] indexes (0x0
0xa367 0x0 0x0 0x0 0xb296 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0)
vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[ 811.369189] SM[0] __flags (0x1) igu_sb_id (0x3) igu_seg_id(0x0)
time_to_expire (0x2f68cfc7) timer_value(0x6)
[ 811.369191] SM[1] __flags (0x0) igu_sb_id (0x3) igu_seg_id(0x0)
time_to_expire (0x2f68cf9d) timer_value(0xff)
[ 811.369192] INDEX[0] flags (0x0) timeout (0x0)
[ 811.369193] INDEX[1] flags (0x2) timeout (0x6)
[ 811.369194] INDEX[2] flags (0x0) timeout (0x0)
[ 811.369196] INDEX[3] flags (0x0) timeout (0x0)
[ 811.369197] INDEX[4] flags (0x1) timeout (0x0)
[ 811.369198] INDEX[5] flags (0x3) timeout (0xc)
[ 811.369199] INDEX[6] flags (0x1) timeout (0x0)
[ 811.369200] INDEX[7] flags (0x1) timeout (0x0)
[ 811.369202] bnx2x: [bnx2x_panic_dump:830(eth0)]fp3:
rx_bd_prod(0x7df1) rx_bd_cons(0xdf3) rx_comp_prod(0x8887)
rx_comp_cons(0x7887) *rx_cons_sb(0x7887)
[ 811.369204] bnx2x: [bnx2x_panic_dump:834(eth0)]
rx_sge_prod(0x400) last_max_sge(0x1a) fp_hc_idx(0x5cb)
[ 811.369206] bnx2x: [bnx2x_panic_dump:846(eth0)]fp3:
tx_pkt_prod(0xb8ce) tx_pkt_cons(0xb7cc) tx_bd_prod(0x15cf)
tx_bd_cons(0x8c5) *tx_cons_sb(0xb7cc)
[ 811.369208] bnx2x: [bnx2x_panic_dump:846(eth0)]fp3: tx_pkt_prod(0x0)
tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
[ 811.369210] bnx2x: [bnx2x_panic_dump:858(eth0)] run indexes
(0x5cb 0x0)
[ 811.369212] bnx2x: [bnx2x_panic_dump:864(eth0)] indexes (0x0
0x7887 0x0 0x0 0x0 0xb7cc 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0)
vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
[ 811.369231] SM[0] __flags (0x0) igu_sb_id (0x4) igu_seg_id(0x0)
time_to_expire (0x2f68cf9e) timer_value(0xff)
[ 811.369233] SM[1] __flags (0x1) igu_sb_id (0x4) igu_seg_id(0x0)
time_to_expire (0x2f68cfe5) timer_value(0xc)
[ 811.369235] INDEX[0] flags (0x0) timeout (0x0)
[ 811.369236] INDEX[1] flags (0x2) timeout (0x6)
[ 811.369237] INDEX[2] flags (0x0) timeout (0x0)
[ 811.369238] INDEX[3] flags (0x0) timeout (0x0)
[ 811.369239] INDEX[4] flags (0x1) timeout (0x0)
[ 811.369240] INDEX[5] flags (0x3) timeout (0xc)
[ 811.369241] INDEX[6] flags (0x1) timeout (0x0)
[ 811.369242] INDEX[7] flags (0x1) timeout (0x0)
[ 811.369246] bnx2x 0000:03:00.0: eth0: bc 6.2.8
[ 811.369250] begin fw dump (mark 0x3c65b0)
[ 811.369257] ttn 0x0->0x10
[ 811.369257] attn 0x10->0x0
[ 811.369258] attn 0x0->0x10
[ 811.369265] attn 0x10->0x0
[ 811.369265] attn 0x0->0x10
[ 811.369272] attn 0x10->0x0
[ 811.369272] attn 0x0->0x10
[ 811.369279] attn 0x10->0x0
[ 811.369279] attn 0x0->0x10
[ 811.369286] attn 0x10->0x0
[ 811.369286] attn 0x0->0x10
[ 811.369293] attn 0x10->0x0
[ 811.369294] attn 0x0->0x10
[ 811.369301] attn 0x10->0x0
[ 811.369301] attn 0x0->0x10
[ 811.369308] attn 0x10->0x0
[ 811.369308] attn 0x0->0x10
[ 811.369309] attn 0x10->0x0
[ 811.369316] attn 0x0->0x10
[ 811.369316] attn 0x10->0x0
[ 811.369323] attn 0x0->0x10
[ 811.369324] attn 0x10->0x0
[ 811.369331] attn 0x0->0x10
[ 811.369331] attn 0x10->0x0
[ 811.369338] attn 0x0->0x10
[ 811.369338] attn 0x10->0x0
[ 811.369345] attn 0x0->0x10
[ 811.369345] attn 0x10->0x0
[ 811.369352] attn 0x0->0x10
[ 811.369352] attn 0x10->0x0
[ 811.369359] attn 0x0->0x10
[ 811.369360] attn 0x10->0x0
[ 811.369360] attn 0x0->0x10
[ 811.369367] attn 0x10->0x0
[ 811.369367] attn 0x0->0x10
[ 811.369374] attn 0x10->0x0
[ 811.369375] attn 0x0->0x10
[ 811.369382] attn 0x10->0x0
[ 811.369382] attn 0x0->0x10
[ 811.369389] attn 0x10->0x0
[ 811.369389] attn 0x0->0x10
[ 811.369396] attn 0x10->0x0
[ 811.369396] attn 0x0->0x10
[ 811.369403] attn 0x10->0x0
[ 811.369403] attn 0x0->0x10
[ 811.369410] attn 0x10->0x0
[ 811.369411] attn 0x0->0x10
[ 811.369417] attn 0x10->0x0
[ 811.369418] attn 0x0->0x10
[ 811.369418] attn 0x10->0x0
[ 811.369439] attn 0x0->0x10
[ 811.369439] attn 0x10->0x0
[ 811.369446] attn 0x0->0x10
[ 811.369446] attn 0x10->0x0
[ 811.369453] attn 0x0->0x10
[ 811.369454] attn 0x10->0x0
[ 811.369461] attn 0x0->0x10
[ 811.369461] attn 0x10->0x0
[ 811.369469] attn 0x0->0x10
[ 811.369469] attn 0x10->0x0
[ 811.369477] attn 0x0->0x10
[ 811.369477] attn 0x10->0x0
[ 811.369484] f0: UNLOAD_REQ_WOL_DIS 0x4
[ 811.369485] evnt[0.0] 0x1mcp intr[0.0]: 0x10:RSV ACCESS => 0x0 PC
0x800dd28
[ 811.369507] >0x0
[ 811.369507] attn 0x0->0x10
[ 811.369507] attn 0x10->0x0
[ 811.369515] f0: UNLOAD_DONE 0x5
[ 811.369515] mcp intr[0.0]: 0x10:RSV ACCESS => 0x0 PC 0x8015e88
[ 811.369530] lnk_cmn_int[0]: (rc 0)
[ 811.369537] link_init[1.0]: 0x4
[ 811.369538] idx = 0, req_line_speed = 0x3e8, req_duplex=0x1
[ 811.369552] idx = 1, req_line_speed = 0x0, req_duplex=0x1
[ 811.369560] ML recurs lvl 1
[ 811.369568] init_phy[1.0]: done
[ 811.369568] ML recurs lvl 1
[ 811.369576] link_init[0.0]: 0x4
[ 811.369576] idx = 0, req_line_speed = 0x3e8, req_duplex=0x1
[ 811.369590] idx = 1, req_line_speed = 0x0, req_duplex=0x1
[ 811.369598] ML recurs lvl 1
[ 811.369605] init_phy[0.0]: done
[ 811.369606] f0: LOAD_REQ 0x6
[ 811.369613] 0.0:PMF->f0
[ 811.369614] f0: LOAD_DONE 0x7
[ 811.369621] evnt[0.0] 0x0->0x1000
[ 811.369629] evnt[0.0] 0x1000->0x0
[ 811.369629] f0: UNLOAD_REQ_WOL_DIS 0x8
[ 811.369637] f0: UNLOAD_DONE 0x9
[ 811.369644] lnk_cmn_int[0]: (rc 0)
[ 811.369645] link_init[1.0]: 0x4
[ 811.369652] idx = 0, req_line_speed = 0x3e8, req_duplex=0x1
[ 811.369667] idx = 1, req_line_speed = 0x0, req_duplex=0x1
[ 811.369675] Ap\x01�AML recurs lvl 1
[ 811.369682] init_phy[1.0]: done
[ 811.369690] ML recurs lvl 1
[ 811.369690] link_init[0.0]: 0x4
[ 811.369698] idx = 0, req_line_speed = 0x3e8, req_duplex=0x1
[ 811.369706] idx = 1, req_line_speed = 0x0, req_duplex=0x1
[ 811.369720] ML recurs lvl 1
[ 811.369720] init_phy[0.0]: done
[ 811.369728] f0: LOAD_REQ 0xa
[ 811.369728] 0.0:PMF->f0
[ 811.369735] f0: LOAD_DONE 0xb
[ 811.369735] evnt[0.0] 0x0->0x1000
[ 811.369742] evnt[0.0] 0x1000->0x0
[ 811.369749] end of fw dump
[ 811.369752] bnx2x:
[bnx2x_mc_assert:597(eth0)]XSTORM_ASSERT_LIST_INDEX 0x2
[ 811.369758] bnx2x: [bnx2x_mc_assert:614(eth0)]XSTORM_ASSERT_INDEX 0x0
= 0x00110000 0x00000042 0x06981000 0x0001003a
[ 811.369776] bnx2x: [bnx2x_panic_dump:996(eth0)]end crash dump
-----------------
[ 819.771607] ------------[ cut here ]------------
[ 819.771618] WARNING: at net/sched/sch_generic.c:263 dev_watchdog
+0x267/0x270()
[ 819.771622] Hardware name: TBG,ICH10
[ 819.771625] NETDEV WATCHDOG: eth0 (bnx2x): transmit queue 1 timed out
[ 819.771627] Modules linked in: act_mirred cls_u32 cls_tcindex
sch_dsmark xt_multiport iptable_mangle ip_tables x_tables pca954x
i2c_mux processor cdc_acm uhci_hcd ehci_hcd i2c_dev i2c_i801 i2c_core
i2c_debug msr cpuid bnx2x crc32c libcrc32c mdio ipv6 genrtc
[ 819.771661] Pid: 0, comm: swapper/6 Tainted: G W
3.3.6-dbg-DEV #5
[ 819.771664] Call Trace:
[ 819.771666] <IRQ> [<ffffffff8107fc0f>] warn_slowpath_common
+0x7f/0xc0
[ 819.771679] [<ffffffff8107fd06>] warn_slowpath_fmt+0x46/0x50
[ 819.771685] [<ffffffff814cd327>] dev_watchdog+0x267/0x270
[ 819.771692] [<ffffffff81090343>] run_timer_softirq+0x183/0x440
[ 819.771696] [<ffffffff810902b4>] ? run_timer_softirq+0xf4/0x440
[ 819.771701] [<ffffffff814cd0c0>] ? pfifo_fast_init+0x90/0x90
[ 819.771707] [<ffffffff810875ad>] __do_softirq+0xbd/0x250
[ 819.771714] [<ffffffff810ca054>] ? tick_program_event+0x24/0x30
[ 819.771724] [<ffffffff8156169c>] call_softirq+0x1c/0x30
[ 819.771730] [<ffffffff8104f21d>] do_softirq+0x8d/0xc0
[ 819.771732] [<ffffffff810879de>] irq_exit+0x9e/0xc0
[ 819.771735] [<ffffffff81003dee>] smp_apic_timer_interrupt+0x6e/0x99
[ 819.771738] [<ffffffff81560cb0>] apic_timer_interrupt+0x70/0x80
[ 819.771739] <EOI> [<ffffffffa011503c>] ? acpi_idle_enter_bm
+0x220/0x260 [processor]
[ 819.771746] [<ffffffffa0115037>] ? acpi_idle_enter_bm+0x21b/0x260
[processor]
[ 819.771751] [<ffffffff8146c2cd>] cpuidle_idle_call+0xcd/0x2a0
[ 819.771755] [<ffffffff8155be60>] ? notifier_call_chain+0x70/0x70
[ 819.771758] [<ffffffff8104c1d5>] cpu_idle+0x85/0xe0
[ 819.771763] [<ffffffff8154b726>] start_secondary+0x1e3/0x1ea
[ 819.771764] ---[ end trace e93713a9d40cd06f ]---
[ 820.851700] bnx2x: [bnx2x_clean_tx_queue:1381(eth0)]timeout waiting
for queue[0]: txdata->tx_pkt_prod(45546) != txdata->tx_pkt_cons(45192)
[ 821.926357] bnx2x: [bnx2x_clean_tx_queue:1381(eth0)]timeout waiting
for queue[1]: txdata->tx_pkt_prod(47679) != txdata->tx_pkt_cons(47407)
[ 823.000384] bnx2x: [bnx2x_clean_tx_queue:1381(eth0)]timeout waiting
for queue[2]: txdata->tx_pkt_prod(46070) != txdata->tx_pkt_cons(45718)
[ 824.082211] bnx2x: [bnx2x_clean_tx_queue:1381(eth0)]timeout waiting
for queue[3]: txdata->tx_pkt_prod(47370) != txdata->tx_pkt_cons(47052)
[ 824.084515] bnx2x: [bnx2x_del_all_macs:7179(eth0)]Failed to delete
MACs: -5
[ 824.084520] bnx2x: [bnx2x_chip_cleanup:7952(eth0)]Failed to schedule
DEL commands for UC MACs list: -5
[ 824.097445] bnx2x: [bnx2x_func_stop:7758(eth0)]FUNC_STOP ramrod
failed. Running a dry transaction
[ 824.960780] bnx2x 0000:03:00.0: eth0: using MSI-X IRQs: sp 41 fp[0]
42 ... fp[3] 45
[ 824.967241] bnx2x: [bnx2x_nic_load:1857(eth0)]Function start failed!
^ permalink raw reply
* [XFRM][RFC v1] Fix unexpected SA hard expiration after setting new date
From: fan.du @ 2012-06-18 8:24 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev, fdu
First, I'm not sure whether I Cced to the right person, if not,
apologize for the noise.
*Background*:
Once IPsec SAs are created between two peers, kernel setup a timer to monitor
two events: soft/hard expiration. However the timer handler use xtime to
caculate whether it's soft or hard expiration event.
normal code flow(hard expire time:100s, soft expire time:82s)
a) When new SAs created, xfrm_timer_handler is called one second
after its creation. At this point, calculate soft expire
interval(81s), setup the timer;
b) soft expire occur, rearm the timer with hard expire interval(18s)
then notify racoon2 about soft expire event. racoon2 will create
new SAs.
c) hard expire happen, notify racoon2 about it. racoon2 will delete
the old SAs.
*Scenario*:
Setting a new date before b),and after a) could result c) happens first,
As a result, old SAs is deleted before new ones are created. Normally
new SAs will be created by the next time networking traffic, but there
is a small time being when networking connection is down, this could
result in upper layer connections failed in tel comm area, thus it's
better to keep it strict in sequence.
*Workaround*:
set new time could happen:
1) before a), then SAs is updated with new time.
2) before b),and after a)
2a) When new SAs created, xfrm_timer_handler is called one second
after its creation. At this point, calculate soft expire
interval(81s), setup the timer;(set flag to mark next time should
be soft time expire)
<<---- new date comes
2b) soft expire occur, the calculation results in a hard time expire
event, but flag is set, so catch ya. Sync the addtime, and rearm
the timer with hard expire interval(18s), then notify racoon2
about soft expire event;
2c) hard expire happen, notify racoon2 about it;
so everything is in order.
3) after b), hard expire always happened anyway.
So, could you please give your comments on this?
thanks
^ permalink raw reply
* [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: fan.du @ 2012-06-18 8:24 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev, fdu
In-Reply-To: <1340007856-27651-1-git-send-email-fan.du@windriver.com>
After SA is setup, one timer is armed to detect soft/hard expiration,
however the timer handler uses xtime to do the math. This makes hard
expiration occurs first before soft expiration after setting new date
with big interval. As a result new child SA is deleted before rekeying
the new one.
Signed-off-by: fan.du <fan.du@windriver.com>
---
include/net/xfrm.h | 2 ++
net/xfrm/xfrm_state.c | 22 ++++++++++++++++++----
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 2933d74..1734acc 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -214,6 +214,8 @@ struct xfrm_state
/* Private data of this transformer, format is opaque,
* interpreted by xfrm_type methods. */
void *data;
+ u32 flags;
+ long saved_tmo;
};
/* xflags - make enum if more show up */
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index fd77cf0..da2cc78 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -442,8 +442,18 @@ static void xfrm_timer_handler(unsigned long data)
if (x->lft.hard_add_expires_seconds) {
long tmo = x->lft.hard_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0)
- goto expired;
+ if (tmo <= 0) {
+ if (x->flags != 1)
+ goto expired;
+ else {
+ /* enter hard expire without soft expire first?!
+ * setting a new date could trigger this.
+ * workarbound: fix x->curflt.add_time by below:
+ */
+ x->curlft.add_time = now - x->saved_tmo - 1;
+ tmo = x->lft.hard_add_expires_seconds - x->saved_tmo;
+ }
+ }
if (tmo < next)
next = tmo;
}
@@ -460,10 +470,14 @@ static void xfrm_timer_handler(unsigned long data)
if (x->lft.soft_add_expires_seconds) {
long tmo = x->lft.soft_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0)
+ if (tmo <= 0) {
warn = 1;
- else if (tmo < next)
+ x->flags = 0;
+ } else if (tmo < next) {
next = tmo;
+ x->flags = 1;
+ x->saved_tmo = tmo;
+ }
}
if (x->lft.soft_use_expires_seconds) {
long tmo = x->lft.soft_use_expires_seconds +
--
1.6.3.1
^ permalink raw reply related
* [PATCH] net: added support for 40GbE link.
From: Parav Pandit @ 2012-06-18 12:44 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, Parav Pandit
1. link speed of 40GbE and #4 KR4, CR4, SR4, LR4 modes defined.
2. removed code replication for tov calculation for 1G, 10G and
made is common for 1G, 10G, 40G.
Port cost calculation changes for bridging for 40G will be done once have more clarify from 802.1d spec in coming days.
Signed-off-by: Parav Pandit <parav.pandit@emulex.com>
---
include/linux/ethtool.h | 11 ++++++++++-
net/packet/af_packet.c | 8 +++-----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 297370a..1ebfa6e 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -1153,6 +1153,10 @@ struct ethtool_ops {
#define SUPPORTED_10000baseR_FEC (1 << 20)
#define SUPPORTED_20000baseMLD2_Full (1 << 21)
#define SUPPORTED_20000baseKR2_Full (1 << 22)
+#define SUPPORTED_40000baseKR4_Full (1 << 23)
+#define SUPPORTED_40000baseCR4_Full (1 << 24)
+#define SUPPORTED_40000baseSR4_Full (1 << 25)
+#define SUPPORTED_40000baseLR4_Full (1 << 26)
/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half (1 << 0)
@@ -1178,6 +1182,10 @@ struct ethtool_ops {
#define ADVERTISED_10000baseR_FEC (1 << 20)
#define ADVERTISED_20000baseMLD2_Full (1 << 21)
#define ADVERTISED_20000baseKR2_Full (1 << 22)
+#define ADVERTISED_40000baseKR4_Full (1 << 23)
+#define ADVERTISED_40000baseCR4_Full (1 << 24)
+#define ADVERTISED_40000baseSR4_Full (1 << 25)
+#define ADVERTISED_40000baseLR4_Full (1 << 26)
/* The following are all involved in forcing a particular link
* mode for the device for setting things. When getting the
@@ -1185,12 +1193,13 @@ struct ethtool_ops {
* it was forced up into this mode or autonegotiated.
*/
-/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
+/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE, 40GbE. */
#define SPEED_10 10
#define SPEED_100 100
#define SPEED_1000 1000
#define SPEED_2500 2500
#define SPEED_10000 10000
+#define SPEED_40000 40000
#define SPEED_UNKNOWN -1
/* Duplex, half or full. */
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8a10d5b..dd0e503 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -542,13 +542,11 @@ static int prb_calc_retire_blk_tmo(struct packet_sock *po,
rtnl_unlock();
if (!err) {
switch (ecmd.speed) {
- case SPEED_10000:
- msec = 1;
- div = 10000/1000;
- break;
case SPEED_1000:
+ case SPEED_10000:
+ case SPEED_40000:
msec = 1;
- div = 1000/1000;
+ div = ecmd.speed / 1000;
break;
/*
* If the link speed is so slow you don't really
--
1.6.0.2
^ permalink raw reply related
* [PATCH] ethtool: added support for 40G link.
From: Parav Pandit @ 2012-06-18 12:45 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Parav Pandit
1. defined 40G link speed.
2. defined values for KR4, CR4, SR4, LR4 PHY.
Signed-off-by: Parav Pandit <parav.pandit@emulex.com>
---
ethtool-copy.h | 11 ++++++++++-
ethtool.c | 4 ++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3027ca3..3bbc0ed 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -913,6 +913,10 @@ enum ethtool_sfeatures_retval_bits {
#define SUPPORTED_10000baseR_FEC (1 << 20)
#define SUPPORTED_20000baseMLD2_Full (1 << 21)
#define SUPPORTED_20000baseKR2_Full (1 << 22)
+#define SUPPORTED_40000baseKR4_Full (1 << 23)
+#define SUPPORTED_40000baseCR4_Full (1 << 24)
+#define SUPPORTED_40000baseSR4_Full (1 << 25)
+#define SUPPORTED_40000baseLR4_Full (1 << 26)
/* Indicates what features are advertised by the interface. */
#define ADVERTISED_10baseT_Half (1 << 0)
@@ -938,6 +942,10 @@ enum ethtool_sfeatures_retval_bits {
#define ADVERTISED_10000baseR_FEC (1 << 20)
#define ADVERTISED_20000baseMLD2_Full (1 << 21)
#define ADVERTISED_20000baseKR2_Full (1 << 22)
+#define ADVERTISED_40000baseKR4_Full (1 << 23)
+#define ADVERTISED_40000baseCR4_Full (1 << 24)
+#define ADVERTISED_40000baseSR4_Full (1 << 25)
+#define ADVERTISED_40000baseLR4_Full (1 << 26)
/* The following are all involved in forcing a particular link
* mode for the device for setting things. When getting the
@@ -945,12 +953,13 @@ enum ethtool_sfeatures_retval_bits {
* it was forced up into this mode or autonegotiated.
*/
-/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
+/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE, 40GbE. */
#define SPEED_10 10
#define SPEED_100 100
#define SPEED_1000 1000
#define SPEED_2500 2500
#define SPEED_10000 10000
+#define SPEED_40000 40000
#define SPEED_UNKNOWN -1
/* Duplex, half or full. */
diff --git a/ethtool.c b/ethtool.c
index b0d3eea..6e9418e 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -460,6 +460,10 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask)
{ 0, ADVERTISED_10000baseT_Full, "10000baseT/Full" },
{ 0, ADVERTISED_10000baseKX4_Full, "10000baseKX4/Full" },
{ 0, ADVERTISED_20000baseMLD2_Full, "20000baseMLD2/Full" },
+ { 0, ADVERTISED_40000baseKR4_Full, "40000baseKR4/Full" },
+ { 0, ADVERTISED_40000baseCR4_Full, "40000baseCR4/Full" },
+ { 0, ADVERTISED_40000baseSR4_Full, "40000baseSR4/Full" },
+ { 0, ADVERTISED_40000baseLR4_Full, "40000baseLR4/Full" },
};
int indent;
int did1, new_line_pend, i;
--
1.6.0.2
^ permalink raw reply related
* Re: [XFRM][RFC v1] Fix unexpected SA hard expiration after setting new date
From: Herbert Xu @ 2012-06-18 8:40 UTC (permalink / raw)
To: fan.du; +Cc: davem, netdev, fdu
In-Reply-To: <1340007856-27651-1-git-send-email-fan.du@windriver.com>
On Mon, Jun 18, 2012 at 04:24:15PM +0800, fan.du wrote:
>
> So, could you please give your comments on this?
Well, this used to work back when we were using relative time
instead of absolute time. Then someone came along and changed
it for suspend/resume.
I didn't like this new behaviour but Dave convinced me that
it is a good thing :)
I guess I can live with your workaround if Dave is happy with
it. But IMHO we should just go back to relative time and fix
the suspend/resume user-space scripts instead.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [XFRM][RFC v1] Fix unexpected SA hard expiration after setting new date
From: Fan Du @ 2012-06-18 8:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev, fdu
In-Reply-To: <20120618084021.GA24902@gondor.apana.org.au>
On 2012年06月18日 16:40, Herbert Xu wrote:
> On Mon, Jun 18, 2012 at 04:24:15PM +0800, fan.du wrote:
>>
>> So, could you please give your comments on this?
>
> Well, this used to work back when we were using relative time
> instead of absolute time. Then someone came along and changed
> it for suspend/resume.
>
> I didn't like this new behaviour but Dave convinced me that
> it is a good thing :)
>
One of our custom complained the networking down when changing date,
even it's only less than 10 seconds, but they complain anyway:)
So it probably hurts much in practice for tel comm company.
> I guess I can live with your workaround if Dave is happy with
> it. But IMHO we should just go back to relative time and fix
> the suspend/resume user-space scripts instead.
Ok, let's see what Dave will say about this.
And thanks for your comments.
>
> Cheers,
--
Love each day!
--fan
^ permalink raw reply
* [PATCH] phy/micrel: change phy_id_mask for KSZ9021 and KS8001
From: Hui Wang @ 2012-06-18 8:52 UTC (permalink / raw)
To: david.choi, davem, nobuhiro.iwamatsu.yj; +Cc: netdev
On a freescale imx6q platform, a hardware phy chip KSZ9021 is
recognized as a KS8001 chip by the current driver like this:
eth0: Freescale FEC PHY driver [Micrel KS8001 or KS8721]
KSZ9021 has phy_id 0x00221610, while KSZ8001 has phy_id
0x0022161a, the current phy_id_mask (0x00fffff0/0x00ffff10) can't
distinguish them. So change phy_id_mask to resolve this problem.
Although the micrel datasheet says that the 4 LSB of phyid2 register
contains the chip revision number and the current driver is designed
to follow this rule, in reality the chip implementation doesn't follow
it.
Cc: David J. Choi <david.choi@micrel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Hui Wang <jason77.wang@gmail.com>
---
drivers/net/phy/micrel.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 590f902..9d6c80c 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -161,7 +161,7 @@ static struct phy_driver ks8051_driver = {
static struct phy_driver ks8001_driver = {
.phy_id = PHY_ID_KS8001,
.name = "Micrel KS8001 or KS8721",
- .phy_id_mask = 0x00fffff0,
+ .phy_id_mask = 0x00ffffff,
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = kszphy_config_init,
@@ -174,7 +174,7 @@ static struct phy_driver ks8001_driver = {
static struct phy_driver ksz9021_driver = {
.phy_id = PHY_ID_KSZ9021,
- .phy_id_mask = 0x000fff10,
+ .phy_id_mask = 0x000ffffe,
.name = "Micrel KSZ9021 Gigabit PHY",
.features = (PHY_GBIT_FEATURES | SUPPORTED_Pause
| SUPPORTED_Asym_Pause),
@@ -240,8 +240,8 @@ MODULE_AUTHOR("David J. Choi");
MODULE_LICENSE("GPL");
static struct mdio_device_id __maybe_unused micrel_tbl[] = {
- { PHY_ID_KSZ9021, 0x000fff10 },
- { PHY_ID_KS8001, 0x00fffff0 },
+ { PHY_ID_KSZ9021, 0x000ffffe },
+ { PHY_ID_KS8001, 0x00ffffff },
{ PHY_ID_KS8737, 0x00fffff0 },
{ PHY_ID_KS8041, 0x00fffff0 },
{ PHY_ID_KS8051, 0x00fffff0 },
--
1.7.6
^ permalink raw reply related
* Re: [PATCH net-next v2 01/12] netfilter: fix problem with proto register
From: Pablo Neira Ayuso @ 2012-06-18 9:06 UTC (permalink / raw)
To: Gao feng; +Cc: netdev, netfilter-devel
In-Reply-To: <4FDE7D5F.5080703@cn.fujitsu.com>
On Mon, Jun 18, 2012 at 08:59:11AM +0800, Gao feng wrote:
> 于 2012年06月16日 18:50, Pablo Neira Ayuso 写道:
> > On Sat, Jun 16, 2012 at 11:41:12AM +0800, Gao feng wrote:
> >> commit 2c352f444ccfa966a1aa4fd8e9ee29381c467448
> >> (netfilter: nf_conntrack: prepare namespace support for
> >> l4 protocol trackers) register proto before register sysctl.
> >>
> >> it changes the behavior that when register sysctl failed, the
> >> proto should not be registered too.
> >>
> >> so change to register sysctl before register protos.
> >
> > Could you explain why we need to change the order in the registration?
> > ie. now first proto->init_net then sysctl things.
>
> before commit 2c352f444ccfa966a1aa4fd8e9ee29381c467448, we register sysctl before
> register protos, so if sysctl is registered faild, the protos will not be registered.
>
> but now, we register protos first, and when register sysctl failed, we can use protos
> too, it's different from before.
That makes sense.
IMO, this is the thing that should be included in the description.
^ permalink raw reply
* unstable 10GBE performance with recent kernels (> 3.0.X)
From: Stefan Priebe - Profihost AG @ 2012-06-18 9:22 UTC (permalink / raw)
To: Linux Netdev List
Hello list,
i've discovered very unstable 10GBE performance using recent kernels.
I'm using some optimized settings mentioned by intel here
(part:Improving Performance):
http://downloadmirror.intel.com/5874/eng/README.txt
I'm using Intel X520 cards (ixgbe driver version: 3.9.17-NAPI in all
tests).
I'm measuring the performance with iperf.
With 3.0.32 i get constant 9,90 Gbit/s in both directions simultaneously.
With 3.4.2 or 3.5.0-rc2 it get sometimes 9,9gbit/s - sometimes 3gbit/s
or even sometimes only 1gbit/s throughput.
I also tried to change the tcp_congestion_control from cubic to reno,
bic and highspeed but no change.
I also tried to bisect the issue but there are so many changes in the
net kernel part that i'm unable to identify the problem as with some
commits i only get 0-300kb/s performance.
Any ideas?
Greets
Stefan
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Eric Dumazet @ 2012-06-18 9:45 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <4FDEF34C.808@profihost.ag>
On Mon, 2012-06-18 at 11:22 +0200, Stefan Priebe - Profihost AG wrote:
> Hello list,
>
> i've discovered very unstable 10GBE performance using recent kernels.
> I'm using some optimized settings mentioned by intel here
> (part:Improving Performance):
> http://downloadmirror.intel.com/5874/eng/README.txt
>
like what settings ?
> I'm using Intel X520 cards (ixgbe driver version: 3.9.17-NAPI in all
> tests).
>
> I'm measuring the performance with iperf.
>
> With 3.0.32 i get constant 9,90 Gbit/s in both directions simultaneously.
>
> With 3.4.2 or 3.5.0-rc2 it get sometimes 9,9gbit/s - sometimes 3gbit/s
> or even sometimes only 1gbit/s throughput.
>
> I also tried to change the tcp_congestion_control from cubic to reno,
> bic and highspeed but no change.
>
> I also tried to bisect the issue but there are so many changes in the
> net kernel part that i'm unable to identify the problem as with some
> commits i only get 0-300kb/s performance.
>
> Any ideas?
ethtool -S eth0
ethtool -k eth0
netstat -s (on sender, on receiver)
single flow , multiple flows ?
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Stefan Priebe - Profihost AG @ 2012-06-18 10:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1340012706.7491.770.camel@edumazet-glaptop>
Am 18.06.2012 11:45, schrieb Eric Dumazet:
> On Mon, 2012-06-18 at 11:22 +0200, Stefan Priebe - Profihost AG wrote:
>> Hello list,
>>
>> i've discovered very unstable 10GBE performance using recent kernels.
>> I'm using some optimized settings mentioned by intel here
>> (part:Improving Performance):
>> http://downloadmirror.intel.com/5874/eng/README.txt
>>
> like what settings ?
Sorry these ones:
http://pastebin.com/raw.php?i=J2XRFAjD
>> Any ideas?
>
> ethtool -S eth0
From host1 and 2: http://pastebin.com/raw.php?i=0Pp8Vs3Y
> ethtool -k eth0
From host1 and 2: # ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: on
# ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: on
> netstat -s (on sender, on receiver)
From host1 and 2: http://pastebin.com/raw.php?i=P9T96j0L
> single flow , multiple flows ?
host1: iperf -s
host2: iperf -c ssdstor002 -d -t 600 -i 10;
In this test i got around 7.4Gbit/s
Stefan
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Eric Dumazet @ 2012-06-18 10:25 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <4FDEFD55.7010204@profihost.ag>
On Mon, 2012-06-18 at 12:05 +0200, Stefan Priebe - Profihost AG wrote:
> Am 18.06.2012 11:45, schrieb Eric Dumazet:
> > On Mon, 2012-06-18 at 11:22 +0200, Stefan Priebe - Profihost AG wrote:
> >> Hello list,
> >>
> >> i've discovered very unstable 10GBE performance using recent kernels.
> >> I'm using some optimized settings mentioned by intel here
> >> (part:Improving Performance):
> >> http://downloadmirror.intel.com/5874/eng/README.txt
> >>
> > like what settings ?
>
> Sorry these ones:
> http://pastebin.com/raw.php?i=J2XRFAjD
>
I would remove all this (pretty old and obsolete) stuff and use standard
params.
Only thing you could do is :
ethtool -K eth2 ntuple on
on both machines
^ permalink raw reply
* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: Steffen Klassert @ 2012-06-18 11:05 UTC (permalink / raw)
To: fan.du; +Cc: davem, herbert, netdev, fdu
In-Reply-To: <1340007856-27651-2-git-send-email-fan.du@windriver.com>
On Mon, Jun 18, 2012 at 04:24:16PM +0800, fan.du wrote:
> After SA is setup, one timer is armed to detect soft/hard expiration,
> however the timer handler uses xtime to do the math. This makes hard
> expiration occurs first before soft expiration after setting new date
> with big interval. As a result new child SA is deleted before rekeying
> the new one.
>
> Signed-off-by: fan.du <fan.du@windriver.com>
> ---
> include/net/xfrm.h | 2 ++
> net/xfrm/xfrm_state.c | 22 ++++++++++++++++++----
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index 2933d74..1734acc 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -214,6 +214,8 @@ struct xfrm_state
> /* Private data of this transformer, format is opaque,
> * interpreted by xfrm_type methods. */
> void *data;
> + u32 flags;
We already have the xflags field, it holds exactly one flag
at the moment. So I think we don't need yet another u32 that
holds one flag too.
^ permalink raw reply
* [PATCH net-next] em_canid: Ematch rule to match CAN frames according to their CAN IDs
From: Rostislav Lisovy @ 2012-06-18 12:22 UTC (permalink / raw)
To: netdev; +Cc: linux-can, lartc, pisa, sojkam1, Rostislav Lisovy
This ematch makes it possible to classify CAN frames (AF_CAN) according
to their identifiers. This functionality can not be easily achieved with
existing classifiers, such as u32, because CAN ID is always stored in
native endianness, whereas u32 expects Network byte order.
The filtering rules for EFF frames are stored in an array, which
is traversed during classification. A bitmap is used to store SFF
rules -- one bit for each ID.
It is possible to to pass up to 32 'rules' to this ematch during
configuration.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
---
This Patch contains a reworked classifier initially posted in
http://www.spinics.net/lists/netdev/msg200114.html
The functionality is the same however there is almost 50% reduction
in the source code length.
There were simple benchmark performed on MPC5200 -- an embedded PowerPC CPU
(e300 core, G2 LE), 396 MHz, with 128 MiB of RAM running 3.4.2 Linux kernel
The benchmark simply generated CAN frames with different identifiers and the
time spent in can_send() function was measured.
CAN device was configured as follows:
ip link set can0 type can bitrate 1000000
ip link set can0 txqueuelen 1000
CAN frames were generated with command:
cangen can0 -I ${ID} -L 8 -D i -g 1 -n 100
With no extra filter/qdisc configured, median of the time spent in can_send()
was about 27 us -- with prio qdisc with 5 bands and 5 appropriate cls_can
filters (previous patch), it was about 30 us -- with prio qdisc with 5 bands
and 5 appropriate em_can filters (this patch), it was about 34 us.
---
include/linux/can.h | 3 +
include/linux/pkt_cls.h | 5 +-
net/sched/Kconfig | 10 ++
net/sched/Makefile | 1 +
net/sched/em_canid.c | 252 +++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 269 insertions(+), 2 deletions(-)
create mode 100644 net/sched/em_canid.c
diff --git a/include/linux/can.h b/include/linux/can.h
index 9a19bcb..08d1610 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -38,6 +38,9 @@
*/
typedef __u32 canid_t;
+#define CAN_SFF_ID_BITS 11
+#define CAN_EFF_ID_BITS 29
+
/*
* Controller Area Network Error Frame Mask structure
*
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index defbde2..7fbe6c2 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -451,8 +451,9 @@ enum {
#define TCF_EM_U32 3
#define TCF_EM_META 4
#define TCF_EM_TEXT 5
-#define TCF_EM_VLAN 6
-#define TCF_EM_MAX 6
+#define TCF_EM_VLAN 6
+#define TCF_EM_CANID 7
+#define TCF_EM_MAX 7
enum {
TCF_EM_PROG_TC
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 75b58f8..bc0ceab 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -485,6 +485,16 @@ config NET_EMATCH_TEXT
To compile this code as a module, choose M here: the
module will be called em_text.
+config NET_EMATCH_CANID
+ tristate "CAN ID"
+ depends on NET_EMATCH && CAN
+ ---help---
+ Say Y here if you want to be able to classify CAN frames based
+ on CAN ID.
+
+ To compile this code as a module, choose M here: the
+ module will be called em_canid.
+
config NET_CLS_ACT
bool "Actions"
---help---
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 8cdf4e2..47f9262 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_NET_EMATCH_NBYTE) += em_nbyte.o
obj-$(CONFIG_NET_EMATCH_U32) += em_u32.o
obj-$(CONFIG_NET_EMATCH_META) += em_meta.o
obj-$(CONFIG_NET_EMATCH_TEXT) += em_text.o
+obj-$(CONFIG_NET_EMATCH_CANID) += em_canid.o
diff --git a/net/sched/em_canid.c b/net/sched/em_canid.c
new file mode 100644
index 0000000..5cc6e5e
--- /dev/null
+++ b/net/sched/em_canid.c
@@ -0,0 +1,252 @@
+/*
+ * em_canid.c Ematch rule to match CAN frames according to their CAN IDs
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Idea: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Copyright: (c) 2011 Czech Technical University in Prague
+ * (c) 2011 Volkswagen Group Research
+ * Authors: Michal Sojka <sojkam1@fel.cvut.cz>
+ * Pavel Pisa <pisa@cmp.felk.cvut.cz>
+ * Rostislav Lisovy <lisovy@gmail.cz>
+ * Funded by: Volkswagen Group Research
+ */
+
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/skbuff.h>
+#include <net/pkt_cls.h>
+#include <linux/can.h>
+
+#define EM_CAN_RULES_SIZE 32
+
+struct canid_match {
+ /*
+ * Raw rules copied from netlink message; Used for sending
+ * information to userspace (when 'tc filter show' is invoked)
+ * AND when matching EFF frames
+ */
+ struct can_filter rules_raw[EM_CAN_RULES_SIZE];
+
+ /* For each SFF CAN ID (11 bit) there is one record in this bitfield */
+ DECLARE_BITMAP(match_sff, (1 << CAN_SFF_ID_BITS));
+
+ int rules_count;
+ int eff_rules_count;
+ int sff_rules_count;
+};
+
+/**
+ * em_canid_get_id() - Extracts Can ID out of the sk_buff structure.
+ */
+static canid_t em_canid_get_id(struct sk_buff *skb)
+{
+ /* CAN ID is stored within the data field */
+ struct can_frame *cf = (struct can_frame *)skb->data;
+
+ return cf->can_id;
+}
+
+static void em_canid_sff_match_add(struct canid_match *cm, u32 can_id,
+ u32 can_mask)
+{
+ int i;
+
+ /*
+ * Limit can_mask and can_id to SFF range to
+ * protect against write after end of array
+ */
+ can_mask &= CAN_SFF_MASK;
+ can_id &= can_mask;
+
+ /* Single frame */
+ if (can_mask == CAN_SFF_MASK) {
+ set_bit(can_id, cm->match_sff);
+ return;
+ }
+
+ /* All frames */
+ if (can_mask == 0) {
+ bitmap_fill(cm->match_sff, (1 << CAN_SFF_ID_BITS));
+ return;
+ }
+
+ /*
+ * Individual frame filter.
+ * Add record (set bit to 1) for each ID that
+ * conforms particular rule
+ */
+ for (i = 0; i < (1 << CAN_SFF_ID_BITS); i++) {
+ if ((i & can_mask) == can_id)
+ set_bit(i, cm->match_sff);
+ }
+}
+
+static inline struct canid_match *em_canid_priv(struct tcf_ematch *m)
+{
+ return (struct canid_match *) (m)->data;
+}
+
+static int em_canid_match(struct sk_buff *skb, struct tcf_ematch *m,
+ struct tcf_pkt_info *info)
+{
+ struct canid_match *cm = em_canid_priv(m);
+ canid_t can_id;
+ unsigned int match = false;
+ int i;
+
+ can_id = em_canid_get_id(skb);
+
+ if (can_id & CAN_EFF_FLAG) {
+ can_id &= CAN_EFF_MASK;
+
+ for (i = 0; i < cm->eff_rules_count; i++) {
+ if (!(((cm->rules_raw[i].can_id ^ can_id) &
+ cm->rules_raw[i].can_mask) & CAN_EFF_MASK)) {
+ match = true;
+ break;
+ }
+ }
+ } else { /* SFF */
+ can_id &= CAN_SFF_MASK;
+ match = test_bit(can_id, cm->match_sff);
+ }
+
+ if (match)
+ return 1;
+
+ return 0;
+}
+
+static int em_canid_change(struct tcf_proto *tp, void *data, int len,
+ struct tcf_ematch *m)
+{
+ struct can_filter *conf = data; /* Array with rules,
+ * fixed size EM_CAN_RULES_SIZE
+ */
+ struct canid_match *cm;
+ int err;
+ int i;
+
+ if (len < sizeof(struct can_filter))
+ return -EINVAL;
+
+ err = -ENOBUFS;
+ cm = kzalloc(sizeof(*cm), GFP_KERNEL);
+ if (cm == NULL)
+ goto errout;
+
+ cm->sff_rules_count = 0;
+ cm->eff_rules_count = 0;
+ cm->rules_count = len/sizeof(struct can_filter);
+ err = -EINVAL;
+
+ /* Be sure to fit into the array */
+ if (cm->rules_count > EM_CAN_RULES_SIZE)
+ goto errout_free;
+
+ /*
+ * We need two for() loops for copying rules into
+ * two contiguous areas in rules_raw
+ */
+
+ /* Process EFF frame rules*/
+ for (i = 0; i < cm->rules_count; i++) {
+ if ((conf[i].can_id & CAN_EFF_FLAG) &&
+ (conf[i].can_mask & CAN_EFF_FLAG)) {
+ memcpy(cm->rules_raw + cm->eff_rules_count,
+ &conf[i],
+ sizeof(struct can_filter));
+
+ cm->eff_rules_count++;
+ } else {
+ continue;
+ }
+ }
+
+ /* Process SFF frame rules */
+ for (i = 0; i < cm->rules_count; i++) {
+ if ((conf[i].can_id & CAN_EFF_FLAG) &&
+ (conf[i].can_mask & CAN_EFF_FLAG)) {
+ continue;
+ } else {
+ memcpy(cm->rules_raw
+ + cm->eff_rules_count
+ + cm->sff_rules_count,
+ &conf[i], sizeof(struct can_filter));
+
+ cm->sff_rules_count++;
+
+ em_canid_sff_match_add(cm,
+ conf[i].can_id, conf[i].can_mask);
+ }
+ }
+
+ m->datalen = sizeof(*cm);
+ m->data = (unsigned long) cm;
+
+ return 0;
+
+errout_free:
+ kfree(cm);
+errout:
+ return err;
+}
+
+static void em_canid_destroy(struct tcf_proto *tp, struct tcf_ematch *m)
+{
+ struct canid_match *cm = em_canid_priv(m);
+
+ kfree(cm);
+}
+
+static int em_canid_dump(struct sk_buff *skb, struct tcf_ematch *m)
+{
+ struct canid_match *cm = em_canid_priv(m);
+
+ /*
+ * When configuring this ematch 'rules_count' is set not to exceed
+ * 'rules_raw' array size
+ */
+ if (nla_put_nohdr(skb, sizeof(cm->rules_raw[0]) * cm->rules_count,
+ &cm->rules_raw) < 0)
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -1;
+}
+
+static struct tcf_ematch_ops em_canid_ops = {
+ .kind = TCF_EM_CANID,
+ .change = em_canid_change,
+ .match = em_canid_match,
+ .destroy = em_canid_destroy,
+ .dump = em_canid_dump,
+ .owner = THIS_MODULE,
+ .link = LIST_HEAD_INIT(em_canid_ops.link)
+};
+
+static int __init init_em_canid(void)
+{
+ return tcf_em_register(&em_canid_ops);
+}
+
+static void __exit exit_em_canid(void)
+{
+ tcf_em_unregister(&em_canid_ops);
+}
+
+MODULE_LICENSE("GPL");
+
+module_init(init_em_canid);
+module_exit(exit_em_canid);
+
+MODULE_ALIAS_TCF_EMATCH(TCF_EM_CANID);
--
1.7.10
^ permalink raw reply related
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Stefan Priebe - Profihost AG @ 2012-06-18 12:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1340015143.7491.855.camel@edumazet-glaptop>
Am 18.06.2012 12:25, schrieb Eric Dumazet:
> I would remove all this (pretty old and obsolete) stuff and use standard
> params.
OK, thanks. done.
I've one RHEL6 system (using default 2.6.32 kernel) where only using
"ntuple on" results in just 4-5Gbit/s while the others using 3.5.0-rc2
are working fine.
> Only thing you could do is :
> ethtool -K eth2 ntuple on
>
> on both machines
Thanks that works great and boosts the performance a lot. What does it
do? man ethtool doesn't show anything useful.
Is this also recommanded for 1Gb/s?
Could you recommend a tcp_congestion_control module? RHEL6 uses cubic by
default. Some others use reno or bic.
Stefan
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Eric Dumazet @ 2012-06-18 12:51 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <4FDF20B2.2010603@profihost.ag>
On Mon, 2012-06-18 at 14:36 +0200, Stefan Priebe - Profihost AG wrote:
> Am 18.06.2012 12:25, schrieb Eric Dumazet:
> > I would remove all this (pretty old and obsolete) stuff and use standard
> > params.
> OK, thanks. done.
>
> I've one RHEL6 system (using default 2.6.32 kernel) where only using
> "ntuple on" results in just 4-5Gbit/s while the others using 3.5.0-rc2
> are working fine.
>
OK, then you might play with affinities, that's the only thing that
might need sysadmin tuning (irqbalance needs to be disabled)
> > Only thing you could do is :
> > ethtool -K eth2 ntuple on
> >
> > on both machines
> Thanks that works great and boosts the performance a lot. What does it
> do? man ethtool doesn't show anything useful.
>
I am not Intel guy, but you might find some info in :
http://downloadmirror.intel.com/14687/eng/README.txt
> Is this also recommanded for 1Gb/s?
>
Not sure it's supported on ixgb
> Could you recommend a tcp_congestion_control module? RHEL6 uses cubic by
> default. Some others use reno or bic.
Hard to tell, there is no generic answer. Default should be fine for
most uses.
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Stefan Priebe - Profihost AG @ 2012-06-18 13:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1340023876.7491.1153.camel@edumazet-glaptop>
Am 18.06.2012 14:51, schrieb Eric Dumazet:
> On Mon, 2012-06-18 at 14:36 +0200, Stefan Priebe - Profihost AG wrote:
>> Am 18.06.2012 12:25, schrieb Eric Dumazet:
>>> I would remove all this (pretty old and obsolete) stuff and use
standard
>>> params.
>> OK, thanks. done.
>>
>> I've one RHEL6 system (using default 2.6.32 kernel) where only using
>> "ntuple on" results in just 4-5Gbit/s while the others using 3.5.0-rc2
>> are working fine.
>>
>
> OK, then you might play with affinities, that's the only thing that
> might need sysadmin tuning (irqbalance needs to be disabled)
I've now used this one:
# script provided by intel
/root/set_irq_affinity.sh eth2
ifconfig eth2 mtu 9000
ethtool -K eth2 ntuple on
irqbalance is off
But with the latest long term stable vanilla kernel 3.0.34.
# iperf -c HOST -t 60
works fine but with -d for using both directions i see around 9.8Gbit/s
in one direction and only 300kb/s in the other direction.
Stefan
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Eric Dumazet @ 2012-06-18 13:29 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <4FDF2829.6050705@profihost.ag>
On Mon, 2012-06-18 at 15:07 +0200, Stefan Priebe - Profihost AG wrote:
> Am 18.06.2012 14:51, schrieb Eric Dumazet:
> > On Mon, 2012-06-18 at 14:36 +0200, Stefan Priebe - Profihost AG wrote:
> >> Am 18.06.2012 12:25, schrieb Eric Dumazet:
> >>> I would remove all this (pretty old and obsolete) stuff and use
> standard
> >>> params.
> >> OK, thanks. done.
> >>
> >> I've one RHEL6 system (using default 2.6.32 kernel) where only using
> >> "ntuple on" results in just 4-5Gbit/s while the others using 3.5.0-rc2
> >> are working fine.
> >>
> >
> > OK, then you might play with affinities, that's the only thing that
> > might need sysadmin tuning (irqbalance needs to be disabled)
>
> I've now used this one:
>
> # script provided by intel
> /root/set_irq_affinity.sh eth2
> ifconfig eth2 mtu 9000
> ethtool -K eth2 ntuple on
>
> irqbalance is off
>
> But with the latest long term stable vanilla kernel 3.0.34.
>
> # iperf -c HOST -t 60
>
> works fine but with -d for using both directions i see around 9.8Gbit/s
> in one direction and only 300kb/s in the other direction.
>
> Stefan
I would try using regular MTU.
And post "netstat -s" results before/after your iperf.
^ permalink raw reply
* Re: unstable 10GBE performance with recent kernels (> 3.0.X)
From: Stefan Priebe - Profihost AG @ 2012-06-18 14:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1340026144.7491.1231.camel@edumazet-glaptop>
Am 18.06.2012 15:29, schrieb Eric Dumazet:
>> But with the latest long term stable vanilla kernel 3.0.34.
>>
>> # iperf -c HOST -t 60
>>
>> works fine but with -d for using both directions i see around 9.8Gbit/s
>> in one direction and only 300kb/s in the other direction.
>
> I would try using regular MTU.
For 3.5.0-rc2 this works fine but decreases the speed from 9,9Gbit/s to
9,3Gbit/s. With mtu 9000 i get around 3-4Gbit/s (netstat -s attached below)
With 3.0.34 MTU 9000 works fine with constant 9,9Gbit/s in both directions.
> And post "netstat -s" results before/after your iperf.
Tests with mtu 9000 and 3.5rc2:
Pre: http://pastebin.com/raw.php?i=uBjsFKjs
Post: http://pastebin.com/raw.php?i=TAK8JS6j
Thanks again!
Stefan
^ permalink raw reply
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Huajun Li @ 2012-06-18 16:25 UTC (permalink / raw)
To: Oliver Neukum
Cc: David Miller, tom.leiming-Re5JQEeQqe8AvxtiuMwx3w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201206180923.36091.oneukum-l3A5Bk7waGM@public.gmane.org>
On Mon, Jun 18, 2012 at 3:23 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
> Am Montag, 18. Juni 2012, 01:30:17 schrieb David Miller:
>> From: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 13 Jun 2012 20:50:31 +0800
>>
>> > intr_complete() submits URB even the interrupt endpoint stalls.
>> > This patch will try to activate the endpoint once the exception
>> > occurs, and then re-submit the URB if the endpoint works again.
>> >
>> > Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> Review from USB experts would be appreciated.
>
> The code implements a minimum error handler correctly.
> Did you observe a stall in actual hardware or is this a just
> in case patch?
>
This one is just a patch, thanks for your comments.
> Regards
> Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: added support for 40GbE link.
From: Rick Jones @ 2012-06-18 16:27 UTC (permalink / raw)
To: Parav Pandit; +Cc: netdev, bhutchings
In-Reply-To: <0c7c97b0-bfe1-4143-a562-2019f86912fc@exht1.ad.emulex.com>
On 06/18/2012 05:44 AM, Parav Pandit wrote:
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 297370a..1ebfa6e 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -1153,6 +1153,10 @@ struct ethtool_ops {
> #define SUPPORTED_10000baseR_FEC (1<< 20)
> #define SUPPORTED_20000baseMLD2_Full (1<< 21)
> #define SUPPORTED_20000baseKR2_Full (1<< 22)
> +#define SUPPORTED_40000baseKR4_Full (1<< 23)
> +#define SUPPORTED_40000baseCR4_Full (1<< 24)
> +#define SUPPORTED_40000baseSR4_Full (1<< 25)
> +#define SUPPORTED_40000baseLR4_Full (1<< 26)
>
> /* Indicates what features are advertised by the interface. */
> #define ADVERTISED_10baseT_Half (1<< 0)
> @@ -1178,6 +1182,10 @@ struct ethtool_ops {
> #define ADVERTISED_10000baseR_FEC (1<< 20)
> #define ADVERTISED_20000baseMLD2_Full (1<< 21)
> #define ADVERTISED_20000baseKR2_Full (1<< 22)
> +#define ADVERTISED_40000baseKR4_Full (1<< 23)
> +#define ADVERTISED_40000baseCR4_Full (1<< 24)
> +#define ADVERTISED_40000baseSR4_Full (1<< 25)
> +#define ADVERTISED_40000baseLR4_Full (1<< 26)
Any idea how many defines will be wanted for 100 Gbit Ethernet?
Supported and advertising in ethtool_cmd are __u32s...
rick jones
^ permalink raw reply
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Oliver Neukum @ 2012-06-18 16:51 UTC (permalink / raw)
To: Huajun Li
Cc: David Miller, tom.leiming-Re5JQEeQqe8AvxtiuMwx3w,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+v9cxZG6b1O7kOQpeTELtv0vHzqy-8NH84boMpim0BM+tp1eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Montag, 18. Juni 2012, 18:25:15 schrieb Huajun Li:
> On Mon, Jun 18, 2012 at 3:23 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
> > Am Montag, 18. Juni 2012, 01:30:17 schrieb David Miller:
> >> From: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date: Wed, 13 Jun 2012 20:50:31 +0800
> >>
> >> > intr_complete() submits URB even the interrupt endpoint stalls.
> >> > This patch will try to activate the endpoint once the exception
> >> > occurs, and then re-submit the URB if the endpoint works again.
> >> >
> >> > Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>
> >> Review from USB experts would be appreciated.
> >
> > The code implements a minimum error handler correctly.
> > Did you observe a stall in actual hardware or is this a just
> > in case patch?
> >
>
> This one is just a patch, thanks for your comments.
Then I am inclined to say that this is not fully thought through
If the endpoint stalls, the device has detected an error.
We have no idea how to generically handle this error.
We might come into a vicious circle. Could you add a sanity limit for the
amount of halts we clear?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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