Attaching USB input devices is slow when laptop-mode-tools is installed (laptop_mode not running) #140
Labels
Comments
|
THis is working as designed. Laptop Mode Tools applies aggressive power savings by default. You can blacklist the relevant usb device in |
I have the same issue with a mouse and LMT. What do we actually need to write into |
|
@PF4Public I put those defaults keeping in mind that pluggable USB devices are something people would want to not have power savings enabled for. I just checked here locally to verify that is working or not. But, for me, a plugged-in usb mouse is working fine. This is what I have in And my external USB mouse is: As you can see, I haven't blacklisted the mouse's device id. Because the generic You can also tally the below reporting from It is unfortunate that the same is not working for you. Can you try out the things I have demoed above? |
|
I was also running into this with serial devices (Arduinos) that take a few seconds to get their udev rules applied, which sometimes causes firmware uploads to fail due to permissions not being set yet. I believe the problem is not so much that laptop-mode powersaving is applied for these devices, but that whenever any USB device is inserted, I wonder:
|
It actually seems there is already a (commented) rule in the udev rules file that seems to do just this: I just tried this, and that seems to be fast enough to make udev process the USB device a lot faster (250-300ms, vs 60-150ms when the udev rule is disabled completely, and just under 3s with the default rule). I measured these times by looking at |
laptop-mode rules apply almost at the end in the udev rules processing chain. When you say "delaying further processing of the USB device", do you mean the udev rules ? Because, given we run quite late in the chain, that shouldn't be the effect.
I'll have to dig the git history and the bug report. But yes, there were reasons to make this the default mode. I left the other option commented out for this very reason. If there are users that need further fine grained control, they could uncomment and use it.
|
In practice, I see that applying the What I suspect is that the add event for the USB device itself delays processing of the USB interfaces/subdevices, such as the serial device. Here's what All these kernel/cgroup lines seem to be generated by laptop-mode-tools (they are absent when I remove the lmt rule from udev). As you can see, at least some part of the ttyACM event is listed after all this cgroup stuff, so I suspect that the dialout rule happens there (though there is also a ttyACM event before the lmt stuff, so I'm not entirely sure how to interpret this output). |
|
I did a plug/unplug of my USB Type-C headphone and I don't get similar results. |
|
And this one, an add event, for a USB mouse |
|
I don't see By the time, lmt is processing your device (which where it just tries to switch on power saving knobs, if available), your device is supposed to be available and ready. I can't say for sure if the device's settling is hindered by lmt. It may just be giving you an impression given its runtime cost but I can't see any reason how it'd hinder |
Yes. THat could be a possibility. Depending on how many USB type sub-devices are generated. And how many In lmt, to ensure that we don't lose events, while at the same time to ensure that we don't get DoS-ed with too many events, we have a 2 lock system. The first event processing acquires lock-1, any follow-up event gets to acquire lock-2. All other events during that time span are let go off. When first event (that acquired lock-1) is complete, the second event (that acquired lock-2) is run. The average runtime that I calculated for an lmt invocation was around 4 seconds. But that was very limited to my setup. And the event that acquired lock-2 will loop for 10 seconds to see that event one is complete and that is can now acquire lock-1. This is by design, to ensure we don't lose events to process. |
It seems you don't have this cgroup stuff, but that might just be related to what lmt does exactly on my system. I do not think the cgroup stuff actually causes the problems, it's just an indication that lmt is doing something, the real problem is the delay it causes. In your last post about the mouse, I see a similar delay (over 2s) between the first time the 3-1 usb device is mentioned (the kernel add event) and the last time it is mentioned (the udev add complete event I think?):
It looks like the kernel has made the device available, but udev has not finished processing, so the permissions on the /dev/ file are not set yet. I would think that something similar might happen to e.g. a USB mouse as well
Ah, I had not actually considered multiple invocations yet, I guess that could indeed be relevant as well. Doing a quick test indeed shows that it runs twice for my USB mouse, and four times for my serial device (probably because it has a few subdevices). If I modify the script to run only the first time, the delay I see in udevadm is about 1s, when it runs twice for the mouse its just under 2s, and for my serial device it was about 3s, so I suspect it's just running multiple times and the delay just stacks). I was thinking the locking might be influential (that the first invocation prevents the second invocation from returning quickly or something), but I don't think that is the case. I did a quick test, where I let When then plugging in an USB mouse (taking care that |
Possibly, yes. But yes, from what you are showing, if that is the case (runtime length of lmt), then this is an ugly trade-off. |
In a short span of time, example a plug/unplug of a device, it usually should settle with 2 invocations. All other event invocations will be ignored. The reason I explained in one of the previous comments. If you have more than 2 instances of the run, I'd be interested in the time span. Because the kernel can generate many many events on device plugs/unplugs, but because we do a global power savings settings re-apply, we only try to honor 2 instances (in the short time span)
PS: I hope I have been able to explain in words. /me realizes my English still needs a lot of improvement :-) |
Yeah, this might be something to further investigate.
I just counted the invocations of
I've had no problem following your English, so don't worry :-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I close then open the lid in my laptop (I see the Wacom "Pen and multitouch sensor" USB device disconnecting and connecting in the kernel logs then), the touchscreen does not respond for 1 to 5 seconds. When I disconnect then connect a USB trackball, the cursor does not move for a similar period of time. Starting the
laptop_modeandacpidservices is disabled.If I uninstall
laptop-mode-tools, there is no noticeable delay when reconnecting those devices.I've found that there is
/lib/udev/rules.d/99-laptop-mode.rulesthat runslmt-udev forcewhen a USB device is added, and I see #137 mentioning a similar slowdown, but on boot on a different system.systemd.laptop-mode-toolsversion:app-laptop/laptop-mode-tools-1.72.2-r1.eudevversion:sys-fs/eudev-3.2.7-r1.The text was updated successfully, but these errors were encountered: