Re: [PATCH v1 0/3] allow ramoops to collect all kmesg_dump events

[Pavel Tatashin]

> > # reboot -f
> >
> > After VM is back:
> >
> > # mount -t pstore pstore /mnt
> > # head /mnt/dmesg-ramoops-0
> > Restart#1 Part1
>
> Is there a reason that using ramoops.console_size isn't sufficient for
> this?

Unfortunately, the console option is not working for us (Microsoft),
we have an embedded device with a serial console, and the baud rate
reduces the reboot performance, so we must keep the console quiet. We
also want to be able collect full shutdown logs from the field that
are collected during kexec based updates.

>
> I'm not strictly opposed to making these changes, but traditionally the
> granularity of dmesg output has been pretty easily "all or crashes"
> instead of a range within.

As of now, ramoops  allows collecting dmesg only for oops and panic,
but not for all types of events.

Thank you,
Pasha

On Mon, May 4, 2020 at 2:14 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Sat, May 02, 2020 at 10:35:52AM -0400, Pavel Tatashin wrote:
> > Currently, ramoops is capable to collect dmesg buffer only during
> > panic and oops events. However, it is desirable for shutdown performance
> > analysis reasons to optionally allow collecting dmesg buffers during other
> > events as well: reboot, kexec, emergency reboot etc.
> >
> > How to quickly test:
> >
> > virtme-run --mods=auto --kdir --mods=auto --kdir . \
> >       -a memmap=1G$8G -a ramoops.mem_address=0x200000000 \
> >       -a ramoops.mem_size=0x100000 -a ramoops.record_size=32768 \
> >       -a ramoops.dump_all=1 -a quiet --qemu-opts -m 8G
> > ..
> > # reboot -f
> >
> > After VM is back:
> >
> > # mount -t pstore pstore /mnt
> > # head /mnt/dmesg-ramoops-0
> > Restart#1 Part1
>
> Is there a reason that using ramoops.console_size isn't sufficient for
> this?
>
> I'm not strictly opposed to making these changes, but traditionally the
> granularity of dmesg output has been pretty easily "all or crashes"
> instead of a range within.
>
> --
> Kees Cook