Big delay (1/2min) upon boot before system responds

Support
1

Hi everybody,
I installed Manjaro (latest Gnome) on a new system and I noticed the following upon booting the system.
I use my mouse optical sensor (red led underneath) as a reference… I’ll explain it…
So I press the power button and the computer switches on. At that same time my mouse also switches on (with its optical sensor being on)… Then I got my MB splash screen…
Then I got a black screen (also at this moment my mouse sensor turns off) and some POST text (scrolling text from Linux), then again a black screen.
But at one moment the mouse cursor is displaying on the lower right corner.
After around half a minute, the login screen appears too.
But my mouse seems to be still off (no light from the sensor), and so my keyboard I guess since I cannot do anything. Nothing respond.
After a minute or two, when noticing my mouse sensor’s light switches on, I’m able to control the cursor and the keyboard works.

So something disable or inhibit my usb devices.

How I can further investigate?

I don’t remember what was the command to use to check the log of the boot…
Is it possible to find what’s causing this and if there’s a workaround?

Edit: Something very weird I noticed right now.
Once I’m logged in and everything is working…
If I unplug AND then replug my mouse OR my keyboard (only one of them at a time). The one being plugged is still working, and once I replug the unplugged one, it starts to work again… I want to say it’s the normal expected behaviour…
But if I unplug both my mouse and my keyboard and plug them again, nothing respond again for a solid ~1 to 2 minutes…

Edit 2: I’m not using USB hubs and this happens on both the front panel USB slots or the one at the rear.

2

Hey sanjibukai,

You can start with systemd-analyze blame and systemd-analyze blame --user commands.

Based on the output, you can get bearings for your next steps, hopefully.

1 Like
3 
1min 10.068s upower.service                                              
 29.034s plymouth-quit-wait.service                                  
  2.116s lvm2-pvscan@259:6.service                                   
  2.077s lvm2-pvscan@259:3.service                                   
  1.690s lvm2-pvscan@259:5.service                                   
   721ms dev-mapper-tt_vg\x2dlv_data.device                          
   601ms tlp.service                                                 
   567ms systemd-modules-load.service                                
   472ms systemd-random-seed.service                                 
   395ms lvm2-monitor.service                                        
   312ms var-lib-snapd-snap-gtk\x2dcommon\x2dthemes-1514.mount       
   300ms var-lib-snapd-snap-snapd-11036.mount                        
   235ms var-lib-snapd-snap-kde\x2dframeworks\x2d5\x2dcore18-32.mount
   226ms var-lib-snapd-snap-core18-1988.mount                        
   198ms snapd.service                                               
   165ms dev-loop0.device                                            
   144ms user@1000.service                                           
   128ms dev-loop1.device                                            
   113ms boot-efi.mount                                              
    81ms dev-loop2.device                                            
    78ms systemd-udev-trigger.service                                
    68ms systemd-journald.service                                    
    66ms systemd-udevd.service                                       
    65ms polkit.service                                              
    64ms systemd-journal-flush.service                               
    55ms fprintd.service                                             
    53ms geoclue.service                                             
    49ms dev-loop3.device                                            
    44ms systemd-logind.service                                      
    43ms NetworkManager.service                                      
    38ms udisks2.service                                             
    32ms ModemManager.service                                        
    25ms systemd-rfkill.service                                      
    23ms dev-mapper-tt_vg\x2dswap_lv.swap                            
    22ms systemd-vconsole-setup.service                              
    19ms cups.service                                                
    17ms plymouth-start.service                                      
    16ms systemd-binfmt.service                                      
    15ms linux-module-cleanup.service                                
    14ms dev-hugepages.mount                                         
    14ms dev-mqueue.mount                                            
    14ms systemd-tmpfiles-setup.service                              
    13ms sys-kernel-debug.mount                                      
    12ms plymouth-read-write.service                                 
    12ms modprobe@fuse.service                                       
    12ms sys-kernel-tracing.mount                                    
    12ms gdm.service

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

Does this mean something?
The longer delay shown here is the thing called upower.service, could it be that?
BTW it’s a dektop computer and has no battery (precising in case upower is related to power management of laptops…)

Edit:
It seems indeed that the problem is about upower…
I saw that this command might helped too:

~> sudo systemd-analyze critical-chain                                                                                                                                                                
graphical.target @30.102s
└─multi-user.target @30.102s
  └─plymouth-quit-wait.service @1.067s +29.034s
    └─systemd-user-sessions.service @1.059s +5ms
      └─nss-user-lookup.target @1.105s

But I’m still not sure what to do with that…

4

Can you check the output of systemctl status upower.service?

it should contain the path to the service and I’m expecting to be something like /usr/lib/systemd/system/upower.service

Then you can use cat /usr/lib/systemd/system/upower.service to check what is the path to run the it manually and see some more details, e.g. /usr/lib/upowerd --verbose

Also, you can find something useful with journalctl -xe

1 Like
5

Hello @sanjibukai :wink:

Sounds more like an aggressive usb suspend…

In /etc/tlp.conf you can disable it with:

USB_AUTOSUSPEND=0

or even just blacklist some devices with:

USB_BLACKLIST="1111:2222"

On my workstation i had another behavior… It says at the Xorg logs that my machine was too slow, but actually my mouse and keyboard were suspending after x minutes and don’t react.

Maybe it helps :wink:

1 Like
6

Hello !

Here is the output (link to raw pastebin)
I saw many failed, etc… Maybe that’s the problem?
And I also noticed that on some USB related paths there is also PCI related stuff, e.g: failed to coldplug /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/usb1

Hi @megavolt :wink:
I did simply changed that option to USB_AUTOSUSPEND=0 since I was not sure what are the USB device that can cause the problem and how to identify them (guess lsusb)…
But that didn’t change anything unfortunately.
Oh BTW here is the output of lsusb if it can help…

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 047d:8018 Kensington Expert Wireless TB
Bus 001 Device 007: ID 1c4f:0034 SiGma Micro XM102K Optical Wheel Mouse
Bus 001 Device 006: ID 2516:0014 Cooler Master Co., Ltd. Storm Quick Fire TK Nkeys
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Here it says I have some USB HUB, but I didn’t… I have only my keyboard and trackball (and a mouse that I use as a sensor :sweat_smile: )

Weird :confused:

7

It is a root hub… fully normal.

You can try:

lsusb -vt

to see on which root hub it is connected.

Maybe switch your mouse&keyboard to a 2.0 root hub? Could be possible that the 3.0 root hub cause this problem…

1 Like
8

Thanks!

Here is the output of lsusb -vt:

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        ID 047d:8018 Kensington 
    |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        ID 047d:8018 Kensington 
    |__ Port 11: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        ID 2516:0014 Cooler Master Co., Ltd. Storm Quick Fire TK Nkeys
    |__ Port 11: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        ID 2516:0014 Cooler Master Co., Ltd. Storm Quick Fire TK Nkeys
    |__ Port 14: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 1c4f:0034 SiGma Micro XM102K Optical Wheel Mouse

There all plugged on the front panel and it seems there are all plugged on the 1d6b:0002 USB 2.0 root hub which is weird because two of the 4 ports I have on the front panels are labeled USB 3.0 (and are blue).
I’ll try to change the slots to see…
Will update…

9

Ok it’s still weird, because on my back panel, I only have USB 3.0 ports (all of them are blue and labeled USB 3.0 and one is even light blue…)
So I tried to plug my keyboard on each port and ran again the lsusb -vt and it always appear on one of the USB 2.0 root hub…
Never on any of the USB 3.0 root hub… S maybe it’s because there are USB 2.0 devices?

10

Yeah possible… but what says:

sudo tlp-stat --usb

:question:

1 Like
11

@sanjibukai you can try to stop upower.service sudo systemctl stop upower.service and check if all your HW works OK.

If yes, then you can disable and mask the service,

sudo systemctl disable upower.service
sudo systemctl mask upower.service

reboot and check again the timing with systemd-analyze blame. Not elegant by any means :wink:

As for your keyboard, Cooler Master Storm Quick Fire TK - it uses USB 2.0 interface.

1 Like
12

I tried using a usb 3.0 drive, and indeed for this it was displayed under the correct USB 3.0 root hub.
However, since the last time I re-installed quite a few time in order to test other things (this problem was still there however even on KDE Manjaro)…

But something strange is that this doesn’t happen on the USB live stick (upower.service took only 100ms).

I’ll try to update later one I’ll make my final installation (I’m still trying some things…)

13

It seems my problem was related to the Bluetooth module…
In fact my Bluetooth wasn’t working… Until now I didn’t care…
But I managed to solve that (explained here No Bluetooth settings available (having a dual WIFI/BT card) - #7 by sanjibukai) and this also solved my long delay…

Now systemd-analyze blame displays something like 6 seconds…

Edit: the exact fix for the delay in my case was to set bt_coex_active=Y in /etc/modprobe.d/iwlwifi.conf

14

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.