* [net-2.6 5/7] ixgbe: limit VF access to network traffic
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change fixes VM pool allocation issues based on MAC address filtering,
as well as limits the scope of VF access to promiscuous mode.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_common.c | 3 +++
drivers/net/ixgbe/ixgbe_sriov.c | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c b/drivers/net/ixgbe/ixgbe_common.c
index d5ede2d..ebbda7d 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1370,6 +1370,9 @@ s32 ixgbe_init_rx_addrs_generic(struct ixgbe_hw *hw)
hw_dbg(hw, " New MAC Addr =%pM\n", hw->mac.addr);
hw->mac.ops.set_rar(hw, 0, hw->mac.addr, 0, IXGBE_RAH_AV);
+
+ /* clear VMDq pool/queue selection for RAR 0 */
+ hw->mac.ops.clear_vmdq(hw, 0, IXGBE_CLEAR_VMDQ_ALL);
}
hw->addr_ctrl.overflow_promisc = 0;
diff --git a/drivers/net/ixgbe/ixgbe_sriov.c b/drivers/net/ixgbe/ixgbe_sriov.c
index 47b1573..187b3a1 100644
--- a/drivers/net/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ixgbe/ixgbe_sriov.c
@@ -110,12 +110,10 @@ static int ixgbe_set_vf_vlan(struct ixgbe_adapter *adapter, int add, int vid,
return adapter->hw.mac.ops.set_vfta(&adapter->hw, vid, vf, (bool)add);
}
-
static void ixgbe_set_vmolr(struct ixgbe_hw *hw, u32 vf, bool aupe)
{
u32 vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
vmolr |= (IXGBE_VMOLR_ROMPE |
- IXGBE_VMOLR_ROPE |
IXGBE_VMOLR_BAM);
if (aupe)
vmolr |= IXGBE_VMOLR_AUPE;
--
1.7.4
^ permalink raw reply related
* [net-2.6 4/7] ixgbe: fix for 82599 erratum on Header Splitting
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, bphilips, stable, Jeff Kirsher
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
We have found a hardware erratum on 82599 hardware that can lead to
unpredictable behavior when Header Splitting mode is enabled. So
we are no longer enabling this feature on affected hardware.
Please see the 82599 Specification Update for more information.
CC: stable@kernel.org
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 44a1cf0..d6c21a3 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -3176,9 +3176,16 @@ static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
u32 mhadd, hlreg0;
/* Decide whether to use packet split mode or not */
+ /* On by default */
+ adapter->flags |= IXGBE_FLAG_RX_PS_ENABLED;
+
/* Do not use packet split if we're in SR-IOV Mode */
- if (!adapter->num_vfs)
- adapter->flags |= IXGBE_FLAG_RX_PS_ENABLED;
+ if (adapter->num_vfs)
+ adapter->flags &= ~IXGBE_FLAG_RX_PS_ENABLED;
+
+ /* Disable packet split due to 82599 erratum #45 */
+ if (hw->mac.type == ixgbe_mac_82599EB)
+ adapter->flags &= ~IXGBE_FLAG_RX_PS_ENABLED;
/* Set the RX buffer length according to the mode */
if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
--
1.7.4
^ permalink raw reply related
* [net-2.6 3/7] ixgbe: fix variable set but not used warnings by gcc 4.6
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Caught with gcc 4.6 -Wunused-but-set-variable
Remove unused napi_vectors variable.
Fix the use of reset_bit in ixgbe_reset_hw_X540()
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 3 ---
drivers/net/ixgbe/ixgbe_x540.c | 6 +++---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 602078b..44a1cf0 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4863,16 +4863,13 @@ static int ixgbe_alloc_q_vectors(struct ixgbe_adapter *adapter)
{
int q_idx, num_q_vectors;
struct ixgbe_q_vector *q_vector;
- int napi_vectors;
int (*poll)(struct napi_struct *, int);
if (adapter->flags & IXGBE_FLAG_MSIX_ENABLED) {
num_q_vectors = adapter->num_msix_vectors - NON_Q_VECTORS;
- napi_vectors = adapter->num_rx_queues;
poll = &ixgbe_clean_rxtx_many;
} else {
num_q_vectors = 1;
- napi_vectors = 1;
poll = &ixgbe_poll;
}
diff --git a/drivers/net/ixgbe/ixgbe_x540.c b/drivers/net/ixgbe/ixgbe_x540.c
index 3a89239..f2518b0 100644
--- a/drivers/net/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ixgbe/ixgbe_x540.c
@@ -133,17 +133,17 @@ static s32 ixgbe_reset_hw_X540(struct ixgbe_hw *hw)
}
ctrl = IXGBE_READ_REG(hw, IXGBE_CTRL);
- IXGBE_WRITE_REG(hw, IXGBE_CTRL, (ctrl | IXGBE_CTRL_RST));
+ IXGBE_WRITE_REG(hw, IXGBE_CTRL, (ctrl | reset_bit));
IXGBE_WRITE_FLUSH(hw);
/* Poll for reset bit to self-clear indicating reset is complete */
for (i = 0; i < 10; i++) {
udelay(1);
ctrl = IXGBE_READ_REG(hw, IXGBE_CTRL);
- if (!(ctrl & IXGBE_CTRL_RST))
+ if (!(ctrl & reset_bit))
break;
}
- if (ctrl & IXGBE_CTRL_RST) {
+ if (ctrl & reset_bit) {
status = IXGBE_ERR_RESET_FAILED;
hw_dbg(hw, "Reset polling failed to complete.\n");
}
--
1.7.4
^ permalink raw reply related
* [net-2.6 2/7] e1000: add support for Marvell Alaska M88E1118R PHY
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem
Cc: Florian Fainelli, netdev, gospo, bphilips, Dirk Brandewie,
Jeff Kirsher
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Florian Fainelli <ffainelli@freebox.fr>
This patch adds support for Marvell Alask M88E188R PHY chips. Support for
other M88* PHYs is already there, so there is nothing more to add than its
PHY id.
CC: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_hw.c | 4 +++-
drivers/net/e1000/e1000_hw.h | 1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index aed223b..7501d97 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -124,6 +124,7 @@ static s32 e1000_set_phy_type(struct e1000_hw *hw)
case M88E1000_I_PHY_ID:
case M88E1011_I_PHY_ID:
case M88E1111_I_PHY_ID:
+ case M88E1118_E_PHY_ID:
hw->phy_type = e1000_phy_m88;
break;
case IGP01E1000_I_PHY_ID:
@@ -3222,7 +3223,8 @@ static s32 e1000_detect_gig_phy(struct e1000_hw *hw)
break;
case e1000_ce4100:
if ((hw->phy_id == RTL8211B_PHY_ID) ||
- (hw->phy_id == RTL8201N_PHY_ID))
+ (hw->phy_id == RTL8201N_PHY_ID) ||
+ (hw->phy_id == M88E1118_E_PHY_ID))
match = true;
break;
case e1000_82541:
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index 196eeda..c70b23d 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -2917,6 +2917,7 @@ struct e1000_host_command_info {
#define M88E1000_14_PHY_ID M88E1000_E_PHY_ID
#define M88E1011_I_REV_4 0x04
#define M88E1111_I_PHY_ID 0x01410CC0
+#define M88E1118_E_PHY_ID 0x01410E40
#define L1LXT971A_PHY_ID 0x001378E0
#define RTL8211B_PHY_ID 0x001CC910
--
1.7.4
^ permalink raw reply related
* [net-2.6 1/7] e1000e: tx_timeout should not increment for non-hang events
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1297158279-20277-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Currently the driver increments the tx_timeout counter (an error counter)
when simply resetting the part with outstanding transmit work pending.
This is an unnecessary count of an error, when all we should be doing is
just resetting the part and discarding the transmits. With this change the
only increment of tx_timeout is when the stack calls the watchdog reset
function due to a true Tx timeout.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 1c18f26..3065870 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4309,7 +4309,6 @@ link_up:
* to get done, so reset controller to flush Tx.
* (Do the reset outside of interrupt context).
*/
- adapter->tx_timeout_count++;
schedule_work(&adapter->reset_task);
/* return immediately since reset is imminent */
return;
--
1.7.4
^ permalink raw reply related
* [net-2.6 0/7][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-02-08 9:44 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
The following series contains the addition of a PHY id for e1000,
fix for e1000e, and several ixgbe fixes.
We are currently still working on the patch:
ixgbe: DDP last buffer size work around
which was in the previous pull request, and has been removed from this
pull request.
The following are changes since commit 429a01a70f301baf0c8fc780f891a18c296d5e24:
Merge branch 'batman-adv/merge' of git://git.open-mesh.org/ecsv/linux-merge
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-2.6 master
Alexander Duyck (1):
ixgbe: limit VF access to network traffic
Don Skidmore (3):
ixgbe: fix for 82599 erratum on Header Splitting
ixgbe: cleanup variable initialization
ixgbe: update version string
Emil Tantilov (1):
ixgbe: fix variable set but not used warnings by gcc 4.6
Florian Fainelli (1):
e1000: add support for Marvell Alaska M88E1118R PHY
Jesse Brandeburg (1):
e1000e: tx_timeout should not increment for non-hang events
drivers/net/e1000/e1000_hw.c | 4 +++-
drivers/net/e1000/e1000_hw.h | 1 +
drivers/net/e1000e/netdev.c | 1 -
drivers/net/ixgbe/ixgbe_common.c | 3 +++
drivers/net/ixgbe/ixgbe_fcoe.c | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 16 ++++++++++------
drivers/net/ixgbe/ixgbe_sriov.c | 2 --
drivers/net/ixgbe/ixgbe_x540.c | 6 +++---
8 files changed, 21 insertions(+), 14 deletions(-)
--
1.7.4
^ permalink raw reply
* 2.6.38-rc3 regression ipv6 TFTP download with curl failing in getpeername?
From: Eric W. Biederman @ 2011-02-08 9:41 UTC (permalink / raw)
To: netdev, linux-kernel
Does anyone have a clue what could be causing this? It looks like
getpeername for ipv6 has changed in the tcp case did udp possibly get
missed?
Currently curl is failing for me like this. When doing a tftp transfer
over ::1.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 200M 0 0 0 570k 0 12.7M 0:00:15 --:--:-- 0:00:15 12.7M
curl: (55) getpeername() failed with errno 107: Transport endpoint is not connected
Tomorrow I will dig deeper but for tonight I wanted to ask and see what
other people see.
Eric
^ permalink raw reply
* [PATCH 3/3] pch_can: fix module reload issue with MSI
From: Tomoya MORINAGA @ 2011-02-08 9:29 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <1297157343-3213-1-git-send-email-tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Currently, in case reload pch_can,
pch_can not to be able to catch interrupt.
The cause is bus-master is not set in pch_can.
Thus, add enabling bus-master processing.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 342d514..7d8bc12 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -1238,6 +1238,7 @@ static int __devinit pch_can_probe(struct pci_dev *pdev,
priv->use_msi = 0;
} else {
netdev_err(ndev, "PCH CAN opened with MSI\n");
+ pci_set_master(pdev);
priv->use_msi = 1;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/3] pch_can: fix rmmod issue
From: Tomoya MORINAGA @ 2011-02-08 9:29 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <1297157343-3213-1-git-send-email-tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Currently, when rmmod pch_can, kernel failure occurs.
The cause is pci_iounmap executed before pch_can_reset.
Thus pci_iounmap moves after pch_can_reset.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 9b171d1..342d514 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -959,13 +959,13 @@ static void __devexit pch_can_remove(struct pci_dev *pdev)
struct pch_can_priv *priv = netdev_priv(ndev);
unregister_candev(priv->ndev);
- pci_iounmap(pdev, priv->regs);
if (priv->use_msi)
pci_disable_msi(priv->dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
pch_can_reset(priv);
+ pci_iounmap(pdev, priv->regs);
free_candev(priv->ndev);
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/3] pch_can: fix 800k comms issue
From: Tomoya MORINAGA @ 2011-02-08 9:29 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Currently, 800k comms fails since prop_seg set zero.
(EG20T PCH CAN register of prop_seg must be set more than 1)
To prevent prop_seg set to zero, change tseg2_min 1 to 2.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index c42e972..9b171d1 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -187,7 +187,7 @@ static struct can_bittiming_const pch_can_bittiming_const = {
.name = KBUILD_MODNAME,
.tseg1_min = 1,
.tseg1_max = 16,
- .tseg2_min = 1,
+ .tseg2_min = 2,
.tseg2_max = 8,
.sjw_max = 4,
.brp_min = 1,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v5 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Bhupesh SHARMA @ 2011-02-08 9:04 UTC (permalink / raw)
To: 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marc Kleine-Budde
Hi Wolfgang,
>> + stats->rx_errors++;
>> + cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
>> + cf->data[2] |= CAN_ERR_PROT_UNSPEC;
>> +
>> + switch (lec_type) {
>> + case LEC_STUFF_ERROR:
>> + netdev_dbg(dev, "stuff error\n");
>> + cf->data[2] |= CAN_ERR_PROT_STUFF;
>> + break;
>> +
>> + case LEC_FORM_ERROR:
>> + netdev_dbg(dev, "form error\n");
>> + cf->data[2] |= CAN_ERR_PROT_FORM;
>> + break;
>> +
>> + case LEC_ACK_ERROR:
>> + netdev_dbg(dev, "ack error\n");
>> + cf->data[2] |= (CAN_ERR_PROT_LOC_ACK |
>> + CAN_ERR_PROT_LOC_ACK_DEL);
>> + break;
>> +
>> + case LEC_BIT1_ERROR:
>> + netdev_dbg(dev, "bit1 error\n");
>> + cf->data[2] |= CAN_ERR_PROT_BIT1;
>> + break;
>> +
>> + case LEC_BIT0_ERROR:
>> + netdev_dbg(dev, "bit0 error\n");
>> + cf->data[2] |= CAN_ERR_PROT_BIT0;
>> + break;
>> +
>> + case LEC_CRC_ERROR:
>> + netdev_dbg(dev, "CRC error\n");
>> + cf->data[2] |= (CAN_ERR_PROT_LOC_CRC_SEQ |
>> + CAN_ERR_PROT_LOC_CRC_DEL);
>> + break;
>> + }
>From the C_CAN manual:
>
>"The LEC field holds a code which indicates the type of the last error
>to occur on the CAN bus. This field will be cleared to '0' when a
>message has been transferred (reception or transmission) without error.
>The unused code '7' may be written by the CPU to check for updates."
>Not sure if it's necessary to reset the lec at init and after an error
>to 0x7 and check it. More below...
I worked on your suggestion and instead found that the follow algo must be used
for reading updated `lec` values:
a. Init lec by 0x07 at start.
b. In function `c_can_err` check if lec is 0x7 (no bus error since this value was
written by CPU on status register) or 0x0 (no error). If so, return without
sending an error frame on stack. Else, check for the lec error type and
submit error frame on stack accordingly.
c. In case a lec error is found and served in `c_can_err` routine, write
lec value to 0x07 again in status reg to check for updated lec later.
This is my understanding after reading the specs time and again and
implementing/testing the logic.
Do you think this is fine or do you have any better approach?
Regards,
Bhupesh
^ permalink raw reply
* Re: [PATCH] GRO: fix merging a paged skb after non-paged skbs
From: Herbert Xu @ 2011-02-08 8:49 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Michal Schmidt, David Miller, netdev, linux-net-drivers
In-Reply-To: <1297111160.4077.14.camel@bwh-desktop>
On Mon, Feb 07, 2011 at 08:39:20PM +0000, Ben Hutchings wrote:
>
> That is indeed the case; commit da3bc07171dff957906cbe2ad5abb443eccf57c4
> made the following deletions:
>
> - /* Both our generic-LRO and SFC-SSR support skb and page based
> - * allocation, but neither support switching from one to the
> - * other on the fly. If we spot that the allocation mode has
> - * changed, then flush the LRO state.
> - */
> - if (unlikely(channel->rx_alloc_pop_pages != (rx_buf->page != NULL))) {
> - efx_flush_lro(channel);
> - channel->rx_alloc_pop_pages = (rx_buf->page != NULL);
> - }
Oops, sorry about that.
How about changing skb_gro_receive to detect such switches and
simply return an error, which should have the same effect as
flushing that flow?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] pch_gbe: Fix the issue that the receiving data is not normal.
From: Toshiharu Okada @ 2011-02-08 8:24 UTC (permalink / raw)
To: ML netdev, David S. Miller
Cc: LKML, Wang, Qi, Wang, Yong Y, Andrew, Intel OTC, Ewe, Kok Howg,
Tomoya Morinaga
Hi Devid
I resubmit this patch modified.
Please check them.
Best regards
Toshiharu Okada(OKI semiconductor)
---
This PCH_GBE driver had an issue that the receiving data is not normal.
This driver had not removed correctly the padding data
which the DMA include in receiving data.
This patch fixed this issue.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe_main.c | 77 +++++++++++++++++++++--------------
1 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 03a1d28..3248313 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -29,6 +29,7 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_SHORT_PKT 64
#define DSC_INIT16 0xC000
#define PCH_GBE_DMA_ALIGN 0
+#define PCH_GBE_DMA_PADDING 2
#define PCH_GBE_WATCHDOG_PERIOD (1 * HZ) /* watchdog time */
#define PCH_GBE_COPYBREAK_DEFAULT 256
#define PCH_GBE_PCI_BAR 1
@@ -1373,7 +1374,7 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int cleaned_count = 0;
bool cleaned = false;
- struct sk_buff *skb;
+ struct sk_buff *skb, *new_skb;
u8 dma_status;
u16 gbec_status;
u32 tcp_ip_status;
@@ -1422,55 +1423,69 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_err("Receive CRC Error\n");
} else {
/* get receive length */
- /* length convert[-3], padding[-2] */
- length = (rx_desc->rx_words_eob) - 3 - 2;
+ /* length convert[-3] */
+ length = (rx_desc->rx_words_eob) - 3;
/* Decide the data conversion method */
if (!adapter->rx_csum) {
/* [Header:14][payload] */
skb_padding_flag = 0;
- skb_copy_flag = 1;
+ if (NET_IP_ALIGN)
+ /* [NET_IP_ALIGN][Header:14][payload] */
+ skb_copy_flag = 1;
+ else
+ skb_copy_flag = 0;
} else {
/* [Header:14][padding:2][payload] */
skb_padding_flag = 1;
+ /* The length includes padding length */
+ length = length - PCH_GBE_DMA_PADDING;
if (length < copybreak)
skb_copy_flag = 1;
- else
- skb_copy_flag = 0;
+ else {
+ /* [Header:14][padding:2][payload]
+ * Chenge to the following
+ * [NET_IP_ALIGN][Header:14][payload] */
+ if (NET_IP_ALIGN == PCH_GBE_DMA_PADDING)
+ skb_copy_flag = 0;
+ else
+ skb_copy_flag = 1;
+ }
}
-
/* Data conversion */
- if (skb_copy_flag) { /* recycle skb */
- struct sk_buff *new_skb;
- new_skb =
- netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (new_skb) {
- if (!skb_padding_flag) {
- skb_reserve(new_skb,
- NET_IP_ALIGN);
- }
- memcpy(new_skb->data, skb->data,
- length);
- /* save the skb
- * in buffer_info as good */
- skb = new_skb;
- } else if (!skb_padding_flag) {
+ if (skb_copy_flag) {
+ new_skb = netdev_alloc_skb(netdev,
+ length + NET_IP_ALIGN);
+ if (!new_skb) {
/* dorrop error */
pr_err("New skb allocation Error\n");
goto dorrop;
}
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ if (skb_padding_flag) {
+ memcpy(new_skb->data, skb->data,
+ ETH_HLEN);
+ memcpy(&new_skb->data[ETH_HLEN],
+ &skb->data[ETH_HLEN +
+ PCH_GBE_DMA_PADDING],
+ length - ETH_HLEN);
+ } else {
+ memcpy(new_skb->data, skb->data,
+ length);
+ }
+ skb = new_skb;
} else {
+ if (skb_padding_flag) {
+ memcpy(&tmp_packet[0], &skb->data[0],
+ ETH_HLEN);
+ memcpy(&skb->data[PCH_GBE_DMA_PADDING],
+ &tmp_packet[0], ETH_HLEN);
+ skb_reserve(skb, PCH_GBE_DMA_PADDING);
+ }
buffer_info->skb = NULL;
}
- if (skb_padding_flag) {
- memcpy(&tmp_packet[0], &skb->data[0], ETH_HLEN);
- memcpy(&skb->data[NET_IP_ALIGN], &tmp_packet[0],
- ETH_HLEN);
- skb_reserve(skb, NET_IP_ALIGN);
-
- }
-
+ /* The length includes FCS length */
+ length = length - ETH_FCS_LEN;
/* update status of driver */
adapter->stats.rx_bytes += length;
adapter->stats.rx_packets++;
--
1.6.2.5
^ permalink raw reply related
* Re: About bittiming calculation result
From: Wolfgang Grandegger @ 2011-02-08 7:57 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <93C12206407640199DCDD3A89A333F13-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
Hi Tomoya,
On 02/08/2011 02:27 AM, Tomoya MORINAGA wrote:
> On Tuesday, February 08, 2011 12:53 AM, Wolfgang Grandegger wrote:
>
>> BTW, it's always possible to specify optimized bit-timing
>> parameters directly, e.g. the following seem better:
>>
>> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>>
>> You could set these with:
>>
>> $ ip link set can0 type can \
>> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
>
> I can confirm 800K comms works well using the above.
Cool, I got these magic values from a CAN hardware expert.
> I wish Can-core could calculate like above.
Me too! I also got some indication on how to improve our algorithm in
case the bit-rate does not match. Hope to find some time soon to work
on this issue.
>>> seg1/seg2/sjw/prop_seg must be more than 1 ?
> BTW, according to EG20T PCH data sheet,
> CAN bit-timing parameters(BRP, Prop_Seg, Phase_Seg1, Phase_Seg2, SJW) must not be set 0.
OK, then please provide a patch setting tseg1_min to 2.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] usb: gadget: nokia: disallow compilation with HIGHMEM
From: Rémi Denis-Courmont @ 2011-02-08 7:39 UTC (permalink / raw)
To: ext-eero.nurkkala; +Cc: linux-usb, dbrownell, netdev
In-Reply-To: <1297150245-31696-1-git-send-email-ext-eero.nurkkala@nokia.com>
On Tuesday 08 February 2011 09:30:45 ext-eero.nurkkala@nokia.com, you wrote:
> From: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
>
> With HIGHMEM, g_phonet oopses with the following path:
> pn_rx_complete() -> pskb_pull() -> ... kmap_skb_frag() and
> oops with BUG_ON(in_irq()). Thus, if the gadget is enabled,
> it'd better conflict with the HIGHMEM.
>
> Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
In the long run, we should probably kludge the skb code like we did in
cdc-phonet.c.
Or better yet, fix kmap_skb_frag() to be less pessimistic. Thing is, the BUG_ON
is really bogus here. The way we allocated the skb, the fragment really cannot
be in HIGHMEM...
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 4:11 UTC (permalink / raw)
To: 'Bhupesh SHARMA', 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <D5ECB3C7A6F99444980976A8C6D896384DEE2BE1A7-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
Hi Bhupesh,
On Tuesday, February 08, 2011 12:30 PM, Bhupesh SHARMA wrote:
> AFAIK pch uses the Bosch C_CAN core internally.
> As per Bosch C_CAN user manual tseg1= prop_seg + phase_seg1
> So, ideally tseg1_min should be 2. My version of Bosch C_CAN
> driver Uses the value 2.
Thank you for your suggestions.
I will submit the patch.
With Best Regards,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: pull request: batman-adv 2011-02-08
From: David Miller @ 2011-02-08 3:55 UTC (permalink / raw)
To: sven; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1297123161-25612-1-git-send-email-sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Tue, 8 Feb 2011 00:59:20 +0100
> I would like to propose following patch for net-2.6.git/2.6.38 which fixes a
> possible kernel oops in the unicast fragmentation code.
...
> The following changes since commit 1181e1daace88018b2ff66592aa10a4791d705ff:
>
> batman-adv: Make vis info stack traversal threadsafe (2011-01-30 10:32:08 +0100)
>
> are available in the git repository at:
> git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge
Pulled, thanks.
^ permalink raw reply
* RE: About bittiming calculation result
From: Bhupesh SHARMA @ 2011-02-08 3:29 UTC (permalink / raw)
To: Tomoya MORINAGA, 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <E2BAACFF191C4175854E6B2EB9135BE5-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
Hi Tomoya,
> -----Original Message-----
> From: socketcan-core-bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org [mailto:socketcan-core-
> bounces-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org] On Behalf Of Tomoya MORINAGA
> Sent: Tuesday, February 08, 2011 6:40 AM
> To: 'Wolfgang Grandegger'
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: About bittiming calculation result
>
> On Monday, February 07, 2011 9:01 PM, Wolfgang Grandegger wrote
> >
> > Well, only prop_seg+phase_seg=tseg1 is relevant and the
> > pch_can driver sets the allowed minimum "tseg1_min1" currently to 1:
> >
> > static struct can_bittiming_const pch_can_bittiming_const = {
> > .name = KBUILD_MODNAME,
> > .tseg1_min = 1,
> > .tseg1_max = 16,
> > .tseg2_min = 1,
> > .tseg2_max = 8,
> > .sjw_max = 4,
> > .brp_min = 1,
> > .brp_max = 1024, /* 6bit + extended 4bit */
> > .brp_inc = 1,
> > };
> >
> > > seg1/seg2/sjw/prop_seg must be more than 1 ?
> >
> > Then "tseg1_min" should be set to *2*.
>
> Though some drivers accepted by upstream have parameter "tseg1_min" as
> 1,
> Sould we release the patch like below ?
> - .tseg1_min = 1,
> + .tseg1_min = 2,
>
AFAIK pch uses the Bosch C_CAN core internally.
As per Bosch C_CAN user manual tseg1= prop_seg + phase_seg1
So, ideally tseg1_min should be 2. My version of Bosch C_CAN driver
Uses the value 2.
Regards,
Bhupesh
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Jesse Gross @ 2011-02-08 2:24 UTC (permalink / raw)
To: chriss; +Cc: netdev
In-Reply-To: <loom.20110206T203347-475@post.gmane.org>
On Sun, Feb 6, 2011 at 11:37 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Jesse Gross <jesse <at> nicira.com> writes:
>
>>
>> You should either attached a bridge to a vlan device or stack a vlan
>> device on the bridge port depending on what you are trying to achieve.
>>
>> The bridge handler takes all packets of the device that it is attached
>> to, so having a vlan also attached to the same device will not work.
>> You may get different results on older kernels depending on what NIC
>> you were using but that was a bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo <at> vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> Hi and thanks for your reply
>
> I tried that.
>
> I had under 2.6.36.3 following combination:
>
> eth1 in br0 -> all traffic without vlan id
> eth1.3 -> traffic with vlan 3
>
> with 2.6.37 i should do the following
> eth1 in br0 -> traffic w/o vlans
> and br0.3 -> traffic with vlan id 3
>
> But still there is no rx for vlan 3.
> Any suggestions? Or am i missing something?
That configuration should work (and I've tested it in the past). I
would try running tcpdump on the various interfaces in the path (eth1,
br0, br0.3) to see where traffic is flowing or not.
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 1:27 UTC (permalink / raw)
To: 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D501555.5000905-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Tuesday, February 08, 2011 12:53 AM, Wolfgang Grandegger wrote:
> BTW, it's always possible to specify optimized bit-timing
> parameters directly, e.g. the following seem better:
>
> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>
> You could set these with:
>
> $ ip link set can0 type can \
> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
I can confirm 800K comms works well using the above.
I wish Can-core could calculate like above.
>> seg1/seg2/sjw/prop_seg must be more than 1 ?
BTW, according to EG20T PCH data sheet,
CAN bit-timing parameters(BRP, Prop_Seg, Phase_Seg1, Phase_Seg2, SJW) must not be set 0.
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
> -----Original Message-----
> From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
> Sent: Tuesday, February 08, 2011 12:53 AM
> To: Tomoya MORINAGA
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: About bittiming calculation result
>
> On 02/07/2011 01:00 PM, Wolfgang Grandegger wrote:
> > Hi Tomoya,
> >
> > On 02/07/2011 12:38 PM, Tomoya MORINAGA wrote:
> >> Hi,
> >>
> >> I have a question for bittiming-value calculated by Can-core.
> >>
> >> In case setting like below,
> >> - ip link set can0 type can bitrate 800000
> >> - clock=50MHz
> >> - Use pch_can
> >>
> >> Can-core calculates like below
> >> brp=21
> >> seg1=1
> >> seg2=1
> >> sjw=1
> >> prop_seg=0
> >>
> >> Is "prop_seg=0" true ?
> >
> > Well, only prop_seg+phase_seg=tseg1 is relevant and the
> pch_can driver
> > sets the allowed minimum "tseg1_min1" currently to 1:
> >
> > static struct can_bittiming_const pch_can_bittiming_const = {
> > .name = KBUILD_MODNAME,
> > .tseg1_min = 1,
> > .tseg1_max = 16,
> > .tseg2_min = 1,
> > .tseg2_max = 8,
> > .sjw_max = 4,
> > .brp_min = 1,
> > .brp_max = 1024, /* 6bit + extended 4bit */
> > .brp_inc = 1,
> > };
> >
> >> seg1/seg2/sjw/prop_seg must be more than 1 ?
> >
> > Then "tseg1_min" should be set to *2*.
> >
> >> Also I can see the following kernel error log.
> >> bitrate error 0.7%
> >
> > A clock frequency of 50 MHz is sub-optimal for CAN and some
> bit-rates
> > cannot be reproduced properly. Here is the output of the can-utils
> > program "can-calc-bit-timing" (with an entry for the pch-can added):
> >
> > $ ./can-calc-bit-timing pch-can
> > Bit timing parameters for pch-can with 50.000000 MHz ref clock
> > nominal real Bitrt nom real SampP
> > Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP
> SampP Error CNF1 CNF2 CNF3
> > 1000000 100 3 3 3 1 5 1000000 0.0% 75.0%
> 70.0% 6.7% 0x05 0x92 0x02
> > 800000 420 0 1 1 1 21 793650 0.8% 80.0%
> 66.6% 16.8% 0x15 0xff 0x00
> > 500000 100 8 8 3 1 5 500000 0.0% 87.5%
> 85.0% 2.9% 0x05 0xbf 0x02
> > 250000 500 3 3 1 1 25 250000 0.0% 87.5%
> 87.5% 0.0% 0x19 0x92 0x00
> > 125000 500 6 7 2 1 25 125000 0.0% 87.5%
> 87.5% 0.0% 0x19 0xb5 0x01
> > 100000 500 8 8 3 1 25 100000 0.0% 87.5%
> 85.0% 2.9% 0x19 0xbf 0x02
> > 50000 2500 3 3 1 1 125 50000 0.0% 87.5%
> 87.5% 0.0% 0x7d 0x92 0x00
> > 20000 2500 8 8 3 1 125 20000 0.0% 87.5%
> 85.0% 2.9% 0x7d 0xbf 0x02
> > 10000 12500 3 3 1 1 625 10000 0.0% 87.5%
> 87.5% 0.0% 0x71 0x92 0x00
> >
> > As you can see, especially 800000 gives rather bad results.
>
> BTW, it's always possible to specify optimized bit-timing
> parameters directly, e.g. the following seem better:
>
> 800000 60 12 4 4 4 3 793650 0.8% 80.0% 81.0% 1.2%
>
> You could set these with:
>
> $ ip link set can0 type can \
> tq 60 prop-seg 12 phase-seg1 4 phase-seg2 4 sjw 4
>
> Wolfgang.
>
^ permalink raw reply
* compat-wireless for 2.6.38-rc3 - third release
From: Luis R. Rodriguez @ 2011-02-08 1:10 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, netdev; +Cc: linux-kernel
I updated compat-wireless for 2.6.38-rc3, this is the third update, it
should now include the proper compat.git branch and also adds some new
patches from Hauke to minimize deltas and fix compilation. While at it
I took the time to suck in new pending-stable patches for an "-s"
release, I haven't cherry picked any patches yet as I cannot think of
anything immediately important, if you do send me a patch.
Code metrics for the vanilla release:
782535 - Total upstream lines of code being pulled
2108 - backport code changes
1847 - backport code additions
261 - backport code deletions
7292 - backport from compat module
9400 - total backport code
1.2012 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.38-rc3
compat-wireless release: compat-wireless-v2.6.38-rc3-3
Code metrics for the "-s" release:
782535 - Total upstream lines of code being pulled
2108 - backport code changes
1847 - backport code additions
261 - backport code deletions
7292 - backport from compat module
9400 - total backport code
1.2012 - % of code consists of backport work
115 - Code changes brought in from pending-stable
57 - Code additions brought in from pending-stable
58 - Code deletions brought in from pending-stable
0.0147 - % of code being cherry picked from pending-stable
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.38-rc3
compat-wireless release: compat-wireless-v2.6.38-rc3-3-s
Relevant URLs:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/compat-wireless-2.6.38-rc3-3.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/compat-wireless-2.6.38-rc3-3-s.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.38/ChangeLog-2.6.38-wireless
http://wireless.kernel.org/en/users/Download/stable
Luis
^ permalink raw reply
* RE: About bittiming calculation result
From: Tomoya MORINAGA @ 2011-02-08 1:09 UTC (permalink / raw)
To: 'Wolfgang Grandegger'
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D4FDEF9.2030305-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Monday, February 07, 2011 9:01 PM, Wolfgang Grandegger wrote
>
> Well, only prop_seg+phase_seg=tseg1 is relevant and the
> pch_can driver sets the allowed minimum "tseg1_min1" currently to 1:
>
> static struct can_bittiming_const pch_can_bittiming_const = {
> .name = KBUILD_MODNAME,
> .tseg1_min = 1,
> .tseg1_max = 16,
> .tseg2_min = 1,
> .tseg2_max = 8,
> .sjw_max = 4,
> .brp_min = 1,
> .brp_max = 1024, /* 6bit + extended 4bit */
> .brp_inc = 1,
> };
>
> > seg1/seg2/sjw/prop_seg must be more than 1 ?
>
> Then "tseg1_min" should be set to *2*.
Though some drivers accepted by upstream have parameter "tseg1_min" as 1,
Sould we release the patch like below ?
- .tseg1_min = 1,
+ .tseg1_min = 2,
Thanks,
-----------------------------------------
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28542] New: 3c59x.c: Regression since 2.6.36 (incl.), for e. g., TCP stalls on receive
From: Ben Hutchings @ 2011-02-08 0:39 UTC (permalink / raw)
To: for.poige+bugzilla.kernel.org
Cc: netdev, bugzilla-daemon, bugme-daemon, Jan Beulich, Neil Horman,
Steffen Klassert, Andrew Morton
In-Reply-To: <20110207150919.cd253b97.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Mon, 2011-02-07 at 15:09 -0800, Andrew Morton wrote:
> On Mon, 7 Feb 2011 18:55:29 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
[...]
> > Dump of kernel source bz2 download being stalled:
> > http://poige.livejournal.com/475372.html#cutid1 (see the bunch of ACKs
> > #5555523).
That's not a stall, that's selective-ACKing (see the ranges listed on
the right of each ACK line).
> > As a workaround I've just replaced drivers/net/3c59x.c with its former
> > (2.6.35.11) version, the connectivity problems are gone now.
This could just be a coincidence. But it could be that packet loss is
now more likely for some reason. Does the rx_fifo_errors statistic
increase quickly with the later version of the driver? (This seems to
be the only receive error type reported.)
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Send-to-self TCP connection hangs in 2.6.38-rc3.
From: Ben Greear @ 2011-02-08 0:34 UTC (permalink / raw)
To: netdev
I'm seeing something weird on the latest wireless-testing kernel
(I have some wifi hacks in here, but no modifications to the basic
networking system, no proprietary modules loaded.)
Wireless-testing is currently based on 2.6.38-rc3.
This has been happening for a while, but I'm not sure
exactly when it started.
I am sending-to-self across some virtual wifi stations. UDP runs fine,
but TCP connections tend to hang after a while..often in only one
direction.
The ip rules seem right, I'm detecting no spurious link admin up/down. I suspect
conn-tracking. Notice that the dport and sport do not match the netstat output
in the entry marked 'UNREPLIED'. What sort of thing could cause that?
Here's some conntrack output for a broken connection:
ipv4 2 tcp 6 299 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0
zone=0 use=2
ipv4 2 tcp 6 431687 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194
mark=0 zone=0 use=2
ipv4 2 udp 17 179 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2
The 33.1.2.32 side seems unable to send to the peer, though the peer can send to .32
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp 0 0 33.1.2.32:33382 0.0.0.0:* LISTEN
tcp 0 5852 33.1.2.32:33382 33.1.2.35:33381 ESTABLISHED
tcp 0 0 33.1.2.35:33381 33.1.2.32:33382 ESTABLISHED
udp 0 0 33.1.2.32:33382 0.0.0.0:*
udp 0 0 33.1.2.32:123 0.0.0.0:*
Here's the same connection after re-starting it. It appears to be passing traffic
properly.
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.32
tcp 0 0 33.1.2.32:33480 0.0.0.0:* LISTEN
tcp 0 0 33.1.2.35:33479 33.1.2.32:33480 ESTABLISHED
tcp 0 0 33.1.2.32:33480 33.1.2.35:33479 ESTABLISHED
udp 0 0 33.1.2.32:123 0.0.0.0:*
udp 0 0 33.1.2.32:33484 0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.32
ipv4 2 udp 17 179 src=33.1.2.35 dst=33.1.2.32 sport=33483 dport=33484 src=33.1.2.32 dst=33.1.2.35 sport=33484 dport=33483 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 430352 ESTABLISHED src=33.1.2.32 dst=33.1.2.35 sport=33194 dport=33193 [UNREPLIED] src=33.1.2.35 dst=33.1.2.32 sport=33193 dport=33194
mark=0 zone=0 use=2
ipv4 2 udp 17 161 src=33.1.2.35 dst=33.1.2.32 sport=33381 dport=33382 src=33.1.2.32 dst=33.1.2.35 sport=33382 dport=33381 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 431999 ESTABLISHED src=33.1.2.35 dst=33.1.2.32 sport=33479 dport=33480 src=33.1.2.32 dst=33.1.2.35 sport=33480 dport=33479 [ASSURED]
mark=0 zone=0 use=2
Here's a connection that had been running for several minutes and seems
to have been passing traffic fine. I'm not sure about what the
CLOSE_WAIT thing is...
[root@lec2010-ath9k-1 lanforge]# netstat -an|grep 1.2.20
tcp 0 0 33.1.2.18:33362 33.1.2.20:33361 ESTABLISHED
tcp 1 0 33.1.2.18:33202 33.1.2.20:33201 CLOSE_WAIT
tcp 0 0 33.1.2.20:33361 33.1.2.18:33362 ESTABLISHED
udp 0 0 33.1.2.20:33361 0.0.0.0:*
udp 0 0 33.1.2.20:123 0.0.0.0:*
[root@lec2010-ath9k-1 lanforge]# cat /proc/net/nf_conntrack|grep 1.2.20
ipv4 2 tcp 6 431999 ESTABLISHED src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED]
mark=0 zone=0 use=2
ipv4 2 udp 17 178 src=33.1.2.20 dst=33.1.2.18 sport=33361 dport=33362 src=33.1.2.18 dst=33.1.2.20 sport=33362 dport=33361 [ASSURED] mark=0 zone=0 use=2
I'll be happy to provide more details..just ask.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] tcp: undo_retrans counter fixes
From: Yuchung Cheng @ 2011-02-08 0:22 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev
In-Reply-To: <alpine.DEB.2.00.1102080112450.29228@melkinpaasi.cs.helsinki.fi>
On Mon, Feb 7, 2011 at 3:36 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
>
> On Mon, 7 Feb 2011, David Miller wrote:
>
> > From: Yuchung Cheng <ycheng@google.com>
> > Date: Mon, 7 Feb 2011 14:57:04 -0800
> >
> > > Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> > > not set or undo_retrans is already 0. This happens when sender receives
> > > more DSACK ACKs than packets retransmitted during the current
> > > undo phase. This may also happen when sender receives DSACK after
> > > the undo operation is completed or cancelled.
> > >
> > > Fix another bug that undo_retrans is incorrectly incremented when
> > > sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> > > is rare but not impossible.
> > >
> > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> >
> > Looks good, Ilpo could you please review this real quick?
>
> I already too a quick look so you're real lucky, only delay of writing is
> needed... :-)
thanks.
>
> Neither is harmful to "fix" but I think they're partially also checking
> for things which shouldn't cause problems... E.g., undo_retrans is only
> used after checking undo_marker's validity first so I don't think
> undo_marker check is exactly necessary there (but on the other hand it
> does no harm)...
logically we should check the validity of undo_marker/undo_retrans
before we use them? The current code has no problem if
tcp_fastretrans_alert() always call tcp_try_undo_* functions whenever
undo_marker != 0 and undo_retrans == 0. I don't think that's always
true.
>
> The tcp_retransmit_skb problem I don't understand at all as we should be
> fragmenting or resetting pcount to 1 (the latter is true only if all
> bugfixes were included to the kernel where >1 pcount for a rexmitted skb
> was seen). If pcount is indeed >1 we might have other issues too somewhere
We found that sometimes pcount > 1 on real servers. This change keeps
the retrans_out/undo_retrans counters consistent.
> but I fail to remember immediately what they would be. That change is not
> bad though since using +/-1 is something we should be getting rid of
> anyway and on long term it would be nice to make tcp_retransmit_skb to be
> able to take advantage of TSO anyway whenever possible.
>
> I also noticed that the undo_retrans code in sacktag side is still doing
> undo_retrans-- ops which could certainly cause real miscounts, though
> it is extremely unlikely due to the fact that DSACK should be sent
> immediately for a single segment at a time (so the sender would need to
> split+recollapse in between).
I have the same doubt but our servers never hit this condition (pcount
> 1). So I keep this part intact.
>
> --
> i.
^ 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