* Re: [PATCH net-next 1/5] sky2: force receive checksum when using RSS on some hardware
From: Michał Mirosław @ 2011-07-07 17:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110707155212.000920741@vyatta.com>
2011/7/7 Stephen Hemminger <shemminger@vyatta.com>:
> Found when reviewing the vendor driver. Apparently some chip versions
> require receive checksumming to be enabled in order for RSS to work.
> Rather than silently enabling checksumming which is what the vendor
> driver does, return an error to the user instead.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
> --- a/drivers/net/sky2.c 2011-07-07 08:36:10.748003369 -0700
> +++ b/drivers/net/sky2.c 2011-07-07 08:36:37.372004595 -0700
> @@ -2996,7 +2996,8 @@ static int __devinit sky2_init(struct sk
> hw->flags = SKY2_HW_GIGABIT
> | SKY2_HW_NEWER_PHY
> | SKY2_HW_NEW_LE
> - | SKY2_HW_ADV_POWER_CTL;
> + | SKY2_HW_ADV_POWER_CTL
> + | SKY2_HW_RSS_CHKSUM;
>
> /* New transmit checksum */
> if (hw->chip_rev != CHIP_REV_YU_EX_B0)
> @@ -3024,7 +3025,7 @@ static int __devinit sky2_init(struct sk
>
> /* The workaround for status conflicts VLAN tag detection. */
> if (hw->chip_rev == CHIP_REV_YU_FE2_A0)
> - hw->flags |= SKY2_HW_VLAN_BROKEN;
> + hw->flags |= SKY2_HW_VLAN_BROKEN | SKY2_HW_RSS_CHKSUM;
> break;
>
> case CHIP_ID_YUKON_SUPR:
> @@ -3033,6 +3034,9 @@ static int __devinit sky2_init(struct sk
> | SKY2_HW_NEW_LE
> | SKY2_HW_AUTO_TX_SUM
> | SKY2_HW_ADV_POWER_CTL;
> +
> + if (hw->chip_rev == CHIP_REV_YU_SU_A0)
> + hw->flags |= SKY2_HW_RSS_CHKSUM;
> break;
>
> case CHIP_ID_YUKON_UL_2:
> @@ -4187,6 +4191,11 @@ static int sky2_set_features(struct net_
> struct sky2_port *sky2 = netdev_priv(dev);
> u32 changed = dev->features ^ features;
>
> + /* Some hardware requires receive checksum for RSS to work. */
> + if ( (features & (NETIF_F_RXHASH|NETIF_F_RXCSUM)) == NETIF_F_RXHASH &&
> + (sky2->hw->flags & SKY2_HW_RSS_CHKSUM))
> + return -EINVAL;
> +
> if (changed & NETIF_F_RXCSUM) {
> u32 on = features & NETIF_F_RXCSUM;
> sky2_write32(sky2->hw, Q_ADDR(rxqaddr[sky2->port], Q_CSR),
Nah. This won't work as the error is not passed to user (except via
dmesg) as there is no way to do it. Failing ndo_set_features() without
updating dev->features will also prevent other unrelated changes to
features set.
This should either force RXCSUM when RXHASH is on or disable RXHASH
when RXCSUM is off (both in sky2_fix_features()). Or maybe enable
RXCSUM with RXHASH but ignore hardware-computed checksum when it's not
requested.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: 3.0.0rc6: ethtool not working without a cable
From: Ben Hutchings @ 2011-07-07 17:03 UTC (permalink / raw)
To: Arkadiusz Miskiewicz
Cc: Brandeburg, Jesse, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <201107071847.14362.a.miskiewicz@gmail.com>
On Thu, 2011-07-07 at 18:47 +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 06 of July 2011, Arkadiusz Miskiewicz wrote:
> > On Wednesday 06 of July 2011, Brandeburg, Jesse wrote:
> > > On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> > > > On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > > > > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > > > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > > > > 3.0.0rc6, thinkpad t400 notebook.
> > > > > > >
> > > > > > > If there is no cable then ethtool reports no device. It wasn't
> > > > > > > that before AFAIK.
> > > > > > >
> > > > > > > ethtool version 2.6.36
> > >
> > > snip
> > >
> > > > Then the only other explanation I can think of is that the driver has
> > > > 'detached' the device due to some kind of error. The ethtool core does
> > > > have a check for that.
> > >
> > > could it be that aspm is enabled
> >
> > I have CONFIG_PCIEASPM=y
> >
> > > or that you've enabled runtime power
> > > management?
> >
> > In e1000e? no (unless it's default somehow).
>
> And if this is normal behaviour (when apsm is enabled) then maybe ethtool
> could disable apsm/power management for device for time of querying?
No, it's a driver bug if the device comes up in a 'detached' state.
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: 3.0.0rc6: ethtool not working without a cable
From: Arkadiusz Miskiewicz @ 2011-07-07 16:47 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: Ben Hutchings, netdev@vger.kernel.org, e1000-devel
In-Reply-To: <201107061857.21206.a.miskiewicz@gmail.com>
On Wednesday 06 of July 2011, Arkadiusz Miskiewicz wrote:
> On Wednesday 06 of July 2011, Brandeburg, Jesse wrote:
> > On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> > > On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > > > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > > > 3.0.0rc6, thinkpad t400 notebook.
> > > > > >
> > > > > > If there is no cable then ethtool reports no device. It wasn't
> > > > > > that before AFAIK.
> > > > > >
> > > > > > ethtool version 2.6.36
> >
> > snip
> >
> > > Then the only other explanation I can think of is that the driver has
> > > 'detached' the device due to some kind of error. The ethtool core does
> > > have a check for that.
> >
> > could it be that aspm is enabled
>
> I have CONFIG_PCIEASPM=y
>
> > or that you've enabled runtime power
> > management?
>
> In e1000e? no (unless it's default somehow).
And if this is normal behaviour (when apsm is enabled) then maybe ethtool
could disable apsm/power management for device for time of querying?
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* [PATCH net-next 3/5] sky2: support for new Optima chipsets (EXPERIMENTAL)
From: Stephen Hemminger @ 2011-07-07 15:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110707155056.939223264@vyatta.com>
[-- Attachment #1: sky2-op2.patch --]
[-- Type: text/plain, Size: 6749 bytes --]
This is a backport from the vendor driver of support for the newer Optima
(Prime and 2) chipsets. It also includes some setup changes for the
current Optima chip as well. The code and comments intentionally
mirror the vendor sk98lin driver to allow for easier maintenance.
Although this adds support for new chip id's, these chip id's are not
used by any of the current PCI device id's listed in the driver.
The patch is just to get initial infrastructure in place to handle them
when they come.
I don't have access to any of this hardware to actually test it yet.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-07-07 08:36:42.420004801 -0700
+++ b/drivers/net/sky2.c 2011-07-07 08:36:44.988004931 -0700
@@ -365,6 +365,17 @@ static void sky2_phy_init(struct sky2_hw
gm_phy_write(hw, port, PHY_MARV_FE_SPEC_2, spec);
}
} else {
+ if (hw->chip_id >= CHIP_ID_YUKON_OPT) {
+ u16 ctrl2 = gm_phy_read(hw, port, PHY_MARV_EXT_CTRL_2);
+
+ /* enable PHY Reverse Auto-Negotiation */
+ ctrl2 |= 1u << 13;
+
+ /* Write PHY changes (SW-reset must follow) */
+ gm_phy_write(hw, port, PHY_MARV_EXT_CTRL_2, ctrl2);
+ }
+
+
/* disable energy detect */
ctrl &= ~PHY_M_PC_EN_DET_MSK;
@@ -626,6 +637,63 @@ static void sky2_phy_init(struct sky2_hw
if (ledover)
gm_phy_write(hw, port, PHY_MARV_LED_OVER, ledover);
+ } else if (hw->chip_id == CHIP_ID_YUKON_PRM &&
+ (sky2_read8(hw, B2_MAC_CFG) & 0xf) == 0x7) {
+ int i;
+ /* This a phy register setup workaround copied from vendor driver. */
+ static const struct {
+ u16 reg, val;
+ } eee_afe[] = {
+ { 0x156, 0x58ce },
+ { 0x153, 0x99eb },
+ { 0x141, 0x8064 },
+ /* { 0x155, 0x130b },*/
+ { 0x000, 0x0000 },
+ { 0x151, 0x8433 },
+ { 0x14b, 0x8c44 },
+ { 0x14c, 0x0f90 },
+ { 0x14f, 0x39aa },
+ /* { 0x154, 0x2f39 },*/
+ { 0x14d, 0xba33 },
+ { 0x144, 0x0048 },
+ { 0x152, 0x2010 },
+ /* { 0x158, 0x1223 },*/
+ { 0x140, 0x4444 },
+ { 0x154, 0x2f3b },
+ { 0x158, 0xb203 },
+ { 0x157, 0x2029 },
+ };
+
+ /* Start Workaround for OptimaEEE Rev.Z0 */
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0x00fb);
+
+ gm_phy_write(hw, port, 1, 0x4099);
+ gm_phy_write(hw, port, 3, 0x1120);
+ gm_phy_write(hw, port, 11, 0x113c);
+ gm_phy_write(hw, port, 14, 0x8100);
+ gm_phy_write(hw, port, 15, 0x112a);
+ gm_phy_write(hw, port, 17, 0x1008);
+
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0x00fc);
+ gm_phy_write(hw, port, 1, 0x20b0);
+
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0x00ff);
+
+ for (i = 0; i < ARRAY_SIZE(eee_afe); i++) {
+ /* apply AFE settings */
+ gm_phy_write(hw, port, 17, eee_afe[i].val);
+ gm_phy_write(hw, port, 16, eee_afe[i].reg | 1u<<13);
+ }
+
+ /* End Workaround for OptimaEEE */
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
+
+ /* Enable 10Base-Te (EEE) */
+ if (hw->chip_id >= CHIP_ID_YUKON_PRM) {
+ reg = gm_phy_read(hw, port, PHY_MARV_EXT_CTRL);
+ gm_phy_write(hw, port, PHY_MARV_EXT_CTRL,
+ reg | PHY_M_10B_TE_ENABLE);
+ }
}
/* Enable phy interrupt on auto-negotiation complete (or link up) */
@@ -2959,6 +3027,8 @@ static u32 sky2_mhz(const struct sky2_hw
case CHIP_ID_YUKON_SUPR:
case CHIP_ID_YUKON_UL_2:
case CHIP_ID_YUKON_OPT:
+ case CHIP_ID_YUKON_PRM:
+ case CHIP_ID_YUKON_OP_2:
return 125;
case CHIP_ID_YUKON_FE:
@@ -3064,6 +3134,8 @@ static int __devinit sky2_init(struct sk
break;
case CHIP_ID_YUKON_OPT:
+ case CHIP_ID_YUKON_PRM:
+ case CHIP_ID_YUKON_OP_2:
hw->flags = SKY2_HW_GIGABIT
| SKY2_HW_NEW_LE
| SKY2_HW_ADV_POWER_CTL;
@@ -3163,30 +3235,33 @@ static void sky2_reset(struct sky2_hw *h
sky2_pci_write32(hw, PCI_DEV_REG3, P_CLK_MACSEC_DIS);
}
- if (hw->chip_id == CHIP_ID_YUKON_OPT) {
+ if (hw->chip_id == CHIP_ID_YUKON_OPT ||
+ hw->chip_id == CHIP_ID_YUKON_PRM ||
+ hw->chip_id == CHIP_ID_YUKON_OP_2) {
u16 reg;
u32 msk;
- if (hw->chip_rev == 0) {
+ if (hw->chip_id == CHIP_ID_YUKON_OPT && hw->chip_rev == 0) {
/* disable PCI-E PHY power down (set PHY reg 0x80, bit 7 */
sky2_write32(hw, Y2_PEX_PHY_DATA, (0x80UL << 16) | (1 << 7));
/* set PHY Link Detect Timer to 1.1 second (11x 100ms) */
reg = 10;
+
+ /* re-enable PEX PM in PEX PHY debug reg. 8 (clear bit 12) */
+ sky2_write32(hw, Y2_PEX_PHY_DATA, PEX_DB_ACCESS | (0x08UL << 16));
} else {
/* set PHY Link Detect Timer to 0.4 second (4x 100ms) */
reg = 3;
}
reg <<= PSM_CONFIG_REG4_TIMER_PHY_LINK_DETECT_BASE;
+ reg |= PSM_CONFIG_REG4_RST_PHY_LINK_DETECT;
/* reset PHY Link Detect */
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- sky2_pci_write16(hw, PSM_CONFIG_REG4,
- reg | PSM_CONFIG_REG4_RST_PHY_LINK_DETECT);
sky2_pci_write16(hw, PSM_CONFIG_REG4, reg);
-
/* enable PHY Quick Link */
msk = sky2_read32(hw, B0_IMSK);
msk |= Y2_IS_PHY_QLNK;
@@ -4705,9 +4780,11 @@ static const char *sky2_name(u8 chipid,
"UL 2", /* 0xba */
"Unknown", /* 0xbb */
"Optima", /* 0xbc */
+ "Optima Prime", /* 0xbd */
+ "Optima 2", /* 0xbe */
};
- if (chipid >= CHIP_ID_YUKON_XL && chipid <= CHIP_ID_YUKON_OPT)
+ if (chipid >= CHIP_ID_YUKON_XL && chipid <= CHIP_ID_YUKON_OP_2)
strncpy(buf, name[chipid - CHIP_ID_YUKON_XL], sz);
else
snprintf(buf, sz, "(chip %#x)", chipid);
--- a/drivers/net/sky2.h 2011-07-07 08:36:42.420004801 -0700
+++ b/drivers/net/sky2.h 2011-07-07 08:36:44.992004932 -0700
@@ -412,7 +412,7 @@ enum {
Y2_IS_HW_ERR = 1<<31, /* Interrupt HW Error */
Y2_IS_STAT_BMU = 1<<30, /* Status BMU Interrupt */
Y2_IS_ASF = 1<<29, /* ASF subsystem Interrupt */
-
+ Y2_IS_CPU_TO = 1<<28, /* CPU Timeout */
Y2_IS_POLL_CHK = 1<<27, /* Check IRQ from polling unit */
Y2_IS_TWSI_RDY = 1<<26, /* IRQ on end of TWSI Tx */
Y2_IS_IRQ_SW = 1<<25, /* SW forced IRQ */
@@ -547,6 +547,8 @@ enum {
CHIP_ID_YUKON_SUPR = 0xb9, /* YUKON-2 Supreme */
CHIP_ID_YUKON_UL_2 = 0xba, /* YUKON-2 Ultra 2 */
CHIP_ID_YUKON_OPT = 0xbc, /* YUKON-2 Optima */
+ CHIP_ID_YUKON_PRM = 0xbd, /* YUKON-2 Optima Prime */
+ CHIP_ID_YUKON_OP_2 = 0xbe, /* YUKON-2 Optima 2 */
};
enum yukon_xl_rev {
@@ -1420,8 +1422,10 @@ enum {
PHY_M_EC_FIB_AN_ENA = 1<<3, /* Fiber Auto-Neg. Enable (88E1011S only) */
PHY_M_EC_DTE_D_ENA = 1<<2, /* DTE Detect Enable (88E1111 only) */
PHY_M_EC_TX_TIM_CT = 1<<1, /* RGMII Tx Timing Control */
- PHY_M_EC_TRANS_DIS = 1<<0, /* Transmitter Disable (88E1111 only) */};
+ PHY_M_EC_TRANS_DIS = 1<<0, /* Transmitter Disable (88E1111 only) */
+ PHY_M_10B_TE_ENABLE = 1<<7, /* 10Base-Te Enable (88E8079 and above) */
+};
#define PHY_M_EC_M_DSC(x) ((u16)(x)<<10 & PHY_M_EC_M_DSC_MSK)
/* 00=1x; 01=2x; 10=3x; 11=4x */
#define PHY_M_EC_S_DSC(x) ((u16)(x)<<8 & PHY_M_EC_S_DSC_MSK)
^ permalink raw reply
* [PATCH net-next 0/5] sky2 driver update
From: Stephen Hemminger @ 2011-07-07 15:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Got inspired to look at what has changed in recent versions
of vendor driver (10.88.1.3). There were a couple of small things
and some new chip versions.
^ permalink raw reply
* [PATCH net-next 1/5] sky2: force receive checksum when using RSS on some hardware
From: Stephen Hemminger @ 2011-07-07 15:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110707155056.939223264@vyatta.com>
[-- Attachment #1: sky2-rxhash-rxcsum.patch --]
[-- Type: text/plain, Size: 2231 bytes --]
Found when reviewing the vendor driver. Apparently some chip versions
require receive checksumming to be enabled in order for RSS to work.
Rather than silently enabling checksumming which is what the vendor
driver does, return an error to the user instead.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-07-07 08:36:10.748003369 -0700
+++ b/drivers/net/sky2.c 2011-07-07 08:36:37.372004595 -0700
@@ -2996,7 +2996,8 @@ static int __devinit sky2_init(struct sk
hw->flags = SKY2_HW_GIGABIT
| SKY2_HW_NEWER_PHY
| SKY2_HW_NEW_LE
- | SKY2_HW_ADV_POWER_CTL;
+ | SKY2_HW_ADV_POWER_CTL
+ | SKY2_HW_RSS_CHKSUM;
/* New transmit checksum */
if (hw->chip_rev != CHIP_REV_YU_EX_B0)
@@ -3024,7 +3025,7 @@ static int __devinit sky2_init(struct sk
/* The workaround for status conflicts VLAN tag detection. */
if (hw->chip_rev == CHIP_REV_YU_FE2_A0)
- hw->flags |= SKY2_HW_VLAN_BROKEN;
+ hw->flags |= SKY2_HW_VLAN_BROKEN | SKY2_HW_RSS_CHKSUM;
break;
case CHIP_ID_YUKON_SUPR:
@@ -3033,6 +3034,9 @@ static int __devinit sky2_init(struct sk
| SKY2_HW_NEW_LE
| SKY2_HW_AUTO_TX_SUM
| SKY2_HW_ADV_POWER_CTL;
+
+ if (hw->chip_rev == CHIP_REV_YU_SU_A0)
+ hw->flags |= SKY2_HW_RSS_CHKSUM;
break;
case CHIP_ID_YUKON_UL_2:
@@ -4187,6 +4191,11 @@ static int sky2_set_features(struct net_
struct sky2_port *sky2 = netdev_priv(dev);
u32 changed = dev->features ^ features;
+ /* Some hardware requires receive checksum for RSS to work. */
+ if ( (features & (NETIF_F_RXHASH|NETIF_F_RXCSUM)) == NETIF_F_RXHASH &&
+ (sky2->hw->flags & SKY2_HW_RSS_CHKSUM))
+ return -EINVAL;
+
if (changed & NETIF_F_RXCSUM) {
u32 on = features & NETIF_F_RXCSUM;
sky2_write32(sky2->hw, Q_ADDR(rxqaddr[sky2->port], Q_CSR),
--- a/drivers/net/sky2.h 2011-07-06 21:57:43.155687362 -0700
+++ b/drivers/net/sky2.h 2011-07-07 08:36:37.372004595 -0700
@@ -2281,6 +2281,7 @@ struct sky2_hw {
#define SKY2_HW_ADV_POWER_CTL 0x00000080 /* additional PHY power regs */
#define SKY2_HW_RSS_BROKEN 0x00000100
#define SKY2_HW_VLAN_BROKEN 0x00000200
+#define SKY2_HW_RSS_CHKSUM 0x00000400 /* RSS requires chksum */
u8 chip_id;
u8 chip_rev;
^ permalink raw reply
* [PATCH net-next 4/5] sky2: version 1.29
From: Stephen Hemminger @ 2011-07-07 15:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110707155056.939223264@vyatta.com>
[-- Attachment #1: sky2-version.patch --]
[-- Type: text/plain, Size: 445 bytes --]
Since new hardware chip support was added bump version.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-07-07 08:38:11.208009500 -0700
+++ b/drivers/net/sky2.c 2011-07-07 08:38:21.612001463 -0700
@@ -50,7 +50,7 @@
#include "sky2.h"
#define DRV_NAME "sky2"
-#define DRV_VERSION "1.28"
+#define DRV_VERSION "1.29"
/*
* The Yukon II chipset takes 64 bit command blocks (called list elements)
^ permalink raw reply
* [PATCH net-next 5/5] skge/sky2: change config references to Marvell
From: Stephen Hemminger @ 2011-07-07 15:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110707155056.939223264@vyatta.com>
[-- Attachment #1: marvell.patch --]
[-- Type: text/plain, Size: 1498 bytes --]
Change references to SysKonnect in Kconfig to Marvell since
SysKonnect was acquired by Marvell back in 2002.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/Kconfig 2011-07-07 08:39:18.456011945 -0700
+++ b/drivers/net/Kconfig 2011-07-07 08:43:41.372026416 -0700
@@ -2272,7 +2272,7 @@ config SIS190
will be called sis190. This is recommended.
config SKGE
- tristate "SysKonnect GigaEthernet support"
+ tristate "Marvell Yukon Gigabit Ethernet support"
depends on PCI
select CRC32
---help---
@@ -2288,7 +2288,7 @@ config SKGE
Linksys EG1032/EG1064, 3Com 3C940/3C940B, SysKonnect SK-9871/9872.
It does not support the newer Yukon2 chipset: a separate driver,
- sky2, is provided for Yukon2-based adapters.
+ sky2, is provided for these adapters.
To compile this driver as a module, choose M here: the module
will be called skge. This is recommended.
@@ -2313,7 +2313,7 @@ config SKGE_GENESIS
by making code smaller. If unsure say Y.
config SKY2
- tristate "SysKonnect Yukon2 support"
+ tristate "Marvell Yukon 2 support"
depends on PCI
select CRC32
---help---
@@ -2323,7 +2323,7 @@ config SKY2
88E8053/88E8055/88E8061/88E8062, SysKonnect SK-9E21D/SK-9S21
There is companion driver for the older Marvell Yukon and
- Genesis based adapters: skge.
+ SysKonnect Genesis based adapters: skge.
To compile this driver as a module, choose M here: the module
will be called sky2. This is recommended.
^ permalink raw reply
* [PATCH net-next 2/5] sky2: use correct Inter Packet Gap at 10/100mbit
From: Stephen Hemminger @ 2011-07-07 15:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20110707155056.939223264@vyatta.com>
[-- Attachment #1: sky2-100mbit-ipg.patch --]
[-- Type: text/plain, Size: 2390 bytes --]
This is another fix picked out of the vendor driver. The IPG value
in the serial mode register is supposed to be programmed differently
at lower speeds.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-07-07 08:36:37.372004595 -0700
+++ b/drivers/net/sky2.c 2011-07-07 08:36:42.420004801 -0700
@@ -714,6 +714,20 @@ static void sky2_phy_power_down(struct s
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
+/* configure IPG according to used link speed */
+static void sky2_set_ipg(struct sky2_port *sky2)
+{
+ u16 reg;
+
+ reg = gma_read16(sky2->hw, sky2->port, GM_SERIAL_MODE);
+ reg &= ~GM_SMOD_IPG_MSK;
+ if (sky2->speed > SPEED_100)
+ reg |= IPG_DATA_VAL(IPG_DATA_DEF_1000);
+ else
+ reg |= IPG_DATA_VAL(IPG_DATA_DEF_10_100);
+ gma_write16(sky2->hw, sky2->port, GM_SERIAL_MODE, reg);
+}
+
/* Enable Rx/Tx */
static void sky2_enable_rx_tx(struct sky2_port *sky2)
{
@@ -882,7 +896,7 @@ static void sky2_mac_init(struct sky2_hw
/* serial mode register */
reg = DATA_BLIND_VAL(DATA_BLIND_DEF) |
- GM_SMOD_VLAN_ENA | IPG_DATA_VAL(IPG_DATA_DEF);
+ GM_SMOD_VLAN_ENA | IPG_DATA_VAL(IPG_DATA_DEF_1000);
if (hw->dev[port]->mtu > ETH_DATA_LEN)
reg |= GM_SMOD_JUMBO_ENA;
@@ -2053,6 +2067,8 @@ static void sky2_link_up(struct sky2_por
[FC_BOTH] = "both",
};
+ sky2_set_ipg(sky2);
+
sky2_enable_rx_tx(sky2);
gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
@@ -2290,8 +2306,11 @@ static int sky2_change_mtu(struct net_de
dev->mtu = new_mtu;
netdev_update_features(dev);
- mode = DATA_BLIND_VAL(DATA_BLIND_DEF) |
- GM_SMOD_VLAN_ENA | IPG_DATA_VAL(IPG_DATA_DEF);
+ mode = DATA_BLIND_VAL(DATA_BLIND_DEF) | GM_SMOD_VLAN_ENA;
+ if (sky2->speed > SPEED_100)
+ mode |= IPG_DATA_VAL(IPG_DATA_DEF_1000);
+ else
+ mode |= IPG_DATA_VAL(IPG_DATA_DEF_10_100);
if (dev->mtu > ETH_DATA_LEN)
mode |= GM_SMOD_JUMBO_ENA;
--- a/drivers/net/sky2.h 2011-07-07 08:36:37.372004595 -0700
+++ b/drivers/net/sky2.h 2011-07-07 08:36:42.420004801 -0700
@@ -1807,10 +1807,11 @@ enum {
};
#define DATA_BLIND_VAL(x) (((x)<<11) & GM_SMOD_DATABL_MSK)
-#define DATA_BLIND_DEF 0x04
-
#define IPG_DATA_VAL(x) (x & GM_SMOD_IPG_MSK)
-#define IPG_DATA_DEF 0x1e
+
+#define DATA_BLIND_DEF 0x04
+#define IPG_DATA_DEF_1000 0x1e
+#define IPG_DATA_DEF_10_100 0x18
/* GM_SMI_CTRL 16 bit r/w SMI Control Register */
enum {
^ permalink raw reply
* Re: [PATCH 08/10] dynamic_debug: make netif_dbg() call __netdev_printk()
From: Joe Perches @ 2011-07-07 16:29 UTC (permalink / raw)
To: Jason Baron
Cc: gregkh, jim.cromie, bvanassche, linux-kernel, davem,
aloisio.almeida, netdev
In-Reply-To: <20110707141259.GA2536@redhat.com>
On Thu, 2011-07-07 at 10:13 -0400, Jason Baron wrote:
> On Wed, Jul 06, 2011 at 02:59:03PM -0700, Joe Perches wrote:
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > @@ -2731,10 +2731,8 @@ do { \
> > > #elif defined(CONFIG_DYNAMIC_DEBUG)
> > > #define netif_dbg(priv, type, netdev, format, args...) \
> > > do { \
> > > - if (netif_msg_##type(priv)) \
> > > - dynamic_dev_dbg((netdev)->dev.parent, \
> > > - "%s: " format, \
> > > - netdev_name(netdev), ##args); \
> > > + dynamic_netif_dbg(netdev, (netif_msg_##type(priv)), \
> > > + format, ##args); \
> > Because you've already added dynamic_netdev_dbg,
> > maybe this should be:
> > #define netif_dbg(priv, type, netdev, format, args...) \
> > do { \
> > if (netif_msg_##type(priv)) \
> > dynamic_netdev_dbg(netdev, format, ##args); \
> > } while (0)
> The reason I didn't add it this way is b/c I plan on converting the
> outer 'ifs' to the jump label infrastructure - which makes the disabled
> case just a no-op and moves the printk and tests out of line.
Perhaps you needn't do that.
I think there's little to be gained to move the test
outwards and not perform the netif_msg##type(priv)
> Until that is done, i could see coding it as you've suggested, but I'd
> prefer to leave it as is (and leave future churn to within the dynamic
> debug code as opposed to the netdevice.h header).
Shrug. I think that dynamic_debug will have continuing
impacts on various subsystems unless there's some generic
__dynamic_dbg() and _prefix() mechanism introduced into
more generic <foo>_dbg style.
Anything logging message that uses <foo>_dbg or <foo>_vdbg
is a candidate for dynamic_debug uses, but there's no
current generic mechanism to avoid subsystem specific needs.
Any of these could need some dynamic_debug consideration:
$ grep -rPoh --include=*.[ch] "[a-z_]+_[v]?dbg\(" * | sort | uniq
acpi_ut_allocate_object_desc_dbg(
acpi_ut_create_internal_object_dbg(
adc_dbg(
add_dyn_dbg(
airo_print_dbg(
ata_dev_dbg(
ata_link_dbg(
ata_port_dbg(
ath_dbg(
atm_dbg(
bat_dbg(
bit_dbg(
cafe_dev_dbg(
cam_dbg(
c_freq_dbg(
chan_dbg(
chan_reg_rule_print_dbg(
cmm_dbg(
c_pm_dbg(
ctrl_dbg(
__dbg(
desc_dbg(
dev_dbg(
dev_vdbg(
dma_request_channel_dbg(
__dump_desc_dbg(
dump_desc_dbg(
dump_pq_desc_dbg(
dynamic_dev_dbg(
e_dbg(
ehca_dbg(
ehca_gen_dbg(
ehci_dbg(
ehci_vdbg(
en_dbg(
ep_dbg(
ep_vdbg(
fhci_dbg(
fhci_vdbg(
fit_dbg(
gig_dbg(
gpio_dbg(
gru_dbg(
hgpk_dbg(
hid_dbg(
hw_dbg(
ibmvfc_dbg(
ipath_dbg(
ipoib_dbg(
ipr_dbg(
iser_dbg(
isp_isr_dbg(
itd_dbg(
ite_dbg(
l_dbg(
lg_dbg(
mce_dbg(
memblock_dbg(
mhwmp_dbg(
mpeg_dbg(
mpl_dbg(
msg_dbg(
mthca_dbg(
netdev_dbg(
netdev_vdbg(
netif_dbg(
netif_vdbg(
nfc_dbg(
nfc_dev_dbg(
nsp_dbg(
nvt_dbg(
ohci_dbg(
ohci_vdbg(
oxu_dbg(
oxu_vdbg(
pch_dbg(
pch_pci_dbg(
pm_dev_dbg(
pnp_dbg(
pop_dbg(
prep_dma_pq_dbg(
prep_dma_pqzero_sum_dbg(
prep_dma_xor_dbg(
_print_dbg(
print_dbg(
pwm_dbg(
rdev_dbg(
reg_dbg(
sh_keysc_map_dbg(
slice_dbg(
smsc_dbg(
start_dbg(
stop_dbg(
sysrq_handle_dbg(
tda_dbg(
tgt_dbg(
tipc_msg_dbg(
__tuner_dbg(
tuner_dbg(
tveeprom_dbg(
tx_dbg(
uea_dbg(
uea_vdbg(
ugeth_dbg(
ugeth_vdbg(
urb_dbg(
usb_dbg(
vpif_dbg(
wiphy_dbg(
wiphy_vdbg(
xhci_dbg(
x_show_dbg(
^ permalink raw reply
* Re: linux-next: Tree for July 7 (net/af_packet)
From: Randy Dunlap @ 2011-07-07 15:40 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20110707.081839.2119597618388053074.davem@davemloft.net>
On Thu, 07 Jul 2011 08:18:39 -0700 (PDT) David Miller wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Thu, 7 Jul 2011 08:12:02 -0700
>
> > On Thu, 7 Jul 2011 17:25:44 +1000 Stephen Rothwell wrote:
> >
> >> Hi all,
> >>
> >> The next linux-next release will (probably) be next-20110718.
> >>
> >> Changes since 20110706:
> >
> >
> > When CONFIG_INET is not enabled:
> >
> > af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
> > or
> > ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!
>
> Sorry about that, fixed thusly:
>
> --------------------
> packet: Fix build with INET disabled.
>
> af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
> or
> ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!
>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
> ---
> net/packet/af_packet.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index aa4c73a..d2294ad 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -456,6 +456,7 @@ static struct sock *fanout_demux_cpu(struct packet_fanout *f, struct sk_buff *sk
>
> static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
> {
> +#ifdef CONFIG_INET
> const struct iphdr *iph;
> u32 len;
>
> @@ -486,6 +487,7 @@ static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
> skb->rxhash = 0;
> }
> }
> +#endif
> return skb;
> }
>
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-07 15:34 UTC (permalink / raw)
To: Loke, Chetan, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B912622709@nsmail.netscout.com>
> From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> > -----Original Message-----
> > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> >
> > > From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> > >
> > > > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> >
> > > How often are you going to re-size your remote-SWAP?
> >
> > is "as often as the working set changes on any machine in the
> > cluster", meaning *constantly*, entirely dynamically! How
> > about a more specific example: Suppose you have 2 machines,
> > each with 8GB of memory. 99% of the time each machine is
> > chugging along just fine and doesn't really need more than 4GB,
> > and may even use less than 1GB a large part of the time.
> > But very now and then, one of the machines randomly needs
> > 9GB, 10GB, maybe even 12GB of memory. This would normally
> > result in swapping. (Most system administrators won't even
> > have this much information... they'll just know they are
> > seeing swapping and decide they need to buy more RAM.)
> >
>
> Ok, I understand there is interest in implementing
> 'remote-volatile-ballooning-variant' but how do you pick a remote
> candidate(hypervisor)? Let's say, memory could be available on remote
> system but what if the remote-p{NIC,CPU} is overloaded? Sure, sysadmins
> won't have this info because this so dynamic(and it's quite possible as
> you mentioned above). But does the trans-remote-API know about this
> resource-availability before opening a remote-channel?
>
> Stressing the remote-p{NIC/CPU} might trick hypervisor-vmotion-plugin to
> vmotion VM[s] to another hypervisor. How is trans-remote-API integrating
> with remote/global vmotion policies to avoid this false vmotion?
Hi Chetan --
Thanks for the continued discussion.
First, let me clarify that RAMster does not depend on virtualization.
At some time in the future, it may be a nice addition for KVM*,
but the version I am developing currently only works on a
cluster of physical machines. So vmotion/migration is not
an issue right now
As for choosing the remote machine, another key feature of
the Transcendent Memory mechanism is that any and every page
can be rejected. If rejected, the page remains local. In
essence, on *every* page-to-be-swapped, machine A *asks*
machine B, "can you take this page"? If the answer is no,
machine A can choose another machine (C), or may choose to
swap the page to its own slow swap disk. (Currently,
only the latter is implemented, but more complicated
policy could certainly be implemented.)
Dan
* Xen doesn't have drivers so RAMster-over-network is not an option
for Xen. A future RAMster-over-exofabric might work with Xen though.)
And, by the way, the Transcendent Memory implementation on Xen
does handle vmotion/migration so it is a solvable problem.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: Tree for July 7 (net/af_packet)
From: David Miller @ 2011-07-07 15:18 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20110707081202.6dddcbce.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 7 Jul 2011 08:12:02 -0700
> On Thu, 7 Jul 2011 17:25:44 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> The next linux-next release will (probably) be next-20110718.
>>
>> Changes since 20110706:
>
>
> When CONFIG_INET is not enabled:
>
> af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
> or
> ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!
Sorry about that, fixed thusly:
--------------------
packet: Fix build with INET disabled.
af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
or
ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/packet/af_packet.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index aa4c73a..d2294ad 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -456,6 +456,7 @@ static struct sock *fanout_demux_cpu(struct packet_fanout *f, struct sk_buff *sk
static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
{
+#ifdef CONFIG_INET
const struct iphdr *iph;
u32 len;
@@ -486,6 +487,7 @@ static struct sk_buff *fanout_check_defrag(struct sk_buff *skb)
skb->rxhash = 0;
}
}
+#endif
return skb;
}
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] [v3][net][bna] Fix call trace when interrupts are disabled while sleeping function kzalloc is called
From: Ivan Vecera @ 2011-07-07 15:13 UTC (permalink / raw)
To: Shyam Iyer; +Cc: netdev, rmody, ddutt, huangj, davem, Shyam Iyer
In-Reply-To: <1309287485-6077-1-git-send-email-shyam_iyer@dell.com>
Small note, the root of the problem was that non-atomic allocation was
requested with IRQs disabled. Your patch description does not contain
why were the IRQs disabled.
The function bnad_mbox_irq_alloc incorrectly uses 'flags' var for two
different things, 1) to save current CPU flags and 2) for request_irq
call.
First the spin_lock_irqsave disables the IRQs and saves _all_ CPU flags
(including one that enables/disables interrupts) to 'flags'. Then the
'flags' is overwritten by 0 or 0x80 (IRQF_SHARED). Finally the
spin_unlock_irqrestore should restore saved flags, but these flags are
now either 0x00 or 0x80. The interrupt bit value in flags register on
x86 arch is 0x100.
This means that the interrupt bit is zero (IRQs disabled) after
spin_unlock_irqrestore so the request_irq function is called with
disabled interrupts.
Rasesh, this is not a good idea to use one variable for two different
purposes in parallel.
Regards,
Ivan
On Tue, 2011-06-28 at 14:58 -0400, Shyam Iyer wrote:
> request_threaded irq will call kzalloc that can sleep. Initializing the flags variable outside of spin_lock_irqsave/restore in bnad_mbox_irq_alloc will avoid call traces like below.
>
> Jun 27 08:15:24 home-t710 kernel: [11735.634550] Brocade 10G Ethernet driver
> Jun 27 08:15:24 home-t710 kernel: [11735.634590] bnad_pci_probe : (0xffff880427f3d000, 0xffffffffa020f3e0) PCI Func : (2)
> Jun 27 08:15:24 home-t710 kernel: [11735.637677] bna 0000:82:00.2: PCI INT A -> GSI 66 (level, low) -> IRQ 66
> Jun 27 08:15:24 home-t710 kernel: [11735.638290] bar0 mapped to ffffc90014980000, len 262144
> Jun 27 08:15:24 home-t710 kernel: [11735.638732] BUG: sleeping function called from invalid context at mm/slub.c:847
> Jun 27 08:15:24 home-t710 kernel: [11735.638736] in_atomic(): 0, irqs_disabled(): 1, pid: 11243, name: insmod
> Jun 27 08:15:24 home-t710 kernel: [11735.638740] Pid: 11243, comm: insmod Not tainted 3.0.0-rc4+ #6
> Jun 27 08:15:24 home-t710 kernel: [11735.638743] Call Trace:
> Jun 27 08:15:24 home-t710 kernel: [11735.638755] [<ffffffff81046427>] __might_sleep+0xeb/0xf0
> Jun 27 08:15:24 home-t710 kernel: [11735.638766] [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
> Jun 27 08:15:24 home-t710 kernel: [11735.638773] [<ffffffff8111201c>] kmem_cache_alloc_trace+0x43/0xd8
> Jun 27 08:15:24 home-t710 kernel: [11735.638782] [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
> Jun 27 08:15:24 home-t710 kernel: [11735.638787] [<ffffffff810ab791>] request_threaded_irq+0xa1/0x113
> Jun 27 08:15:24 home-t710 kernel: [11735.638798] [<ffffffffa020f0c0>] bnad_pci_probe+0x612/0x8e5 [bna]
> Jun 27 08:15:24 home-t710 kernel: [11735.638807] [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
> Jun 27 08:15:24 home-t710 kernel: [11735.638816] [<ffffffff81482ef4>] ? _raw_spin_unlock_irqrestore+0x17/0x19
> Jun 27 08:15:24 home-t710 kernel: [11735.638822] [<ffffffff8124d17a>] local_pci_probe+0x44/0x75
> Jun 27 08:15:24 home-t710 kernel: [11735.638826] [<ffffffff8124dc06>] pci_device_probe+0xd0/0xff
> Jun 27 08:15:24 home-t710 kernel: [11735.638832] [<ffffffff812ef8ab>] driver_probe_device+0x131/0x213
> Jun 27 08:15:24 home-t710 kernel: [11735.638836] [<ffffffff812ef9e7>] __driver_attach+0x5a/0x7e
> Jun 27 08:15:24 home-t710 kernel: [11735.638840] [<ffffffff812ef98d>] ? driver_probe_device+0x213/0x213
> Jun 27 08:15:24 home-t710 kernel: [11735.638844] [<ffffffff812ee933>] bus_for_each_dev+0x53/0x89
> Jun 27 08:15:24 home-t710 kernel: [11735.638848] [<ffffffff812ef48a>] driver_attach+0x1e/0x20
> Jun 27 08:15:24 home-t710 kernel: [11735.638852] [<ffffffff812ef0ae>] bus_add_driver+0xd1/0x224
> Jun 27 08:15:24 home-t710 kernel: [11735.638858] [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
> Jun 27 08:15:24 home-t710 kernel: [11735.638862] [<ffffffff812efe57>] driver_register+0x98/0x105
> Jun 27 08:15:24 home-t710 kernel: [11735.638866] [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
> Jun 27 08:15:24 home-t710 kernel: [11735.638871] [<ffffffff8124e4c9>] __pci_register_driver+0x56/0xc1
> Jun 27 08:15:24 home-t710 kernel: [11735.638875] [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
> Jun 27 08:15:24 home-t710 kernel: [11735.638884] [<ffffffffa01b8040>] bnad_module_init+0x40/0x60 [bna]
> Jun 27 08:15:24 home-t710 kernel: [11735.638892] [<ffffffff81002099>] do_one_initcall+0x7f/0x136
> Jun 27 08:15:24 home-t710 kernel: [11735.638899] [<ffffffff8108608b>] sys_init_module+0x88/0x1d0
> Jun 27 08:15:24 home-t710 kernel: [11735.638906] [<ffffffff81489682>] system_call_fastpath+0x16/0x1b
> Jun 27 08:15:24 home-t710 kernel: [11735.639642] bnad_pci_probe : (0xffff880427f3e000, 0xffffffffa020f3e0) PCI Func : (3)
> Jun 27 08:15:24 home-t710 kernel: [11735.639665] bna 0000:82:00.3: PCI INT A -> GSI 66 (level, low) -> IRQ 66
> Jun 27 08:15:24 home-t710 kernel: [11735.639735] bar0 mapped to ffffc90014400000, len 262144
>
> Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
> ---
> drivers/net/bna/bnad.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bna/bnad.c b/drivers/net/bna/bnad.c
> index 7d25a97..44e219c 100644
> --- a/drivers/net/bna/bnad.c
> +++ b/drivers/net/bna/bnad.c
> @@ -1111,7 +1111,7 @@ bnad_mbox_irq_alloc(struct bnad *bnad,
> struct bna_intr_info *intr_info)
> {
> int err = 0;
> - unsigned long flags;
> + unsigned long irq_flags = 0, flags;
> u32 irq;
> irq_handler_t irq_handler;
>
> @@ -1125,18 +1125,17 @@ bnad_mbox_irq_alloc(struct bnad *bnad,
> if (bnad->cfg_flags & BNAD_CF_MSIX) {
> irq_handler = (irq_handler_t)bnad_msix_mbox_handler;
> irq = bnad->msix_table[bnad->msix_num - 1].vector;
> - flags = 0;
> intr_info->intr_type = BNA_INTR_T_MSIX;
> intr_info->idl[0].vector = bnad->msix_num - 1;
> } else {
> irq_handler = (irq_handler_t)bnad_isr;
> irq = bnad->pcidev->irq;
> - flags = IRQF_SHARED;
> + irq_flags = IRQF_SHARED;
> intr_info->intr_type = BNA_INTR_T_INTX;
> /* intr_info->idl.vector = 0 ? */
> }
> spin_unlock_irqrestore(&bnad->bna_lock, flags);
> -
> + flags = irq_flags;
> sprintf(bnad->mbox_irq_name, "%s", BNAD_NAME);
>
> /*
^ permalink raw reply
* Re: linux-next: Tree for July 7 (net/af_packet)
From: Randy Dunlap @ 2011-07-07 15:12 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML
In-Reply-To: <20110707172544.867b980a1196db005b577c14@canb.auug.org.au>
On Thu, 7 Jul 2011 17:25:44 +1000 Stephen Rothwell wrote:
> Hi all,
>
> The next linux-next release will (probably) be next-20110718.
>
> Changes since 20110706:
When CONFIG_INET is not enabled:
af_packet.c:(.text+0x3d130): undefined reference to `ip_defrag'
or
ERROR: "ip_defrag" [net/packet/af_packet.ko] undefined!
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 08/10] dynamic_debug: make netif_dbg() call __netdev_printk()
From: Jason Baron @ 2011-07-07 14:13 UTC (permalink / raw)
To: Joe Perches
Cc: gregkh, jim.cromie, bvanassche, linux-kernel, davem,
aloisio.almeida, netdev
In-Reply-To: <1309989543.1710.19.camel@Joe-Laptop>
On Wed, Jul 06, 2011 at 02:59:03PM -0700, Joe Perches wrote:
> On Wed, 2011-07-06 at 13:25 -0400, Jason Baron wrote:
> > From: Jason Baron <jbaron@redhat.com>
> >
> > Previously, netif_dbg() was using dynamic_dev_dbg() to perform
> > the underlying printk. Fix it to use __netdev_printk(), instead.
> >
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Jason Baron <jbaron@redhat.com>
> > ---
> > include/linux/dynamic_debug.h | 12 ++++++++++++
> > include/linux/netdevice.h | 6 ++----
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> []
> > +#define dynamic_netif_dbg(dev, cond, fmt, ...) do { \
> > + static struct _ddebug descriptor \
> > + __used \
> > + __attribute__((section("__verbose"), aligned(8))) = \
> > + { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
> > + _DPRINTK_FLAGS_DEFAULT }; \
> > + if (unlikely(descriptor.enabled)) { \
> > + if (cond) \
> > + __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
> > + } \
> > + } while (0)
> > +
>
> Just nits:
>
> I think it'd be better to use
> #define dynamic_netif_dbg(etc) \
> do { \
> etc...
> } while (0)
>
> so that there aren't 2 consecutive close braces at the same indent level.
>
> and maybe just use one test
>
> if (unlikely(descriptor.enabled) && cond)
> __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);
>
If you look at the next patch, 9/10, I've combined the tests there
just as you've described. I agree, that it would be better if that were
folded into this patch. will fix.
>
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 9b132ef..99c358f 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -2731,10 +2731,8 @@ do { \
> > #elif defined(CONFIG_DYNAMIC_DEBUG)
> > #define netif_dbg(priv, type, netdev, format, args...) \
> > do { \
> > - if (netif_msg_##type(priv)) \
> > - dynamic_dev_dbg((netdev)->dev.parent, \
> > - "%s: " format, \
> > - netdev_name(netdev), ##args); \
> > + dynamic_netif_dbg(netdev, (netif_msg_##type(priv)), \
> > + format, ##args); \
>
> Because you've already added dynamic_netdev_dbg,
> maybe this should be:
>
> #define netif_dbg(priv, type, netdev, format, args...) \
> do { \
> if (netif_msg_##type(priv)) \
> dynamic_netdev_dbg(netdev, format, ##args); \
> } while (0)
>
>
The reason I didn't add it this way is b/c I plan on converting the
outer 'ifs' to the jump label infrastructure - which makes the disabled
case just a no-op and moves the printk and tests out of line.
Until that is done, i could see coding it as you've suggested, but I'd
prefer to leave it as is (and leave future churn to within the dynamic
debug code as opposed to the netdevice.h header).
Thanks,
-Jason
^ permalink raw reply
* Re: [stable] [PATCH] e1000: always call e1000_check_for_link() on e1000_ce4100 MACs.
From: Greg KH @ 2011-07-07 14:10 UTC (permalink / raw)
To: nschichan; +Cc: Jeff Kirsher, Dirk Brandewie, netdev, stable, Florian Fainelli
In-Reply-To: <1310044617-22978-1-git-send-email-nschichan@freebox.fr>
On Thu, Jul 07, 2011 at 03:16:57PM +0200, nschichan@freebox.fr wrote:
> From: Nicolas Schichan <nschichan@freebox.fr>
>
> Interrupts about link lost or rx sequence errors are not reported by
> the ce4100 hardware, leading to transitions from link UP to link DOWN
> never being reported.
>
> Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
> ---
> drivers/net/e1000/e1000_main.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Greg KH @ 2011-07-07 13:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Jesper Juhl, David Miller, netdev
In-Reply-To: <20110707152857.83d48e1d1c175f811b255952@canb.auug.org.au>
On Thu, Jul 07, 2011 at 03:28:57PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/rtl8187se/ieee80211/ieee80211_softmac.c between commit
> 219eb47e6f35 ("net/staging: add needed interrupt.h and hardirq.h
> includes") from the net tree and commit 41134db17a7d ("Remove unneeded
> version.h includes from drivers/staging/rtl*/") from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks correct, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next-2.6] af_packet: lock imbalance
From: David Miller @ 2011-07-07 13:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1310045587.2127.15.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Jul 2011 15:33:07 +0200
> fanout_add() might return with fanout_mutex held.
>
> Reduce indentation level while we are at it
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks for fixing this Eric.
^ permalink raw reply
* Re: [PATCHv3] sctp: Enforce retransmission limit during shutdown
From: Vladislav Yasevich @ 2011-07-07 13:36 UTC (permalink / raw)
To: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <20110707102835.GA6277@canuck.infradead.org>
On 07/07/2011 06:28 AM, Thomas Graf wrote:
> When initiating a graceful shutdown while having data chunks
> on the retransmission queue with a peer which is in zero
> window mode the shutdown is never completed because the
> retransmission error count is reset periodically by the
> following two rules:
>
> - Do not timeout association while doing zero window probe.
> - Reset overall error count when a heartbeat request has
> been acknowledged.
>
> The graceful shutdown will wait for all outstanding TSN to
> be acknowledged before sending the SHUTDOWN request. This
> never happens due to the peer's zero window not acknowledging
> the continuously retransmitted data chunks. Although the
> error counter is incremented for each failed retransmission,
> the receiving of the SACK announcing the zero window clears
> the error count again immediately. Also heartbeat requests
> continue to be sent periodically. The peer acknowledges these
> requests causing the error counter to be reset as well.
>
> This patch changes behaviour to only reset the overall error
> counter for the above rules while not in shutdown. After
> reaching the maximum number of retransmission attempts, the
> T5 shutdown guard timer is scheduled to give the receiver
> some additional time to recover. The timer is stopped as soon
> as the receiver acknowledges any data.
>
> The issue can be easily reproduced by establishing a sctp
> association over the loopback device, constantly queueing
> data at the sender while not reading any at the receiver.
> Wait for the window to reach zero, then initiate a shutdown
> by killing both processes simultaneously. The association
> will never be freed and the chunks on the retransmission
> queue will be retransmitted indefinitely.
>
> Signed-off-by: Thomas Graf <tgraf@infradead.org>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Thanks
-vlad
>
> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
> index dd6847e..6506458 100644
> --- a/include/net/sctp/command.h
> +++ b/include/net/sctp/command.h
> @@ -63,6 +63,7 @@ typedef enum {
> SCTP_CMD_ECN_ECNE, /* Do delayed ECNE processing. */
> SCTP_CMD_ECN_CWR, /* Do delayed CWR processing. */
> SCTP_CMD_TIMER_START, /* Start a timer. */
> + SCTP_CMD_TIMER_START_ONCE, /* Start a timer once */
> SCTP_CMD_TIMER_RESTART, /* Restart a timer. */
> SCTP_CMD_TIMER_STOP, /* Stop a timer. */
> SCTP_CMD_INIT_CHOOSE_TRANSPORT, /* Choose transport for an INIT. */
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 1c88c89..d036821 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1582,6 +1582,8 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> #endif /* SCTP_DEBUG */
> if (transport) {
> if (bytes_acked) {
> + struct sctp_association *asoc = transport->asoc;
> +
> /* We may have counted DATA that was migrated
> * to this transport due to DEL-IP operation.
> * Subtract those bytes, since the were never
> @@ -1600,6 +1602,17 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> transport->error_count = 0;
> transport->asoc->overall_error_count = 0;
>
> + /*
> + * While in SHUTDOWN PENDING, we may have started
> + * the T5 shutdown guard timer after reaching the
> + * retransmission limit. Stop that timer as soon
> + * as the receiver acknowledged any data.
> + */
> + if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING &&
> + del_timer(&asoc->timers
> + [SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD]))
> + sctp_association_put(asoc);
> +
> /* Mark the destination transport address as
> * active if it is not so marked.
> */
> @@ -1629,10 +1642,15 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> * A sender is doing zero window probing when the
> * receiver's advertised window is zero, and there is
> * only one data chunk in flight to the receiver.
> + *
> + * Allow the association to timeout while in SHUTDOWN
> + * PENDING or SHUTDOWN RECEIVED in case the receiver
> + * stays in zero window mode forever.
> */
> if (!q->asoc->peer.rwnd &&
> !list_empty(&tlist) &&
> - (sack_ctsn+2 == q->asoc->next_tsn)) {
> + (sack_ctsn+2 == q->asoc->next_tsn) &&
> + q->asoc->state < SCTP_STATE_SHUTDOWN_PENDING) {
> SCTP_DEBUG_PRINTK("%s: SACK received for zero "
> "window probe: %u\n",
> __func__, sack_ctsn);
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 534c2e5..6e0f882 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -670,10 +670,19 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
> /* 8.3 Upon the receipt of the HEARTBEAT ACK, the sender of the
> * HEARTBEAT should clear the error counter of the destination
> * transport address to which the HEARTBEAT was sent.
> - * The association's overall error count is also cleared.
> */
> t->error_count = 0;
> - t->asoc->overall_error_count = 0;
> +
> + /*
> + * Although RFC4960 specifies that the overall error count must
> + * be cleared when a HEARTBEAT ACK is received, we make an
> + * exception while in SHUTDOWN PENDING. If the peer keeps its
> + * window shut forever, we may never be able to transmit our
> + * outstanding data and rely on the retransmission limit be reached
> + * to shutdown the association.
> + */
> + if (t->asoc->state != SCTP_STATE_SHUTDOWN_PENDING)
> + t->asoc->overall_error_count = 0;
>
> /* Clear the hb_sent flag to signal that we had a good
> * acknowledgement.
> @@ -1437,6 +1446,13 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> sctp_cmd_setup_t2(commands, asoc, cmd->obj.ptr);
> break;
>
> + case SCTP_CMD_TIMER_START_ONCE:
> + timer = &asoc->timers[cmd->obj.to];
> +
> + if (timer_pending(timer))
> + break;
> + /* fall through */
> +
> case SCTP_CMD_TIMER_START:
> timer = &asoc->timers[cmd->obj.to];
> timeout = asoc->timeouts[cmd->obj.to];
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index a297283..2461171 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -5154,7 +5154,7 @@ sctp_disposition_t sctp_sf_do_9_2_start_shutdown(
> * The sender of the SHUTDOWN MAY also start an overall guard timer
> * 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
> */
> - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START,
> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
> SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
>
> if (asoc->autoclose)
> @@ -5299,14 +5299,28 @@ sctp_disposition_t sctp_sf_do_6_3_3_rtx(const struct sctp_endpoint *ep,
> SCTP_INC_STATS(SCTP_MIB_T3_RTX_EXPIREDS);
>
> if (asoc->overall_error_count >= asoc->max_retrans) {
> - sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> - SCTP_ERROR(ETIMEDOUT));
> - /* CMD_ASSOC_FAILED calls CMD_DELETE_TCB. */
> - sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> - SCTP_PERR(SCTP_ERROR_NO_ERROR));
> - SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
> - SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> - return SCTP_DISPOSITION_DELETE_TCB;
> + if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
> + /*
> + * We are here likely because the receiver had its rwnd
> + * closed for a while and we have not been able to
> + * transmit the locally queued data within the maximum
> + * retransmission attempts limit. Start the T5
> + * shutdown guard timer to give the receiver one last
> + * chance and some additional time to recover before
> + * aborting.
> + */
> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START_ONCE,
> + SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
> + } else {
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ETIMEDOUT));
> + /* CMD_ASSOC_FAILED calls CMD_DELETE_TCB. */
> + sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> + SCTP_PERR(SCTP_ERROR_NO_ERROR));
> + SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
> + SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> + return SCTP_DISPOSITION_DELETE_TCB;
> + }
> }
>
> /* E1) For the destination address for which the timer
> diff --git a/net/sctp/sm_statetable.c b/net/sctp/sm_statetable.c
> index 0338dc6..7c211a7 100644
> --- a/net/sctp/sm_statetable.c
> +++ b/net/sctp/sm_statetable.c
> @@ -827,7 +827,7 @@ static const sctp_sm_table_entry_t other_event_table[SCTP_NUM_OTHER_TYPES][SCTP_
> /* SCTP_STATE_ESTABLISHED */ \
> TYPE_SCTP_FUNC(sctp_sf_timer_ignore), \
> /* SCTP_STATE_SHUTDOWN_PENDING */ \
> - TYPE_SCTP_FUNC(sctp_sf_timer_ignore), \
> + TYPE_SCTP_FUNC(sctp_sf_t5_timer_expire), \
> /* SCTP_STATE_SHUTDOWN_SENT */ \
> TYPE_SCTP_FUNC(sctp_sf_t5_timer_expire), \
> /* SCTP_STATE_SHUTDOWN_RECEIVED */ \
>
^ permalink raw reply
* Re: [PATCH] net/fec: gasket needs to be enabled for some i.mx
From: Shawn Guo @ 2011-07-07 13:41 UTC (permalink / raw)
To: David Miller
Cc: shawn.guo, netdev, linux-arm-kernel, u.kleine-koenig, LW,
troy.kisky, s.hauer, Grant Likely
In-Reply-To: <20110707.041257.670268148869400054.davem@davemloft.net>
On Thu, Jul 07, 2011 at 04:12:57AM -0700, David Miller wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
> Date: Fri, 1 Jul 2011 18:11:22 +0800
>
> > On the recent i.mx (mx25/50/53), there is a gasket inside fec
> > controller which needs to be enabled no matter phy works in MII
> > or RMII mode.
> >
> > The current code enables the gasket only when phy interface is RMII.
> > It's broken when the driver works with a MII phy. The patch uses
> > platform_device_id to distinguish the SoCs that have the gasket and
> > enables it on these SoCs for both MII and RMII mode.
> >
> > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>
> Acked-by: David S. Miller <davem@davemloft.net>
> --
Thanks, David. I will try to get it through Sascha's tree after
the rebase again dt series.
Hi Sascha,
How should we proceed? It seems Grant will take the fec-dt series
on his tree. Would you then merge that tree into yours, so that I
can rebase this patch on your tree and get it go through there?
--
Regards,
Shawn
^ permalink raw reply
* [PATCH net-next-2.6] af_packet: lock imbalance
From: Eric Dumazet @ 2011-07-07 13:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
fanout_add() might return with fanout_mutex held.
Reduce indentation level while we are at it
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/packet/af_packet.c | 62 +++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index aec50a1..caa9fba 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -589,43 +589,43 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
break;
}
}
+ err = -EINVAL;
if (match && match->defrag != defrag)
- return -EINVAL;
+ goto out;
if (!match) {
+ err = -ENOMEM;
match = kzalloc(sizeof(*match), GFP_KERNEL);
- if (match) {
- write_pnet(&match->net, sock_net(sk));
- match->id = id;
- match->type = type;
- match->defrag = defrag;
- atomic_set(&match->rr_cur, 0);
- INIT_LIST_HEAD(&match->list);
- spin_lock_init(&match->lock);
- atomic_set(&match->sk_ref, 0);
- match->prot_hook.type = po->prot_hook.type;
- match->prot_hook.dev = po->prot_hook.dev;
- match->prot_hook.func = packet_rcv_fanout;
- match->prot_hook.af_packet_priv = match;
- dev_add_pack(&match->prot_hook);
- list_add(&match->list, &fanout_list);
- }
+ if (!match)
+ goto out;
+ write_pnet(&match->net, sock_net(sk));
+ match->id = id;
+ match->type = type;
+ match->defrag = defrag;
+ atomic_set(&match->rr_cur, 0);
+ INIT_LIST_HEAD(&match->list);
+ spin_lock_init(&match->lock);
+ atomic_set(&match->sk_ref, 0);
+ match->prot_hook.type = po->prot_hook.type;
+ match->prot_hook.dev = po->prot_hook.dev;
+ match->prot_hook.func = packet_rcv_fanout;
+ match->prot_hook.af_packet_priv = match;
+ dev_add_pack(&match->prot_hook);
+ list_add(&match->list, &fanout_list);
}
- err = -ENOMEM;
- if (match) {
- err = -EINVAL;
- if (match->type == type &&
- match->prot_hook.type == po->prot_hook.type &&
- match->prot_hook.dev == po->prot_hook.dev) {
- err = -ENOSPC;
- if (atomic_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
- __dev_remove_pack(&po->prot_hook);
- po->fanout = match;
- atomic_inc(&match->sk_ref);
- __fanout_link(sk, po);
- err = 0;
- }
+ err = -EINVAL;
+ if (match->type == type &&
+ match->prot_hook.type == po->prot_hook.type &&
+ match->prot_hook.dev == po->prot_hook.dev) {
+ err = -ENOSPC;
+ if (atomic_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
+ __dev_remove_pack(&po->prot_hook);
+ po->fanout = match;
+ atomic_inc(&match->sk_ref);
+ __fanout_link(sk, po);
+ err = 0;
}
}
+out:
mutex_unlock(&fanout_mutex);
return err;
}
^ permalink raw reply related
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-07-07 13:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Tom Lendacky
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <20110629084206.GA14627@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]
On 6/29/11 1:42 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> >roprabhu, Tom,
>> >
>> >Thanks very much for the testing. So on the first glance
>> >one seems to see a significant performance gain in V0 here,
>> >and a slightly less significant in V2, with V1
>> >being worse than base. But I'm afraid that's not the
>> >whole story, and we'll need to work some more to
>> >know what really goes on, please see below.
>> >
>> >
>> >Some comments on the results: I found out that V0 because of mistake
>> >on my part was actually almost identical to base.
>> >I pushed out virtio-net-limit-xmit-polling/v1a instead that
>> >actually does what I intended to check. However,
>> >the fact we get such a huge distribution in the results by Tom
>> >most likely means that the noise factor is very large.
>> >
>> >
>> >From my experience one way to get stable results is to
>> >divide the throughput by the host CPU utilization
>> >(measured by something like mpstat).
>> >Sometimes throughput doesn't increase (e.g. guest-host)
>> >by CPU utilization does decrease. So it's interesting.
>> >
>> >
>> >Another issue is that we are trying to improve the latency
>> >of a busy queue here. However STREAM/MAERTS tests ignore the latency
>> >(more or less) while TCP_RR by default runs a single packet per queue.
>> >Without arguing about whether these are practically interesting
>> >workloads, these results are thus unlikely to be significantly affected
>> >by the optimization in question.
>> >
>> >What we are interested in, thus, is either TCP_RR with a -b flag
>> >(configure with --enable-burst) or multiple concurrent
>> >TCP_RRs.
>
> ok sounds good. I am testing your v1a patch. Will try to get some results out
> end of this week. Thanks.
>
[-- Attachment #1.2: Type: text/html, Size: 2328 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] e1000: always call e1000_check_for_link() on e1000_ce4100 MACs.
From: nschichan @ 2011-07-07 13:16 UTC (permalink / raw)
To: Nicolas Schichan, Jeff Kirsher, Dirk Brandewie, netdev
Cc: Florian Fainelli, stable, Nicolas Schichan
From: Nicolas Schichan <nschichan@freebox.fr>
Interrupts about link lost or rx sequence errors are not reported by
the ce4100 hardware, leading to transitions from link UP to link DOWN
never being reported.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
---
drivers/net/e1000/e1000_main.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 76e8af0..a02333f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2357,13 +2357,16 @@ bool e1000_has_link(struct e1000_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
bool link_active = false;
- /* get_link_status is set on LSC (link status) interrupt or
- * rx sequence error interrupt. get_link_status will stay
- * false until the e1000_check_for_link establishes link
- * for copper adapters ONLY
+ /* get_link_status is set on LSC (link status) interrupt or rx
+ * sequence error interrupt (except on intel ce4100).
+ * get_link_status will stay false until the
+ * e1000_check_for_link establishes link for copper adapters
+ * ONLY
*/
switch (hw->media_type) {
case e1000_media_type_copper:
+ if (hw->mac_type == e1000_ce4100)
+ hw->get_link_status = 1;
if (hw->get_link_status) {
e1000_check_for_link(hw);
link_active = !hw->get_link_status;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] sky2: use GFP_KERNEL allocations at device setup
From: David Miller @ 2011-07-07 13:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger
In-Reply-To: <1310044288.2127.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Jul 2011 15:11:28 +0200
> In process and sleep allowed context, favor GFP_KERNEL allocations over
> GFP_ATOMIC ones.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ 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