Description of problem: When I start my Acer TravelMate 6292 with the wifi disabled is impossible to enable wireless: rfkill hard block is "on" and soft is "off", but when pressing the wifi button (and also bluetooth had the same problem) the hard block goes correctly to "off" but the soft block goes to "on", so using the wireless is impossible. Pressing the button again the hard block turn to "on" and soft "off" and so again. The only system to enable wireless is using rfkill unblock wifi|bluetooth. How reproducible: When starting computer with the wifi disabled via kill switch Steps to Reproduce: 1. Disable wireless via hardware button 2. Reboot 3. Press the wireless button Actual results: rfkill hard block goes correctly to "off", but the soft block is turned "on". Expected results: Both hard and soft block should be in "off" state. Additional info: 2.6.33.4-95.fc13.x86_64 05:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61) [daniele@tmbook ~]$ rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes [daniele@tmbook ~]$ rfkill event 1274998521.820638: idx 0 type 1 op 0 soft 0 hard 1 1274998522.959362: idx 0 type 1 op 2 soft 0 hard 0 1274998522.964437: idx 0 type 1 op 2 soft 1 hard 0 [daniele@tmbook ~]$ rfkill list 0: phy0: Wireless LAN Soft blocked: yes Hard blocked: no [root@tmbook ~]# ifconfig wlan0 up SIOCSIFFLAGS: Operation not possible due to RF-kill [daniele@tmbook ~]$ rfkill unblock wifi 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no
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.