linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: keescook@chromium.org, anton@enomsg.org, ccross@android.com,
	tony.luck@intel.com
Cc: linux-kernel@vger.kernel.org,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	gpiccoli@igalia.com, "Guilherme G. Piccoli" <kernel@gpiccoli.net>
Subject: pstore/ramoops - why only collect a partial dmesg?
Date: Wed, 29 Dec 2021 11:43:51 -0300	[thread overview]
Message-ID: <a21201cf-1e5f-fed1-356d-42c83a66fa57@igalia.com> (raw)

Hi Anton / Colin / Kees / Tony, I'd like to understand the rationale
behind a ramoops behavior, appreciate in advance any information/advice!

I've noticed that while using ramoops as a backend for pstore, only the
first "record_size" bytes of dmesg is collected/saved in sysfs on panic.
It is the "Part 1" of dmesg - seems this is on purpose [0], so I'm
curious on why can't we save the full dmesg split in multi-part files,
like efi-pstore for example?

If that's an interesting idea, I'm willing to try implementing that in
case there are no available patches for it already (maybe somebody
worked on it for their own usage). My idea would be to have a tuning to
enable or disable such new behavior, and we could have files like
"dmesg-ramoops-0.partX" as the partitions of the full "dmesg-ramoops-0".

Thanks in advance,


Guilherme


[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/pstore/ram.c#n353

             reply	other threads:[~2021-12-29 14:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 14:43 Guilherme G. Piccoli [this message]
2022-01-03 23:31 ` pstore/ramoops - why only collect a partial dmesg? Luck, Tony
2022-01-04 12:17   ` Guilherme G. Piccoli
2022-01-04 17:00     ` Luck, Tony
2022-01-04 18:03       ` Guilherme G. Piccoli
2022-01-04 18:46         ` Luck, Tony
2022-01-04 19:36           ` Guilherme G. Piccoli
2023-06-28 18:48             ` [PATCH] pstore: ramoops: support pmsg size larger than kmalloc limitation Yuxiao Zhang
2023-06-28 19:05               ` Guilherme G. Piccoli

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=a21201cf-1e5f-fed1-356d-42c83a66fa57@igalia.com \
    --to=gpiccoli@igalia.com \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=keescook@chromium.org \
    --cc=kernel@gpiccoli.net \
    --cc=linux-fsdevel@vger.kernel.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 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).