Hi,
I encountered a strange rfkill problem on the ASUS laptop.
But it's more like an rfkill issue to me, so I mail to the
linux-wireless mailing list and
CC'd to the maintainer of the asus-wmi driver.
I attached 2 rfkill event log files.
1. The first one(rfkill.0.log) is the driver we use currently,
you can see that I can soft block/unblock the devices by hitting the hotkey.
But the behavior is abnormal if I reboot the system with the devices blocked.
They are blocked after reboot is as expected.
But while I'm trying to unblock them, the phy0(the one keeps changing
its index) will become blocked.
So, there is no way to unblock the bt device by hitting hotkey.
2. The second log file is I try to remove the line from asus-wmi.c
rfkill_init_sw_state(*rfkill, !result);
Then, it works after rebooting.
I suspect the problem comes from the line in rfkill_init_sw_state() function
rfkill->persistent = true;
While calling rfkill_register() with persistent is false, then it'll
call rfkill_sync_work()
to set device block state, so that it prevents this issue.
But I'm not sure if my guess is correct and have no idea why it
doesn't need to this if persistent is true.
The persistent value seems doesn't affect the rfkill state that much
after reboot, the rfkill state is correct all the time.
BTW, the BIOS of this ASUS machine doesn't set the rfkill state while
we hit the hotkey.
Best regards,
AceLan Kao.
--
Chia-Lin Kao(AceLan)
http://blog.acelan.idv.tw/
E-Mail: acelan.kaoATcanonical.com (s/AT/@/)
> 2012/11/27 Corentin Chary <[email protected]>:
>> On Tue, Nov 27, 2012 at 8:28 AM, Johannes Berg
>> <[email protected]> wrote:
>>> On Tue, 2012-11-27 at 14:35 +0800, AceLan Kao wrote:
>>>> Hi,
>>>>
>>>> I encountered a strange rfkill problem on the ASUS laptop.
>>>> But it's more like an rfkill issue to me, so I mail to the
>>>> linux-wireless mailing list and
>>>> CC'd to the maintainer of the asus-wmi driver.
>>>
>>> This totally sounds like a platform driver issue, adding that mailing
>>> list (left full text intact below). Nothing I can help you with.
>>>
>>> johannes
>>>
>>>> I attached 2 rfkill event log files.
>>>> 1. The first one(rfkill.0.log) is the driver we use currently,
>>>> you can see that I can soft block/unblock the devices by hitting the hotkey.
>>>> But the behavior is abnormal if I reboot the system with the devices blocked.
>>>> They are blocked after reboot is as expected.
>>>> But while I'm trying to unblock them, the phy0(the one keeps changing
>>>> its index) will become blocked.
>>>> So, there is no way to unblock the bt device by hitting hotkey.
>>>>
>>>> 2. The second log file is I try to remove the line from asus-wmi.c
>>>> rfkill_init_sw_state(*rfkill, !result);
>>>> Then, it works after rebooting.
>>>> I suspect the problem comes from the line in rfkill_init_sw_state() function
>>>> rfkill->persistent = true;
>>
>> Well, persistent means:
>> "Whether the soft blocked state is initialised from non-volatile
>> storage at startup."
>> So if we call rfkill_init_sw_state(), that makes some sense
>>
>>>> While calling rfkill_register() with persistent is false, then it'll
>>>> call rfkill_sync_work()
>>>> to set device block state, so that it prevents this issue.
>>>> But I'm not sure if my guess is correct and have no idea why it
>>>> doesn't need to this if persistent is true.
>>>> The persistent value seems doesn't affect the rfkill state that much
>>>> after reboot, the rfkill state is correct all the time.
>>>
>>>> BTW, the BIOS of this ASUS machine doesn't set the rfkill state while
>>>> we hit the hotkey.
>>
>> We are missing some context here. What is the hotkey doing in userspace ?
>> Who owns this phy0 rfkill ? The asus platform driver, or the wireless driver ?
>> If it's the asus platform driver, why is it different from bluetooth ?
>> Something special done by the BIOS ? or the driver ?
> Sorry, my fault, it's hci0, not phy0
> The hci0 is not controlled by asus-wmi driver,
> I think only asus-wlan and asus-bluetooth are controlled by asus-wmi driver.
So hci0 state is bad right ? And hci0 is not controlled by asus-wmi.
But if you change something in asus-wmi, then hci0 will be correct ?
Looks like a weird thing is done by the DSDT...
> I didn't report keyevent while receiving the WMI hotkey event,
> so I think userspace app don't know what happened.
Can you check that nothing handled the key ? For example do that with
X being shutdown.
> And as far as I know, ASUS BIOS engineer says in the wapf=4 mode,
> BIOS will do nothing.
Yeah ... we all know that BIOSes are deterministic. :)
--
Corentin Chary
http://xf.iksaif.net
On Tue, Nov 27, 2012 at 8:28 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2012-11-27 at 14:35 +0800, AceLan Kao wrote:
>> Hi,
>>
>> I encountered a strange rfkill problem on the ASUS laptop.
>> But it's more like an rfkill issue to me, so I mail to the
>> linux-wireless mailing list and
>> CC'd to the maintainer of the asus-wmi driver.
>
> This totally sounds like a platform driver issue, adding that mailing
> list (left full text intact below). Nothing I can help you with.
>
> johannes
>
>> I attached 2 rfkill event log files.
>> 1. The first one(rfkill.0.log) is the driver we use currently,
>> you can see that I can soft block/unblock the devices by hitting the hotkey.
>> But the behavior is abnormal if I reboot the system with the devices blocked.
>> They are blocked after reboot is as expected.
>> But while I'm trying to unblock them, the phy0(the one keeps changing
>> its index) will become blocked.
>> So, there is no way to unblock the bt device by hitting hotkey.
>>
>> 2. The second log file is I try to remove the line from asus-wmi.c
>> rfkill_init_sw_state(*rfkill, !result);
>> Then, it works after rebooting.
>> I suspect the problem comes from the line in rfkill_init_sw_state() function
>> rfkill->persistent = true;
Well, persistent means:
"Whether the soft blocked state is initialised from non-volatile
storage at startup."
So if we call rfkill_init_sw_state(), that makes some sense
>> While calling rfkill_register() with persistent is false, then it'll
>> call rfkill_sync_work()
>> to set device block state, so that it prevents this issue.
>> But I'm not sure if my guess is correct and have no idea why it
>> doesn't need to this if persistent is true.
>> The persistent value seems doesn't affect the rfkill state that much
>> after reboot, the rfkill state is correct all the time.
>
>> BTW, the BIOS of this ASUS machine doesn't set the rfkill state while
>> we hit the hotkey.
We are missing some context here. What is the hotkey doing in userspace ?
Who owns this phy0 rfkill ? The asus platform driver, or the wireless driver ?
If it's the asus platform driver, why is it different from bluetooth ?
Something special done by the BIOS ? or the driver ?
--
Corentin Chary
http://xf.iksaif.net
Dear Corentin,
2012/11/27 Corentin Chary <[email protected]>:
> On Tue, Nov 27, 2012 at 8:28 AM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2012-11-27 at 14:35 +0800, AceLan Kao wrote:
>>> Hi,
>>>
>>> I encountered a strange rfkill problem on the ASUS laptop.
>>> But it's more like an rfkill issue to me, so I mail to the
>>> linux-wireless mailing list and
>>> CC'd to the maintainer of the asus-wmi driver.
>>
>> This totally sounds like a platform driver issue, adding that mailing
>> list (left full text intact below). Nothing I can help you with.
>>
>> johannes
>>
>>> I attached 2 rfkill event log files.
>>> 1. The first one(rfkill.0.log) is the driver we use currently,
>>> you can see that I can soft block/unblock the devices by hitting the hotkey.
>>> But the behavior is abnormal if I reboot the system with the devices blocked.
>>> They are blocked after reboot is as expected.
>>> But while I'm trying to unblock them, the phy0(the one keeps changing
>>> its index) will become blocked.
>>> So, there is no way to unblock the bt device by hitting hotkey.
>>>
>>> 2. The second log file is I try to remove the line from asus-wmi.c
>>> rfkill_init_sw_state(*rfkill, !result);
>>> Then, it works after rebooting.
>>> I suspect the problem comes from the line in rfkill_init_sw_state() function
>>> rfkill->persistent = true;
>
> Well, persistent means:
> "Whether the soft blocked state is initialised from non-volatile
> storage at startup."
> So if we call rfkill_init_sw_state(), that makes some sense
>
>>> While calling rfkill_register() with persistent is false, then it'll
>>> call rfkill_sync_work()
>>> to set device block state, so that it prevents this issue.
>>> But I'm not sure if my guess is correct and have no idea why it
>>> doesn't need to this if persistent is true.
>>> The persistent value seems doesn't affect the rfkill state that much
>>> after reboot, the rfkill state is correct all the time.
>>
>>> BTW, the BIOS of this ASUS machine doesn't set the rfkill state while
>>> we hit the hotkey.
>
> We are missing some context here. What is the hotkey doing in userspace ?
> Who owns this phy0 rfkill ? The asus platform driver, or the wireless driver ?
> If it's the asus platform driver, why is it different from bluetooth ?
> Something special done by the BIOS ? or the driver ?
Sorry, my fault, it's hci0, not phy0
The hci0 is not controlled by asus-wmi driver,
I think only asus-wlan and asus-bluetooth are controlled by asus-wmi driver.
I didn't report keyevent while receiving the WMI hotkey event,
so I think userspace app don't know what happened.
And as far as I know, ASUS BIOS engineer says in the wapf=4 mode,
BIOS will do nothing.
>
> --
> Corentin Chary
> http://xf.iksaif.net
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chia-Lin Kao(AceLan)
http://blog.acelan.idv.tw/
E-Mail: acelan.kaoATcanonical.com (s/AT/@/)
On Tue, 2012-11-27 at 14:35 +0800, AceLan Kao wrote:
> Hi,
>
> I encountered a strange rfkill problem on the ASUS laptop.
> But it's more like an rfkill issue to me, so I mail to the
> linux-wireless mailing list and
> CC'd to the maintainer of the asus-wmi driver.
This totally sounds like a platform driver issue, adding that mailing
list (left full text intact below). Nothing I can help you with.
johannes
> I attached 2 rfkill event log files.
> 1. The first one(rfkill.0.log) is the driver we use currently,
> you can see that I can soft block/unblock the devices by hitting the hotkey.
> But the behavior is abnormal if I reboot the system with the devices blocked.
> They are blocked after reboot is as expected.
> But while I'm trying to unblock them, the phy0(the one keeps changing
> its index) will become blocked.
> So, there is no way to unblock the bt device by hitting hotkey.
>
> 2. The second log file is I try to remove the line from asus-wmi.c
> rfkill_init_sw_state(*rfkill, !result);
> Then, it works after rebooting.
> I suspect the problem comes from the line in rfkill_init_sw_state() function
> rfkill->persistent = true;
> While calling rfkill_register() with persistent is false, then it'll
> call rfkill_sync_work()
> to set device block state, so that it prevents this issue.
> But I'm not sure if my guess is correct and have no idea why it
> doesn't need to this if persistent is true.
> The persistent value seems doesn't affect the rfkill state that much
> after reboot, the rfkill state is correct all the time.
>
> BTW, the BIOS of this ASUS machine doesn't set the rfkill state while
> we hit the hotkey.
>
> Best regards,
> AceLan Kao.
>