Michael Ellerman [off-list ref] writes:
Joel Stanley [off-list ref] writes:
quoted
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 :)
quoted
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;
}