Re: [systemd-devel] systemd-udev causes slow boot and high load
Am 19.05.2015 um 18:32 schrieb Marco Steinacher: Am 19.05.2015 um 12:37 schrieb Lennart Poettering: On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Thank you for the swift reply and for clarifying the situation. I understand now that this is a kernel issue and not a problem with systemd. I'll try to track down the kernel issue now. Just for the record - in case somebody faces a similar issue and stumbles upon this thread: I solved the problem. It was embarrassingly simple: Loading the I2C driver JC42 with kernel 3.16.0 caused the irq 16: nobody cared issue and the subsequent timeouts. Removing the module jc42 from /etc/modules solved it! Thanks again and sorry for the noise on the wrong mailing list, Marco -- OpenPGP Key ID: 0x62937F7F ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udev causes slow boot and high load
On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udev causes slow boot and high load
Am 19.05.2015 um 12:37 schrieb Lennart Poettering: On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Thank you for the swift reply and for clarifying the situation. I understand now that this is a kernel issue and not a problem with systemd. I'll try to track down the kernel issue now. Thanks, Marco -- OpenPGP Key ID: 0x62937F7F ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
