[opensuse-kernel] Boot to kernel-xen 3.19.4 fails to "Start Load Kernel Modules" because it can't "find module 'xen-acpi-processor'". Is this bug or config?
![](https://seccdn.libravatar.org/avatar/ab45a2435cd3d6457b6510bb63114bed.jpg?s=120&d=mm&r=g)
After booting to uname -r 3.19.4-1.g74c332b-xen Boot log fails include dmesg | grep -i modules [ 0.144000] Modules linked in: [ 4.357642] systemd[1]: Failed to start Load Kernel Modules. [ 25.284199] systemd-modules-load[779]: Inserted module 'pciback' [ 35.284122] systemd-modules-load[779]: Failed to find module 'xen-acpi-processor' [ 45.312110] systemd-modules-load[779]: Inserted module 'blktap2' [ 47.972022] systemd[1]: Failed to start Load Kernel Modules. Systemd's service fails systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since Sat 2015-04-18 14:59:05 PDT; 27min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 779 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 779 (code=exited, status=1/FAILURE) The module exists locate xen | grep acpi | grep proc | grep 3.19.4 /lib/modules/3.19.4-1.g74c332b-xen/kernel/drivers/acpi/processor.ko is not loaded after boot lsmod | grep acpi acpi_pad 12960 0 Can't be loaded by the given name modprobe xen-acpi-processor modprobe: FATAL: Module xen-acpi-processor not found. And isn't mentioned (as CONFIG_XEN_ACPI_PROCESSOR) in the kernel config grep PROCESSOR /boot/config-3.19.4-1.g74c332b-xen # CONFIG_PROCESSOR_SELECT is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_PROCESSOR_EXTERNAL_CONTROL=y On this server xenpm get-cpufreq-states cpu id : 0 total P-states : 16 usable P-states : 16 current frequency : 800 MHz P0 [3101 MHz]: transition [ 314] residency [ 13730 ms] P1 [3100 MHz]: transition [ 4] residency [ 23 ms] P2 [2900 MHz]: transition [ 2] residency [ 21 ms] P3 [2800 MHz]: transition [ 7] residency [ 33 ms] P4 [2600 MHz]: transition [ 5] residency [ 4 ms] P5 [2400 MHz]: transition [ 4] residency [ 0 ms] P6 [2300 MHz]: transition [ 3] residency [ 21 ms] P7 [2100 MHz]: transition [ 8] residency [ 30 ms] P8 [1900 MHz]: transition [ 5] residency [ 2 ms] P9 [1800 MHz]: transition [ 12] residency [ 56 ms] P10 [1600 MHz]: transition [ 5] residency [ 13 ms] P11 [1500 MHz]: transition [ 7] residency [ 39 ms] P12 [1300 MHz]: transition [ 8] residency [ 34 ms] P13 [1100 MHz]: transition [ 5] residency [ 33 ms] P14 [1000 MHz]: transition [ 20] residency [ 123 ms] *P15 [ 800 MHz]: transition [ 296] residency [ 6896 ms] xenpm get-cpufreq-para cpu id : 0 affected_cpus : 0 cpuinfo frequency : max [3101000] min [800000] cur [3100000] scaling_driver : acpi-cpufreq scaling_avail_gov : userspace performance powersave ondemand current_governor : ondemand ondemand specific : sampling_rate : max [10000000] min [10000] cur [20000] up_threshold : 80 scaling_avail_freq : 3101000 3100000 2900000 2800000 2600000 2400000 2300000 2100000 1900000 1800000 1600000 1500000 1300000 1100000 1000000 *800000 scaling frequency : max [3101000] min [800000] cur [800000] turbo mode : enabled [CPU1] failed to get cpufreq parameter [CPU2] failed to get cpufreq parameter [CPU3] failed to get cpufreq parameter I want to fix, or avoid, the on-boot systemd failure. Is this a bug, or a config fix? LT -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
В Sat, 18 Apr 2015 15:48:56 -0700 lyndat3@your-mail.com пишет:
After booting to
uname -r 3.19.4-1.g74c332b-xen
Boot log fails include
dmesg | grep -i modules [ 0.144000] Modules linked in: [ 4.357642] systemd[1]: Failed to start Load Kernel Modules. [ 25.284199] systemd-modules-load[779]: Inserted module 'pciback' [ 35.284122] systemd-modules-load[779]: Failed to find module 'xen-acpi-processor' [ 45.312110] systemd-modules-load[779]: Inserted module 'blktap2' [ 47.972022] systemd[1]: Failed to start Load Kernel Modules.
Systemd's service fails
systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since Sat 2015-04-18 14:59:05 PDT; 27min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 779 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 779 (code=exited, status=1/FAILURE)
The module exists
locate xen | grep acpi | grep proc | grep 3.19.4 /lib/modules/3.19.4-1.g74c332b-xen/kernel/drivers/acpi/processor.ko
It is processor.ko, not xen-acpi-processor.ko
is not loaded after boot
lsmod | grep acpi acpi_pad 12960 0
Can't be loaded by the given name
modprobe xen-acpi-processor modprobe: FATAL: Module xen-acpi-processor not found.
And isn't mentioned (as CONFIG_XEN_ACPI_PROCESSOR) in the kernel config
grep PROCESSOR /boot/config-3.19.4-1.g74c332b-xen # CONFIG_PROCESSOR_SELECT is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_PROCESSOR_EXTERNAL_CONTROL=y
On this server
xenpm get-cpufreq-states cpu id : 0 total P-states : 16 usable P-states : 16 current frequency : 800 MHz P0 [3101 MHz]: transition [ 314] residency [ 13730 ms] P1 [3100 MHz]: transition [ 4] residency [ 23 ms] P2 [2900 MHz]: transition [ 2] residency [ 21 ms] P3 [2800 MHz]: transition [ 7] residency [ 33 ms] P4 [2600 MHz]: transition [ 5] residency [ 4 ms] P5 [2400 MHz]: transition [ 4] residency [ 0 ms] P6 [2300 MHz]: transition [ 3] residency [ 21 ms] P7 [2100 MHz]: transition [ 8] residency [ 30 ms] P8 [1900 MHz]: transition [ 5] residency [ 2 ms] P9 [1800 MHz]: transition [ 12] residency [ 56 ms] P10 [1600 MHz]: transition [ 5] residency [ 13 ms] P11 [1500 MHz]: transition [ 7] residency [ 39 ms] P12 [1300 MHz]: transition [ 8] residency [ 34 ms] P13 [1100 MHz]: transition [ 5] residency [ 33 ms] P14 [1000 MHz]: transition [ 20] residency [ 123 ms] *P15 [ 800 MHz]: transition [ 296] residency [ 6896 ms]
xenpm get-cpufreq-para cpu id : 0 affected_cpus : 0 cpuinfo frequency : max [3101000] min [800000] cur [3100000] scaling_driver : acpi-cpufreq scaling_avail_gov : userspace performance powersave ondemand current_governor : ondemand ondemand specific : sampling_rate : max [10000000] min [10000] cur [20000] up_threshold : 80 scaling_avail_freq : 3101000 3100000 2900000 2800000 2600000 2400000 2300000 2100000 1900000 1800000 1600000 1500000 1300000 1100000 1000000 *800000 scaling frequency : max [3101000] min [800000] cur [800000] turbo mode : enabled
[CPU1] failed to get cpufreq parameter [CPU2] failed to get cpufreq parameter [CPU3] failed to get cpufreq parameter
I want to fix, or avoid, the on-boot systemd failure.
Remove file that loads non-existing module.
Is this a bug, or a config fix?
rpm -qf /file/that/loads/xen-acpi-processor and open bug report against this RPM.
LT
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/ab45a2435cd3d6457b6510bb63114bed.jpg?s=120&d=mm&r=g)
On Sat, Apr 18, 2015, at 11:12 PM, Andrei Borzenkov wrote:
and open bug report against this RPM.
Thanks. Not clear to me if the fix should be in xen-tools, providing the missing module, or checks for 'exist?' in systemd's loader. Filed @ Xen, https://bugzilla.opensuse.org/show_bug.cgi?id=927750 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
В Sun, 19 Apr 2015 08:24:10 -0700 lyndat3@your-mail.com пишет:
On Sat, Apr 18, 2015, at 11:12 PM, Andrei Borzenkov wrote:
and open bug report against this RPM.
Thanks.
Not clear to me if the fix should be in xen-tools, providing the missing module, or checks for 'exist?' in systemd's loader.
systemd-modules-load just loads what it had been told. If it is missing, it is an error. Silently (or even not silently) ignoring missing modules would mean real errors will go unnoticed.
Filed @ Xen, https://bugzilla.opensuse.org/show_bug.cgi?id=927750
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/a961d54b41a44a48c5241aab3571178f.jpg?s=120&d=mm&r=g)
On Sun, Apr 19, Andrei Borzenkov wrote:
systemd-modules-load just loads what it had been told. If it is missing, it is an error. Silently (or even not silently) ignoring missing modules would mean real errors will go unnoticed.
A real error is if some other package relying on a possibly missing driver fails. Marking missing modules as failure without providing conditionals depending on source and .config is just dumb. Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
В Mon, 20 Apr 2015 17:38:50 +0200 Olaf Hering <olaf@aepfle.de> пишет:
On Sun, Apr 19, Andrei Borzenkov wrote:
systemd-modules-load just loads what it had been told. If it is missing, it is an error. Silently (or even not silently) ignoring missing modules would mean real errors will go unnoticed.
A real error is if some other package relying on a possibly missing driver fails.
It does not rely on anything. It simply loads what you told it to load and informs you if it failed.
Marking missing modules as failure without providing conditionals depending on source and .config is just dumb.
Add generator that drops modules to be loaded in /run/modules-load.d based on whatever condition is appropriate. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/a961d54b41a44a48c5241aab3571178f.jpg?s=120&d=mm&r=g)
On Mon, Apr 20, Andrei Borzenkov wrote:
В Mon, 20 Apr 2015 17:38:50 +0200 Olaf Hering <olaf@aepfle.de> пишет:
On Sun, Apr 19, Andrei Borzenkov wrote:
systemd-modules-load just loads what it had been told. If it is missing, it is an error. Silently (or even not silently) ignoring missing modules would mean real errors will go unnoticed. A real error is if some other package relying on a possibly missing driver fails. It does not rely on anything. It simply loads what you told it to load and informs you if it failed.
Yes, but thats not what I wrote. systemd-modules-load has to be a dumb service, its not allowed to report any errors. The true errors may be reported by the apps which actually rely on a listed driver.
Marking missing modules as failure without providing conditionals depending on source and .config is just dumb.
Add generator that drops modules to be loaded in /run/modules-load.d based on whatever condition is appropriate.
In that case such generator can load the module right away. Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/d85e7926e3558bc23df7a4eb6c8a7c5e.jpg?s=120&d=mm&r=g)
On 19.04.15 at 17:24, <lyndat3@your-mail.com> wrote: On Sat, Apr 18, 2015, at 11:12 PM, Andrei Borzenkov wrote: and open bug report against this RPM.
Thanks.
Not clear to me if the fix should be in xen-tools, providing the missing module, or checks for 'exist?' in systemd's loader.
xen-tools can't possibly provide this (kernel) module. The module in question is a pv-ops one, i.e. should only be attempted to be loaded on pv-ops (i.e. the relatively new -pv flavor) kernels. Or, if the intention is to simply try both variants, ignore errors from one of the load attempts when the other succeeded. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/ab45a2435cd3d6457b6510bb63114bed.jpg?s=120&d=mm&r=g)
On Mon, Apr 20, 2015, at 01:08 AM, Jan Beulich wrote:
xen-tools can't possibly provide this (kernel) module. The module in question is a pv-ops one, i.e. should only be attempted to be loaded on pv-ops (i.e. the relatively new -pv flavor) kernels. Or, if the intention is to simply try both variants, ignore errors from one of the load attempts when the other succeeded.
I'm just running non-pvops kernel-xen from opensuse's KernelStable repos. As mentioned at the bug, https://bugzilla.opensuse.org/show_bug.cgi?id=927750, xen-tools atm tries to load xen-acpi-processor module from /usr/lib/modules-load.d/xen.conf. Afaict there's no such condition on the load. It's there if xen-tools is installed. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (4)
-
Andrei Borzenkov
-
Jan Beulich
-
lyndat3@your-mail.com
-
Olaf Hering