Search Linux Wireless

Re: A weird rfkill problem after rebooting the system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 27, 2012 at 8:28 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux