The commit 2800209994f8 (e1000e: Refactor PM flows) changed the
SET_SYSTEM_SLEEP_PM_OPS to open-coded assignment, but forgot to
protect them with CONFIG_PM_SLEEP. Then cause the following build
error when PM is disabled:
drivers/net/ethernet/intel/e1000e/netdev.c:7079:13:
error:
On Thu, Mar 13, 2014 at 03:32:48PM -0400, Valdis Kletnieks wrote:
My kernel has CONFIG_PM_SLEEP=n, which leads to hilarity...
CC drivers/net/ethernet/intel/e1000e/netdev.o
drivers/net/ethernet/intel/e1000e/netdev.c:7079:13: error:
'e1000e_pm_suspend' undeclared here (not in a
On Fri, 2014-03-14 at 14:57 +0800, Kevin Hao wrote:
The commit 2800209994f8 (e1000e: Refactor PM flows) changed the
SET_SYSTEM_SLEEP_PM_OPS to open-coded assignment, but forgot to
protect them with CONFIG_PM_SLEEP. Then cause the following build
error when PM is disabled:
Hi Emli,
With your patch issue is now resolved, I can receive VLAN tagged packets.
Thanks a lot for your support.
Thanks Regards
Vijay Agrawal
-Original Message-
From: Tantilov, Emil S [mailto:emil.s.tanti...@intel.com]
Sent: 08 March 2014 06:53
To: Vijay Agrawal; Fujinaka, Todd;
Hi
We are using a i210 in flashless mode, programming the iNVM seems to have
worked but when igb is loaded, it reports a checksum error.
[6.883496] Intel(R) Gigabit Ethernet Network Driver - version 5.0.6
[6.883510] Copyright (c) 2007-2013 Intel Corporation.
[6.883716] igb
There should be a doc file with the flashless update that you should follow.
What is the version of eeupdate you are running? And is there a reason you're
running an older version of igb? Can you try the newest version on
e1000.sourceforge.net? igb-5.1.2 changed some of the features for
Hi Todd
The only doc I have is Programming iNVM in I211_rev1.0.pdf (seems to apply
also for i210 flashless devices). The instructions there are rather scarce.
The eeupdate version is:
Using: Intel (R) PRO Network Connections SDK v2.22.14
EEUPDATE v5.22.14.00
I am using igb version 5.0.6
This series is mostly about fixing two things:
- when user space request both SW and HW time stamps
only one of them should be generated (SW is fallback
to HW). Intel drivers would report two time stamps
per packet which may be confusing to user space app;
- all(?) Intel drivers have
tx_hwtstamp_skb is always set before work is scheduled,
work is cancelled before tx_hwtstamp_skb is set to NULL.
PTP work cannot ever see tx_hwtstamp_skb set to NULL.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/net/ethernet/intel/e1000e/netdev.c | 3 ---
1 file changed, 3
igb has a single set of TX time stamping resources per NIC.
Use a simple bit lock to avoid race conditions and leaking skbs
when multiple TX rings try to claim time stamping.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/net/ethernet/intel/igb/igb.h | 3 ++-
skb_tx_timestamp() does not report software time stamp
if SKBTX_IN_PROGRESS is set. According to timestamping.txt
software time stamps are a fallback and should not be
generated if hardware time stamp is provided.
Move call to skb_tx_timestamp() after setting
SKBTX_IN_PROGRESS.
Signed-off-by:
Hardware may fail to report time stamp e.g.:
- when hardware time stamping is not enabled
- when time stamp is requested shortly after ifup
Timeout time stamp reading work to prevent it from
scheduling itself indefinitely. Report timeout events
via system log and device stats.
Signed-off-by:
Since cd4d8fdad1f1 dev_hard_start_xmit() will not provide
software timestamps. It's a responsibility of the drivers
to call skb_tx_timestamp() at the right time.
Cc: linux-...@vger.kernel.org
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
Documentation/networking/timestamping.txt | 6 +++---
1
skb_tx_timestamp() does not report software time stamp
if SKBTX_IN_PROGRESS is set. According to timestamping.txt
software time stamps are a fallback and should not be
generated if hardware time stamp is provided.
Move call to skb_tx_timestamp() after setting
SKBTX_IN_PROGRESS.
Signed-off-by:
ptp_tx_skb is always set before work is scheduled,
work is cancelled before ptp_tx_skb is set to NULL.
PTP work cannot ever see ptp_tx_skb set to NULL.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 4
1 file changed, 4 deletions(-)
diff
skb_tx_timestamp() does not report software time stamp
if SKBTX_IN_PROGRESS is set. According to timestamping.txt
software time stamps are a fallback and should not be
generated if hardware time stamp is provided.
Move call to skb_tx_timestamp() after setting
SKBTX_IN_PROGRESS.
Signed-off-by:
ixgbe has a single set of TX time stamping resources per NIC.
Use a simple bit lock to avoid race conditions and leaking skbs
when multiple TX rings try to claim time stamping.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
Hardware may fail to report time stamp e.g.:
- when hardware time stamping is not enabled
- when time stamp is requested shortly after ifup
trivia:
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
Hello.
On 03/14/2014 08:34 PM, Jakub Kicinski wrote:
Since cd4d8fdad1f1 dev_hard_start_xmit() will not provide
Please also specify that commit's summary line in parens.
software timestamps. It's a responsibility of the drivers
to call skb_tx_timestamp() at the right time.
Cc:
On Fri, 2014-03-14 at 19:02 +0100, Jakub Kiciński wrote:
On Fri, 14 Mar 2014 10:48:37 -0700, Joe Perches wrote:
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
Hardware may fail to report time stamp e.g.:
- when hardware time stamping is not enabled
- when time stamp is
On Fri, 14 Mar 2014 11:44:15 -0700, Joe Perches wrote:
On Fri, 2014-03-14 at 19:02 +0100, Jakub Kiciński wrote:
On Fri, 14 Mar 2014 10:48:37 -0700, Joe Perches wrote:
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
Hardware may fail to report time stamp e.g.:
- when
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
skb_tx_timestamp() does not report software time stamp
if SKBTX_IN_PROGRESS is set. According to timestamping.txt
software time stamps are a fallback and should not be
generated if hardware time stamp is provided.
Move call to
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
ptp_tx_skb is always set before work is scheduled,
work is cancelled before ptp_tx_skb is set to NULL.
PTP work cannot ever see ptp_tx_skb set to NULL.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
tx_hwtstamp_skb is always set before work is scheduled,
work is cancelled before tx_hwtstamp_skb is set to NULL.
PTP work cannot ever see tx_hwtstamp_skb set to NULL.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
ixgbe has a single set of TX time stamping resources per NIC.
Use a simple bit lock to avoid race conditions and leaking skbs
when multiple TX rings try to claim time stamping.
Signed-off-by: Jakub Kicinski kubak...@wp.pl
---
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
Hardware may fail to report time stamp e.g.:
- when hardware time stamping is not enabled
- when time stamp is requested shortly after ifup
Timeout time stamp reading work to prevent it from
scheduling itself indefinitely. Report
On Fri, 2014-03-14 at 18:34 +0100, Jakub Kicinski wrote:
skb_tx_timestamp() does not report software time stamp
if SKBTX_IN_PROGRESS is set. According to timestamping.txt
software time stamps are a fallback and should not be
generated if hardware time stamp is provided.
Move call to
27 matches
Mail list logo
