Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,
> > > > The issue is not the firmware. The issue is that the Linux uio
> > > > driver
> > > > (here: uio_cif) does not work as uio_mmap() -> uio_mmap_physical()
> > > > does not do a mmap on physical memory that is not page aligned...
> > >
> > > Then why not fix the uio_cif driver?
> > The fix might be in uio and not in uio_cif. However
> > uio_mmap_physical() in uio.c has introduced checks to reject non page-
> aligned addresses.
> 
> Yes, because we had real problems with that in the past.
> 
> > These checks have been introduced somewhere in between kernel V3.2 and
> kernel V3.18.
> > Removing these checks again does not sound to me like a good idea...
> 
> I agree, you should fix your hardware :)
> 
> > The overall question is now if the UIO system is working at all with
> > non page aligned PCI memory resources. For me it looks as if this is not the
> case.
> 
> How is your system ending up with such alignment in the first place?
> What is the resource list after booting?
Here is the resource list of the relevant PCI board. The first memory resource 
has a size of 128k and is not page aligned.

0f:05.0 Bridge: PLX Technology, Inc. PCI9030 32-bit 33MHz PCI <-> IOBus Bridge 
(rev 01)
Subsystem: PLX Technology, Inc. Hilscher CIF50-PB/DPS Profibus
Flags: medium devsel, IRQ 23
Memory at eae4f400 (32-bit, non-prefetchable) [size=128]
I/O ports at 9800 [size=128]
Memory at eae4c000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 1
Capabilities: [48] CompactPCI hot-swap 
Capabilities: [4c] Vital Product Data
Kernel driver in use: hilscher

Regards

Mathias

Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,
> > > > The issue is not the firmware. The issue is that the Linux uio
> > > > driver
> > > > (here: uio_cif) does not work as uio_mmap() -> uio_mmap_physical()
> > > > does not do a mmap on physical memory that is not page aligned...
> > >
> > > Then why not fix the uio_cif driver?
> > The fix might be in uio and not in uio_cif. However
> > uio_mmap_physical() in uio.c has introduced checks to reject non page-
> aligned addresses.
> 
> Yes, because we had real problems with that in the past.
> 
> > These checks have been introduced somewhere in between kernel V3.2 and
> kernel V3.18.
> > Removing these checks again does not sound to me like a good idea...
> 
> I agree, you should fix your hardware :)
> 
> > The overall question is now if the UIO system is working at all with
> > non page aligned PCI memory resources. For me it looks as if this is not the
> case.
> 
> How is your system ending up with such alignment in the first place?
> What is the resource list after booting?
Here is the resource list of the relevant PCI board. The first memory resource 
has a size of 128k and is not page aligned.

0f:05.0 Bridge: PLX Technology, Inc. PCI9030 32-bit 33MHz PCI <-> IOBus Bridge 
(rev 01)
Subsystem: PLX Technology, Inc. Hilscher CIF50-PB/DPS Profibus
Flags: medium devsel, IRQ 23
Memory at eae4f400 (32-bit, non-prefetchable) [size=128]
I/O ports at 9800 [size=128]
Memory at eae4c000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 1
Capabilities: [48] CompactPCI hot-swap 
Capabilities: [4c] Vital Product Data
Kernel driver in use: hilscher

Regards

Mathias

Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,
> > thanks for the response.
> > > > Some uio based PCI drivers (e.g. uio_cif) do not work if the
> > > > assigned PCI memory resources are not page aligned.
> > > > By using the kernel option "pci=resource_alignment" it is possible
> > > > to force single PCI boards to use page alignment for their memory
> resources.
> > > > However, this is fairly cumbersome if multiple of these cards are in 
> > > > use.
> > > > This patch adds another kernel option "pci=resources_page_aligned"
> > > > that allows to set the default alignment of PCI memory resources
> > > > to be page aligned.
> > > > Overwriting of this default alignment via "pci=resource_alignment"
> > > > is still possible.
> > >
> > > This seems like a very large hammer for a very specific problem with
> > > a card that seems to be not-in-spec (I can't find anywhere that
> > > requires resources to be "page" aligned in the PCI spec).  Why not fix the
> firmware in these cards?
> > The issue is not the firmware. The issue is that the Linux uio driver
> > (here: uio_cif) does not work as uio_mmap() -> uio_mmap_physical()
> > does not do a mmap on physical memory that is not page aligned...
> 
> Then why not fix the uio_cif driver?
The fix might be in uio and not in uio_cif. However uio_mmap_physical() in
uio.c has introduced checks to reject non page-aligned addresses.
These checks have been introduced somewhere in between kernel V3.2 and kernel 
V3.18. 
Removing these checks again does not sound to me like a good idea...
The overall question is now if the UIO system is working at all with non page 
aligned PCI memory resources. For me it looks as if this is not the case.
E.g. with the boards supported with the uio_cif driver, the memory resource 2 
of the
PCI device is a 128 byte memory. And exactly this memory has to be mmaped by the
driver and this fails.
As the uio driver do (no longer) work with non page aligned PCI memory 
resources,
the conclusion for me is to force the relevant PCI memory resources to be page 
aligned.
And that's why the patch might be used for.

Regards

Mathias

Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,
> > thanks for the response.
> > > > Some uio based PCI drivers (e.g. uio_cif) do not work if the
> > > > assigned PCI memory resources are not page aligned.
> > > > By using the kernel option "pci=resource_alignment" it is possible
> > > > to force single PCI boards to use page alignment for their memory
> resources.
> > > > However, this is fairly cumbersome if multiple of these cards are in 
> > > > use.
> > > > This patch adds another kernel option "pci=resources_page_aligned"
> > > > that allows to set the default alignment of PCI memory resources
> > > > to be page aligned.
> > > > Overwriting of this default alignment via "pci=resource_alignment"
> > > > is still possible.
> > >
> > > This seems like a very large hammer for a very specific problem with
> > > a card that seems to be not-in-spec (I can't find anywhere that
> > > requires resources to be "page" aligned in the PCI spec).  Why not fix the
> firmware in these cards?
> > The issue is not the firmware. The issue is that the Linux uio driver
> > (here: uio_cif) does not work as uio_mmap() -> uio_mmap_physical()
> > does not do a mmap on physical memory that is not page aligned...
> 
> Then why not fix the uio_cif driver?
The fix might be in uio and not in uio_cif. However uio_mmap_physical() in
uio.c has introduced checks to reject non page-aligned addresses.
These checks have been introduced somewhere in between kernel V3.2 and kernel 
V3.18. 
Removing these checks again does not sound to me like a good idea...
The overall question is now if the UIO system is working at all with non page 
aligned PCI memory resources. For me it looks as if this is not the case.
E.g. with the boards supported with the uio_cif driver, the memory resource 2 
of the
PCI device is a 128 byte memory. And exactly this memory has to be mmaped by the
driver and this fails.
As the uio driver do (no longer) work with non page aligned PCI memory 
resources,
the conclusion for me is to force the relevant PCI memory resources to be page 
aligned.
And that's why the patch might be used for.

Regards

Mathias

Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,

thanks for the response.
> > Some uio based PCI drivers (e.g. uio_cif) do not work if the assigned
> > PCI memory resources are not page aligned.
> > By using the kernel option "pci=resource_alignment" it is possible to
> > force single PCI boards to use page alignment for their memory resources.
> > However, this is fairly cumbersome if multiple of these cards are in use.
> > This patch adds another kernel option "pci=resources_page_aligned"
> > that allows to set the default alignment of PCI memory resources to be
> > page aligned.
> > Overwriting of this default alignment via "pci=resource_alignment" is
> > still possible.
> 
> This seems like a very large hammer for a very specific problem with a card
> that seems to be not-in-spec (I can't find anywhere that requires resources to
> be "page" aligned in the PCI spec).  Why not fix the firmware in these cards?
The issue is not the firmware. The issue is that the Linux uio driver (here: 
uio_cif)
does not work as uio_mmap() -> uio_mmap_physical() does not do a mmap 
on physical memory that is not page aligned...

Regards

Mathias

Re: [PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Hi Greg,

thanks for the response.
> > Some uio based PCI drivers (e.g. uio_cif) do not work if the assigned
> > PCI memory resources are not page aligned.
> > By using the kernel option "pci=resource_alignment" it is possible to
> > force single PCI boards to use page alignment for their memory resources.
> > However, this is fairly cumbersome if multiple of these cards are in use.
> > This patch adds another kernel option "pci=resources_page_aligned"
> > that allows to set the default alignment of PCI memory resources to be
> > page aligned.
> > Overwriting of this default alignment via "pci=resource_alignment" is
> > still possible.
> 
> This seems like a very large hammer for a very specific problem with a card
> that seems to be not-in-spec (I can't find anywhere that requires resources to
> be "page" aligned in the PCI spec).  Why not fix the firmware in these cards?
The issue is not the firmware. The issue is that the Linux uio driver (here: 
uio_cif)
does not work as uio_mmap() -> uio_mmap_physical() does not do a mmap 
on physical memory that is not page aligned...

Regards

Mathias

[PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Some uio based PCI drivers (e.g. uio_cif) do not work if the assigned 
PCI memory resources are not page aligned.
By using the kernel option "pci=resource_alignment" it is possible to force
single PCI boards to use page alignment for their memory resources.
However, this is fairly cumbersome if multiple of these cards are in use.
This patch adds another kernel option "pci=resources_page_aligned"
that allows to set the default alignment of PCI memory resources to
be page aligned.
Overwriting of this default alignment via "pci=resource_alignment" is
still possible.

Signed-off-by: Mathias Koehrer 

---
 Documentation/kernel-parameters.txt |1 +
 drivers/pci/pci.c   |6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: linux-4.7-rc1/Documentation/kernel-parameters.txt
===
--- linux-4.7-rc1.orig/Documentation/kernel-parameters.txt
+++ linux-4.7-rc1/Documentation/kernel-parameters.txt
@@ -3004,6 +3004,7 @@ bytes respectively. Such letter suffixes
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+   resources_page_aligned  Force all memory resources to be page 
aligned.
ecrc=   Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
Index: linux-4.7-rc1/drivers/pci/pci.c
===
--- linux-4.7-rc1.orig/drivers/pci/pci.c
+++ linux-4.7-rc1/drivers/pci/pci.c
@@ -4744,7 +4744,7 @@ EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
 #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
 static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
 static DEFINE_SPINLOCK(resource_alignment_lock);
-
+static resource_size_t pci_default_resource_alignment = 0;
 /**
  * pci_specified_resource_alignment - get resource alignment specified by user.
  * @dev: the PCI device to get
@@ -4755,7 +4755,7 @@ static DEFINE_SPINLOCK(resource_alignmen
 static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
 {
int seg, bus, slot, func, align_order, count;
-   resource_size_t align = 0;
+   resource_size_t align = pci_default_resource_alignment;
char *p;
 
spin_lock(_alignment_lock);
@@ -5015,6 +5015,8 @@ static int __init pci_setup(char *str)
} else if (!strncmp(str, "resource_alignment=", 19)) {
pci_set_resource_alignment_param(str + 19,
strlen(str + 19));
+   } else if (!strncmp(str, "resources_page_aligned", 22)) 
{
+   pci_default_resource_alignment = PAGE_SIZE;
} else if (!strncmp(str, "ecrc=", 5)) {
pcie_ecrc_get_policy(str + 5);
} else if (!strncmp(str, "hpiosize=", 9)) {

[PATCH] Introducing kernel option to force all PCI memory resources to be page aligned. Fixes issues with uio based drivers.

[Koehrer Mathias (ETAS/ESW5)]

Some uio based PCI drivers (e.g. uio_cif) do not work if the assigned 
PCI memory resources are not page aligned.
By using the kernel option "pci=resource_alignment" it is possible to force
single PCI boards to use page alignment for their memory resources.
However, this is fairly cumbersome if multiple of these cards are in use.
This patch adds another kernel option "pci=resources_page_aligned"
that allows to set the default alignment of PCI memory resources to
be page aligned.
Overwriting of this default alignment via "pci=resource_alignment" is
still possible.

Signed-off-by: Mathias Koehrer 

---
 Documentation/kernel-parameters.txt |1 +
 drivers/pci/pci.c   |6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: linux-4.7-rc1/Documentation/kernel-parameters.txt
===
--- linux-4.7-rc1.orig/Documentation/kernel-parameters.txt
+++ linux-4.7-rc1/Documentation/kernel-parameters.txt
@@ -3004,6 +3004,7 @@ bytes respectively. Such letter suffixes
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
+   resources_page_aligned  Force all memory resources to be page 
aligned.
ecrc=   Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
Index: linux-4.7-rc1/drivers/pci/pci.c
===
--- linux-4.7-rc1.orig/drivers/pci/pci.c
+++ linux-4.7-rc1/drivers/pci/pci.c
@@ -4744,7 +4744,7 @@ EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
 #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
 static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
 static DEFINE_SPINLOCK(resource_alignment_lock);
-
+static resource_size_t pci_default_resource_alignment = 0;
 /**
  * pci_specified_resource_alignment - get resource alignment specified by user.
  * @dev: the PCI device to get
@@ -4755,7 +4755,7 @@ static DEFINE_SPINLOCK(resource_alignmen
 static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev)
 {
int seg, bus, slot, func, align_order, count;
-   resource_size_t align = 0;
+   resource_size_t align = pci_default_resource_alignment;
char *p;
 
spin_lock(_alignment_lock);
@@ -5015,6 +5015,8 @@ static int __init pci_setup(char *str)
} else if (!strncmp(str, "resource_alignment=", 19)) {
pci_set_resource_alignment_param(str + 19,
strlen(str + 19));
+   } else if (!strncmp(str, "resources_page_aligned", 22)) 
{
+   pci_default_resource_alignment = PAGE_SIZE;
} else if (!strncmp(str, "ecrc=", 5)) {
pcie_ecrc_get_policy(str + 5);
} else if (!strncmp(str, "hpiosize=", 9)) {

RE: [PATCHv2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

> 
> Thanks Mathias, I have added your patch to my queue for Dave's net tree.
Hi Jeff,
thanks. Sorry for the confusion... As this is was my very first patch, I did 
not miss any pitfall...

Regards

Mathias

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH v2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue "tx_hwstamp_work" will only be
initialized if adapter->flags & FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer 

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:27:09.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
-!adapter->tx_hwtstamp_skb)) {
+   if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   (adapter->flags & FLAG_HAS_HW_TIMESTAMP) &&
+   !adapter->tx_hwtstamp_skb) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter->tx_hwtstamp_skb = skb_get(skb);

-- 

[PATCHv2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue "tx_hwstamp_work" will only be
initialized if adapter->flags & FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer 

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:27:09.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
-!adapter->tx_hwtstamp_skb)) {
+   if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   (adapter->flags & FLAG_HAS_HW_TIMESTAMP) &&
+   !adapter->tx_hwtstamp_skb) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter->tx_hwtstamp_skb = skb_get(skb);

-- 

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue "tx_hwstamp_work" will only be
initialized if adapter->flags & FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer 

---
 drivers/net/ethernet/intel/e1000e/netdev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:05:17.0 +0200
@@ -5550,7 +5550,8 @@
 nr_frags);
if (count) {
if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
-!adapter->tx_hwtstamp_skb)) {
+!adapter->tx_hwtstamp_skb &&
+(adapter->flags & FLAG_HAS_HW_TIMESTAMP))) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter->tx_hwtstamp_skb = skb_get(skb);

-- 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue tx_hwstamp_work will only be
initialized if adapter-flags  FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer mathias.koeh...@etas.com

---
 drivers/net/ethernet/intel/e1000e/netdev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:05:17.0 +0200
@@ -5550,7 +5550,8 @@
 nr_frags);
if (count) {
if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
-!adapter-tx_hwtstamp_skb)) {
+!adapter-tx_hwtstamp_skb 
+(adapter-flags  FLAG_HAS_HW_TIMESTAMP))) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter-tx_hwtstamp_skb = skb_get(skb);

-- 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue tx_hwstamp_work will only be
initialized if adapter-flags  FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer mathias.koeh...@etas.com

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:27:09.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
-!adapter-tx_hwtstamp_skb)) {
+   if (unlikely(skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   (adapter-flags  FLAG_HAS_HW_TIMESTAMP) 
+   !adapter-tx_hwtstamp_skb) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter-tx_hwtstamp_skb = skb_get(skb);

-- 

[PATCH v2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.  The reason is here that
in e1000_xmit_frame() a work queue will be scheduled that has not been
initialized in this case.  The work queue tx_hwstamp_work will only be
initialized if adapter-flags  FLAG_HAS_HW_TIMESTAMP set.  This check
is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer mathias.koeh...@etas.com

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-07 
08:27:09.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
-!adapter-tx_hwtstamp_skb)) {
+   if (unlikely(skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   (adapter-flags  FLAG_HAS_HW_TIMESTAMP) 
+   !adapter-tx_hwtstamp_skb) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter-tx_hwtstamp_skb = skb_get(skb);

-- 

RE: [PATCHv2] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

 
 Thanks Mathias, I have added your patch to my queue for Dave's net tree.
Hi Jeff,
thanks. Sorry for the confusion... As this is was my very first patch, I did 
not miss any pitfall...

Regards

Mathias

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running 
the ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be 
scheduled that has not been initialized in this case.
The work queue "tx_hwstamp_work" will only be initialized if 
adapter->flags & FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer 
---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
16:22:10.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
-!adapter->tx_hwtstamp_skb)) {
+   if ((adapter->flags & FLAG_HAS_HW_TIMESTAMP) && 
+   unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   !adapter->tx_hwtstamp_skb)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter->tx_hwtstamp_skb = skb_get(skb);

-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running 
the ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be 
scheduled that has not been initialized in this case.
The work queue "tx_hwstamp_work" will only be initialized if 
adapter->flags & FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
16:22:10.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
-!adapter->tx_hwtstamp_skb)) {
+   if ((adapter->flags & FLAG_HAS_HW_TIMESTAMP) && 
+   unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   !adapter->tx_hwtstamp_skb)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter->tx_hwtstamp_skb = skb_get(skb);

-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running the 
ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be scheduled 
that has not been initialized in this case.
The work queue "tx_hwstamp_work" will only be initialized if adapter->flags & 
FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer 
---
 drivers/net/ethernet/intel/e1000e/netdev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
15:15:42.0 +0200
@@ -5549,7 +5549,8 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   if ((adapter->flags & FLAG_HAS_HW_TIMESTAMP) &&
+unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) 
&&
 !adapter->tx_hwtstamp_skb)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;


-- 

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

> -Original Message-
> From: Nick Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, August 06, 2014 2:37 PM
> To: Koehrer Mathias (ETAS/ESW5)
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) 
> leads
> to a kernel oops (3.12.26)
> 
> On Wed, Aug 6, 2014 at 8:17 AM, Koehrer Mathias (ETAS/ESW5)
>  wrote:
> >> Mathias ,
> >> After tracing this it seems to be either one of two things based on
> >> the warn on messages in
> >> __queue_work. Normally it would be because of this line.
> >> WARN_ON_ONCE(!irqs_disabled());.
> >> However it would also be the second warn on, If you want I can send a
> >> simple patch with
> >> a printk statement to see which one it is.
> >> Regards Nick
> > That would be helpful. I can try to see what's happening.
> >
> > Regards
> >
> > Mathias
> Sorry for the late reply but couldn't figure out how to print the flags.
> Cheers Nick
Hi Nick,
thanks for the patch.
I applied it, however there was no change at all in the output.

My impression is, that it has to do with the network driver as everything works 
fine if I am using a different NIC.

When I apply the patch

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
15:15:42.0 +0200
@@ -5549,7 +5549,8 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+   if ((adapter->flags & FLAG_HAS_HW_TIMESTAMP) &&
+unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) 
&&
 !adapter->tx_hwtstamp_skb)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;

to the e1000e driver it seems to work...
This makes sense as the work queue is only created if  "adapter->flags & 
FLAG_HAS_HW_TIMESTAMP"  is set.
With this NIC this is *not* the case.


Regards

Mathias

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

> Mathias ,
> After tracing this it seems to be either one of two things based on
> the warn on messages in
> __queue_work. Normally it would be because of this line.
> WARN_ON_ONCE(!irqs_disabled());.
> However it would also be the second warn on, If you want I can send a
> simple patch with
> a printk statement to see which one it is.
> Regards Nick
That would be helpful. I can try to see what's happening.

Regards

Mathias
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
> Behalf Of Heinz Diehl
> Sent: Wednesday, August 06, 2014 10:33 AM
> To: linux-kernel@vger.kernel.org
> Cc: Koehrer Mathias (ETAS/ESW5); net...@vger.kernel.org
> Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) 
> leads
> to a kernel oops (3.12.26)
> 
> On 06.08.2014, Nick Krause wrote:
> 
> > I am going to have to ask a few questions first, what distribution is
> > and is this a vanilla kernel?
> 
> Read his mail. He's on Debian, and it's a Debian kernel.
I am on Debian. But it is a vanilla kernel from kernel.org without any 
additional patches.

> 
> > If it's not just send the report to the distribution developers.
> 
> His mail is quite sure a copy from the data entered into the Debian
> bugtracker.
No. I've never entered this into the Debian bugtracker.

Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

Hey Nick,
> Hey Koehrer Mathias,
> I am going to have to ask a few questions first, what distribution is
> and is this a vanilla kernel?
> If it's not just send the report to the distribution developers.
> Regards Nick
The distribution is Debian stable (Wheezy, V7.6).
However, the kernel is a pure vanilla kernel.

Regards

Mathias

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

Hey Nick,
 Hey Koehrer Mathias,
 I am going to have to ask a few questions first, what distribution is
 and is this a vanilla kernel?
 If it's not just send the report to the distribution developers.
 Regards Nick
The distribution is Debian stable (Wheezy, V7.6).
However, the kernel is a pure vanilla kernel.

Regards

Mathias

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

 -Original Message-
 From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
 Behalf Of Heinz Diehl
 Sent: Wednesday, August 06, 2014 10:33 AM
 To: linux-kernel@vger.kernel.org
 Cc: Koehrer Mathias (ETAS/ESW5); net...@vger.kernel.org
 Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) 
 leads
 to a kernel oops (3.12.26)
 
 On 06.08.2014, Nick Krause wrote:
 
  I am going to have to ask a few questions first, what distribution is
  and is this a vanilla kernel?
 
 Read his mail. He's on Debian, and it's a Debian kernel.
I am on Debian. But it is a vanilla kernel from kernel.org without any 
additional patches.

 
  If it's not just send the report to the distribution developers.
 
 His mail is quite sure a copy from the data entered into the Debian
 bugtracker.
No. I've never entered this into the Debian bugtracker.

Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

 Mathias ,
 After tracing this it seems to be either one of two things based on
 the warn on messages in
 __queue_work. Normally it would be because of this line.
 WARN_ON_ONCE(!irqs_disabled());.
 However it would also be the second warn on, If you want I can send a
 simple patch with
 a printk statement to see which one it is.
 Regards Nick
That would be helpful. I can try to see what's happening.

Regards

Mathias
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

 -Original Message-
 From: Nick Krause [mailto:xerofo...@gmail.com]
 Sent: Wednesday, August 06, 2014 2:37 PM
 To: Koehrer Mathias (ETAS/ESW5)
 Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org
 Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) 
 leads
 to a kernel oops (3.12.26)
 
 On Wed, Aug 6, 2014 at 8:17 AM, Koehrer Mathias (ETAS/ESW5)
 mathias.koeh...@etas.com wrote:
  Mathias ,
  After tracing this it seems to be either one of two things based on
  the warn on messages in
  __queue_work. Normally it would be because of this line.
  WARN_ON_ONCE(!irqs_disabled());.
  However it would also be the second warn on, If you want I can send a
  simple patch with
  a printk statement to see which one it is.
  Regards Nick
  That would be helpful. I can try to see what's happening.
 
  Regards
 
  Mathias
 Sorry for the late reply but couldn't figure out how to print the flags.
 Cheers Nick
Hi Nick,
thanks for the patch.
I applied it, however there was no change at all in the output.

My impression is, that it has to do with the network driver as everything works 
fine if I am using a different NIC.

When I apply the patch

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
15:15:42.0 +0200
@@ -5549,7 +5549,8 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   if ((adapter-flags  FLAG_HAS_HW_TIMESTAMP) 
+unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 

 !adapter-tx_hwtstamp_skb)) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;

to the e1000e driver it seems to work...
This makes sense as the work queue is only created if  adapter-flags  
FLAG_HAS_HW_TIMESTAMP  is set.
With this NIC this is *not* the case.


Regards

Mathias

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running the 
ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be scheduled 
that has not been initialized in this case.
The work queue tx_hwstamp_work will only be initialized if adapter-flags  
FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer mathias.koeh...@etas.com
---
 drivers/net/ethernet/intel/e1000e/netdev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
15:15:42.0 +0200
@@ -5549,7 +5549,8 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   if ((adapter-flags  FLAG_HAS_HW_TIMESTAMP) 
+unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 

 !adapter-tx_hwtstamp_skb)) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;


-- 

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running 
the ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be 
scheduled that has not been initialized in this case.
The work queue tx_hwstamp_work will only be initialized if 
adapter-flags  FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
16:22:10.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
-!adapter-tx_hwtstamp_skb)) {
+   if ((adapter-flags  FLAG_HAS_HW_TIMESTAMP)  
+   unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   !adapter-tx_hwtstamp_skb)) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter-tx_hwtstamp_skb = skb_get(skb);

-- 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix e1000e with Intel 82572EI that has no hardware timestamp support

[Koehrer Mathias (ETAS/ESW5)]

With the Intel 82527EI (driver: e1000e) there is an issue when running 
the ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be 
scheduled that has not been initialized in this case.
The work queue tx_hwstamp_work will only be initialized if 
adapter-flags  FLAG_HAS_HW_TIMESTAMP set.
This check is missing in e1000_xmit_frame().

The following patch adds the missing check.

Signed-off-by: Mathias Koehrer mathias.koeh...@etas.com
---
 drivers/net/ethernet/intel/e1000e/netdev.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c   
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06 
16:22:10.0 +0200
@@ -5549,8 +5549,9 @@
count = e1000_tx_map(tx_ring, skb, first, adapter-tx_fifo_limit,
 nr_frags);
if (count) {
-   if (unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
-!adapter-tx_hwtstamp_skb)) {
+   if ((adapter-flags  FLAG_HAS_HW_TIMESTAMP)  
+   unlikely((skb_shinfo(skb)-tx_flags  SKBTX_HW_TSTAMP) 
+   !adapter-tx_hwtstamp_skb)) {
skb_shinfo(skb)-tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
adapter-tx_hwtstamp_skb = skb_get(skb);

-- 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

[1.] One line summary of the problem: 
Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[2.] Full description of the problem/report:
I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 on a 
x86 PC using an Intel 82572EI NIC (driver e1000e).
The ptpd2 is started as
ptpd2 -i eth0 --masteronly --foreground --verbose
I have another PC in the same network that is running the PTP slave.
After a couple of seconds the kernel generates an Oops.

Using a different network adapter works fine.

Thanks for any support on this!

[3.] Keywords (i.e., modules, networking, kernel):
PTP, networking, e1000e

[4.] Kernel information

[4.1.] Kernel version (from /proc/version):
Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 
SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014

[4.2.] Kernel .config file:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.12.26 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-4"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

PROBLEM: Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

[1.] One line summary of the problem: 
Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[2.] Full description of the problem/report:
I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 on a 
x86 PC using an Intel 82572EI NIC (driver e1000e).
The ptpd2 is started as
ptpd2 -i eth0 --masteronly --foreground --verbose
I have another PC in the same network that is running the PTP slave.
After a couple of seconds the kernel generates an Oops.

Using a different network adapter works fine.

Thanks for any support on this!

[3.] Keywords (i.e., modules, networking, kernel):
PTP, networking, e1000e

[4.] Kernel information

[4.1.] Kernel version (from /proc/version):
Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 
SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014

[4.2.] Kernel .config file:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.12.26 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-4"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

PROBLEM: Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

[1.] One line summary of the problem: 
Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[2.] Full description of the problem/report:
I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 on a 
x86 PC using an Intel 82572EI NIC (driver e1000e).
The ptpd2 is started as
ptpd2 -i eth0 --masteronly --foreground --verbose
I have another PC in the same network that is running the PTP slave.
After a couple of seconds the kernel generates an Oops.

Using a different network adapter works fine.

Thanks for any support on this!

[3.] Keywords (i.e., modules, networking, kernel):
PTP, networking, e1000e

[4.] Kernel information

[4.1.] Kernel version (from /proc/version):
Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 
SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014

[4.2.] Kernel .config file:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.12.26 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf32-i386
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=-4
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y

PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Koehrer Mathias (ETAS/ESW5)]

[1.] One line summary of the problem: 
Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[2.] Full description of the problem/report:
I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 on a 
x86 PC using an Intel 82572EI NIC (driver e1000e).
The ptpd2 is started as
ptpd2 -i eth0 --masteronly --foreground --verbose
I have another PC in the same network that is running the PTP slave.
After a couple of seconds the kernel generates an Oops.

Using a different network adapter works fine.

Thanks for any support on this!

[3.] Keywords (i.e., modules, networking, kernel):
PTP, networking, e1000e

[4.] Kernel information

[4.1.] Kernel version (from /proc/version):
Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 
SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014

[4.2.] Kernel .config file:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.12.26 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf32-i386
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=-4
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y