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
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
В 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)
В 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)
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
В 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---
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
22 matches
Mail list logo
