* Re: [Bugme-new] [Bug 37172] New: Enabling 802.1q vlan causes some packets to be received with a vlan id of 64
From: Andrew Morton @ 2011-06-13 23:43 UTC (permalink / raw)
To: a.reversat; +Cc: bugme-daemon, netdev, Patrick McHardy
In-Reply-To: <bug-37172-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 10 Jun 2011 19:20:58 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=37172
>
> Summary: Enabling 802.1q vlan causes some packets to be
> received with a vlan id of 64
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.39
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: a.reversat@gmail.com
> Regression: Yes
>From which kernel version did we regress? Was 2.6.38 OK?
Thanks.
>
> Created an attachment (id=61502)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=61502)
> Packet capture of problem
>
> I added a vlan to my main network card by doing :
>
> vconfig add eth0 6
>
> Then I got huge packet loss when pinging e.g google (around 70% packet loss).
>
> After checking a packet capture it seems that some packets come in with a vlan
> tag even though they shouldn't. In my capture I see them with a vlan id of 64
> where they shouldn't even be 802.1q tagged.
>
> Kernel version is 2.6.39 and I am using the forcedeth driver so I don't know if
> it is related to the network stack or the forcedeth driver.
>
> Attached is the relevant capture. Note how packet with seq 2 for instance is
> tagged and packet with seq 5 isn't.
>
> I'll test this with the latest 3.0 rc and update the bug report if the problem
> is fixed in there.
>
^ permalink raw reply
* [PATCH net-next 6/8] tg3: Show flowctrl settings through get_settings()
From: Matt Carlson @ 2011-06-13 23:39 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch adds code to present the flow control advertisements through
the ethtool get_settings callback.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 7ce50e5..a7bea86 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9934,6 +9934,18 @@ static int tg3_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
}
cmd->advertising = tp->link_config.advertising;
+ if (tg3_flag(tp, PAUSE_AUTONEG)) {
+ if (tp->link_config.flowctrl & FLOW_CTRL_RX) {
+ if (tp->link_config.flowctrl & FLOW_CTRL_TX) {
+ cmd->advertising |= ADVERTISED_Pause;
+ } else {
+ cmd->advertising |= ADVERTISED_Pause |
+ ADVERTISED_Asym_Pause;
+ }
+ } else if (tp->link_config.flowctrl & FLOW_CTRL_TX) {
+ cmd->advertising |= ADVERTISED_Asym_Pause;
+ }
+ }
if (netif_running(dev)) {
ethtool_cmd_speed_set(cmd, tp->link_config.active_speed);
cmd->duplex = tp->link_config.active_duplex;
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 2/8] tg3: Remove 40BIT_DMA_LIMIT_BUG
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch removes the 40BIT_DMA_LIMIT_BUG flag. There already exists a
flag for this purpose (TG3_FLAG_40BIT_DMA_BUG) and was already being
used in the correct spot.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 8 ++------
drivers/net/tg3.h | 1 -
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index e8f16c5..488bcf9 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6022,8 +6022,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
tg3_4g_overflow_test(mapping, len))
would_hit_hwbug = 1;
- if (tg3_flag(tp, 40BIT_DMA_LIMIT_BUG) &&
- tg3_40bit_overflow_test(tp, mapping, len))
+ if (tg3_40bit_overflow_test(tp, mapping, len))
would_hit_hwbug = 1;
if (tg3_flag(tp, 5701_DMA_BUG))
@@ -6060,8 +6059,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
tg3_4g_overflow_test(mapping, len))
would_hit_hwbug = 1;
- if (tg3_flag(tp, 40BIT_DMA_LIMIT_BUG) &&
- tg3_40bit_overflow_test(tp, mapping, len))
+ if (tg3_40bit_overflow_test(tp, mapping, len))
would_hit_hwbug = 1;
if (tg3_flag(tp, HW_TSO_1) ||
@@ -13710,8 +13708,6 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
if (tg3_flag(tp, 5755_PLUS))
tg3_flag_set(tp, SHORT_DMA_BUG);
- else
- tg3_flag_set(tp, 40BIT_DMA_LIMIT_BUG);
if (tg3_flag(tp, 5717_PLUS))
tg3_flag_set(tp, LRG_PROD_RING_CAP);
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 3c113c1..4f5dbf6 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2897,7 +2897,6 @@ enum TG3_FLAGS {
TG3_FLAG_ENABLE_RSS,
TG3_FLAG_ENABLE_TSS,
TG3_FLAG_4G_DMA_BNDRY_BUG,
- TG3_FLAG_40BIT_DMA_LIMIT_BUG,
TG3_FLAG_SHORT_DMA_BUG,
TG3_FLAG_USE_JUMBO_BDFLAG,
TG3_FLAG_L1PLLPD_EN,
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 7/8] tg3: Migrate phy preprocessor defs to system defs
From: Matt Carlson @ 2011-06-13 23:39 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch changes to code to use some of the preprocessor
definitions from mii.h over its homegrown equivalents.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 26 ++++++++++++--------------
drivers/net/tg3.h | 8 --------
include/linux/mii.h | 2 ++
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a7bea86..7dfacc0 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -861,7 +861,7 @@ static int tg3_writephy(struct tg3 *tp, int reg, u32 val)
int ret;
if ((tp->phy_flags & TG3_PHYFLG_IS_FET) &&
- (reg == MII_TG3_CTRL || reg == MII_TG3_AUX_CTRL))
+ (reg == MII_CTRL1000 || reg == MII_TG3_AUX_CTRL))
return 0;
if ((tp->mi_mode & MAC_MI_MODE_AUTO_POLL) != 0) {
@@ -1981,15 +1981,14 @@ static int tg3_phy_reset_5703_4_5(struct tg3 *tp)
/* Set full-duplex, 1000 mbps. */
tg3_writephy(tp, MII_BMCR,
- BMCR_FULLDPLX | TG3_BMCR_SPEED1000);
+ BMCR_FULLDPLX | BMCR_SPEED1000);
/* Set to master mode. */
- if (tg3_readphy(tp, MII_TG3_CTRL, &phy9_orig))
+ if (tg3_readphy(tp, MII_CTRL1000, &phy9_orig))
continue;
- tg3_writephy(tp, MII_TG3_CTRL,
- (MII_TG3_CTRL_AS_MASTER |
- MII_TG3_CTRL_ENABLE_AS_MASTER));
+ tg3_writephy(tp, MII_CTRL1000,
+ CTL1000_AS_MASTER | CTL1000_ENABLE_MASTER);
err = TG3_PHY_AUXCTL_SMDSP_ENABLE(tp);
if (err)
@@ -2014,7 +2013,7 @@ static int tg3_phy_reset_5703_4_5(struct tg3 *tp)
TG3_PHY_AUXCTL_SMDSP_DISABLE(tp);
- tg3_writephy(tp, MII_TG3_CTRL, phy9_orig);
+ tg3_writephy(tp, MII_CTRL1000, phy9_orig);
if (!tg3_readphy(tp, MII_TG3_EXT_CTRL, ®32)) {
reg32 &= ~0x3000;
@@ -2958,16 +2957,15 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
new_adv = 0;
if (advertise & ADVERTISED_1000baseT_Half)
- new_adv |= MII_TG3_CTRL_ADV_1000_HALF;
+ new_adv |= ADVERTISE_1000HALF;
if (advertise & ADVERTISED_1000baseT_Full)
- new_adv |= MII_TG3_CTRL_ADV_1000_FULL;
+ new_adv |= ADVERTISE_1000FULL;
if (tp->pci_chip_rev_id == CHIPREV_ID_5701_A0 ||
tp->pci_chip_rev_id == CHIPREV_ID_5701_B0)
- new_adv |= (MII_TG3_CTRL_AS_MASTER |
- MII_TG3_CTRL_ENABLE_AS_MASTER);
+ new_adv |= CTL1000_AS_MASTER | CTL1000_ENABLE_MASTER;
- err = tg3_writephy(tp, MII_TG3_CTRL, new_adv);
+ err = tg3_writephy(tp, MII_CTRL1000, new_adv);
if (err)
goto done;
@@ -3076,7 +3074,7 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
break;
case SPEED_1000:
- bmcr |= TG3_BMCR_SPEED1000;
+ bmcr |= BMCR_SPEED1000;
break;
}
@@ -3153,7 +3151,7 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
if (mask & ADVERTISED_1000baseT_Full)
all_mask |= ADVERTISE_1000FULL;
- if (tg3_readphy(tp, MII_TG3_CTRL, &tg3_ctrl))
+ if (tg3_readphy(tp, MII_CTRL1000, &tg3_ctrl))
return 0;
if ((tg3_ctrl & all_mask) != all_mask)
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 54441a3..bedc3b4 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2152,14 +2152,6 @@
/*** Tigon3 specific PHY MII registers. ***/
-#define TG3_BMCR_SPEED1000 0x0040
-
-#define MII_TG3_CTRL 0x09 /* 1000-baseT control register */
-#define MII_TG3_CTRL_ADV_1000_HALF 0x0100
-#define MII_TG3_CTRL_ADV_1000_FULL 0x0200
-#define MII_TG3_CTRL_AS_MASTER 0x0800
-#define MII_TG3_CTRL_ENABLE_AS_MASTER 0x1000
-
#define MII_TG3_MMD_CTRL 0x0d /* MMD Access Control register */
#define MII_TG3_MMD_CTRL_DATA_NOINC 0x4000
#define MII_TG3_MMD_ADDRESS 0x0e /* MMD Address Data register */
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 359fba8..103113a 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -128,6 +128,8 @@
/* 1000BASE-T Control register */
#define ADVERTISE_1000FULL 0x0200 /* Advertise 1000BASE-T full duplex */
#define ADVERTISE_1000HALF 0x0100 /* Advertise 1000BASE-T half duplex */
+#define CTL1000_AS_MASTER 0x0800
+#define CTL1000_ENABLE_MASTER 0x1000
/* 1000BASE-T Status register */
#define LPA_1000LOCALRXOK 0x2000 /* Link partner local receiver status */
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 5/8] tg3: Fix EEE debounce timer values
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch fixes the EEE debounce timer values.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index fc33566..54441a3 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1118,10 +1118,10 @@
#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
#define TG3_CPMU_EEE_DBTMR1 0x000036b4
#define TG3_CPMU_DBTMR1_PCIEXIT_2047US 0x07ff0000
-#define TG3_CPMU_DBTMR1_LNKIDLE_2047US 0x000070ff
+#define TG3_CPMU_DBTMR1_LNKIDLE_2047US 0x000007ff
#define TG3_CPMU_EEE_DBTMR2 0x000036b8
#define TG3_CPMU_DBTMR2_APE_TX_2047US 0x07ff0000
-#define TG3_CPMU_DBTMR2_TXIDXEQ_2047US 0x000070ff
+#define TG3_CPMU_DBTMR2_TXIDXEQ_2047US 0x000007ff
#define TG3_CPMU_EEE_LNKIDL_CTRL 0x000036bc
#define TG3_CPMU_EEE_LNKIDL_PCIE_NL0 0x01000000
#define TG3_CPMU_EEE_LNKIDL_UART_IDL 0x00000004
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 4/8] tg3: Add more selfboot formats to NVRAM selftest
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patch adds more selfboot formats to the NVRAM selftest. It also
changes the code to return an error on an unsupported NVRAM format.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 765f3dc..7ce50e5 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -10468,6 +10468,9 @@ error:
#define NVRAM_SELFBOOT_FORMAT1_0_SIZE 0x14
#define NVRAM_SELFBOOT_FORMAT1_2_SIZE 0x18
#define NVRAM_SELFBOOT_FORMAT1_3_SIZE 0x1c
+#define NVRAM_SELFBOOT_FORMAT1_4_SIZE 0x20
+#define NVRAM_SELFBOOT_FORMAT1_5_SIZE 0x24
+#define NVRAM_SELFBOOT_FORMAT1_6_SIZE 0x4c
#define NVRAM_SELFBOOT_HW_SIZE 0x20
#define NVRAM_SELFBOOT_DATA_SIZE 0x1c
@@ -10498,8 +10501,17 @@ static int tg3_test_nvram(struct tg3 *tp)
case TG3_EEPROM_SB_REVISION_3:
size = NVRAM_SELFBOOT_FORMAT1_3_SIZE;
break;
+ case TG3_EEPROM_SB_REVISION_4:
+ size = NVRAM_SELFBOOT_FORMAT1_4_SIZE;
+ break;
+ case TG3_EEPROM_SB_REVISION_5:
+ size = NVRAM_SELFBOOT_FORMAT1_5_SIZE;
+ break;
+ case TG3_EEPROM_SB_REVISION_6:
+ size = NVRAM_SELFBOOT_FORMAT1_6_SIZE;
+ break;
default:
- return 0;
+ return -EIO;
}
} else
return 0;
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 0/8] tg3: Bugfixes and cleanups
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
This patchset commits a interrupt stall bugfix and a couple other minor cleanups.
^ permalink raw reply
* [PATCH net-next 3/8] tg3: Remove 4G_DMA_BNDRY_BUG flag
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
Now that all chips have this bug, the flag checks become useless code.
This patch removes the flag.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 14 +++-----------
drivers/net/tg3.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 488bcf9..765f3dc 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5822,8 +5822,7 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
/* Make sure new skb does not cross any 4G boundaries.
* Drop the packet if it does.
*/
- } else if (tg3_flag(tp, 4G_DMA_BNDRY_BUG) &&
- tg3_4g_overflow_test(new_addr, new_skb->len)) {
+ } else if (tg3_4g_overflow_test(new_addr, new_skb->len)) {
pci_unmap_single(tp->pdev, new_addr, new_skb->len,
PCI_DMA_TODEVICE);
ret = -1;
@@ -6018,8 +6017,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (tg3_flag(tp, SHORT_DMA_BUG) && len <= 8)
would_hit_hwbug = 1;
- if (tg3_flag(tp, 4G_DMA_BNDRY_BUG) &&
- tg3_4g_overflow_test(mapping, len))
+ if (tg3_4g_overflow_test(mapping, len))
would_hit_hwbug = 1;
if (tg3_40bit_overflow_test(tp, mapping, len))
@@ -6055,8 +6053,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
len <= 8)
would_hit_hwbug = 1;
- if (tg3_flag(tp, 4G_DMA_BNDRY_BUG) &&
- tg3_4g_overflow_test(mapping, len))
+ if (tg3_4g_overflow_test(mapping, len))
would_hit_hwbug = 1;
if (tg3_40bit_overflow_test(tp, mapping, len))
@@ -13701,11 +13698,6 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
}
}
- /* All chips can get confused if TX buffers
- * straddle the 4GB address boundary.
- */
- tg3_flag_set(tp, 4G_DMA_BNDRY_BUG);
-
if (tg3_flag(tp, 5755_PLUS))
tg3_flag_set(tp, SHORT_DMA_BUG);
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 4f5dbf6..fc33566 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2896,7 +2896,6 @@ enum TG3_FLAGS {
TG3_FLAG_NO_NVRAM,
TG3_FLAG_ENABLE_RSS,
TG3_FLAG_ENABLE_TSS,
- TG3_FLAG_4G_DMA_BNDRY_BUG,
TG3_FLAG_SHORT_DMA_BUG,
TG3_FLAG_USE_JUMBO_BDFLAG,
TG3_FLAG_L1PLLPD_EN,
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 8/8] tg3: Create funcs for power source switching
From: Matt Carlson @ 2011-06-13 23:39 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson
The power source switching code is about to get a little more complex.
This patch seeks to simplify future power source switching patches by
clarifying the existing code.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 201 +++++++++++++++++++++++++++++++----------------------
1 files changed, 119 insertions(+), 82 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 7dfacc0..372700b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -107,6 +107,8 @@ static inline void _tg3_flag_clear(enum TG3_FLAGS flag, unsigned long *bits)
NETIF_MSG_RX_ERR | \
NETIF_MSG_TX_ERR)
+#define TG3_GRC_LCLCTL_PWRSW_DELAY 100
+
/* length of time before we decide the hardware is borked,
* and dev->tx_timeout() should be called to fix the problem
*/
@@ -2165,6 +2167,118 @@ out:
return 0;
}
+static inline int tg3_pwrsrc_switch_to_vmain(struct tg3 *tp)
+{
+ if (!tg3_flag(tp, IS_NIC))
+ return 0;
+
+ tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ return 0;
+}
+
+static void tg3_pwrsrc_die_with_vmain(struct tg3 *tp)
+{
+ u32 grc_local_ctrl;
+
+ if (!tg3_flag(tp, IS_NIC) ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)
+ return;
+
+ grc_local_ctrl = tp->grc_local_ctrl | GRC_LCLCTRL_GPIO_OE1;
+
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ grc_local_ctrl | GRC_LCLCTRL_GPIO_OUTPUT1,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ grc_local_ctrl | GRC_LCLCTRL_GPIO_OUTPUT1,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+}
+
+static void tg3_pwrsrc_switch_to_vaux(struct tg3 *tp)
+{
+ if (!tg3_flag(tp, IS_NIC))
+ return;
+
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) {
+ tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
+ (GRC_LCLCTRL_GPIO_OE0 |
+ GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OE2 |
+ GRC_LCLCTRL_GPIO_OUTPUT0 |
+ GRC_LCLCTRL_GPIO_OUTPUT1),
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+ } else if (tp->pdev->device == PCI_DEVICE_ID_TIGON3_5761 ||
+ tp->pdev->device == TG3PCI_DEVICE_TIGON3_5761S) {
+ /* The 5761 non-e device swaps GPIO 0 and GPIO 2. */
+ u32 grc_local_ctrl = GRC_LCLCTRL_GPIO_OE0 |
+ GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OE2 |
+ GRC_LCLCTRL_GPIO_OUTPUT0 |
+ GRC_LCLCTRL_GPIO_OUTPUT1 |
+ tp->grc_local_ctrl;
+ tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ grc_local_ctrl |= GRC_LCLCTRL_GPIO_OUTPUT2;
+ tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ grc_local_ctrl &= ~GRC_LCLCTRL_GPIO_OUTPUT0;
+ tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+ } else {
+ u32 no_gpio2;
+ u32 grc_local_ctrl = 0;
+
+ /* Workaround to prevent overdrawing Amps. */
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5714) {
+ grc_local_ctrl |= GRC_LCLCTRL_GPIO_OE3;
+ tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
+ grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+ }
+
+ /* On 5753 and variants, GPIO2 cannot be used. */
+ no_gpio2 = tp->nic_sram_data_cfg &
+ NIC_SRAM_DATA_CFG_NO_GPIO2;
+
+ grc_local_ctrl |= GRC_LCLCTRL_GPIO_OE0 |
+ GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OE2 |
+ GRC_LCLCTRL_GPIO_OUTPUT1 |
+ GRC_LCLCTRL_GPIO_OUTPUT2;
+ if (no_gpio2) {
+ grc_local_ctrl &= ~(GRC_LCLCTRL_GPIO_OE2 |
+ GRC_LCLCTRL_GPIO_OUTPUT2);
+ }
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ tp->grc_local_ctrl | grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ grc_local_ctrl |= GRC_LCLCTRL_GPIO_OUTPUT0;
+
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ tp->grc_local_ctrl | grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+
+ if (!no_gpio2) {
+ grc_local_ctrl &= ~GRC_LCLCTRL_GPIO_OUTPUT2;
+ tw32_wait_f(GRC_LOCAL_CTRL,
+ tp->grc_local_ctrl | grc_local_ctrl,
+ TG3_GRC_LCLCTL_PWRSW_DELAY);
+ }
+ }
+}
+
static void tg3_frob_aux_power(struct tg3 *tp)
{
bool need_vaux = false;
@@ -2200,86 +2314,10 @@ static void tg3_frob_aux_power(struct tg3 *tp)
if (tg3_flag(tp, WOL_ENABLE) || tg3_flag(tp, ENABLE_ASF))
need_vaux = true;
- if (need_vaux) {
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
- GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701) {
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- (GRC_LCLCTRL_GPIO_OE0 |
- GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT0 |
- GRC_LCLCTRL_GPIO_OUTPUT1),
- 100);
- } else if (tp->pdev->device == PCI_DEVICE_ID_TIGON3_5761 ||
- tp->pdev->device == TG3PCI_DEVICE_TIGON3_5761S) {
- /* The 5761 non-e device swaps GPIO 0 and GPIO 2. */
- u32 grc_local_ctrl = GRC_LCLCTRL_GPIO_OE0 |
- GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT0 |
- GRC_LCLCTRL_GPIO_OUTPUT1 |
- tp->grc_local_ctrl;
- tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl, 100);
-
- grc_local_ctrl |= GRC_LCLCTRL_GPIO_OUTPUT2;
- tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl, 100);
-
- grc_local_ctrl &= ~GRC_LCLCTRL_GPIO_OUTPUT0;
- tw32_wait_f(GRC_LOCAL_CTRL, grc_local_ctrl, 100);
- } else {
- u32 no_gpio2;
- u32 grc_local_ctrl = 0;
-
- /* Workaround to prevent overdrawing Amps. */
- if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
- ASIC_REV_5714) {
- grc_local_ctrl |= GRC_LCLCTRL_GPIO_OE3;
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- grc_local_ctrl, 100);
- }
-
- /* On 5753 and variants, GPIO2 cannot be used. */
- no_gpio2 = tp->nic_sram_data_cfg &
- NIC_SRAM_DATA_CFG_NO_GPIO2;
-
- grc_local_ctrl |= GRC_LCLCTRL_GPIO_OE0 |
- GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT1 |
- GRC_LCLCTRL_GPIO_OUTPUT2;
- if (no_gpio2) {
- grc_local_ctrl &= ~(GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT2);
- }
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- grc_local_ctrl, 100);
-
- grc_local_ctrl |= GRC_LCLCTRL_GPIO_OUTPUT0;
-
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- grc_local_ctrl, 100);
-
- if (!no_gpio2) {
- grc_local_ctrl &= ~GRC_LCLCTRL_GPIO_OUTPUT2;
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- grc_local_ctrl, 100);
- }
- }
- } else {
- if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5700 &&
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701) {
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- (GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OUTPUT1), 100);
-
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- GRC_LCLCTRL_GPIO_OE1, 100);
-
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl |
- (GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OUTPUT1), 100);
- }
- }
+ if (need_vaux)
+ tg3_pwrsrc_switch_to_vaux(tp);
+ else
+ tg3_pwrsrc_die_with_vmain(tp);
}
static int tg3_5700_link_polarity(struct tg3 *tp, u32 speed)
@@ -2624,8 +2662,7 @@ static int tg3_power_up(struct tg3 *tp)
pci_set_power_state(tp->pdev, PCI_D0);
/* Switch out of Vaux if it is a NIC */
- if (tg3_flag(tp, IS_NIC))
- tw32_wait_f(GRC_LOCAL_CTRL, tp->grc_local_ctrl, 100);
+ tg3_pwrsrc_switch_to_vmain(tp);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 1/8] tg3: Workaround tagged status update bug
From: Matt Carlson @ 2011-06-13 23:38 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson, Michael Chan
On rare occasions, writing the tag to the interrupt mailbox does not
reenable interrupts. This patch fixes the problem by reissuing the
mailbox update.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 38 +++++++++++++++++++++++++++++++++++++-
drivers/net/tg3.h | 3 +++
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c8a145d..e8f16c5 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7752,6 +7752,9 @@ static void tg3_rings_reset(struct tg3 *tp)
/* Disable interrupts */
tw32_mailbox_f(tp->napi[0].int_mbox, 1);
+ tp->napi[0].chk_msi_cnt = 0;
+ tp->napi[0].last_rx_cons = 0;
+ tp->napi[0].last_tx_cons = 0;
/* Zero mailbox registers. */
if (tg3_flag(tp, SUPPORT_MSIX)) {
@@ -7762,6 +7765,9 @@ static void tg3_rings_reset(struct tg3 *tp)
tw32_mailbox(tp->napi[i].prodmbox, 0);
tw32_rx_mbox(tp->napi[i].consmbox, 0);
tw32_mailbox_f(tp->napi[i].int_mbox, 1);
+ tp->napi[0].chk_msi_cnt = 0;
+ tp->napi[i].last_rx_cons = 0;
+ tp->napi[i].last_tx_cons = 0;
}
if (!tg3_flag(tp, ENABLE_TSS))
tw32_mailbox(tp->napi[0].prodmbox, 0);
@@ -8817,6 +8823,30 @@ static void tg3_periodic_fetch_stats(struct tg3 *tp)
TG3_STAT_ADD32(&sp->rx_errors, RCVLPC_IN_ERRORS_CNT);
}
+static void tg3_chk_missed_msi(struct tg3 *tp)
+{
+ u32 i;
+
+ for (i = 0; i < tp->irq_cnt; i++) {
+ struct tg3_napi *tnapi = &tp->napi[i];
+
+ if (tg3_has_work(tnapi)) {
+ if (tnapi->last_rx_cons == tnapi->rx_rcb_ptr &&
+ tnapi->last_tx_cons == tnapi->tx_cons) {
+ if (tnapi->chk_msi_cnt < 1) {
+ tnapi->chk_msi_cnt++;
+ return;
+ }
+ tw32_mailbox(tnapi->int_mbox,
+ tnapi->last_tag << 24);
+ }
+ }
+ tnapi->chk_msi_cnt = 0;
+ tnapi->last_rx_cons = tnapi->rx_rcb_ptr;
+ tnapi->last_tx_cons = tnapi->tx_cons;
+ }
+}
+
static void tg3_timer(unsigned long __opaque)
{
struct tg3 *tp = (struct tg3 *) __opaque;
@@ -8826,6 +8856,10 @@ static void tg3_timer(unsigned long __opaque)
spin_lock(&tp->lock);
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5717 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765)
+ tg3_chk_missed_msi(tp);
+
if (!tg3_flag(tp, TAGGED_STATUS)) {
/* All of this garbage is because when using non-tagged
* IRQ status the mailbox/status_block protocol the chip
@@ -9301,7 +9335,9 @@ static int tg3_open(struct net_device *dev)
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
tg3_free_rings(tp);
} else {
- if (tg3_flag(tp, TAGGED_STATUS))
+ if (tg3_flag(tp, TAGGED_STATUS) &&
+ GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5717 &&
+ GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_57765)
tp->timer_offset = HZ;
else
tp->timer_offset = HZ / 10;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 5b3d2f3..3c113c1 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2800,6 +2800,7 @@ struct tg3_napi {
struct tg3 *tp;
struct tg3_hw_status *hw_status;
+ u32 chk_msi_cnt;
u32 last_tag;
u32 last_irq_tag;
u32 int_mbox;
@@ -2807,6 +2808,7 @@ struct tg3_napi {
u32 consmbox ____cacheline_aligned;
u32 rx_rcb_ptr;
+ u32 last_rx_cons;
u16 *rx_rcb_prod_idx;
struct tg3_rx_prodring_set prodring;
struct tg3_rx_buffer_desc *rx_rcb;
@@ -2814,6 +2816,7 @@ struct tg3_napi {
u32 tx_prod ____cacheline_aligned;
u32 tx_cons;
u32 tx_pending;
+ u32 last_tx_cons;
u32 prodmbox;
struct tg3_tx_buffer_desc *tx_ring;
struct ring_info *tx_buffers;
--
1.7.3.4
^ permalink raw reply related
* Re: [Bugme-new] [Bug 37202] New: Cannot change MTU on bridged interface
From: Andrew Morton @ 2011-06-13 23:37 UTC (permalink / raw)
To: netdev, bridge; +Cc: bugme-daemon, Stephen Hemminger, steve-alexander
In-Reply-To: <bug-37202-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 11 Jun 2011 10:59:18 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=37202
>
> Summary: Cannot change MTU on bridged interface
> Product: Networking
> Version: 2.5
> Kernel Version: 3.0.0-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: steve-alexander@roadrunner.com
> Regression: No
>
>
> Without bridge, setting mtu on eth0 works as expected.
> When eth0 is added to bridge 'br0' and this command is executed,
>
> ip link set eth0 mtu 4000
>
> results in:
erk.
Is this a new bug in 3.0-rc or have earlier kernels crashed in this manner?
Thanks.
> Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables bridge
> stp llc sunrpc ipv6 kvm_intel kvm uinput snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec
> snd_hwdep snd_seq i915 drm_kms_helper snd_seq_device drm iTCO_wdt i2c_algo_bit
> i2c_i801 ata_generic pata_acpi usblp i2c_core e1000e xhci_hcd video
> iTCO_vendor_support usb_storage snd_pcm se
> rio_raw joydev pata_jmicron pcspkr microcode snd_timer snd soundcore
> snd_page_alloc [last unloaded: scsi_wait_scan]
>
> Pid: 4247, comm: ip Not tainted 3.0.0-rc2 #4 Gigabyte Technology Co., Ltd.
> H57M-USB3/H57M-USB3
> RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> RSP: 0018:ffff8801e419d680 EFLAGS: 00010202
> RAX: 0000000000000640 RBX: 0000000000000640 RCX: ffff880212874788
> RDX: ffffffffa0347e00 RSI: ffffffffa0345c21 RDI: ffff880212874fb0
> RBP: ffff8801e419d6a8 R08: 0000000000000000 R09: ffffffff81666030
> R10: ffffffff81a7a3a0 R11: 0000000000000001 R12: ffff880212874000
> R13: ffff880212874780 R14: 00000000ffffffea R15: ffffffffa00e4030
> FS: 00007effa3ca6720(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 00000001e401b000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ip (pid: 4247, threadinfo ffff8801e419c000, task ffff8801f5f14560)
> Stack:
> ffffffffa033b1a6 ffff880212874000 00000000ffffffed ffff8801f50af400
> ffff880211dc4000 ffff8801e419d6c8 ffffffff813ba810 0000000000000007
> ffff880212874780 ffff8801e419d6f8 ffffffffa033e2b4 ffff880211dc4000
>
> Call Trace:
> [<ffffffffa033b1a6>] ? br_change_mtu+0x61/0x81 [bridge]
> [<ffffffff813ba810>] dev_set_mtu+0x45/0x75
> [<ffffffffa033e2b4>] br_device_event+0x7c/0x16c [bridge]
> [<ffffffff8146f921>] notifier_call_chain+0x37/0x63
> [<ffffffff8106d934>] raw_notifier_call_chain+0x14/0x16
> [<ffffffff813ba107>] call_netdevice_notifiers+0x4a/0x4f
> [<ffffffff813ba838>] dev_set_mtu+0x6d/0x75
> [<ffffffff813c8da2>] do_setlink+0x1ee/0x739
> [<ffffffff810e8052>] ? set_pte_at+0xe/0x12
> [<ffffffff8122e1de>] ? nla_parse+0x4f/0xc3
> [<ffffffff813c9f45>] rtnl_newlink+0x252/0x48d
> [<ffffffff813c9db7>] ? rtnl_newlink+0xc4/0x48d
> [<ffffffff8103d040>] ? need_resched+0x23/0x2d
> [<ffffffff813af3e3>] ? sock_rmalloc+0x33/0x95
> [<ffffffff813c9afe>] rtnetlink_rcv_msg+0x1eb/0x201
> [<ffffffff8103d040>] ? need_resched+0x23/0x2d
> [<ffffffff813c9913>] ? __rtnl_unlock+0x17/0x17
> [<ffffffff813dd9a8>] netlink_rcv_skb+0x45/0x90
> [<ffffffff813c94c4>] rtnetlink_rcv+0x26/0x2d
> [<ffffffff813dd4b3>] netlink_unicast+0xf1/0x15a
> [<ffffffff813dd7a1>] netlink_sendmsg+0x285/0x2a3
> [<ffffffff8110c558>] ? fatal_signal_pending+0x12/0x29
> [<ffffffff813a9e7d>] __sock_sendmsg+0x6a/0x76
> [<ffffffff813aa764>] sock_sendmsg+0xa8/0xc1
> [<ffffffff810cf7b0>] ? filemap_fault+0x20b/0x36c
> [<ffffffff810cde20>] ? unlock_page+0x2a/0x2f
> [<ffffffff810e8a1a>] ? __do_fault+0x34d/0x384
> [<ffffffff8103d040>] ? need_resched+0x23/0x2d
> [<ffffffff8103d058>] ? should_resched+0xe/0x2e
> [<ffffffff8103d040>] ? need_resched+0x23/0x2d
> [<ffffffff8103d058>] ? should_resched+0xe/0x2e
> [<ffffffff813b406e>] ? copy_from_user+0x2f/0x31
> [<ffffffff813b445e>] ? verify_iovec+0x54/0xa6
> [<ffffffff813aaa1a>] __sys_sendmsg+0x1ee/0x272
> [<ffffffff810eb570>] ? handle_mm_fault+0x149/0x15e
> [<ffffffff8146c5b6>] ? _raw_spin_lock+0xe/0x10
> [<ffffffff8146f8ab>] ? do_page_fault+0x321/0x360
> [<ffffffff810efda4>] ? do_brk+0x242/0x296
> [<ffffffff813ac02f>] sys_sendmsg+0x42/0x60
> [<ffffffff81472d42>] system_call_fastpath+0x16/0x1b
> Code: Bad RIP value.
> RIP [< (null)>] (null)
> RSP <ffff8801e419d680>
> CR2: 0000000000000000
> ---[ end trace 29a99239194ab188 ]---
>
>
> Bridge creation is managed by Fedora14 standard configs.
> eth0 is the only interface added to the bridge.
>
> eth0 is
> 03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network
> Connection [8086:10d3]
> Subsystem: Intel Corporation Gigabit CT Desktop Adapter [8086:a01f]
> Kernel driver in use: e1000e
> Kernel modules: e1000e
>
^ permalink raw reply
* Re: [PATCH] Documentation:change all arch/i386 to arch/x86 in Documentation
From: Wanlong Gao @ 2011-06-13 23:28 UTC (permalink / raw)
To: paulmck
Cc: linux-doc, linux-kernel, netdev, linux-kbuild, linux-video,
xiyoulinuxkernelgroup, linux-kernel, Dipankar Sarma, Randy Dunlap,
Nick Piggin, Karsten Keil, Michal Marek, James Bottomley,
Martin Mares, Harry Wei, Chuck Lever, Trond Myklebust,
Thomas Weber, Mike Frysinger, Jiri Kosina, Justin P. Mattock
In-Reply-To: <20110613172344.GC2272@linux.vnet.ibm.com>
On 一, 2011-06-13 at 10:23 -0700, Paul E. McKenney wrote:
> On Mon, Jun 13, 2011 at 01:28:18PM +0800, Wanlong Gao wrote:
> > From: Wanlong Gao <wanlong.gao@gmail.com>
> >
> > Change all "arch/i386" to "arch/x86" in Documentaion/,
> > since the directory has changed.
> >
> > Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
>
> I have queued the Documentation/RCU/NMI-RCU.txt hunk with your
> Signed-off-by, thank you!
>
> Thanx, Paul
Hi Paul:
http://git.kernel.org/?p=linux/kernel/git/jikos/trivial.git;a=commitdiff;h=25eb650a690b95cb0e2cf0c3b03f4900a59e0135
jiri had queued these all, will it get a merge failure?
Thanks
>
> > ---
> > Documentation/RCU/NMI-RCU.txt | 4 +-
> > Documentation/blockdev/README.DAC960 | 2 +-
> > Documentation/blockdev/ramdisk.txt | 8 +++---
> > Documentation/cpu-freq/cpu-drivers.txt | 2 +-
> > Documentation/filesystems/nfs/nfsroot.txt | 2 +-
> > Documentation/isdn/README.HiSax | 2 +-
> > Documentation/kbuild/makefiles.txt | 38 ++++++++++++++--------------
> > Documentation/magic-number.txt | 2 +-
> > Documentation/mca.txt | 6 ++--
> > Documentation/scheduler/sched-arch.txt | 2 +-
> > Documentation/scsi/BusLogic.txt | 2 +-
> > Documentation/serial/computone.txt | 2 +-
> > Documentation/svga.txt | 2 +-
> > Documentation/zh_CN/magic-number.txt | 2 +-
> > 14 files changed, 38 insertions(+), 38 deletions(-)
<snip patch>
^ permalink raw reply
* Re: [PATCH] net/hplance: hplance_init() should be __devinit
From: David Miller @ 2011-06-13 22:33 UTC (permalink / raw)
To: geert; +Cc: netdev, linux-m68k, linux-kernel
In-Reply-To: <1307989056-21814-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Mon, 13 Jun 2011 20:17:36 +0200
> WARNING: vmlinux.o(.devinit.text+0x253e): Section mismatch in reference from the function hplance_init_one() to the function .init.text:hplance_init()
>
> The forward declaration had the correct attribute, but the actual function
> definition hadn't.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bonding:delete a dereference before check
From: David Miller @ 2011-06-13 22:29 UTC (permalink / raw)
To: fubar; +Cc: panweiping3, error27, andy, netdev, linux-kernel
In-Reply-To: <18226.1308003061@death>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Mon, 13 Jun 2011 15:11:01 -0700
> Weiping Pan <panweiping3@gmail.com> wrote:
>
>>Dan Carpenter found that there was a dereference before a check,
>>added in 56d00c677de0(bonding:delete lacp_fast from ad_bond_info).
>>
>>Signed-off-by: Weiping Pan <panweiping3@gmail.com>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: 3c503: fix broken IRQ autoprobing
From: David Miller @ 2011-06-13 22:25 UTC (permalink / raw)
To: ben; +Cc: linux, netdev, linux-kernel
In-Reply-To: <1307915111.22348.652.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 12 Jun 2011 17:45:11 -0400
> On Sun, 2011-06-12 at 21:40 +0200, Ondrej Zary wrote:
>> Fix broken IRQ autoprobing in 3c503 driver:
>> - improper IRQ freeing (does not free IRQs causes WARN)
>> - missing break when an working IRQ is found
>>
>> The driver works with this patch.
>
> I made a previous attempt to fix autoprobing (commit
> b0cf4dfb7cd21556efd9a6a67edcba0840b4d98d), but didn't have any hardware
> to test on. In the process I introduced these new bugs. Sorry about
> that.
>
>> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> [...]
> Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sky2: avoid using uninitialized variable
From: Stephen Hemminger @ 2011-06-13 22:12 UTC (permalink / raw)
To: Greg Thelen; +Cc: Stephen Hemminger, netdev, linux-kernel
In-Reply-To: <xr93vcw9s9zc.fsf@gthelen.mtv.corp.google.com>
On Mon, 13 Jun 2011 14:21:59 -0700
Greg Thelen <gthelen@google.com> wrote:
> I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
> error case. I used 0. A more complete solution might be to plumb up
> error handling to the callers of gm_phy_read().
>
> ==
> From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
> From: Greg Thelen <gthelen@google.com>
> Date: Mon, 13 Jun 2011 14:09:07 -0700
> Subject: [PATCH] sky2: avoid using uninitialized variable
>
> Prior to this change gm_phy_read() could return an uninitialized
> variable if __gm_phy_read() failed.
>
> This change returns zero in the failure case.
>
> Signed-off-by: Greg Thelen <gthelen@google.com>
Shouldn't the callers be changed to check rather than just returning
0 and masking the problem.
^ permalink raw reply
* Re: [PATCH] bonding:delete a dereference before check
From: Jay Vosburgh @ 2011-06-13 22:11 UTC (permalink / raw)
To: Weiping Pan; +Cc: error27, Andy Gospodarek, open list:BONDING DRIVER, open list
In-Reply-To: <1307975410-13523-1-git-send-email-panweiping3@gmail.com>
Weiping Pan <panweiping3@gmail.com> wrote:
>Dan Carpenter found that there was a dereference before a check,
>added in 56d00c677de0(bonding:delete lacp_fast from ad_bond_info).
>
>Signed-off-by: Weiping Pan <panweiping3@gmail.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
-J
> drivers/net/bonding/bond_3ad.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 6122725..77da2e8 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -1900,7 +1900,6 @@ void bond_3ad_initialize(struct bonding *bond, u16 tick_resolution)
> int bond_3ad_bind_slave(struct slave *slave)
> {
> struct bonding *bond = bond_get_bond_by_slave(slave);
>- int lacp_fast = bond->params.lacp_fast;
> struct port *port;
> struct aggregator *aggregator;
>
>@@ -1916,7 +1915,7 @@ int bond_3ad_bind_slave(struct slave *slave)
> // port initialization
> port = &(SLAVE_AD_INFO(slave).port);
>
>- ad_initialize_port(port, lacp_fast);
>+ ad_initialize_port(port, bond->params.lacp_fast);
>
> port->slave = slave;
> port->actor_port_number = SLAVE_AD_INFO(slave).id;
>--
>1.7.4.4
^ permalink raw reply
* Re: Re: [RFC PATCH 1/1] IPVS netns shutdown/startup dead-lock
From: Hans Schillstrom @ 2011-06-13 22:09 UTC (permalink / raw)
To: Julian Anastasov
Cc: Hans Schillstrom, horms, wensong, lvs-devel, netdev,
netfilter-devel
>---- Original Message ----
>From: Julian Anastasov <ja@ssi.bg>
>To: "Hans Schillstrom" <hans.schillstrom@ericsson.com>
>Cc: horms@verge.net.au, wensong@linux-vs.org, lvs-devel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, hans@schillstrom.com
>Sent: Mon, Jun 13, 2011, 23:23 PM
>Subject: Re: [RFC PATCH 1/1] IPVS netns shutdown/startup dead-lock
>
>Hello,
>
>On Mon, 13 Jun 2011, Hans Schillstrom wrote:
>
>> ip_vs_mutext is used by both netns shutdown code and startup
>> and both implicit uses sk_lock-AF_INET mutex.
>>
>> cleanup CPU-1 startup CPU-2
>> ip_vs_dst_event() ip_vs_genl_set_cmd()
>> sk_lock-AF_INET __ip_vs_mutex
>> sk_lock-AF_INET
>> __ip_vs_mutex
>> * DEAD LOCK *
>
> So, sk_lock-AF_INET is locked before calling
>ip_vs_dst_event ? Do you have a backtrace for this case?
Yes plenty this one is with lockdep
Chain exists of:
rtnl_mutex --> __ip_vs_mutex --> sk_lock-AF_INET
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_INET);
lock(__ip_vs_mutex);
lock(sk_lock-AF_INET);
lock(rtnl_mutex);
*** DEADLOCK ***
3 locks held by ipvsadm/993:
#0: (genl_mutex){+.+.+.}, at: [<ffffffff812edc52>] genl_lock+0x17/0x19
#1: (__ip_vs_mutex){+.+.+.}, at: [<ffffffff81307dcb>] ip_vs_genl_set_cmd+0xe1/0x3a3
#2: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8130ffc1>] start_sync_thread+0x3ec/0x5ff
>I assume your patch is tested to fix the problem ?
Yes.
>
>> This can be solved by have the ip_vs_mutex per netns
>> or avid locking when starting/stoping sync-threads.
>> i.e. just add a starting/stoping flag.
>
> sk_release_kernel is called in thread
>context, so ip_vs_mutex is not involved there. We
>have a problem only with start_sync_thread, right?
Yes the socket operations
>
>> ip_vs_mutex per name-space seems to be a more future proof solution.
>
> Global mutex protects some global lists such as
>virtual services. If your patch works, better way to fix this problem
>is to use some new mutex. May be we can move the IPVS_CMD_NEW_DAEMON,
>IPVS_CMD_DEL_DAEMON and IP_VS_SO_GET_DAEMON code before the
>__ip_vs_mutex locking. This mutex should be used for start_sync_thread,
>stop_sync_thread, ip_vs_genl_dump_daemons and IP_VS_SO_GET_DAEMON.
>For example, ip_vs_sync_mutex.
I think we should avoid global mutexes as a rule of tumb,
because it's realy hard to keep track of all possible cases
that can occur when multiple netns is alive and/or goes up and down.
There might be more suprises while a netns exits (in terms of locks)...
my gut feeling is, avoid global locks as long as possible.
>
> Note that __ip_vs_sync_cleanup is missing a
>__ip_vs_mutex lock. We have to use the new mutex there.
OK
>
>> Which one should be used ?
>
> For now __ip_vs_mutex should be global ...
I do agree, but in the long term I vote for mutex per netns.
Thanks a lot Julian
Regards
Hans
^ permalink raw reply
* Re: [PATCH] ieee802154: Don't leak memory in ieee802154_nl_fill_phy
From: David Miller @ 2011-06-13 22:06 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
maxim.osipov-kv7WeFo6aLtBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jj-IYz4IdjRLj0sV2N9l4h3zg
In-Reply-To: <BANLkTikBnQADmUpP7J5gmJLXA9-O+4kSvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Jun 2011 00:02:38 +0400
> On 6/12/11, Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org> wrote:
>> In net/ieee802154/nl-phy.c::ieee802154_nl_fill_phy() I see two small
>> issues.
>> 1) If the allocation of 'buf' fails we may just as well return -EMSGSIZE
>> directly rather than jumping to 'out:' and do a pointless kfree(0).
>> 2) We do not free 'buf' unless we jump to one of the error labels and this
>> leaks memory.
>> This patch should address both.
>>
>> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
>
> Acked-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> David, please commit this.
Applied, thanks.
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
^ permalink raw reply
* Re: [PATCH net-next-2.6] l2tp: fix l2tp_ip_sendmsg() route handling
From: David Miller @ 2011-06-13 21:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jchapman
In-Reply-To: <1307867229.2872.101.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 12 Jun 2011 10:27:09 +0200
> l2tp_ip_sendmsg() in non connected mode incorrectly calls
> sk_setup_caps(). Subsequent send() calls send data to wrong destination.
>
> We can also avoid changing dst refcount in connected mode, using
> appropriate rcu locking. Once output route lookups can also be done
> under rcu, sendto() calls wont change dst refcounts too.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: James Chapman <jchapman@katalix.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH V3 00/10] net: expand time stamping, batch #1
From: David Miller @ 2011-06-13 21:26 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 12 Jun 2011 14:18:57 +0200
> Richard Cochran (10):
> net: export time stamp utility function for Ethernet MAC drivers
> fec: enable transmit and receive time stamping.
> davinci_emac: pass ioctls through to phy device.
> davinci_emac: enable transmit time stamping.
> tg3: enable transmit time stamping.
> dnet: enable transmit time stamping.
> ethoc: enable transmit time stamping.
> r6040: enable transmit time stamping.
> stmmac: enable transmit time stamping.
> smsc9420: enable transmit time stamping.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/1] IPVS netns shutdown/startup dead-lock
From: Julian Anastasov @ 2011-06-13 21:25 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: horms, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1307957530-12732-1-git-send-email-hans.schillstrom@ericsson.com>
Hello,
On Mon, 13 Jun 2011, Hans Schillstrom wrote:
> ip_vs_mutext is used by both netns shutdown code and startup
> and both implicit uses sk_lock-AF_INET mutex.
>
> cleanup CPU-1 startup CPU-2
> ip_vs_dst_event() ip_vs_genl_set_cmd()
> sk_lock-AF_INET __ip_vs_mutex
> sk_lock-AF_INET
> __ip_vs_mutex
> * DEAD LOCK *
So, sk_lock-AF_INET is locked before calling
ip_vs_dst_event ? Do you have a backtrace for this case?
I assume your patch is tested to fix the problem ?
> This can be solved by have the ip_vs_mutex per netns
> or avid locking when starting/stoping sync-threads.
> i.e. just add a starting/stoping flag.
sk_release_kernel is called in thread
context, so ip_vs_mutex is not involved there. We
have a problem only with start_sync_thread, right?
> ip_vs_mutex per name-space seems to be a more future proof solution.
Global mutex protects some global lists such as
virtual services. If your patch works, better way to fix this problem
is to use some new mutex. May be we can move the IPVS_CMD_NEW_DAEMON,
IPVS_CMD_DEL_DAEMON and IP_VS_SO_GET_DAEMON code before the
__ip_vs_mutex locking. This mutex should be used for start_sync_thread,
stop_sync_thread, ip_vs_genl_dump_daemons and IP_VS_SO_GET_DAEMON.
For example, ip_vs_sync_mutex.
Note that __ip_vs_sync_cleanup is missing a
__ip_vs_mutex lock. We have to use the new mutex there.
> Which one should be used ?
For now __ip_vs_mutex should be global ...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH] sky2: avoid using uninitialized variable
From: Greg Thelen @ 2011-06-13 21:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
error case. I used 0. A more complete solution might be to plumb up
error handling to the callers of gm_phy_read().
==
>From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
From: Greg Thelen <gthelen@google.com>
Date: Mon, 13 Jun 2011 14:09:07 -0700
Subject: [PATCH] sky2: avoid using uninitialized variable
Prior to this change gm_phy_read() could return an uninitialized
variable if __gm_phy_read() failed.
This change returns zero in the failure case.
Signed-off-by: Greg Thelen <gthelen@google.com>
---
drivers/net/sky2.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 3ee41da..eba1ac4 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -206,7 +206,8 @@ io_error:
static inline u16 gm_phy_read(struct sky2_hw *hw, unsigned port, u16 reg)
{
u16 v;
- __gm_phy_read(hw, port, reg, &v);
+ if (__gm_phy_read(hw, port, reg, &v) < 0)
+ return 0;
return v;
}
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] ieee802154: Don't leak memory in ieee802154_nl_fill_phy
From: Dmitry Eremin-Solenikov @ 2011-06-13 20:02 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-kernel, netdev, linux-zigbee-devel, David S. Miller,
Sergey Lapin, Maxim Osipov
In-Reply-To: <alpine.LNX.2.00.1106121621360.25151@swampdragon.chaosbits.net>
On 6/12/11, Jesper Juhl <jj@chaosbits.net> wrote:
> In net/ieee802154/nl-phy.c::ieee802154_nl_fill_phy() I see two small
> issues.
> 1) If the allocation of 'buf' fails we may just as well return -EMSGSIZE
> directly rather than jumping to 'out:' and do a pointless kfree(0).
> 2) We do not free 'buf' unless we jump to one of the error labels and this
> leaks memory.
> This patch should address both.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
David, please commit this.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] net/hplance: hplance_init() should be __devinit
From: Geert Uytterhoeven @ 2011-06-13 18:17 UTC (permalink / raw)
To: netdev; +Cc: linux-m68k, linux-kernel, Geert Uytterhoeven
WARNING: vmlinux.o(.devinit.text+0x253e): Section mismatch in reference from the function hplance_init_one() to the function .init.text:hplance_init()
The forward declaration had the correct attribute, but the actual function
definition hadn't.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/hplance.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/hplance.c b/drivers/net/hplance.c
index b6060f7..a900d5b 100644
--- a/drivers/net/hplance.c
+++ b/drivers/net/hplance.c
@@ -135,7 +135,7 @@ static void __devexit hplance_remove_one(struct dio_dev *d)
}
/* Initialise a single lance board at the given DIO device */
-static void __init hplance_init(struct net_device *dev, struct dio_dev *d)
+static void __devinit hplance_init(struct net_device *dev, struct dio_dev *d)
{
unsigned long va = (d->resource.start + DIO_VIRADDRBASE);
struct hplance_private *lp;
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox