From: Florian Fainelli <f.fainelli@gmail.com>
To: Kees Cook <keescook@chromium.org>,
WeiXiong Liao <gmpy.liaowx@gmail.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
Kamal Dasu <kdasu.kdev@gmail.com>
Subject: Invalid pstore_blk use?
Date: Thu, 14 Jul 2022 20:49:48 -0700 [thread overview]
Message-ID: <e97bc607-a913-dbbd-1965-b60d55d956b8@gmail.com> (raw)
Hi Kees, WeiXiong,
I am trying to make use of pstore_blk which is BTW exactly what I had
been looking for to store panic/console logs onto an eMMC partition.
Using the 5.10 kernel plus:
7e2e92e9861b Revert "mark pstore-blk as broken"
01c28bc8f389 pstore/blk: Use the normal block device I/O path
2a7507999638 pstore/blk: remove {un,}register_pstore_blk
fef0b337cd25 pstore/zone: cap the maximum device size
or the android13-5.15 (at Merge 5.15.40 into android13-5.15) kernel with
no changes and using:
mount -t pstore pstore /sys/fs/pstore
modprobe pstore_blk blkdev=/dev/mmcblk1p9 best_effort=yes
upon triggering a crash with:
echo c > /proc/sysrq-trigger
and rebooting and remounting the pstore filesystem and loading
pstore_blk, I only have:
# ls /sys/fs/pstore/
console-pstore_blk-0
which contains the entire console log up to, but excluding the crash.
The kernel does show that pstore_blk was used for all 3 types of kmsg,
pmsg and console:
[ 28.649514] pstore_zone: capping size to 128MiB
[ 28.712894] pstore_zone: registered pstore_blk as backend for
kmsg(Oops) pmsg console
[ 28.721145] pstore: Using crash dump compression: deflate
[ 28.906253] printk: console [pstore_blk-1] enabled
[ 28.911229] pstore: Registered pstore_blk as persistent store backend
[ 28.917735] pstore_blk: attached pstore_blk:/dev/mmcblk1p9
(134217728) (no dedicated panic_write!)
there is no automatic reboot upon panic, so I just tend to reboot after
2-3 seconds manually. The kernel is configured with the default
CONFIG_PSTORE_* options.
Is the observed behavior a limitation of the best_effort mode? If so, do
we have any plans to implementing a non-best effort mode for eMMC devices?
Thanks!
--
Florian
next reply other threads:[~2022-07-15 3:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 3:49 Florian Fainelli [this message]
2022-08-09 18:35 ` Invalid pstore_blk use? Florian Fainelli
2022-08-09 23:06 ` Kees Cook
2022-11-18 20:41 ` Kamal Dasu
2022-12-07 18:31 ` Kamal Dasu
2022-12-07 22:13 ` Kees Cook
2022-12-09 21:19 ` Kamal Dasu
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=e97bc607-a913-dbbd-1965-b60d55d956b8@gmail.com \
--to=f.fainelli@gmail.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=gmpy.liaowx@gmail.com \
--cc=kdasu.kdev@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.