Hello,
this patch set adds the SATA support for Armada 370 and Armada XP. Few
changes have been done since the first version by taking in account
the comments received for the first version.
The evaluation boards for Armada 370 and Armada XP come with 2 SATA
ports, and when both are enable the coherent pool for DMA mapping was
too short. It was exactly the same issue that was fixed for Kirkwood
two months ago. So I used the same fix in the first patch. Later when
Kirkwood will be part of mach-mvebu, then this fix will be shared
between the 2 SoCs families.
This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called mvebu-SATA-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Changelog:
V1 -> V2:
- Added the acked-by from Marek Szyprowski for the first patch.
- Moved the port number from dtsi to board file t o be coherent with
Kirwkood boards.
- Cleaned armada-370-xp.dtsi from test strings.
- Split the second patch in 3 part one for dts, one for config update,
and the last for dtsi.
- Updated the mvebu_defconfig file with only the necessary symbols.
- Updated also the multi_v7_defconfig file.
Regards,
Gregory
Gregory CLEMENT (4):
arm: mvebu: increase atomic coherent pool size for armada 370/XP
arm: mvebu: adding SATA support: dt binding for Armada 370/XP
arm: mvebu: adding SATA support: configs update
arm: mvebu: adding SATA support: dt binding for Armada 370/XP boards
arch/arm/boot/dts/armada-370-db.dts | 4 ++++
arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
arch/arm/boot/dts/armada-xp-db.dts | 4 ++++
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 3 +++
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
6 files changed, 34 insertions(+)
--
1.7.9.5
For Armada 370/XP we have the same problem that for the commit
cb01b63, so we applied the same solution: "The default 256 KiB
coherent pool may be too small for some of the Kirkwood devices, so
increase it to make sure that devices will be able to allocate their
buffers with GFP_ATOMIC flag"
Signed-off-by: Gregory CLEMENT <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
---
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..cbad821 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <linux/io.h>
#include <linux/time-armada-370-xp.h>
+#include <linux/dma-mapping.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
armada_370_xp_timer_init();
}
+void __init armada_370_xp_init_early(void)
+{
+ /*
+ * Some Armada 370/XP devices allocate their coherent buffers
+ * from atomic context. Increase size of atomic coherent pool
+ * to make sure such the allocations won't fail.
+ */
+ init_dma_coherent_pool_size(SZ_1M);
+}
+
struct sys_timer armada_370_xp_timer = {
.init = armada_370_xp_timer_and_clk_init,
};
@@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
+ .init_early = armada_370_xp_init_early,
.init_irq = armada_370_xp_init_irq,
.handle_irq = armada_370_xp_handle_irq,
.timer = &armada_370_xp_timer,
--
1.7.9.5
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Lior Amsalem <[email protected]>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..a911f7a 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -69,6 +69,15 @@
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
};
+
+ sata@d00a0000 {
+ compatible = "marvell,orion-sata";
+ reg = <0xd00a0000 0x2400>;
+ interrupts = <55>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
};
};
--
1.7.9.5
Add the SATA device tree bindings for
- Armada XP evaluation board (DB-78460-BP)
- Armada 370 evaluation board (DB-88F6710-BP-DDR3)
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Lior Amsalem <[email protected]>
---
arch/arm/boot/dts/armada-370-db.dts | 4 ++++
arch/arm/boot/dts/armada-xp-db.dts | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 4a31b03..060e5ba 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,5 +34,9 @@
clock-frequency = <200000000>;
status = "okay";
};
+ sata@d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..375436b 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,9 @@
clock-frequency = <250000000>;
status = "okay";
};
+ sata@d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
};
};
--
1.7.9.5
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Lior Amsalem <[email protected]>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 159f75f..dbea6f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,8 +17,10 @@ CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
+CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_SATA_HIGHBANK=y
+CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_SMSC911X=y
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..76a60b5 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -18,6 +18,9 @@ CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_SATA_MV=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
--
1.7.9.5
On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
> Hello,
>
> this patch set adds the SATA support for Armada 370 and Armada XP. Few
> changes have been done since the first version by taking in account
> the comments received for the first version.
>
> The evaluation boards for Armada 370 and Armada XP come with 2 SATA
> ports, and when both are enable the coherent pool for DMA mapping was
> too short. It was exactly the same issue that was fixed for Kirkwood
> two months ago. So I used the same fix in the first patch. Later when
> Kirkwood will be part of mach-mvebu, then this fix will be shared
> between the 2 SoCs families.
>
> This patch set is based on 3.7-rc2 and depends one the framework clock
> support (the last version was posted last week:
> http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
> called mvebu-SATA-for-3.8 is also available at
> https://github.com/MISL-EBU-System-SW/mainline-public.git.
Hi Gregory
What about the openblocks-ax3?
Andrew
On Fri, 26 Oct 2012 14:39:08 +0200, Andrew Lunn wrote:
> What about the openblocks-ax3?
Grégory does not (yet) have an OpenBlocks AX3, but I'm planning to do
the work for SATA soon for this platform. However, supporting the
OpenBlocks AX3 is not part of our official contract with Marvell, it's
just an additional thing I'm happily doing on my spare time. So I'll
provide support for SATA, network and SMP on OpenBlocks AX3, but we
would like to first see the SATA support for the Marvell evaluation
boards being merged, and on my side the basic support for the
OpenBlocks AX3. I'll send followup patches to enable SATA/network/SMP
on OpenBlocks AX3 later on, if that's ok for you?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Fri, Oct 26, 2012 at 02:48:04PM +0200, Thomas Petazzoni wrote:
>
> On Fri, 26 Oct 2012 14:39:08 +0200, Andrew Lunn wrote:
>
> > What about the openblocks-ax3?
>
> Gr??gory does not (yet) have an OpenBlocks AX3, but I'm planning to do
> the work for SATA soon for this platform. However, supporting the
> OpenBlocks AX3 is not part of our official contract with Marvell, it's
> just an additional thing I'm happily doing on my spare time.
Ah, O.K. I did not realize that.
> So I'll
> provide support for SATA, network and SMP on OpenBlocks AX3, but we
> would like to first see the SATA support for the Marvell evaluation
> boards being merged, and on my side the basic support for the
> OpenBlocks AX3. I'll send followup patches to enable SATA/network/SMP
> on OpenBlocks AX3 later on, if that's ok for you?
Sure, no problem.
Thanks for the clarification,
Andrew
On 10/26/2012 02:39 PM, Andrew Lunn wrote:
> On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
>> Hello,
>>
>> this patch set adds the SATA support for Armada 370 and Armada XP. Few
>> changes have been done since the first version by taking in account
>> the comments received for the first version.
>>
>> The evaluation boards for Armada 370 and Armada XP come with 2 SATA
>> ports, and when both are enable the coherent pool for DMA mapping was
>> too short. It was exactly the same issue that was fixed for Kirkwood
>> two months ago. So I used the same fix in the first patch. Later when
>> Kirkwood will be part of mach-mvebu, then this fix will be shared
>> between the 2 SoCs families.
>>
>> This patch set is based on 3.7-rc2 and depends one the framework clock
>> support (the last version was posted last week:
>> http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
>> called mvebu-SATA-for-3.8 is also available at
>> https://github.com/MISL-EBU-System-SW/mainline-public.git.
>
> Hi Gregory
>
> What about the openblocks-ax3?
Well I don't have this hardware, Thomas have. But with this question
I guess this board have (a) SATA port(s).
Moreover openblocks-ax3 is not (yet) in Jason branch so I can't make
a patch applying on a file which doesn't exist on my branch. It could
be a dependency but I try to reduce it as far as I can.
But as soon as this series will be applied, adding SATA support for
openblocks-ax3 should be pretty fast and just a matter of updating
the dts.
>
> Andrew
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT <[email protected]>
> Signed-off-by: Lior Amsalem <[email protected]>
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 94b4b9e..a911f7a 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -69,6 +69,15 @@
> compatible = "marvell,armada-addr-decoding-controller";
> reg = <0xd0020000 0x258>;
> };
> +
> + sata@d00a0000 {
> + compatible = "marvell,orion-sata";
> + reg = <0xd00a0000 0x2400>;
> + interrupts = <55>;
> + clocks = <&coreclk 0>;
nit. whitespace?
thx,
Jason.
> + status = "disabled";
> + };
> +
> };
> };
>
> --
> 1.7.9.5
>
On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
> On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
> > Signed-off-by: Gregory CLEMENT <[email protected]>
> > Signed-off-by: Lior Amsalem <[email protected]>
> > ---
> > arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> > index 94b4b9e..a911f7a 100644
> > --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> > +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> > @@ -69,6 +69,15 @@
> > compatible = "marvell,armada-addr-decoding-controller";
> > reg = <0xd0020000 0x258>;
> > };
> > +
> > + sata@d00a0000 {
> > + compatible = "marvell,orion-sata";
> > + reg = <0xd00a0000 0x2400>;
> > + interrupts = <55>;
> > + clocks = <&coreclk 0>;
>
> nit. whitespace?
[Don't shoot the messenger]
How about extending checkpatch to check for this? I guess its just
spaces which should be tabs.
Andrew
On 10/26/2012 03:34 PM, Andrew Lunn wrote:
> On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
>> On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
>>> Signed-off-by: Gregory CLEMENT <[email protected]>
>>> Signed-off-by: Lior Amsalem <[email protected]>
>>> ---
>>> arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>>> index 94b4b9e..a911f7a 100644
>>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>>> @@ -69,6 +69,15 @@
>>> compatible = "marvell,armada-addr-decoding-controller";
>>> reg = <0xd0020000 0x258>;
>>> };
>>> +
>>> + sata@d00a0000 {
>>> + compatible = "marvell,orion-sata";
>>> + reg = <0xd00a0000 0x2400>;
>>> + interrupts = <55>;
>>> + clocks = <&coreclk 0>;
>>
>> nit. whitespace?
>
> [Don't shoot the messenger]
>
> How about extending checkpatch to check for this? I guess its just
> spaces which should be tabs.
No it is the opposite in fact! On this line it's tabs: 3 tabs of 8
whitespace, so the line start at 24. But as there is a '+', the first
tab is only 7, so it is still start at 24. Whereas for the other lines
it's 24 white spaces, so with the '+' it starts at 25. That's why I
didn't notice it, and if you apply the patch all is fine.
Now, about white spaces vs tab, I don't know what is the rule for .dts
file.
Gregory
> Now, about white spaces vs tab, I don't know what is the rule for .dts
> file.
I personally use tabs, but i don't see anything in the
Documentation/CodingStyle.
Maybe ask on the device tree mailing list?
Andrew
On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
> > Now, about white spaces vs tab, I don't know what is the rule
> > for .dts file.
>
> I personally use tabs, but i don't see anything in the
> Documentation/CodingStyle.
>
> Maybe ask on the device tree mailing list?
Yes, it would be good to know and document what is the rule for .dts
files, and possibly extend checkpatch to cover those special rules
for .dts files.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Fri, Oct 26, 2012 at 04:57:59PM +0200, Thomas Petazzoni wrote:
>
> On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
> > > Now, about white spaces vs tab, I don't know what is the rule
> > > for .dts file.
> >
> > I personally use tabs, but i don't see anything in the
> > Documentation/CodingStyle.
> >
> > Maybe ask on the device tree mailing list?
>
> Yes, it would be good to know and document what is the rule for .dts
> files, and possibly extend checkpatch to cover those special rules
> for .dts files.
until that is resolved, can we make this patch conform to what is in the
file currently? Once the dt folks clarify, we can run through all the
dts's and submit one cleanup series.
If there are no other comments on this series, I'm fine taking it as is
and doing the fixup on my end. No need to do a version bump just for
this.
thx,
Jason.
On 10/26/2012 05:02 PM, Jason Cooper wrote:
> On Fri, Oct 26, 2012 at 04:57:59PM +0200, Thomas Petazzoni wrote:
>>
>> On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
>>>> Now, about white spaces vs tab, I don't know what is the rule
>>>> for .dts file.
>>>
>>> I personally use tabs, but i don't see anything in the
>>> Documentation/CodingStyle.
>>>
>>> Maybe ask on the device tree mailing list?
>>
>> Yes, it would be good to know and document what is the rule for .dts
>> files, and possibly extend checkpatch to cover those special rules
>> for .dts files.
>
> until that is resolved, can we make this patch conform to what is in the
> file currently? Once the dt folks clarify, we can run through all the
> dts's and submit one cleanup series.
>
> If there are no other comments on this series, I'm fine taking it as is
> and doing the fixup on my end. No need to do a version bump just for
> this.
OK then you will just have to replace my tabs by whitespace.
Thanks,
Gregory
resent as plain text, sorry.
> For Armada 370/XP we have the same problem that for the commit
> cb01b63, so we applied the same solution: "The default 256 KiB
> coherent pool may be too small for some of the Kirkwood devices, so
> increase it to make sure that devices will be able to allocate their
> buffers with GFP_ATOMIC flag"
I see a regression from linux-3.5 to linux-3.6 and think there might be
a fundamental problem
with this patch. On my Kirkwood system (guruplug server plus) with
linux-3.6.2 I see following
errors and corresponding malfunction even with further increased (2M,
4M) pool size:
Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent pool is
too small!
Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
kernel parameter!
So I had to downgrade to linux-3.5 which is running without problems.
I use SATA and several DVB sticks (em28xx / drxk and dib0700).
I already sent this bug report to m.szyprowski and
gregory.clementearlier, but
Sebastian suggested to send it to the mailing list and the responsible
maintainers, too.
Please write to my e-mail directly if you have further questions or
patches for me to test.
Regards,
Soeren
On Tue, Nov 06, 2012 at 10:28:45PM +0100, S?ren Moch wrote:
> resent as plain text, sorry.
>
>
> > For Armada 370/XP we have the same problem that for the commit
> > cb01b63, so we applied the same solution: "The default 256 KiB
> > coherent pool may be too small for some of the Kirkwood devices, so
> > increase it to make sure that devices will be able to allocate their
> > buffers with GFP_ATOMIC flag"
>
> I see a regression from linux-3.5 to linux-3.6 and think there might
> be a fundamental problem
> with this patch. On my Kirkwood system (guruplug server plus) with
> linux-3.6.2 I see following
> errors and corresponding malfunction even with further increased
> (2M, 4M) pool size:
>
> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
> pool is too small!
> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
> kernel parameter!
>
> So I had to downgrade to linux-3.5 which is running without problems.
>
> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
I'm guess its the DVB sticks which are causing the problems. We have a
number of kirkwood devices with two SATA devices which had problems
until we extended the coherent_pool. The DVB sticks are probably take
more coherent RAM. There was also an issue found recently:
http://www.spinics.net/lists/arm-kernel/msg203962.html
That conversation has gone quiet, but that could be because the
participants are at ELCE.
Andrew
On 11/06/2012 11:32 PM, Andrew Lunn wrote:
> On Tue, Nov 06, 2012 at 10:28:45PM +0100, S?ren Moch wrote:
>> I see a regression from linux-3.5 to linux-3.6 and think there might
>> be a fundamental problem
>> with this patch. On my Kirkwood system (guruplug server plus) with
>> linux-3.6.2 I see following
>> errors and corresponding malfunction even with further increased
>> (2M, 4M) pool size:
>>
>> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
>> pool is too small!
>> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
>> kernel parameter!
>>
>> So I had to downgrade to linux-3.5 which is running without problems.
>>
>> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
>
> I'm guess its the DVB sticks which are causing the problems. We have a
> number of kirkwood devices with two SATA devices which had problems
> until we extended the coherent_pool. The DVB sticks are probably take
> more coherent RAM. There was also an issue found recently:
>
> http://www.spinics.net/lists/arm-kernel/msg203962.html
>
> That conversation has gone quiet, but that could be because the
> participants are at ELCE.
So what is the call here? Should we just increase the coherent buffer
size back to what it was before? I am not into this too much but just
increasing the buffer will just postpone the actual issue to a later
point in running the kernel?
Sebastian
>>> For Armada 370/XP we have the same problem that for the commit
>>> cb01b63, so we applied the same solution: "The default 256 KiB
>>> coherent pool may be too small for some of the Kirkwood devices, so
>>> increase it to make sure that devices will be able to allocate their
>>> buffers with GFP_ATOMIC flag"
>>
>> I see a regression from linux-3.5 to linux-3.6 and think there might
>> be a fundamental problem
>> with this patch. On my Kirkwood system (guruplug server plus) with
>> linux-3.6.2 I see following
>> errors and corresponding malfunction even with further increased
>> (2M, 4M) pool size:
>>
>> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
>> pool is too small!
>> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
>> kernel parameter!
>>
>> So I had to downgrade to linux-3.5 which is running without problems.
>>
>> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
>
> I'm guess its the DVB sticks which are causing the problems. We have a
> number of kirkwood devices with two SATA devices which had problems
> until we extended the coherent_pool. The DVB sticks are probably take
> more coherent RAM. There was also an issue found recently:
>
> http://www.spinics.net/lists/arm-kernel/msg203962.html
>
> That conversation has gone quiet, but that could be because the
> participants are at ELCE.
>
> Andrew
OK, I hope this GFP flag correction will help.
Could there be a fragmentation problem in the coherent_pool with the
different drivers running under heavy load?
With a pool size of 1M I see this error after several minutes, with a 4M
pool I see this error after several 10 minutes. Difficult to test, but not
acceptable on a production system.
Soeren