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?
> >
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?
> >
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
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
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
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
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
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
>
> 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
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
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
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
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
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
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
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
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
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
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
> -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
> 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
> -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
> Subje
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
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
-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
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
-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
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
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
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
[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
[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
[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
[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
34 matches
Mail list logo
