Hi all,
In v2:
- Updated documentation per Colin Cross' comments;
- Corrected return value in ramoops_pstore_write() (noticed by Kees Cook);
- Fixed large writes handling in pstore_console_write(), i.e. when
log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook.
These patches depend on the the following series:
http://thread.gmane.org/gmane.linux.kernel/1298642
"[PATCH v3 0/3] Merge ramoops and persistent_ram, generic pstore RAM backend"
And a rationale for the series:
Currently pstore doesn't support logging kernel messages in run-time,
it only dumps dmesg when kernel oopses/panics. This makes pstore
useless for debugging hangs caused by HW issues or improper use of HW
(e.g. weird device inserted -> driver tried to write reserved bits ->
SoC hanged. In that case we don't get any messages in the pstore.
This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE,
plus make pstore/ram.c handle the new messages.
The old ram_console driver is removed. This might probably cause
some pain for out-of-tree code, as it would need to be adjusted...
but "no pain, no gain"? :-) Though, if there's some serious resistance,
we can probably postpone the last two patches.
Thanks!
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
Here comes v3:
- Rebased on current staging-next tree, so only 3 patches left;
- Fixed ram_console dependency in Kconfig (issue noticed by Greg KH).
And the boilerplate, background for the series:
There are currently two competing debug facilities to store kernel
messages in a persistent storage: a generic pstore and Google's
persistent_ram. Not so long ago (https://lkml.org/lkml/2012/3/8/252),
it was decided that we should fix this situation.
Recently ramoops has switched to pstore, which basically means that
it became a RAM backend for the pstore framework.
persistent_ram+ram_console and ramoops+pstore have almost the same
features, except:
1. Ramoops doesn't support ECC. Having ECC is useful when a hardware
reset was used to bring the machine back to life (i.e. a watchdog
triggered). In such cases, RAM may be somewhat corrupt, but
usually it is restorable.
2. Pstore doesn't support logging kernel messages in run-time, it only
dumps dmesg when kernel oopses/panics. This makes pstore useless for
debugging hangs caused by HW issues or improper use of HW (e.g.
weird device inserted -> driver tried to write a reserved bits ->
SoC hanged. In that case we don't get any messages in the pstore.
These patches solve the first issue, plus move things to their
proper places.
---
Documentation/ramoops.txt | 6 +
drivers/staging/android/Kconfig | 10 +-
drivers/staging/android/Makefile | 1 -
drivers/staging/android/persistent_ram.c | 532 ------------------------------
drivers/staging/android/persistent_ram.h | 82 -----
drivers/staging/android/ram_console.c | 2 +-
fs/pstore/Kconfig | 7 +-
fs/pstore/Makefile | 2 +-
fs/pstore/ram.c | 119 ++++---
fs/pstore/ram_core.c | 532 ++++++++++++++++++++++++++++++
include/linux/pstore_ram.h | 81 +++++
11 files changed, 697 insertions(+), 677 deletions(-)
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
Here is v2 of the previous patch set. The series do not include
patches that were already merged.
I believe I addressed all the previous comments, plus now the
series include another small cleanup patch.
Here's some background for the series:
There are currently two competing debug facilities to store kernel
messages in a persistent storage: a generic pstore and Google's
persistent_ram. Not so long ago (https://lkml.org/lkml/2012/3/8/252),
it was decided that we should fix this situation.
Recently ramoops has switched to pstore, which basically means that
it became a RAM backend for the pstore framework.
persistent_ram+ram_console and ramoops+pstore have almost the same
features, except:
1. Ramoops doesn't support ECC. Having ECC is useful when a hardware
reset was used to bring the machine back to life (i.e. a watchdog
triggered). In such cases, RAM may be somewhat corrupt, but
usually it is restorable.
2. Pstore doesn't support logging kernel messages in run-time, it only
dumps dmesg when kernel oopses/panics. This makes pstore useless for
debugging hangs caused by HW issues or improper use of HW (e.g.
weird device inserted -> driver tried to write a reserved bits ->
SoC hanged. In that case we don't get any messages in the pstore.
These patches solve the first issue, plus move things to their
proper places. Patches that will fix the second issue will be sent
shortly.
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 9 -
drivers/char/Makefile | 1 -
drivers/char/ramoops.c | 362 --------------------
drivers/staging/android/Kconfig | 10 +-
drivers/staging/android/Makefile | 1 -
drivers/staging/android/persistent_ram.c | 530 -----------------------------
drivers/staging/android/persistent_ram.h | 84 -----
drivers/staging/android/ram_console.c | 2 +-
fs/pstore/Kconfig | 17 +
fs/pstore/Makefile | 3 +
fs/pstore/ram.c | 383 +++++++++++++++++++++
fs/pstore/ram_core.c | 532 ++++++++++++++++++++++++++++++
include/linux/pstore_ram.h | 98 ++++++
include/linux/ramoops.h | 17 -
15 files changed, 1042 insertions(+), 1015 deletions(-)
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
Hi all,
Currently pstore doesn't support logging kernel messages in run-time,
it only dumps dmesg when kernel oopses/panics. This makes pstore
useless for debugging hangs caused by HW issues or improper use of HW
(e.g. weird device inserted -> driver tried to write reserved bits ->
SoC hanged. In that case we don't get any messages in the pstore.
This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE,
plus make pstore/ram.c handle the new messages.
The old ram_console driver is removed. This might probably cause
some pain for out-of-tree code, as it would need to be adjusted...
but "no pain, no gain"? :-) Though, if there's some serious resistance,
we can probably postpone the last two patches.
These patches depend on the following series:
http://thread.gmane.org/gmane.linux.kernel/1298179
"[PATCH v2 0/6] Merge ramoops and persistent_ram, generic pstore RAM backend"
Thanks!
---
Documentation/ramoops.txt | 15 +++
drivers/staging/android/Kconfig | 5 -
drivers/staging/android/Makefile | 1 -
drivers/staging/android/ram_console.c | 179 ---------------------------------
fs/pstore/Kconfig | 7 ++
fs/pstore/inode.c | 3 +
fs/pstore/platform.c | 25 +++++
fs/pstore/ram.c | 39 +++++--
fs/pstore/ram_core.c | 81 +--------------
include/linux/pstore.h | 1 +
include/linux/pstore_ram.h | 19 ----
11 files changed, 83 insertions(+), 292 deletions(-)
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
=== Highlights ===
* Synced up with interested parties David R. and Jon M. on
Enterprise kernel sessions
* Synced up with Grant on DT status and session at connect
* Synced up with Michael Hope on STM
* Connect session planning
=== Plans ===
* Google Hangout on Air interview for marketing/outreach of Connect
training sessions.
* Continue Connect session planning: creating detailed outlines,
coordinating facilitators, slides, etc...
* Usual 1:1's and meetings
* Work on slides for Upstreaming 101 and Linux Con JP Single zImage
presentation.
* Work on some wiki page updates
=== Issues ===
* Lots to do before leaving, might use all of Portland's coffee supply.
=== Travel/Time Off ===
* May 22nd - June 12th:
Austin to sync up with Mounir, Rob Herring, Doug Deao
Linaro Connect
Few days of vacation in Beijing
Linux Con Japan
A few days of vacation in Tokyo
Back Home!
* Travel to visit family 7/27 - 8/1. Will be working from CST time
zone instead of PST.
* Tentatively out August 22nd- Sept 5th. Will be in the middle of nowhere
and have no connectivity.
=== Highlights ===
=== Pinctrl ===
* reviewed some converting imx driver to use pinctrl patches
* sent out a few pinctrl core fix and clean up patches
* added pinctrl mx5(mx51/mx53) support
* wrote a draft patch to implement per bin based config in a group, but it
seemed not good engouht
and found that current pinctrl config implementation is not suitable for
extend this feature due to different SoC's
characteristic and requirements, may think more on it and open the issue
for discussion
with some other people involved.
* pinctrl gpio support, did not spend too much time on it this week.
Due to the gpio base of dt is dynamically allocated which is not
suitable for current design,
still not found good idea to address this issue.
For IMX, we decided to config gpio in dts file as other pins
temporarily. Will keep tracking on
it.
=== mxs dt ===
* reviewd some mxs dt converting patches
=== Plan ===
* pinctrl per bin based config in the same group
* pinctrl gpio dt support improvement.
* convert remain imx drivers to use pinctrl
* convert mxs driver to support dt