Bug 597007
Summary: | rfkill soft block and hard block not synced | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniele Viganò <dennyvatwork> | ||||||
Component: | rfkill | Assignee: | John Feeney <jfeeney> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Kernel-QE - Hardware <kernel-qe-hw> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 13 | CC: | linville, quanxunzhen, rth | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-06-27 16:51:37 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Daniele Viganò
2010-05-27 22:28:07 UTC
Sounds like a platform device issue? All was working fine on Fedora 12 and also on OpenSuse 11.0 and 11.1, so I don't think it is a bug only relative to my notebook. However I'm still investigating the problem modifying the rfkill module parameter "master_switch_mode". Can you edit /lib/udev/keymaps/acer and remove the two "wlan" lines? (In reply to comment #3) > Can you edit /lib/udev/keymaps/acer and remove the two "wlan" lines? Tested right now, it doesn't change anything. You'll need to reboot afterwards. (In reply to comment #5) > You'll need to reboot afterwards. Yes, did it! More information: if a do rfkill unblock all when wifi button is disabled: soft -> no hard -> yes pressing the button again soft -> yes hard -> no if a do rfkill unblock all when wifi button is enabled: soft -> no hard -> no pressing the button again soft -> yes hard -> yes forcing rfkill module with master_switch_mode and/or default_mode seems to not solve the problem (sometimes works, sometimes not). Still working on... Ok, this is very odd. The only way this should be happening is if that key is generating KEY_WLAN, and removing that assignment from the udev rules should have avoided that being the case. Can you install the evtest package and run it against each device in /dev/input/event* to see whether one of them is generating this keypress? from /dev/input/event5 Event: time 1275070014.379528, type 4 (Misc), code 4 (ScanCode), value d5 Event: time 1275070014.379545, type 1 (Key), code 238 (WLAN), value 1 Event: time 1275070014.379552, -------------- Report Sync ------------ Event: time 1275070014.519709, type 4 (Misc), code 4 (ScanCode), value d5 Event: time 1275070014.519730, type 1 (Key), code 238 (WLAN), value 0 Event: time 1275070014.519734, -------------- Report Sync ------------ Event: time 1275070022.675724, type 4 (Misc), code 4 (ScanCode), value d6 Event: time 1275070022.675743, type 1 (Key), code 238 (WLAN), value 1 Event: time 1275070022.675750, -------------- Report Sync ------------ Event: time 1275070022.804492, type 4 (Misc), code 4 (ScanCode), value d6 Event: time 1275070022.804511, type 1 (Key), code 238 (WLAN), value 0 Event: time 1275070022.804515, -------------- Report Sync ------------ All others are "clear". Now I've re-tested with the "wlans" commented: for the first three reboots everything works fine: soft no -> no hard yes -> no 1275070209.822010: idx 0 type 1 op 2 soft 0 hard 0 1275070209.826757: idx 0 type 1 op 2 soft 0 hard 1 and vv. (tested rebooting both with the wireless active and not). at the fourth reboot the system started with soft "yes": soft yes -> no hard no -> yes 1275070333.574521: idx 0 type 1 op 2 soft 1 hard 0 1275070339.298886: idx 0 type 1 op 2 soft 1 hard 1 <-- this is a strange line! 1275070339.303875: idx 0 type 1 op 2 soft 0 hard 1 Thanks a lot I've found the solution: the problem was that the acer_wmi was not loaded at boot (my TM6292 is fully supportated: http://code.google.com/p/aceracpi/wiki/SupportedHardware). With this module the buttons are working fine. So this is not more a real bug, but there is a new bug: "acer_wmi is not automatically loaded on (some) acer notebooks" I need to opena a new bug report? However, to solve: echo modprobe acer_wmi >> /etc/rc.modules chmod +x /etc/rc.modules if you want to start with wifi and bluetooth disabled add: echo options rfkill master_switch_mode=1 default_state=0 >> /etc/modprobe.d/rfkill.conf Huh. Ok, can you do modinfo acer_wmi and also ls /sys/class/wmi and attach the output? Created attachment 417752 [details]
modinfo acer_wmi
Created attachment 417753 [details]
ls -l /sys/class/wmi/
I think I see the problem, and it's hilariously silly. The lower case f in the modinfo wmi:6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 should be upper case. I'll try to spin you a test kernel next week. (In reply to comment #13) > I think I see the problem, and it's hilariously silly. The lower case f in the > modinfo wmi:6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 should be upper case. I'll try > to spin you a test kernel next week. Wow, thanks a lot for the support! I still have some problems (very few with acer_wmi loaded). Sometimes (randomly?) the system boot with both bluetooth and wireless soft blocked: for bluetooth I need to press the bt hardware button and then using the bt applet to "power on" it. For the wireless, after the hw button is pressed, the option "enable wireless" on NetworkManager is usable but it doesn't change anything, I need to use the rfkill unblock command. This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |