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 пишет:
>
> > 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
> > > quit
В Fri, 21 Nov 2014 01:26:36 +0100
Lennart Poettering пишет:
> 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 s
В Fri, 21 Nov 2014 01:26:36 +0100
Lennart Poettering пишет:
> 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 s
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
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
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 rfk
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 t
2014-11-20 20:34 GMT+01:00 Dan Williams :
> 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 th
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-r
On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote:
> 2014-11-20 14:17 GMT+01:00 Lennart Poettering :
> > 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 (befor
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 s
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
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 wrote:
>>> On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov
>>> wrote:
The problem is, there no easy way to build device name fr
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 wrote:
> > On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov
> > wrote:
> >>
> >> The problem is, there no easy way to build device name from rfkillN for
> >> BindsTo. May be add
2014-11-20 14:17 GMT+01:00 Lennart Poettering :
> 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.
On Thu, 20.11.14 06:40, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> В Tue, 18 Nov 2014 18:37:03 +0100
> Łukasz Stelmach пишет:
>
> >
> > 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<---
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, Nov 20, 2014 at 11:53 AM, Mantas Mikulėnas wrote:
> On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov
> 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 syst
On Thu, Nov 20, 2014 at 5:40 AM, Andrei Borzenkov
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 su
В Tue, 18 Nov 2014 18:37:03 +0100
Łukasz Stelmach пишет:
>
> 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.ser
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 be
22 matches
Mail list logo
