Re: [systemd-devel] [BUG] too many rfkill services
I had the same issue with rfkill as Łukasz did. I have rebuilt including commit 4844262f25a3ff6bd23de05a0a6f84a8e2983d74. I tested by cycling suspend/resume 15 times without reboot, and did not experience any failed phantom rfkill services. I also tested rfkill functionality, and the state of a soft-blocked rfkill switch survived a suspend/resume and a reboot. Hope this helps, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Sun, 23.11.14 12:34, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Fri, 21 Nov 2014 01:26:36 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote: 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. So, I have now added some code that adds BindsTo= for the device unit to the service. This won't fix much though, as the service is likely to fail in ExecStop= because it cannot find the device anymore. Yes, you are right. It accumulates the same services but now failed instead of active. Hmm ... should not systemd inform service that device it is BoundTo is gone? I mean, while service may need to do some cleanup in this case, it is obvious that it cannot access device which no more exists. This would allow graceful exit, instead of returning error. Well, it's racy really. Of course systemd sends SIGTERM before shutting down a service, but this is async... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
В Fri, 21 Nov 2014 01:26:36 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote: 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. So, I have now added some code that adds BindsTo= for the device unit to the service. This won't fix much though, as the service is likely to fail in ExecStop= because it cannot find the device anymore. Yes, you are right. It accumulates the same services but now failed instead of active. Hmm ... should not systemd inform service that device it is BoundTo is gone? I mean, while service may need to do some cleanup in this case, it is obvious that it cannot access device which no more exists. This would allow graceful exit, instead of returning error. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
В Fri, 21 Nov 2014 01:26:36 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote: 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. So, I have now added some code that adds BindsTo= for the device unit to the service. It does not seem to work. bor@opensuse:~ systemctl status systemd-rfkill@rfkill0.service systemd-rfkill@rfkill0.service - Load/Save RF Kill Switch Status of rfkill0 Loaded: loaded (/usr/lib/systemd/system/systemd-rfkill@.service; static) Drop-In: /etc/systemd/system/systemd-rfkill@.service.d └─bind.conf Active: active (exited) since Пт 2014-11-21 06:52:40 MSK; 15h ago Docs: man:systemd-rfkill@.service(8) Process: 636 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, status=0/SUCCESS) Main PID: 636 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-systemd\x2drfkill.slice/systemd-rfkill@rfkill0.service bor@opensuse:~ systemctl --no-pager show -p BindsTo systemd-rfkill@rfkill0.service BindsTo=sys-subsystem-rfkill-devices-rfkill0.device bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill0.device sys-subsystem-rfkill-devices-rfkill0.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill1.device sys-subsystem-rfkill-devices-rfkill1.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill2.device sys-subsystem-rfkill-devices-rfkill2.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl --full | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d2-3\x2d2.1-3\x2d2.1:1.0-bluetooth-hci0-rfkill2.device loaded active plugged /sys/devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2 sys-devices-pci:00-:00:1c.1-:0c:00.0-ieee80211-phy0-rfkill1.device loaded active plugged /sys/devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1 systemd-rfkill@rfkill0.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill2 system-systemd\x2drfkill.slice loaded active activesystem-systemd\x2drfkill.slice bor@opensuse:~ LC_ALL=C ll /sys/class/rfkill/ total 0 lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill1 - ../../devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1 lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill2 - ../../devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2 This won't fix much though, as the service is likely to fail in ExecStop= because it cannot find the device anymore. Should not it be garbage collected at some point (assuming it is properly stopped that is)? For cases like this the tool is entirely useless I figure, since it can only save the rfkill state at shutdown now, but not on unplug. This means each time the device appears as hotplug we restore the state that was set during boot, but not the state from right before we went to suspend. I figure the only proper fix for this is to make some daemon take responsibility, listen to events and store things to disk each time the setting changes... Not too enthusiastic about adding that though... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov arvidj...@gmail.com wrote: The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. You sure about that? /sys/class/rfkill/%i should work fine... -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas graw...@gmail.com wrote: On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov arvidj...@gmail.com wrote: The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. You sure about that? /sys/class/rfkill/%i should work fine... I'm not before my notebook, but I'm pretty sure this device is not present in the systemctl -t device list. Actually I do not think any /sys/class alias is present at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote: Hi. 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/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. 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 -... 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... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, 20.11.14 06:40, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Tue, 18 Nov 2014 18:37:03 +0100 Łukasz Stelmach stl...@poczta.fm пишет: 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 I confirm it. [...] The actual issue as I see it is that systemd does not stop and remove rfkill services that refer to nonexistent devices. The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. BindsTo= does not cause an exited-but-failed service to be flushed out. It just stops running services when another service is ending, that's all. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
2014-11-20 14:17 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote: Hi. 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/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. 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 -... 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... I had some rather interesting experience with the rfkill service as well. See [1]. Basically, running rfkill on one device, made the other device go away. Since there is a race, systemd-rfkill failed for that device, leading to an error message on every boot. A BindsTo= would probably help here as well. So while we are at that topic, would be great to have some input on [1]. Michael [1] https://bugs.freedesktop.org/show_bug.cgi?id=83730 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, Nov 20, 2014 at 12:05:23PM +0300, Andrei Borzenkov wrote: On Thu, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas graw...@gmail.com wrote: On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov arvidj...@gmail.com wrote: The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. You sure about that? /sys/class/rfkill/%i should work fine... I'm not before my notebook, but I'm pretty sure this device is not present in the systemctl -t device list. Actually I do not think any /sys/class alias is present at all. Then something is wrong with your kernel :( You should have something like /sys/class/rfkill/rfkill0 and such in there. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On 20.11.2014 18:57, Greg KH wrote: On Thu, Nov 20, 2014 at 12:05:23PM +0300, Andrei Borzenkov wrote: On Thu, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas graw...@gmail.com wrote: On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov arvidj...@gmail.com wrote: The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. You sure about that? /sys/class/rfkill/%i should work fine... I'm not before my notebook, but I'm pretty sure this device is not present in the systemctl -t device list. Actually I do not think any /sys/class alias is present at all. Then something is wrong with your kernel :( You should have something like /sys/class/rfkill/rfkill0 and such in there. For the record: $ ls /sys/class/rfkill/ rfkill41 rfkill42 $ systemctl -t device | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device -- 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
Re: [systemd-devel] [BUG] too many rfkill services
El 20/11/14 a las 15:40, Lukasz Stelmach escribió: $ ls /sys/class/rfkill/ rfkill41 rfkill42 $ systemctl -t device | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device huh.. so the kernel does not preserve the device number on resume and recreate new ones? Im not sure but that sounds like a kernel bug... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/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
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote: 2014-11-20 14:17 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@poczta.fm) wrote: Hi. 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/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. 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 -... 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... I had some rather interesting experience with the rfkill service as well. See [1]. Basically, running rfkill on one device, made the other device go away. That's normal behavior in the case of a platform rfkill device and a device-specific rfkill device. The platform rfkill functionality can sometimes (often?) cut power to the device through BIOS and GPIOs, and it will drop off the USB or PCI bus. But the device itself can also expose rfkill functionality through it's own drivers, that doesn't cause it to drop off the bus. This is your case with the USB-based Bluetooth device and the BIOS-based platform killswitch. Since the routing of all these rfkills is highly model specific, there is no way to know that the platform rfkill has an affect on any other device in a generic way. That would have to be hardcoded into the kernel and would be pretty awful to maintain. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, Nov 20, 2014 at 03:50:43PM -0300, Cristian Rodríguez wrote: El 20/11/14 a las 15:40, Lukasz Stelmach escribió: $ ls /sys/class/rfkill/ rfkill41 rfkill42 $ systemctl -t device | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device huh.. so the kernel does not preserve the device number on resume and recreate new ones? Im not sure but that sounds like a kernel bug... Nope, not a bug, that's how rfkill is designed, it is an incrementing number that keeps going up. Now we can change this, in the kernel, to recycle numbers, but you will still have the same issue where the numbers could reverse after suspend/resume, so you can't rely on the number for anything. You need to follow the parent of the device to know what it controls. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
2014-11-20 20:34 GMT+01:00 Dan Williams d...@redhat.com: On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote: I had some rather interesting experience with the rfkill service as well. See [1]. Basically, running rfkill on one device, made the other device go away. That's normal behavior in the case of a platform rfkill device and a device-specific rfkill device. The platform rfkill functionality can sometimes (often?) cut power to the device through BIOS and GPIOs, and it will drop off the USB or PCI bus. But the device itself can also expose rfkill functionality through it's own drivers, that doesn't cause it to drop off the bus. This is your case with the USB-based Bluetooth device and the BIOS-based platform killswitch. Since the routing of all these rfkills is highly model specific, there is no way to know that the platform rfkill has an affect on any other device in a generic way. That would have to be hardcoded into the kernel and would be pretty awful to maintain. Thanks for the detailed explanation. Any suggestion how we can address that in systemd-rfkill or its service file? It's kinda ugly if you get a failed service because of that and having the system state be reported as degraded. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, 20.11.14 13:34, Dan Williams (d...@redhat.com) wrote: That's normal behavior in the case of a platform rfkill device and a device-specific rfkill device. The platform rfkill functionality can sometimes (often?) cut power to the device through BIOS and GPIOs, and it will drop off the USB or PCI bus. But the device itself can also expose rfkill functionality through it's own drivers, that doesn't cause it to drop off the bus. This is your case with the USB-based Bluetooth device and the BIOS-based platform killswitch. Since the routing of all these rfkills is highly model specific, there is no way to know that the platform rfkill has an affect on any other device in a generic way. That would have to be hardcoded into the kernel and would be pretty awful to maintain. Hmm, so, currently we include the rfkill device name in the filename we store in disk (combined with ID_PATH if it is known). For an rfkill device that comes and goes and each time changes its name this filename will not be stable. Is there any way how we can get some stable ID out of these devices, in a way that allows multiple rfkill devices per USB device/interface? I don't see how without kernel change. If rfkill devices shall be reliably recognizable, then we need some kind of sub-USB device stability... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, 20.11.14 11:42, Greg KH (gre...@linuxfoundation.org) wrote: On Thu, Nov 20, 2014 at 03:50:43PM -0300, Cristian Rodríguez wrote: El 20/11/14 a las 15:40, Lukasz Stelmach escribió: $ ls /sys/class/rfkill/ rfkill41 rfkill42 $ systemctl -t device | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d1-3\x2d1:1.0-bluetooth-hci0-rfkill42.device sys-devices-pci:00-:00:1a.7-usb1-1\x2d3-1\x2d3:1.0-ieee80211-phy15-rfkill41.device huh.. so the kernel does not preserve the device number on resume and recreate new ones? Im not sure but that sounds like a kernel bug... Nope, not a bug, that's how rfkill is designed, it is an incrementing number that keeps going up. Now we can change this, in the kernel, to recycle numbers, but you will still have the same issue where the numbers could reverse after suspend/resume, so you can't rely on the number for anything. You need to follow the parent of the device to know what it controls. Well, we use ID_PATH, but this will not suffice for USB devices that have two rfkill child devices... How do we get stable identifiers for those? If the rfkill name is not usable, then we need something else there... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote: 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. So, I have now added some code that adds BindsTo= for the device unit to the service. This won't fix much though, as the service is likely to fail in ExecStop= because it cannot find the device anymore. For cases like this the tool is entirely useless I figure, since it can only save the rfkill state at shutdown now, but not on unplug. This means each time the device appears as hotplug we restore the state that was set during boot, but not the state from right before we went to suspend. I figure the only proper fix for this is to make some daemon take responsibility, listen to events and store things to disk each time the setting changes... Not too enthusiastic about adding that though... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
Hi Lennart, That's normal behavior in the case of a platform rfkill device and a device-specific rfkill device. The platform rfkill functionality can sometimes (often?) cut power to the device through BIOS and GPIOs, and it will drop off the USB or PCI bus. But the device itself can also expose rfkill functionality through it's own drivers, that doesn't cause it to drop off the bus. This is your case with the USB-based Bluetooth device and the BIOS-based platform killswitch. Since the routing of all these rfkills is highly model specific, there is no way to know that the platform rfkill has an affect on any other device in a generic way. That would have to be hardcoded into the kernel and would be pretty awful to maintain. Hmm, so, currently we include the rfkill device name in the filename we store in disk (combined with ID_PATH if it is known). For an rfkill device that comes and goes and each time changes its name this filename will not be stable. Is there any way how we can get some stable ID out of these devices, in a way that allows multiple rfkill devices per USB device/interface? I don't see how without kernel change. If rfkill devices shall be reliably recognizable, then we need some kind of sub-USB device stability... actual individual RFKILL switch control is not something that anybody should store anywhere. We support it via /dev/rfkill, but it is not something you can rely on. As you have seen the RFKILL switches can come and go and be re-enumerated at it. For this specific reason we have introduced the RFKILL_OP_CHANGE_ALL where you can either switch on/off all RFKILL switches (comparable to flight mode setting) or where you can switch on/off a specific type of switch (bluetooth, wlan, nfc etc.). What is important that for example Bluetooth comes back up as it is suppose to. So if you do a CHANGE_ALL Bluetooth on, then you would expect to come back after suspend and reboot the same way. So the proper way is record the change all states and keep them. And bring them back after suspend and resume. That is pretty much how ConnMan does it actually since it works on a per technology basis and not individual devices. Of course with this handling a few RFKILL switches will fail to be restored as they were, because people messed with individual switches. There is nothing much you can do about that. Getting a unique RFKILL switch id is really hard. It relies on that your parent exposes a serial number or something really unique that makes it persistent over reboot. And all the platform RFKILL switches are just plain terrible since in most cases we pull some out of the ACPI magic or worse some vendor magic. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
В Tue, 18 Nov 2014 18:37:03 +0100 Łukasz Stelmach stl...@poczta.fm пишет: 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 I confirm it. [...] The actual issue as I see it is that systemd does not stop and remove rfkill services that refer to nonexistent devices. The problem is, there no easy way to build device name from rfkillN for BindsTo. May be additional format specifier that would query udev database. Alternatively systemd-rfkill can be changed to accept sysfs path directly. signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [BUG] too many rfkill services
Hi. 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 exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 systemd-rfkill@rfkill3.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill4 [...] systemd-rfkill@rfkill37.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill37 --8---cut here---end---8--- Indeed currently available rfkill devices have rather high numbers. --8---cut here---start-8--- total 0 lrwxrwxrwx 1 root root 0 11-18 17:13 rfkill36 - ../../devices/pci:00/:00:1a.0/usb3/3-1/3-1:1.0/bluetooth/hci0/rfkill36 lrwxrwxrwx 1 root root 0 11-18 17:13 rfkill37 - ../../devices/pci:00/:00:1a.7/usb1/1-3/1-3:1.0/ieee80211/phy13/rfkill37 --8---cut here---end---8--- State files in /var/lib/systemd/rfkill look a bit odd too. --8---cut here---start-8--- total 16 -rw-r--r-- 1 root root 2 11-07 17:36 pci-:00:1a.0-usb-0:1:1.0:hci0 -rw-r--r-- 1 root root 2 11-07 17:36 pci-:00:1a.7-usb-0:3:1.0:phy0 -rw-r--r-- 1 root root 2 11-02 13:00 pci-:00:1a.7-usb-0:3:1.0:phy1 -rw-r--r-- 1 root root 2 09-22 08:17 pci-:00:1a.7-usb-0:3:1.0:phy4 --8---cut here---end---8--- dmesg shows that upon each resume the wlan phy gets a new number every resume. --8---cut here---start-8--- [221310.762273] ieee80211 phy11: Selected rate control algorithm 'minstrel_ht' [221310.762451] ieee80211 phy11: hwaddr 00:15:af:64:2f:bf, RTL8187vB (default) V1 + rtl8225z2, rfkill mask 2 [229361.374331] ieee80211 phy12: Selected rate control algorithm 'minstrel_ht' [229361.374505] ieee80211 phy12: hwaddr 00:15:af:64:2f:bf, RTL8187vB (default) V1 + rtl8225z2, rfkill mask 2 [243400.372585] ieee80211 phy13: Selected rate control algorithm 'minstrel_ht' [243400.372761] ieee80211 phy13: hwaddr 00:15:af:64:2f:bf, RTL8187vB (default) V1 + rtl8225z2, rfkill mask 2 --8---cut here---end---8--- Status of a stale rfkill service looks like this. --8---cut here---start-8--- * systemd-rfkill@rfkill9.service - Load/Save RF Kill Switch Status of rfkill9 Loaded: loaded (/usr/lib64/systemd/system/systemd-rfkill@.service; static) Active: active (exited) since nie 2014-11-09 19:31:27 CET; 1 weeks 1 days ago Docs: man:systemd-rfkill@.service(8) Process: 12818 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, status=0/SUCCESS) Main PID: 12818 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-systemd\x2drfkill.slice/systemd-rfkill@rfkill9.service --8---cut here---end---8--- and stopping it yields the following messages --8---cut here---start-8--- * systemd-rfkill@rfkill9.service - Load/Save RF Kill Switch Status of rfkill9 Loaded: loaded (/usr/lib64/systemd/system/systemd-rfkill@.service; static) Active: failed (Result: exit-code) since Tue 2014-11-18 18:24:02 CET; 21s ago Docs: man:systemd-rfkill@.service(8) Process: 4860 ExecStop=/usr/lib/systemd/systemd-rfkill save %I (code=exited, status=1/FAILURE) Process: 12818 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, status=0/SUCCESS) Main PID: 12818 (code=exited, status=0/SUCCESS) 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. Kind regards, -- 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 pgp3XamkPUGoe.pgp Description: PGP signature
