Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 597007 - rfkill soft block and hard block not synced
rfkill soft block and hard block not synced
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rfkill (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: John Feeney
Kernel-QE - Hardware
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 18:28 EDT by Daniele Viganò
Modified: 2015-03-19 14:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 12:51:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
modinfo acer_wmi (687 bytes, text/plain)
2010-05-28 17:50 EDT, Daniele Viganò
no flags Details
ls -l /sys/class/wmi/ (1.52 KB, text/plain)
2010-05-28 17:50 EDT, Daniele Viganò
no flags Details

  None (edit)
Description Daniele Viganò 2010-05-27 18:28:07 EDT
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
Comment 1 John W. Linville 2010-05-28 09:52:26 EDT
Sounds like a platform device issue?
Comment 2 Daniele Viganò 2010-05-28 10:06:19 EDT
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".
Comment 3 Matthew Garrett 2010-05-28 10:21:42 EDT
Can you edit /lib/udev/keymaps/acer and remove the two "wlan" lines?
Comment 4 Daniele Viganò 2010-05-28 10:53:56 EDT
(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.
Comment 5 Matthew Garrett 2010-05-28 11:02:35 EDT
You'll need to reboot afterwards.
Comment 6 Daniele Viganò 2010-05-28 11:55:44 EDT
(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...
Comment 7 Matthew Garrett 2010-05-28 12:05:28 EDT
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?
Comment 8 Daniele Viganò 2010-05-28 14:15:21 EDT
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
Comment 9 Daniele Viganò 2010-05-28 17:28:38 EDT
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
Comment 10 Matthew Garrett 2010-05-28 17:42:11 EDT
Huh. Ok, can you do

modinfo acer_wmi

and also

ls /sys/class/wmi

and attach the output?
Comment 11 Daniele Viganò 2010-05-28 17:50:10 EDT
Created attachment 417752 [details]
modinfo acer_wmi
Comment 12 Daniele Viganò 2010-05-28 17:50:47 EDT
Created attachment 417753 [details]
ls -l /sys/class/wmi/
Comment 13 Matthew Garrett 2010-05-28 18:03:43 EDT
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.
Comment 14 Daniele Viganò 2010-05-28 18:11:38 EDT
(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!
Comment 15 Daniele Viganò 2010-06-04 16:52:32 EDT
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.
Comment 16 Bug Zapper 2011-06-02 09:10:04 EDT
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
Comment 17 Bug Zapper 2011-06-27 12:51:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.