Re: [systemd-devel] Udev rules hardware database
IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) Thanks for your input. Do you know in which kernel version the above mentioned bug got fixed? I just checked two mice, a keyboard and a bunch of internal devices with a 3.17 kernel. Only one of the mice works completely reliable with activated power saving as input device – no problems with the internal devices. The funny thing is: That mouse is built from the same company as some other operating system – dog feeding does make sense. You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. Unfortunately, I do not know anyone from a distribution who is in charge for that area. Do you? A short Google search didn't bring up any distribution which did that, but my search was probably incomplete. But if my results mentioned above should be remotely representative, that might be disastrous, because for an average user it might be close to impossible to deactivate power savings without working input devices. Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
On Thursday, 6. November 2014, 14:28:12 Lennart Poettering wrote: Is unattended-upgrades a package of its own? Yes, it's a separate package (although it's obviously closely coupled with the apt package manager). If so, I'd probably ask the packagers to include drop-ins for reboot.target to override the timeout. That way, as soon as you install it the shutdown timeouts are disabled. That should be possible. Currently the package contains /lib/systemd/system/unattended-upgrades.service which contains: [Unit] Description=Unattended Upgrades DefaultDependencies=no Before=shutdown.target reboot.target halt.target Documentation=man:unattended-upgrade(8) [Service] Type=oneshot ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown [Install] WantedBy=shutdown.target Only the maintainer Michael Vogt can decide if he wants to go in that direction, thus I added him as CC. @Michael Vogt: The discussion is about adding a watchdog to systemd to power down the system if the shutdown takes longer than some time (i.e. 30 minutes). The question was how to avoid killing unattended-upgrade during a longer upgrade if it is configured to update the packages at shutdown. Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target
However, this one appears bogus to me. Is there any such software around that really does this? And if so, this really appears weird to me to support. Delaying shutdown for more than 30min is just wrong. Isn't this what the various download updates and reboot gnome-y things are doing? At least unattended-upgrades from Debian/Ubuntu/... can be configured to install updates on shutdown (without any special mode or something). And, yes, this can run for more than 30 minutes, which I could already observe in its default mode (installing during normal system activities), so I see no reason why this should not happen when configured to install during shutdown. The reason is, that unattended-upgrades can basically update the whole distribution to the next version, which naturally can take a lot of time. It's questionable if this is a sane setup, but I can think of setups where this might be useful, e.g. having two identically configured servers for redundancy reasons where one server would be enough. Then it might make sense to update one system during shutdown while the other one takes over. This has the advantage, that normally running servers either have the old or the new state, but never some intermediate state during the update. The shutdown time does not really matter in this case and a watchdog killing the system wouldn't be welcome. But all in all this seems like an exotic use case. Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Udev rules hardware database
Dear all, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. I you want to have permanent power saving activated for your devices, the recommended way is to use udev (e.g. https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? - If not, is udev the correct piece in the Linux stack to put this? - What is the general way to contribute udev rules? - Where is it documented? Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
