On 20.11.2014 14:17, Lennart Poettering wrote: > On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote: > >> Recently, after I had found an update for my BIOS, my desktop started to >> resume properly (before I could only suspend it). Kernel and systemd do >> their jobs fine. But they seem to have problem cooperating. >> >> For the record I use systemd 215, which means that the issue I describe >> here may have been fixed already. >> >> After several suspend/resumes systemctl shows more than three dozens of >> rfkill devices even though I've got only one BT and one WLAN. >> >> --8<---------------cut here---------------start------------->8--- >> systemd-rfkill@rfkill0.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill0 >> systemd-rfkill@rfkill1.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill1 >> systemd-rfkill@rfkill2.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill4 >> systemd-rfkill@rfkill3.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill4 >> >> [...] > > This really smells like a kernel bug. systemd gets the device names > via udev from the kernel, hence it's probably some driver bug that > creates these devices incorrectly.
I talked to the kernel guys at my office and they told me that it is quite usual (at least for USB devices, and my wlan and bt are USB) that devices are stopped and unregistered in the kernel before a system is suspended end reported as completely new ones with increased numbers after machine resumes. >> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status >> of rfkill9... >> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill@rfkill9.service: control >> process exited, code=exited status=1 >> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status of >> rfkill9. >> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill@rfkill9.service >> entered failed state. >> --8<---------------cut here---------------end--------------->8--- >> >> The actual issue as I see it is that systemd does not stop and remove >> rfkill services that refer to nonexistent devices. > > Yes, we do not flush out information about failed services by default > so that the admin can have a look and figure out what's going on. If > this is not desired, then the binary path in ExecStart= should be > prefixed with "-"... The above system-rfkill@rfkill9 failed because I tried to stop it manually. Before I did it it was like all the others "loaded active exited". > I think in this case (and by default) we should keep track of errors > though, even if it is annoying. But systemd is really not the place to > work around all possible kernel bugs... As I wrote above, this isn't necessary a "kernel bug" but it may be ... "underdesigned" feature. I mean removing devices (at least USB) before entering STR/S3 seems reasonable. I don't find (from the kernel perspective) anything wrong with registering them with ever increasing numbers after resume either. However, maybe, the way it works together with user-land needs more attention. -- Było mi bardzo miło. Twoje oczy lubią mnie >Łukasz< i to mnie zgubi (c)SNL REKLAMA: http://ars-fabrica.eu/ sklep z rękodziełem
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
