summaryrefslogtreecommitdiff
path: root/Documentation/ramoops.txt
diff options
context:
space:
mode:
authorRob Herring <robherring2@gmail.com>2014-09-12 11:32:24 -0700
committerTony Luck <tony.luck@intel.com>2014-12-11 13:35:49 -0800
commit7ae9cb81933515dc7db1aa3c47ef7653717e3090 (patch)
tree2555836fbb81d18c41e30a690b552a3c0d791be1 /Documentation/ramoops.txt
parent069fb0b63722f8c9f8b4bbce236793626c89af33 (diff)
pstore-ram: Fix hangs by using write-combine mappings
Currently trying to use pstore on at least ARMs can hang as we're mapping the peristent RAM with pgprot_noncached(). On ARMs, pgprot_noncached() will actually make the memory strongly ordered, and as the atomic operations pstore uses are implementation defined for strongly ordered memory, they may not work. So basically atomic operations have undefined behavior on ARM for device or strongly ordered memory types. Let's fix the issue by using write-combine variants for mappings. This corresponds to normal, non-cacheable memory on ARM. For many other architectures, this change does not change the mapping type as by default we have: #define pgprot_writecombine pgprot_noncached The reason why pgprot_noncached() was originaly used for pstore is because Colin Cross <ccross@android.com> had observed lost debug prints right before a device hanging write operation on some systems. For the platforms supporting pgprot_noncached(), we can add a an optional configuration option to support that. But let's get pstore working first before adding new features. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rob Herring <rob.herring@calxeda.com> [tony@atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
Diffstat (limited to 'Documentation/ramoops.txt')
0 files changed, 0 insertions, 0 deletions