linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: smoch@web.de (Sören Moch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
Date: Wed, 07 Nov 2012 00:07:01 +0100	[thread overview]
Message-ID: <50999815.4020701@web.de> (raw)
In-Reply-To: <20121106223257.GB30428@lunn.ch>


 >>> 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

  parent reply	other threads:[~2012-11-06 23:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06 21:28 [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP Sören Moch
2012-11-06 22:32 ` Andrew Lunn
2012-11-06 22:55   ` Sebastian Hesselbarth
2012-11-06 23:07   ` Sören Moch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-10-26 12:30 [PATCH V2 0/4] Adding SATA support for Armada 370/XP Gregory CLEMENT
2012-10-26 12:30 ` [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP Gregory CLEMENT

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50999815.4020701@web.de \
    --to=smoch@web.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).