Bug 907393

obviously systemd-udev-settle.service should not take 2 minutes

Please provide output from hwinfo --all
or at least some overview of what disks / FS / LVM is used on the system

Do you have Intel wireless adapter? using iwlwifi?

Here's my hardware information: https://dl.dropboxusercontent.com/u/44544435/Hardware%20Info

I've got two hard disks with 2 partitions on each. My /home partition is on one of them and it uses BtrFS. My system is on a partition on the other hard disk and it also uses BtrFS. The second partition on the system's hard drive uses ext4 and it mounts as /storage. It's about 600 GiB and it mainly contains media. The fourth partition is not mounted at boot and is empty. 
The /home disk drive is an HDD with 1 TB capacity and the other is also an HDD with 750GiB capacity.

Also, I use a cable to connect to the internet, not wifi.

Antoine, try to boot with udev.log-priority=debug and attach the output of:

journalctl -abx or /var/log/messages ?

Sorry, journalctl -axb :)

There you go. I deleted some of the log parts when it comes to gnome-session due to privacy. 
I don't think that would matter though.
https://dl.dropboxusercontent.com/u/44544435/log.txt
Also, I came across this, it might be helpful: https://bugzilla.redhat.com/show_bug.cgi?id=670964

Well the log doesn't help at all, don't see any udev debug messages. The bug which you are referring to has nothing to do with this.

Again, are you sure you booted with 'udev.log-priority=debug' ?

here are the contents of udev.conf. Am I missing something?
http://paste.opensuse.org/25026496

Antoine, the udev.log-priority=debug should be used at boot time, not in udev.conf.

That means to edit grub and add the line to  linux /boot/....

Check the screenshot: http://paste.opensuse.org/28834109

There you go: https://dl.dropboxusercontent.com/u/44544435/log.txt

NB: I've noticed that the booting process is faster after I edited the udev.conf

Well, first of all, from the logs I can see that the number of children is limited to 16, why is that?

Second, I dont see anything saying that it should not work, all seems OK, besides the fact that you limited the number of udev children.

Nov 27 19:10:58 linux-zfgp systemd-udevd[403]: maximum number (16) of children reached

In the logs I see more then 600 of this messages. 

Whats the output of /proc/cmdline

Never mind with the /proc/cmdline, don't understand why you have that? 16 maximum allow children?

As you may have guessed, I am not an expert on the lower level systems. I have no idea why the limit is 16 and you can be damn sure that I did not tamper with it myself. I just installed openSUSE 13.2 and left it as it is. I tweaked the DE and installed Nvidia's binary blob but that's about it.

How much RAM and how many CPUs do you have?

5.8 GiB of Ram and four cores.

OK, I'm working on it and it might be after all a bug in udev.

Trying out a patch, will let you know tomorrow.

Antoine, can you please go to: http://beta.suse.com/private/rmilasan/bnc-907393

Download the udev rpms and install the following (as root, of course):

rpm -Uhv udev-210-894.1.x86_64.rpm \
libudev1-210-894.1.x86_64.rpm \
libgudev-1_0-0-210-894.1.x86_64.rpm

and then reboot your machine.

Success! Boot time now takes 51 seconds. 
  12.015s postfix.service
         10.944s SuSEfirewall2.service
         10.212s SuSEfirewall2_init.service
          6.167s systemd-udev-settle.service
          4.987s ModemManager.service
          4.826s home.mount
          4.334s systemd-remount-fs.service
          4.321s sys-kernel-debug.mount
          4.321s dev-mqueue.mount
          4.320s dev-hugepages.mount
          4.083s display-manager.service
          3.591s rsyslog.service
          3.043s NetworkManager.service
          3.025s packagekit.service
          2.554s console-kit-log-system-start.service
          2.554s alsa-restore.service
          2.540s vboxadd.service
          2.539s systemd-user-sessions.service
          2.536s avahi-daemon.service
          2.536s wpa_supplicant.service
          2.350s nscd.service
          2.267s rc-local.service
          1.861s polkit.service
          1.799s apparmor.service
          1.502s systemd-fsck@dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dp
           821ms cycle.service
           807ms sshd.service
           746ms console-kit-daemon.service
           730ms colord.service
           714ms systemd-tmpfiles-setup-dev.service
           698ms systemd-tmpfiles-setup.service
           525ms dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dpart3.swap
           455ms rtkit-daemon.service
           335ms plymouth-read-write.service
           318ms systemd-udev-trigger.service
           312ms systemd-udev-root-symlink.service
           298ms lvm2-activation-early.service
           275ms accounts-daemon.service
           253ms udisks2.service
           211ms systemd-random-seed.service
           211ms systemd-journal-flush.service
           209ms iscsi.service
           193ms systemd-logind.service
           182ms bluetooth.service
           164ms storage.mount
           135ms lvm2-activation.service
           113ms user@1000.service
           106ms systemd-readahead-replay.service
           101ms upower.service
            98ms systemd-readahead-done.service
            82ms systemd-readahead-collect.service
            79ms systemd-update-utmp.service
            73ms user@485.service
            33ms systemd-udevd.service
            19ms systemd-sysctl.service
            18ms systemd-modules-load.service
            14ms systemd-vconsole-setup.service
            14ms plymouth-start.service
            13ms geoclue.service
             3ms systemd-update-utmp-runlevel.service
             3ms sys-fs-fuse-connections.mount
             3ms kmod-static-nodes.service
             3ms systemd-localed.service

Superb, so we have a udev bug.

Will try to push the fix to upstream and to openSUSE also.

Thank you very much for testing and helping out.

False positive. The bug is back.
  1min 46.739s systemd-udev-settle.service
          8.937s packagekit.service
          6.715s SuSEfirewall2_init.service
          6.092s systemd-tmpfiles-clean.service
          5.742s lvm2-activation-early.service
          5.213s home.mount
          4.651s colord.service
          4.386s ModemManager.service
          3.645s display-manager.service
          3.519s postfix.service
          3.309s NetworkManager.service
          3.298s rsyslog.service
          3.263s systemd-fsck@dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dpart1.service
          2.779s SuSEfirewall2.service
          2.756s udisks2.service
          2.665s sys-kernel-debug.mount
          2.664s dev-mqueue.mount
          2.663s dev-hugepages.mount
          2.345s alsa-restore.service
          2.345s console-kit-log-system-start.service
          2.331s vboxadd.service
          2.331s systemd-user-sessions.service
          2.328s avahi-daemon.service
          2.328s wpa_supplicant.service
          2.218s systemd-remount-fs.service
          2.132s nscd.service
          1.981s rc-local.service
          1.869s apparmor.service
          1.838s polkit.service
          1.269s systemd-tmpfiles-setup-dev.service
          1.018s rtkit-daemon.service
          1.014s sshd.service
           987ms bluetooth.service
           913ms dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dpart3.swap
           762ms console-kit-daemon.service
           735ms cycle.service
           680ms systemd-random-seed.service
           617ms systemd-tmpfiles-setup.service
           593ms systemd-udev-trigger.service
           496ms systemd-udev-root-symlink.service
           390ms systemd-readahead-replay.service
           298ms plymouth-read-write.service
           272ms storage.mount
           234ms systemd-journal-flush.service
           225ms iscsi.service
           171ms systemd-logind.service
           168ms systemd-modules-load.service

Well, enable udev.log-priority=debug and attach the logs again.

Here are the logs: https://dl.dropboxusercontent.com/u/44544435/log.txt

Also, 
it took the system 1 minute and 24 seconds to boot. The SUSE Firewall alone took 30 seconds to load. udev didn't hang this time. The boot times are varying and aren't consistent.
   32.345s SuSEfirewall2_init.service
         11.673s ModemManager.service
         10.837s rsyslog.service
          8.463s apparmor.service
          7.820s alsa-restore.service
          7.820s console-kit-log-system-start.service
          7.803s vboxadd.service
          7.802s systemd-user-sessions.service
          7.800s avahi-daemon.service
          7.798s wpa_supplicant.service
          7.788s nscd.service
          7.786s sys-kernel-debug.mount
          7.785s dev-mqueue.mount
          7.784s dev-hugepages.mount
          7.772s rc-local.service
          7.476s postfix.service
          7.070s systemd-remount-fs.service
          6.624s systemd-udev-settle.service
          5.910s home.mount
          5.399s display-manager.service
          3.219s polkit.service
          3.038s packagekit.service
          2.983s SuSEfirewall2.service
          1.959s systemd-logind.service
          1.785s NetworkManager.service
          1.157s sshd.service
           995ms bluetooth.service
           953ms colord.service
           777ms cycle.service
           767ms systemd-tmpfiles-setup-dev.service
           762ms systemd-udev-trigger.service
           669ms systemd-tmpfiles-setup.service
           569ms systemd-fsck@dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dp
           406ms rtkit-daemon.service
           362ms dev-disk-by\x2did-ata\x2dST3750640AS_3QD0G846\x2dpart3.swap
           334ms upower.service
           332ms plymouth-read-write.service
           238ms lvm2-activation-early.service
           225ms console-kit-daemon.service
           210ms systemd-journal-flush.service
           200ms iscsi.service
           191ms systemd-readahead-replay.service
           182ms udisks2.service
           164ms systemd-readahead-collect.service
           152ms systemd-sysctl.service
           123ms storage.mount
           112ms accounts-daemon.service
            89ms systemd-udev-root-symlink.service
            86ms systemd-udevd.service
            75ms user@1000.service
            61ms systemd-update-utmp.service
            43ms systemd-readahead-done.service
            28ms systemd-modules-load.service
            22ms lvm2-activation.service
            21ms systemd-random-seed.service
            16ms plymouth-start.service
            14ms systemd-vconsole-setup.service
            14ms geoclue.service
             4ms systemd-update-utmp-runlevel.service
             4ms kmod-static-nodes.service
             3ms sys-fs-fuse-connections.mount

This could be your own machine, I mean the hardware, but to be totally fair I wouldn't know for sure.

Can you try to downgrade udev to the original version, not the one from me and try a couple of reboots and systemd-analyze blame and maybe save them in 3-4 different log files to see the difference, if its not too much to ask.

I don't think it's my hardware since downgrading back to 13.1 solves the issue. I'm gathering the data you requested right now. I'll post it when I'm done.

https://dl.dropboxusercontent.com/u/44544435/blame1.log
https://dl.dropboxusercontent.com/u/44544435/blame2.log
https://dl.dropboxusercontent.com/u/44544435/blame3.log
Strangely enough, this long boot sequence is now happening only occasionally and not persistently like it did when I first reported the bug. The three logs have reasonable boot times.

Created attachment 616797 [details]
Hardware

I also have this systemd-udev-settle.service time delay with original udev-210-25.8.1.x86_64.

Created attachment 616799 [details]
journalctl-10.txt

Created attachment 616800 [details]
systemd-analyse-blame-10.txt

Created attachment 616801 [details]
journalctl-11.txt

Created attachment 616802 [details]
systemd-analyse-blame-11.txt

Created attachment 616803 [details]
journalctl-12.txt

Created attachment 616804 [details]
systemd-analyse-blame-12.txt

Created attachment 616805 [details]
journalctl-13.txt

Created attachment 616806 [details]
systemd-analyse-blame-13.txt

Created attachment 616807 [details]
journalctl-14.txt

Created attachment 616809 [details]
systemd-analyse-blame-14.txt

OK, looks to be a problem with kmod builtin as it doesn't have a timeout.

Werner, you create the patch for kmod from udev, do you have some ideas why is taking so long?

(In reply to Robert Milasan from comment #39)

The only explanation is that the kernel module takes this time.  As patch

  1087-infinit-timeout-for-kmod-loaded-modules.patch

has been added due bug #889297 to avoid that a running kmod/modprobe is killed and cause other troubles.  The patch also includes a kernel command line option

     udev.killkmod=1

which should allow udevd to kill a running kmod/modprobe. But be aware that this might cause other trouble (compare with bug #889297). The question rises what is better, a longer boot time to long running hardware and kernel driver  	initialization or an unstable system due a killed kmod/modprobe.

IMHO and due bug #889297 this is a kernel issue.  The kernel guys have 	ordered this patch know they have to fix the affected driver.

(In reply to Dr. Werner Fink from comment #40)
> IMHO and due bug #889297 this is a kernel issue.  The kernel guys have 
> ordered this patch know they have to fix the affected driver.

I was thinking the same, but as I didn't do the patch, don't wanna just talk for no good reason.

Who should we assign to the bug? Luiz?

Luis?  Here we have a bug report due long taking kmod caused by the requested patch to not killing kmod processes in udevd (bug #889297).

Which kernel module take long time to load?

The old firmware issue was already fixed, there should be no longer udev call but aborts immediately if no firmware file is found.  The rest are driver-specific issues, so we need to know which driver shows the behavior.

We are not talking about a certain kernel module, but kmod builtin from udev, which eats the time due to disabled timeout.

Please check comment #31

OK, then it's misunderstanding to say it's a kernel issue :)
It was initiated for workaround of other kernel issues, though.

(In reply to Takashi Iwai from comment #45)

Hmmm ... I had added this patch due to a request from the kernel guys. Without this patch it would not happen but killed after 30 seconds.  Please note that systemd/udevd uses libkmod.so by spawning a worker process to do the final load of the module(s).  AFAIK there is no API within libkmod to enable systemd/udevd to handle success or fail or timeouts (beside of missing dependencies or remove or insert a not existing module).

(In reply to Werner Fink from comment #40)
> (In reply to Robert Milasan from comment #39)
> 
> The only explanation is that the kernel module takes this time.

Which kernel module?

>  As patch
> 
>   1087-infinit-timeout-for-kmod-loaded-modules.patch
> 
> has been added due bug #889297 to avoid that a running kmod/modprobe is
> killed and cause other troubles.  The patch also includes a kernel command
> line option
> 
>      udev.killkmod=1
> 
> which should allow udevd to kill a running kmod/modprobe.

Does that work around work?

> But be aware that
> this might cause other trouble (compare with bug #889297).

Indeed, its exactly why it was advised against the timeout to kill the driver, as the error paths could cause more issues than not.

> The question
> rises what is better, a longer boot time to long running hardware and kernel
> driver  	initialization or an unstable system due a killed kmod/modprobe.

The upstream agreed upon solution was to device async probe support in the kernel as that is what systemd wanted, and then let system use it. Kernel support for async probe support is underway, I'm ironing final kinks with Dmitry before posting a final patch set. If we want to test that set early I am comfortable with a patch set we can enable and if system wants it can opt in for it early on OpenSUSE. A module parameter would just need to be passed onto every module loaded through kmod.

> IMHO and due bug #889297 this is a kernel issue.

Its a long standing collateral design issue on systemd caused by folks making the assumption we probed asynchronously on modules. Upstream-wise we decided then to implement support for this but by no means can one then consider this a kernel issue as async probe is just about to get merged and its a new feature. Systemd design needs to be considered while we get this support upstream on the kernel.

> The kernel guys have  ordered this patch know they have to fix the affected driver.

Which driver?

If not a driver can you please explain exactly how the patch introduced is causing an issue if the patch was supposed to just to allow no timeout when loading modules with kmod?

Is not a kernel module, but exactly builtin kmod for udev.

If you check the logs, you'll see a lot of:

Dec 11 09:33:24 linux-oqld systemd-udevd[396]: Check if link configuration needs reloading.
Dec 11 09:33:27 linux-oqld systemd-udevd[396]: validate module index

One of the logs has this from 10:32 to 10:34, check comment #29.

I'm not sure whats going on, but seems to be builtin kmod issue.

Lets ask the reporters to check with 'udev.killkmod=1'.

@Julian, can you please boot your machine with 'udev.killkmod=1' and check the times?

Sorry, I made a small mistake, but seems to be that the net_setup_link to be involved in this, together with builtin kmod. Don't exactly know why.

(In reply to Robert Milasan from comment #49)
> Sorry, I made a small mistake, but seems to be that the net_setup_link to be
> involved in this, together with builtin kmod. Don't exactly know why.

OK -- and just to be clear the original suggestion was to devise a non-timeout only for kmod built-in cmds, that would rule out other non-kmod threads from going afoul. If this is still the issue then I'd hope the patch can be altered to only avoid the timeout for kmod cmds.

Booting with 'udev.killkmod=1' does not reduce the time.

(In reply to Julian Ladisch from comment #51)

Are you sure that you do have written udev.killkmod=1 on the kernels command line  without a typo? Please run

  cat /proc/cmdline

and check, because the patch includes

+static bool event_killkmod = false;

[...]

+                } else if (startswith(opt, "udev.killkmod=")) {
+                        r = parse_boolean(opt + 14);
+                        if (r < 0)
+                                log_warning("Invalid udev.killkmod Ignoring: %s", opt + 14);
+                        else
+                                event_killkmod = r;

[...]

+                                if (udev_check_for_kmod(worker->pid)) {
+                                        log_debug("worker [%u] %s is using kmod", worker->pid, worker->event->devpath);
+                                        if (!event_killkmod)
+                                                continue;
+                                }

and that means that udev.killkmod=1 or udev.killkmod=yes or udev.killkmod=true should disable the effect of the check `udev_check_for_kmod(worker->pid)' on the fly

On the other hand Werner, it might not matter. For whatever reason it keep validating both kmod builtin and net_setup_link, but to be totally honest, don't know why.

I haven't been able to reproduce it which takes me to the idea is it somehow also network related and only happens in the normal system, not initrd.

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.6-2-desktop root=UUID=c8bea264-579c-4a11-a9af-5d1c072f2f36 ro resume=/dev/sda2 splash=silent quiet showopts udev.log-priority=debug udev.killkmod=1

I tried this cmdline with 
udev-210-25.8.1.x86_64 and with 
Robert Milasan's
rpm -Uhv udev-210-894.1.x86_64.rpm
libudev1-210-894.1.x86_64.rpm
libgudev-1_0-0-210-894.1.x86_64.rpm

It always takes 3 minutes.

Julian, I see some strange things comming from input7:

Dec 11 09:36:15 linux-oqld systemd-udevd[416]: slow: 'accelerometer /devices/platform/lis3lv02d/input/input7' [484]
Dec 11 09:36:16 linux-oqld.site systemd-udevd[416]: slow: 'accelerometer /devices/platform/lis3lv02d/input/input7' [484]
Dec 11 09:36:16 linux-oqld.site systemd-udevd[416]: 'accelerometer /devices/platform/lis3lv02d/input/input7' [484] terminated by signal 9 (Killed)

Can you please tell me what is input7?

# udevadm info /devices/platform/lis3lv02d/input/input7

Attach the output here please.

LIS3LV02DL is an onboard accelerometer:
http://www.ubuntu.com/certification/hardware/201403-14879/components/
http://www.st.com/web/catalog/sense_power/FM89/SC444/PF127514

linux-oqld:~ # udevadm info --path=/devices/platform/lis3lv02d/input/input7    
P: /devices/platform/lis3lv02d/input/input7
E: ABS=7
E: DEVPATH=/devices/platform/lis3lv02d/input/input7
E: EV=9
E: ID_FOR_SEAT=input-platform-lis3lv02d
E: ID_INPUT=1
E: ID_INPUT_ACCELEROMETER=1
E: ID_PATH=platform-lis3lv02d
E: ID_PATH_TAG=platform-lis3lv02d
E: MODALIAS=input:b0019v0000p0000e0000-e0,3,kra0,1,2,mlsfw
E: NAME="ST LIS3LV02DL Accelerometer"
E: PHYS="lis3lv02d/input0"
E: PRODUCT=19/0/0/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=644699

Is there a way to boot your machine without this device? Just disable it for one time?

I couldn't find a bios option to disable the device, but commenting out the rule in /usr/lib/udev/rules.d/61-accelerometer.rules yields a fast boot without 3 minutes delay.

openSUSE-RU-2015:0214-1: An update that has 16 recommended fixes can now be installed.

Category: recommended (important)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,906709,907318,907393,908476,910643,912030
CVE References: 
Sources used:
openSUSE 13.2 (src):    systemd-210-25.12.1, systemd-mini-210-25.12.1

SUSE-RU-2015:0638-1: An update that has 21 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,905550,906709,907318,907393,908476,910315,910643,911347,912030,916420,918118
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2
SUSE Linux Enterprise Server 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2
SUSE Linux Enterprise Desktop 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2

openSUSE-RU-2015:1969-1: An update that has 21 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,905550,906709,907318,907393,908476,910315,910643,911347,912030,916420,918118
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    aaa_base-13.2+git20140911.61c1681-7.1

openSUSE-RU-2016:0320-1: An update that has 146 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 737690,742774,750845,818044,838475,841544,849870,852015,852021,852232,853293,854884,856389,856392,856858,857204,858864,859072,859365,860574,860937,861316,861489,863217,864745,864904,865834,866732,866933,867128,867663,867664,867840,868019,868230,868439,868931,869142,869603,872929,873432,873444,874665,875502,876587,876694,877021,877674,878525,880438,880732,881125,881559,881942,882393,882714,883565,884271,884403,885232,885288,886211,886599,886852,888178,888215,888612,889297,889357,890977,892096,892162,892300,893797,895087,896664,897799,897801,897803,898233,898240,898432,900558,901481,902240,902901,903009,903963,904214,904517,904828,905550,906709,906900,907318,907393,908476,909358,910643,911347,912030,912334,913517,916420,918118,919095,920195,921831,921898,921920,926169,927250,927457,928265,931388,932284,933365,933512,933521,933533,934077,934901,937512,937900,938908,939571,940264,941576,944132,944799,945282,947212,948458,948555,948705,949574,949683,949739,950510,951265,951663,953241,954336,954781,955635,961576
CVE References: 
Sources used:
openSUSE 13.1 (src):    systemd-210-40.1, systemd-mini-210-40.1

Issue still occurring on Tumbleweed:
      2min 327ms systemd-udev-settle.service
          5.087s lvm2-activation-net.service
           612ms display-manager.service
           604ms apparmor.service
           495ms postfix.service
           434ms dev-sdb2.device
           276ms \x2esnapshots.mount
           275ms tmp.mount
           273ms boot-grub2-x86_64\x2defi.mount
           270ms var-spool.mount
           267ms usr-local.mount
           267ms var-lib-mailman.mount
           264ms opt.mount
           260ms var-lib-pgsql.mount
           254ms var-log.mount
           236ms var-opt.mount
           217ms var-lib-named.mount
           199ms systemd-fsck@dev-disk-by\x2duuid-d7212877\x2d25fc\x2d45dd\x2db1
           183ms srv.mount
           171ms cups.service
           164ms boot-grub2-i386\x2dpc.mount
           155ms var-tmp.mount
           117ms lvm2-activation-early.service

Working around a slow down on an accelerometer by disabling it through a script is not ideal because:

a) You are disabling it
b) Scripts change as the distribution evolves

The described device, the LIS3LV02DL accelerometer, seems to have a respective device driver, the "STMicroelectronics accelerometers 3-Axis Driver" enabled via IIO_ST_ACCEL_3AXIS which is the st_accel device driver. If this device driver is taking long and you want to enable it and avoid this long delay on boot, one way is to enable asynchronous probe one the device driver, its exactly what another vendor used to help avoid delay on boots on some device drivers. Asynchronous probe is now upstream. I've described how this functionality came about and future prospects for us here:

http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

Can someone confirm if the st_accel device driver is what takes for ever to load? Also did disabling the udev script disable loading the driver? If not what did it exactly do to help?

Seems this driver has an i2c and spi interface:

drivers/iio/accel/st_accel_i2c.c:       err = st_accel_common_probe(indio_dev);
drivers/iio/accel/st_accel_spi.c:       err = st_accel_common_probe(indio_dev);

The LIS3LV02DL device seems to be controlled through the i2c bus:

drivers/iio/accel/st_accel_i2c.c:               .data = LIS3LV02DL_ACCEL_DEV_NAME,

To use async probe we'll need to ensure upstream commit 4355efbd80482a961cae849281a8ef866e53d55c has already been merged on the Tumbleweed's kernel.

Anyway, if we want to try if this helps we can patch up the kernel as follows:

--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -134,6 +134,7 @@ static struct i2c_driver st_accel_driver = {
        .driver = {
                .name = "st-accel-i2c",
                .of_match_table = of_match_ptr(st_accel_of_match),
+               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
        },
        .probe = st_accel_i2c_probe,
        .remove = st_accel_i2c_remove,

This would be useful if the issue is just this device and we want to generalize a solution. If it does help it would be useful to understand later why the delay occurs for these devices and see if it makes sense to just enable for all such type of devices. Likewise systemd can now also just make use of the async probe for all modules provided commit 4355efbd80482a961cae849281a8ef866e53d55c is merged (or we just wait for the next release that has this fix merged and use it as of then.

openSUSE 13.2 reached EOL.  If the issue is still reproduced in the newer distro versions like openSUSE Leap, please open a new bug report.  Thanks.