* [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
* Re: Question about LRO/GRO and TCP acknowledgements
From: Rick Jones @ 2011-06-13 17:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Joris van Rantwijk, netdev
In-Reply-To: <1307890657.2872.158.camel@edumazet-laptop>
On Sun, 2011-06-12 at 16:57 +0200, Eric Dumazet wrote:
> Le dimanche 12 juin 2011 à 13:24 +0200, Joris van Rantwijk a écrit :
> > On 2011-06-12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > So your concern is more a Sender side implementation missing this
> > > recommendation, not GRO per se...
> >
> > Not really. The same RFC says:
> > Specifically, an ACK SHOULD be generated for at least every
> > second full-sized segment, ...
> >
>
> Well, SHOULD is not MUST.
>
>
> > I can see how the world may have been a better place if every sender
> > implemented Appropriate Byte Counting and TCP receivers were allowed to
> > send fewer ACKs. However, current reality is that ABC is optional,
> > disabled by default in Linux, and receivers are recommended to send one
> > ACK per two segments.
> >
>
> ABC might be nice for stacks that use byte counters for cwnd. We use
> segments.
>
> > I suspect that GRO currently hurts throughput of isolated TCP
> > connections. This is based on a purely theoretic argument. I may be
> > wrong and I have absolutely no data to confirm my suspicion.
> >
> > If you can point out the flaw in my reasoning, I would be greatly
> > relieved. Until then, I remain concerned that there may be something
> > wrong with GRO and TCP ACKs.
>
> Think of GRO being a receiver facility against stress/load, typically in
> datacenter.
>
> Only when receiver is overloaded, GRO kicks in and can coalesce several
> frames before being handled in TCP stack in one run.
How is that affected by interrupt coalescing in the NIC and the sending
side doing TSO (and so, ostensibly sending back-to-back frames)? Are we
assured that a NIC is updating its completion pointer on the rx ring
continuously rather than just before a coalesced interrupt?
Does GRO "never" kick-in over a 1GbE link (making the handwaving
assumption that cores today are >> faster than a 1GbE link on a bulk
transfer).
It was just a quick and dirty test, but it does seem there is a positive
hit from GRO being enabled on a 1GbE link on a system with "fast
processors"
raj@tardy:~/netperf2_trunk$ sudo ethtool -K eth1 gro off
raj@tardy:~/netperf2_trunk$ src/netperf -t TCP_MAERTS -H 192.168.1.3 -i
10,3 -c -- -k foo
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 (192.168.1.3) port 0 AF_INET : +/-2.500% @ 99% conf. :
histogram : demo
THROUGHPUT=935.07
LOCAL_INTERFACE_NAME=eth1
LOCAL_CPU_UTIL=16.64
LOCAL_SD=5.830
raj@tardy:~/netperf2_trunk$ sudo ethtool -K eth1 gro on
raj@tardy:~/netperf2_trunk$ src/netperf -t TCP_MAERTS -H 192.168.1.3 -i
10,3 -c -- -k foo
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 (192.168.1.3) port 0 AF_INET : +/-2.500% @ 99% conf. :
histogram : demo
THROUGHPUT=934.81
LOCAL_INTERFACE_NAME=eth1
LOCAL_CPU_UTIL=16.21
LOCAL_SD=5.684
raj@tardy:~/netperf2_trunk$ uname -a
Linux tardy 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 18:42:20 UTC
2011 x86_64 GNU/Linux
The receiver system here has a 3.07 GHz W3550 in it and eth1 is a port
on an Intel 82571EB-based four-port card.
raj@tardy:~/netperf2_trunk$ ethtool -i eth1
driver: e1000e
version: 1.0.2-k4
firmware-version: 5.10-2
bus-info: 0000:2a:00.0
> If receiver is so loaded that more than 2 frames are coalesced in a NAPI
> run, it certainly helps to not allow sender to increase its cwnd more
> than one SMSS. We probably are right before packet drops anyway.
If we are indeed statistically certain we are right before packet drops
(or I suppose asserting pause) then shouldn't ECN get set by the GRO
code?
rick
^ permalink raw reply
* Re: Question about LRO/GRO and TCP acknowledgements
From: Rick Jones @ 2011-06-13 17:34 UTC (permalink / raw)
To: Joris van Rantwijk; +Cc: netdev
In-Reply-To: <20110611215919.5fc29c27@konijn>
On Sat, 2011-06-11 at 21:59 +0200, Joris van Rantwijk wrote:
> Hi,
>
> I'm trying to understand how Linux produces TCP acknowledgements
> for segments received via LRO/GRO.
>
> As far as I can see, the network driver uses GRO to collect several
> received packets into one big super skb, which is then handled
> during just one call to tcp_v4_rcv(). This will eventually result
> in the sending of at most one ACK packet for the entire GRO packet.
>
> Conventional wisdom (RFC 5681) says that a receiver should send at
> least one ACK for every two data segments received. The sending TCP
> needs these ACKs to update its congestion window (e.g. slow start).
>
> It seems to me that the current implementation in Linux may send
> just one ACK for a large number of received segments. This would
> be a deviation from the standard. As a result the congestion
> window of the sender would grow much slower than intended.
>
> Maybe I misunderstand something in the network code (likely).
> Could someone please explain me how this ACK issue is handled?
FWIW, HP-UX and Solaris stacks (perhaps others) have had ACK-avoidance
heuristics in place since the mid to late 1990's, and the ACK-avoidance
of LRO/GRO is quite similar "on the wire." Have those heuristics been
stellar? Probably not, but they've not it seems caused massive
problems, and when one has TSO and LRO/GRO the overhead of
ACK-every-other-MSS processing becomes non-trivial. Even more so when
copy-avoidance is present.
I'd go with increase by the bytes ACKed not the ACK count.
rick jones
^ permalink raw reply
* Re: [PATCH] Documentation:change all arch/i386 to arch/x86 in Documentation
From: Paul E. McKenney @ 2011-06-13 17:23 UTC (permalink / raw)
To: Wanlong Gao
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: <1307942898-3728-1-git-send-email-wanlong.gao@gmail.com>
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
> ---
> 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(-)
>
> diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt
> index a8536cb..bf82851 100644
> --- a/Documentation/RCU/NMI-RCU.txt
> +++ b/Documentation/RCU/NMI-RCU.txt
> @@ -5,8 +5,8 @@ Although RCU is usually used to protect read-mostly data structures,
> it is possible to use RCU to provide dynamic non-maskable interrupt
> handlers, as well as dynamic irq handlers. This document describes
> how to do this, drawing loosely from Zwane Mwaikambo's NMI-timer
> -work in "arch/i386/oprofile/nmi_timer_int.c" and in
> -"arch/i386/kernel/traps.c".
> +work in "arch/x86/oprofile/nmi_timer_int.c" and in
> +"arch/x86/kernel/traps.c".
>
> The relevant pieces of code are listed below, each followed by a
> brief explanation.
> diff --git a/Documentation/blockdev/README.DAC960 b/Documentation/blockdev/README.DAC960
> index 0e8f618..bd85fb9 100644
> --- a/Documentation/blockdev/README.DAC960
> +++ b/Documentation/blockdev/README.DAC960
> @@ -214,7 +214,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree:
> make config
> make bzImage (or zImage)
>
> -Then install "arch/i386/boot/bzImage" or "arch/i386/boot/zImage" as your
> +Then install "arch/x86/boot/bzImage" or "arch/x86/boot/zImage" as your
> standard kernel, run lilo if appropriate, and reboot.
>
> To create the necessary devices in /dev, the "make_rd" script included in
> diff --git a/Documentation/blockdev/ramdisk.txt b/Documentation/blockdev/ramdisk.txt
> index 6c820ba..fa72e97 100644
> --- a/Documentation/blockdev/ramdisk.txt
> +++ b/Documentation/blockdev/ramdisk.txt
> @@ -64,9 +64,9 @@ the RAM disk dynamically grows as data is being written into it, a size field
> is not required. Bits 11 to 13 are not currently used and may as well be zero.
> These numbers are no magical secrets, as seen below:
>
> -./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
> -./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
> -./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000
> +./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF
> +./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000
> +./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000
>
> Consider a typical two floppy disk setup, where you will have the
> kernel on disk one, and have already put a RAM disk image onto disk #2.
> @@ -85,7 +85,7 @@ The command line equivalent is: "prompt_ramdisk=1"
> Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word.
> So to create disk one of the set, you would do:
>
> - /usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0
> + /usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0
> /usr/src/linux# rdev /dev/fd0 /dev/fd0
> /usr/src/linux# rdev -r /dev/fd0 49152
>
> diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
> index 6c30e93..ed07e4f 100644
> --- a/Documentation/cpu-freq/cpu-drivers.txt
> +++ b/Documentation/cpu-freq/cpu-drivers.txt
> @@ -168,7 +168,7 @@ in-chipset dynamic frequency switching to policy->min, the upper limit
> to policy->max, and -if supported- select a performance-oriented
> setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a
> powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check
> -the reference implementation in arch/i386/kernel/cpu/cpufreq/longrun.c
> +the reference implementation in arch/x86/kernel/cpu/cpufreq/longrun.c
>
>
>
> diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
> index 90c71c6..ffdd9d8 100644
> --- a/Documentation/filesystems/nfs/nfsroot.txt
> +++ b/Documentation/filesystems/nfs/nfsroot.txt
> @@ -226,7 +226,7 @@ They depend on various facilities being available:
> cdrecord.
>
> e.g.
> - cdrecord dev=ATAPI:1,0,0 arch/i386/boot/image.iso
> + cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso
>
> For more information on isolinux, including how to create bootdisks
> for prebuilt kernels, see http://syslinux.zytor.com/
> diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax
> index 99e87a6..b1a573c 100644
> --- a/Documentation/isdn/README.HiSax
> +++ b/Documentation/isdn/README.HiSax
> @@ -506,7 +506,7 @@ to e.g. the Internet:
> <ISDN subsystem - ISDN support -- HiSax>
> make clean; make zImage; make modules; make modules_install
> 2. Install the new kernel
> - cp /usr/src/linux/arch/i386/boot/zImage /etc/kernel/linux.isdn
> + cp /usr/src/linux/arch/x86/boot/zImage /etc/kernel/linux.isdn
> vi /etc/lilo.conf
> <add new kernel in the bootable image section>
> lilo
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 47435e5..f47cdef 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -441,7 +441,7 @@ more details, with real examples.
> specified if first option are not supported.
>
> Example:
> - #arch/i386/kernel/Makefile
> + #arch/x86/kernel/Makefile
> vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
>
> In the above example, vsyscall-flags will be assigned the option
> @@ -460,7 +460,7 @@ more details, with real examples.
> supported to use an optional second option.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
>
> In the above example, cflags-y will be assigned the option
> @@ -522,7 +522,7 @@ more details, with real examples.
> even though the option was accepted by gcc.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> cflags-y += $(shell \
> if [ $(call cc-version) -ge 0300 ] ; then \
> echo "-mregparm=3"; fi ;)
> @@ -802,7 +802,7 @@ but in the architecture makefiles where the kbuild infrastructure
> is not sufficient this sometimes needs to be explicit.
>
> Example:
> - #arch/i386/boot/Makefile
> + #arch/x86/boot/Makefile
> subdir- := compressed/
>
> The above assignment instructs kbuild to descend down in the
> @@ -812,12 +812,12 @@ To support the clean infrastructure in the Makefiles that builds the
> final bootimage there is an optional target named archclean:
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> archclean:
> - $(Q)$(MAKE) $(clean)=arch/i386/boot
> + $(Q)$(MAKE) $(clean)=arch/x86/boot
>
> -When "make clean" is executed, make will descend down in arch/i386/boot,
> -and clean as usual. The Makefile located in arch/i386/boot/ may use
> +When "make clean" is executed, make will descend down in arch/x86/boot,
> +and clean as usual. The Makefile located in arch/x86/boot/ may use
> the subdir- trick to descend further down.
>
> Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is
> @@ -882,7 +882,7 @@ When kbuild executes, the following steps are followed (roughly):
> LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> LDFLAGS_vmlinux := -e stext
>
> OBJCOPYFLAGS objcopy flags
> @@ -920,14 +920,14 @@ When kbuild executes, the following steps are followed (roughly):
> Often, the KBUILD_CFLAGS variable depends on the configuration.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> cflags-$(CONFIG_M386) += -march=i386
> KBUILD_CFLAGS += $(cflags-y)
>
> Many arch Makefiles dynamically run the target C compiler to
> probe supported options:
>
> - #arch/i386/Makefile
> + #arch/x86/Makefile
>
> ...
> cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
> @@ -1038,8 +1038,8 @@ When kbuild executes, the following steps are followed (roughly):
> into the arch/$(ARCH)/boot/Makefile.
>
> Example:
> - #arch/i386/Makefile
> - boot := arch/i386/boot
> + #arch/x86/Makefile
> + boot := arch/x86/boot
> bzImage: vmlinux
> $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>
> @@ -1051,7 +1051,7 @@ When kbuild executes, the following steps are followed (roughly):
> To support this, $(archhelp) must be defined.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> define archhelp
> echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
> endif
> @@ -1065,7 +1065,7 @@ When kbuild executes, the following steps are followed (roughly):
> from vmlinux.
>
> Example:
> - #arch/i386/Makefile
> + #arch/x86/Makefile
> all: bzImage
>
> When "make" is executed without arguments, bzImage will be built.
> @@ -1083,7 +1083,7 @@ When kbuild executes, the following steps are followed (roughly):
> 2) kbuild knows what files to delete during "make clean"
>
> Example:
> - #arch/i386/kernel/Makefile
> + #arch/x86/kernel/Makefile
> extra-y := head.o init_task.o
>
> In this example, extra-y is used to list object files that
> @@ -1133,7 +1133,7 @@ When kbuild executes, the following steps are followed (roughly):
> Compress target. Use maximum compression to compress target.
>
> Example:
> - #arch/i386/boot/Makefile
> + #arch/x86/boot/Makefile
> LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
> LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
>
> @@ -1193,7 +1193,7 @@ When kbuild executes, the following steps are followed (roughly):
>
> When updating the $(obj)/bzImage target, the line
>
> - BUILD arch/i386/boot/bzImage
> + BUILD arch/x86/boot/bzImage
>
> will be displayed with "make KBUILD_VERBOSE=0".
>
> @@ -1207,7 +1207,7 @@ When kbuild executes, the following steps are followed (roughly):
> kbuild knows .lds files and includes a rule *lds.S -> *lds.
>
> Example:
> - #arch/i386/kernel/Makefile
> + #arch/x86/kernel/Makefile
> always := vmlinux.lds
>
> #Makefile
> diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
> index 4b12abc..20ec3d9 100644
> --- a/Documentation/magic-number.txt
> +++ b/Documentation/magic-number.txt
> @@ -66,7 +66,7 @@ MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h
> RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h
> SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h
> HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c
> -APM_BIOS_MAGIC 0x4101 apm_user arch/i386/kernel/apm.c
> +APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm.c
> CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h
> DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c
> DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c
> diff --git a/Documentation/mca.txt b/Documentation/mca.txt
> index 510375d..cf8fd39 100644
> --- a/Documentation/mca.txt
> +++ b/Documentation/mca.txt
> @@ -3,7 +3,7 @@ i386 Micro Channel Architecture Support
>
> MCA support is enabled using the CONFIG_MCA define. A machine with a MCA
> bus will have the kernel variable MCA_bus set, assuming the BIOS feature
> -bits are set properly (see arch/i386/boot/setup.S for information on
> +bits are set properly (see arch/x86/boot/setup.S for information on
> how this detection is done).
>
> Adapter Detection
> @@ -11,7 +11,7 @@ Adapter Detection
>
> The ideal MCA adapter detection is done through the use of the
> Programmable Option Select registers. Generic functions for doing
> -this have been added in include/linux/mca.h and arch/i386/kernel/mca.c.
> +this have been added in include/linux/mca.h and arch/x86/kernel/mca.c.
> Everything needed to detect adapters and read (and write) configuration
> information is there. A number of MCA-specific drivers already use
> this. The typical probe code looks like the following:
> @@ -81,7 +81,7 @@ more people use shared IRQs on PCI machines.
> In general, an interrupt must be acknowledged not only at the ICU (which
> is done automagically by the kernel), but at the device level. In
> particular, IRQ 0 must be reset after a timer interrupt (now done in
> -arch/i386/kernel/time.c) or the first timer interrupt hangs the system.
> +arch/x86/kernel/time.c) or the first timer interrupt hangs the system.
> There were also problems with the 1.3.x floppy drivers, but that seems
> to have been fixed.
>
> diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt
> index d43dbcb..28aa107 100644
> --- a/Documentation/scheduler/sched-arch.txt
> +++ b/Documentation/scheduler/sched-arch.txt
> @@ -66,7 +66,7 @@ Your cpu_idle routines need to obey the following rules:
> barrier issued (followed by a test of need_resched with
> interrupts disabled, as explained in 3).
>
> -arch/i386/kernel/process.c has examples of both polling and
> +arch/x86/kernel/process.c has examples of both polling and
> sleeping idle functions.
>
>
> diff --git a/Documentation/scsi/BusLogic.txt b/Documentation/scsi/BusLogic.txt
> index d7fbc94..48e982c 100644
> --- a/Documentation/scsi/BusLogic.txt
> +++ b/Documentation/scsi/BusLogic.txt
> @@ -553,7 +553,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree:
> make config
> make zImage
>
> -Then install "arch/i386/boot/zImage" as your standard kernel, run lilo if
> +Then install "arch/x86/boot/zImage" as your standard kernel, run lilo if
> appropriate, and reboot.
>
>
> diff --git a/Documentation/serial/computone.txt b/Documentation/serial/computone.txt
> index c57ea47..60a6f65 100644
> --- a/Documentation/serial/computone.txt
> +++ b/Documentation/serial/computone.txt
> @@ -87,7 +87,7 @@ c) Set address on ISA cards then:
> edit /usr/src/linux/drivers/char/ip2.c
> (Optional - may be specified on kernel command line now)
> d) Run "make zImage" or whatever target you prefer.
> -e) mv /usr/src/linux/arch/i386/boot/zImage to /boot.
> +e) mv /usr/src/linux/arch/x86/boot/zImage to /boot.
> f) Add new config for this kernel into /etc/lilo.conf, run "lilo"
> or copy to a floppy disk and boot from that floppy disk.
> g) Reboot using this kernel
> diff --git a/Documentation/svga.txt b/Documentation/svga.txt
> index cd66ec8..e5da082 100644
> --- a/Documentation/svga.txt
> +++ b/Documentation/svga.txt
> @@ -150,7 +150,7 @@ end of the display.
>
> 4. Options
> ~~~~~~~~~~
> - Some options can be set in the source text (in arch/i386/boot/video.S).
> + Some options can be set in the source text (in arch/x86/boot/video.S).
> All of them are simple #define's -- change them to #undef's when you want to
> switch them off. Currently supported:
>
> diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
> index 4c4ce85..a9e6fdd 100644
> --- a/Documentation/zh_CN/magic-number.txt
> +++ b/Documentation/zh_CN/magic-number.txt
> @@ -66,7 +66,7 @@ MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h
> RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h
> SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h
> HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c
> -APM_BIOS_MAGIC 0x4101 apm_user arch/i386/kernel/apm.c
> +APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm.c
> CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h
> DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c
> DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c
> --
> 1.7.4.1
>
^ permalink raw reply
* RE: [Pv-drivers] [PATCH] vmxnet3: remove unused variable
From: Bhavesh Davda @ 2011-06-13 17:10 UTC (permalink / raw)
To: Neil Horman, netdev@vger.kernel.org; +Cc: VMware, Inc., David S. Miller
In-Reply-To: <1307980110-9585-1-git-send-email-nhorman@tuxdriver.com>
Good find. LGTM.
Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
- Bhavesh
Bhavesh P. Davda
> -----Original Message-----
> From: pv-drivers-bounces@vmware.com [mailto:pv-drivers-bounces@vmware.com] On
> Behalf Of Neil Horman
> Sent: Monday, June 13, 2011 8:49 AM
> To: netdev@vger.kernel.org
> Cc: VMware, Inc.; David S. Miller; Neil Horman
> Subject: [Pv-drivers] [PATCH] vmxnet3: remove unused variable
>
> While doing some backporting I noticed that vmxnet3 had a variable that was
> set
> but never used. Get rid of it, and stop the compiler from griping
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: "VMware, Inc." <pv-drivers@vmware.com>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
> b/drivers/net/vmxnet3/vmxnet3_drv.c
> index fa6e2ac..a9b60a2 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -405,10 +405,8 @@ vmxnet3_tq_cleanup(struct vmxnet3_tx_queue *tq,
>
> while (tq->tx_ring.next2comp != tq->tx_ring.next2fill) {
> struct vmxnet3_tx_buf_info *tbi;
> - union Vmxnet3_GenericDesc *gdesc;
>
> tbi = tq->buf_info + tq->tx_ring.next2comp;
> - gdesc = tq->tx_ring.base + tq->tx_ring.next2comp;
>
> vmxnet3_unmap_tx_buf(tbi, adapter->pdev);
> if (tbi->skb) {
> --
> 1.7.5.4
>
> _______________________________________________
> Pv-drivers mailing list
> Pv-drivers@vmware.com
> http://mailman2.vmware.com/mailman/listinfo/pv-drivers
^ 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