** Description changed:
+ [Impact]
+
+ * Too small dmsg kernel buf ring size leads to loosing/missing early
+ boot kernel messages which happen before journald starts slurping them
+ up and storing them on disc. This results in messages similar to this
+ one on boot "missed NN kernel messages on boot". This is especially
+ pronounced on arm64 as the default setting there is way lower than any
+ other 32bit or 64bit architecture we ship. Also amd64 appears to have
+ the highest setting of 18 among all architectures we ship. The best
+ course of action to bump all 64bit arches to 18, and keep all 32bit
+ arches at the current & upstream default of 17.
+
+ [Test Case]
+
+ * $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT
+
+ on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18
+ on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17
+
+ * run systemd adt test, the boot-and-services test case should not fail
+ journald tests with "missed kernel messages" visible in the error logs.
+
+ [Regression Potential]
+
+ * Increasing the size of the log_buf, will increase kernel memory usage
+ which cannot be reclaimed. It will now become 256kb on arm64, ppc64el,
+ s390x instead of 8kB/128kb/128kb respectively. 32bit arches remain
+ unchanged at 128kb.
+
+ [Other Info]
+
+ * Original bug report
+
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
-
-
=== systemd ===
systemd, boot-and-services test case can bump the ring buffer before
running the tests.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
