[PATCH 1/3] ARM: dts: rainier: Add reserved memory for ramoops

[Milton Miller II]

On October 5, 2020 about 10:23 in some timezone, Joel Stanley wrote:
>Subject: [EXTERNAL] Re: [PATCH 1/3] ARM: dts: rainier: Add reserved
>memory for ramoops
>
>On Fri, 2 Oct 2020 at 06:35, Andrew Jeffery <andrew at aj.id.au> wrote:
>>
>> Reserve a 1MiB region of memory to record kmsg dumps and console
>state
>> into 16kiB ring-buffer slots. The sizing allows for up to 32 dumps
>to be
>> captured and read out.
>>
>> Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>> ---
>>  arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
>b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
>> index e6f422edf454..46a0e95049fd 100644
>> --- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
>> +++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
>> @@ -47,6 +47,14 @@ reserved-memory {
>>                 #size-cells = <1>;
>>                 ranges;
>>
>> +               ramoops at b7f00000 {
>> +                       compatible = "ramoops";
>> +                       reg = <0xb7f00000 0x100000>;
>> +                       record-size = <0x4000>;
>> +                       console-size = <0x4000>;
>
>This is conserative. We've got plenty of space, how about we make it
>bigger?
>
>$ git grep console-size *.dts* | grep -Po "0x([0-9]+)" | xargs printf
>"%x\n" | sort -n
>8000
>8000
>10000
>10000
>20000
>20000
>20000
>20000
>20000
>60000
>100000
>
>The median is 128KB, which sounds reasonable.

How big is the dmesg after we are booted?   How big is the default 
kernel buffer for 2 cpus (the kernel config has a base size, but 
also a dynamic size with a base + n * cpu min at boot).

Having the console space larger than printk buffer will not help.

We could config the buffer up if we are not capturing enough of a 
boot and some runtime.

>
>$ git grep record-size *.dts* | grep -Po "0x([0-9]+)" | xargs printf
>"%x\n"
>20000
>400
>400
>20000
>20000
>20000
>10000
>10000
>10000
>10000
>20000
>
>64KB is the median record size.
>
This probably affects the effective compression, assuming
each block is a seperate compression input.

>> +                       pmsg-size = <0x4000>;
>
>Do we want to add ftrace too?
>
>Should we also add max-reason = KMSG_DUMP_EMERG?
>

The admin guide lists KMSG_DUMP_OOPS and KMSG_DUMP_PANIC ?
https://www.kernel.org/doc/html/latest/admin-guide/ramoops.html

We could have something monitoring for OOPS , copying to a log and 
then unlinking the pstore after committed.

>Logging reboots and shutdowns is informative (you know if a reboot
>was
>intentional or due to a crash that wasn't recorded) and allows for
>testing.
>

That should be exposed from audit logging?
but yes.

milton

>Cheers,
>
>Joel
>
>> +               };
>> +
>>                 flash_memory: region at B8000000 {
>>                         no-map;
>>                         reg = <0xB8000000 0x04000000>; /* 64M */
>> --
>> 2.25.1
>>
>
>