On Tue, 01 Dec 2009, Kevin Locke wrote: > I should have mentioned originally, the testing is being done on > 2.6.31.6 with thinkpad-acpi-0.23-20091010_v2.6.31.3.patch applied (but > I could pull from git if you would prefer). Well, if you pull from here: git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git release/2.6.31 You will get the latest 2.6.31 with the latest thinkpad-acpi stable code. Note: that branch is rewinded all the time, since it is a stgit branch tip. Be prepared to have to rebase if you use it. Maybe the easiest is to just squash-merge it. > Actually, with a little more testing I just figured it out. It was > staring me in the face this whole time. The trick was to add the > following somewhere in /etc/modprobe.d > > options rfkill default_state=0 master_switch_mode=0 Ok, so it is the rfkill-input stuff (that is now part of the rfkill core) that is showing the problem (the bug might be elsewhere). We need to track the state of the rfkill input device to know what's broken, then. Please check and report what thinkpad-acpi reports for the content of /sys/bus/platform/devices/thinkpad-acpi/hotkey_radio_sw It has to be zero if the rfkill *physical* switch is on the "radios disabled" position, and 1 if it is in the "radios enabled" position. When the switch is in the "radios disabled" position, *every* rfkill device based on thinkpad-acpi *must* report that the state is "2" (hardware-blocked). When the switch is in the "radios enabled" position, the rfkill devices must report either state "0" (software blocked) or "1" (unblocked). > With that line added, everything works as expected. Interestingly, > I would have thought master_switch_mode=1 (restore) would fix it as > well, but it does not. Only master_switch_mode=0 (unlock) works. master_switch_mode should change the behaviour of the kernel rfkill handler when the switch transitions from "radios disabled" to "radios enabled". The rfkill core keeps "global" state for each type of rfkill switch, and something weird might be happening related to that. It could be interesting to check it, but you will need something to interface to /dev/rfkill. http://wireless.kernel.org/download/rfkill Should have the userspace utility to interface with /dev/rfkill. But it appears, from your description, that we are disturbing the kernel at module load. One of the things that thinkpad-acpi will do at module load, is to issue a EV_SW SW_RFKILL_ALL event with the current state of the rfkill switch. If that is not working right, it might be the reason for the problem. > If this is expected behavior, could it be documented somewhere (or am > I overlooking somewhere that it is documented already)? No, there is something wrong, and I'd really like to know what :P -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
