Michael Ellerman <[email protected]> writes:
> Joel Stanley <[email protected]> writes:
>
>> The OPAL memory console is reported to be size zero, as we do not
>> initialise the struct attr with any size information due to the size
>> being variable. This leads users to think that the console is empty.
>
> Hmm OK. That is a general property of /proc and /sys files that are
> dynamically generated, so users probably need to get used to it :)
>
>> Instead report the maximum size.
>
> But OK. That sounds sane enough. My only worry is that it might confuse
> some tools, ie. the file claims to be x bytes but is actually smaller.
> But I guess that can actually happen anyway with any file.
>
> So I'll merge this and stop blabbing :)
Hmm, but then I get:
$ ls -la msglog
-r--r--r-- 1 root root 4503599627370496 Jan 25 13:09 msglog
I know firmware likes to spit out lots of messages, but 4PB seems a bit
large :P
I fixed it with the patch below which I'll fold in, resulting in:
$ ls -la msglog
-r--r--r-- 1 root root 1048576 Jan 25 13:30 msglog
Which seems more likely.
cheers
diff --git a/arch/powerpc/platforms/powernv/opal-msglog.c
b/arch/powerpc/platforms/powernv/opal-msglog.c
index 8486b2ceb510..7a9cde0cfbd1 100644
--- a/arch/powerpc/platforms/powernv/opal-msglog.c
+++ b/arch/powerpc/platforms/powernv/opal-msglog.c
@@ -124,8 +124,8 @@ void __init opal_msglog_init(void)
}
/* Report maximum size */
- opal_msglog_attr.size = be64_to_cpu(mc->ibuf_size) +
- be64_to_cpu(mc->obuf_size);
+ opal_msglog_attr.size = be32_to_cpu(mc->ibuf_size) +
+ be32_to_cpu(mc->obuf_size);
opal_memcons = mc;
}
