Red Hat Bugzilla – Bug 485322
rfkill - inadequate state for eeepc and kernels below 2.6.29-0.22.rc4.git1.fc10
Last modified: 2009-12-18 02:54:30 EST
Description of problem: On Asus EeePC (1002HA model) with kernels 2.6.27.12-170.2.5.fc10 or 2.6.27.15-170.2.22.fc10 (the later one from koji) there are rfkill0 and rfkill1 in /sys/class/rfkill/ and 'cat /sys/class/rfkill/rfkill*/uevent' gives: RFKILL_NAME=eeepc-wlan RFKILL_TYPE=wlan RFKILL_STATE=1 RFKILL_NAME=eeepc-bluetooth RFKILL_TYPE=bluetooth RFKILL_STATE=-19 There is indeed a bluetooth icon in a notification area but doing things like 'echo -n 0 >/sys/class/rfkill/rfkill1/state' gets "echo: write error: No such device". If bluetooth really does work I do not know, as I do not have any such device handy, but it is at least recognized. Writing 0 or 1 to 'state' in 'rfkill0' directory does turn off or on wireless but a wifi control light is all the time on as it goes off only if both wifi and bluetooth are off. That is different with 2.6.29-0.22.rc4.git1.fc10 (from koji again) which sports updated eeepc-laptop module. This shows rfkill0, rfkill1 and rfkill2 directories and 'cat /sys/class/rfkill/rfkill*/uevent' now gets: RFKILL_NAME=eeepc-wlan RFKILL_TYPE=wlan RFKILL_STATE=1 RFKILL_NAME=eeepc-bluetooth RFKILL_TYPE=bluetooth RFKILL_STATE=1 RFKILL_NAME=ath9k-phy0:rfkill RFKILL_TYPE=wlan RFKILL_STATE=1 'rfkill2/state' does not seem to be really writeable but writing 0's and 1's into 'rfkill0/state' and 'rfkill1/state' does turn off and on both wifi and bluetooth and with both off wifi LED goes dark. Rebooting to one of 2.6.27-... kernels with bluetooth off makes its icon to vanish from a notification area, with no way to turn that back on within that boot, on toggling wlan state toggles also wifi LED. It seems that reusing new eeepc-laptop.c code in older kernels would be quite straighforward if f10 stays with 2.6.27. I did not check that this is all what would be needed but it appears that way. With all of the above it does not seem to be a way to change rfkill state other than by directly writing to /sys/class/rfkill/rfkill[01]/state files. 1002HA does sport "wifi control key" Fn+F2. It is recognized on a desktop as XF86WLAN key but that key does not seem to be doing anything at all and I was unable to find a way to tie it to some user defined actions. "Keyboard Shortcuts" seem to have a predefined list and if not on it you are apparently SOL. A reasonable action would be to cycle through all four possible rfkill states for wireless. Version-Release number of selected component (if applicable): kernel-2.6.27.12-170.2.5.fc10
Further experiments with 2.6.27 and with 2.6.29-0.53.rc7.fc10.i686 show that after rfkill-input module is loaded the WLAN (Fn-F2) key starts to react. Only: - nothing inserts rfkill-input unless explicitely loaded - Fn-F2, with an anntena picture on it, toggles only /sys/class/rfkill/rfkill0/state and does nothing to bluetooth - a controll light goes off only if both /sys/class/rfkill/rfkill{0,1}/state, i.e eeepc-wlan and eeepc-bluetooth are set to 0 - you cannot change bluetooth state with 2.6.27 kernels anyway - bluetooth marker in a notification area correctly reflects changes in /sys/class/rfkill/rfkill1/state
Confirmed similar issue with bluetooth killswitch on EeePC 901 running kernel-2.6.27.19-170.2.35.fc10.i686. # echo 1 > /sys/class/rfkill/rfkill1/state -bash: echo: write error: No such device $ lshal|grep rfkill udi = '/org/freedesktop/Hal/devices/computer_rfkill_eeepc_bluetooth_bluetooth' info.subsystem = 'rfkill' (string) info.udi = '/org/freedesktop/Hal/devices/computer_rfkill_eeepc_bluetooth_bluetooth' (string) linux.subsystem = 'rfkill' (string) linux.sysfs_path = '/sys/devices/LNXSYSTM:00/device:00/ASUS010:00/rfkill/rfkill1' (string) udi = '/org/freedesktop/Hal/devices/computer_rfkill_eeepc_wlan_wlan' info.subsystem = 'rfkill' (string) info.udi = '/org/freedesktop/Hal/devices/computer_rfkill_eeepc_wlan_wlan' (string) linux.subsystem = 'rfkill' (string) linux.sysfs_path = '/sys/devices/LNXSYSTM:00/device:00/ASUS010:00/rfkill/rfkill0' (string) $ cat /sys/class/rfkill/rfkill*/uevent RFKILL_NAME=eeepc-wlan RFKILL_TYPE=wlan RFKILL_STATE=1 RFKILL_NAME=eeepc-bluetooth RFKILL_TYPE=bluetooth RFKILL_STATE=-19 PS. Please make all your EeePC-related bugreports block FedoraMini tracker bug.
rfkill and rfkill-input are built into the kernel as of version 2.6.29.1-34.fc10
The last kernel from this series on koji is currently 2.6.29.1-30.fc10 which has rfkill and rfkill-input as modules. Conveniently enough for me the key in question on my keyboard generates "hotkey ATKD 00000010" ACPI event which allows to handle both WiFi and bluetooth with a help of a script in /etc/acpi/events. To emulate 2.6.29.1-34.fc10 I inserted rfkill-input and disabled my event script. That left me with unswitchable bluetooth and after few hits on switch key on a keyboard I got for my troubles the following: irq 18: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.29.1-30.fc10.i686 #1 Call Trace: [<c0468e22>] __report_bad_irq+0x2e/0x6f [<c0468f53>] note_interrupt+0xf0/0x149 [<c0469489>] handle_fasteoi_irq+0x8f/0xb5 [<c04693fa>] ? handle_fasteoi_irq+0x0/0xb5 <IRQ> [<c040442c>] ? common_interrupt+0x2c/0x34 [<c044a7c8>] ? tick_nohz_stop_sched_tick+0x33d/0x34d [<c0402ddb>] ? cpu_idle+0x26/0x8b [<c06c4a8b>] ? rest_init+0x53/0x55 handlers: [<c05f250d>] (usb_hcd_irq+0x0/0xa3) [<f7ed4a58>] (ath_isr+0x0/0x13a [ath9k]) Disabling IRQ #18 Still turning on wifi back makes it to work again. No idea how repeatable that can be. Apparently this is not easy but I never got that when using my script in /etc/acpi/events/. My attempts to follow what is written on http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html in order to make hal to handle these keyboard events came to naught.
kernel-2.6.29.1-42.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.1-42.fc10
kernel-2.6.29.1-42.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3999
kernel-2.6.29.2-52.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.2-52.fc10
Re comment #6 about "updates-testing". Remarks from comment #4 apply in full. Without my acpi event handler script an "rfkill" key switches off and on wifi but does not seem to have any effect on bluetooth. Also I got after few toggles off and on as with 2.6.29.1-30.fc10: irq 18: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.29.1-42.fc10.i686 #1 Call Trace: [<c0467a0e>] __report_bad_irq+0x2e/0x6f [<c0467b3f>] note_interrupt+0xf0/0x149 [<c0468075>] handle_fasteoi_irq+0x8f/0xb5 [<c0467fe6>] ? handle_fasteoi_irq+0x0/0xb5 <IRQ> [<c04043ac>] ? common_interrupt+0x2c/0x34 [<c044007b>] ? run_posix_cpu_timers+0x1c2/0x705 [<c04493b4>] ? tick_nohz_stop_sched_tick+0x33d/0x34d [<c0402db7>] ? cpu_idle+0x26/0x8b [<c06c675b>] ? rest_init+0x53/0x55 handlers: [<c05f0ea5>] (usb_hcd_irq+0x0/0xa3) [<f7eeba54>] (ath_isr+0x0/0x13a [ath9k]) Disabling IRQ #18 Also, close in time to the above, messages reported in bug 492699 (or something very similar) did show up but this may be just a time coincidence.
kernel-2.6.29.2-52.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4132
> kernel-2.6.29.2-52.fc10 has been pushed ... A behaviour is the same as in comment 4 and comment 8. That includes "irq 18: nobody cared" with a trace if no extra handling via acpid is configured. OTOH at least wifi can be toggled "out of the box".
kernel-2.6.29.3-60.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.3-60.fc10,hal-0.5.12-15.20081027git.fc10
kernel-2.6.29.3-60.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4818
kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.4-75.fc10,hal-0.5.12-15.20081027git.fc10
kernel-2.6.29.4-75.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5527
> kernel-2.6.29.4-75.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed ... The netbook in question was "on the road" so I could try only now. I am not sure what was supposed to happen but with kernel-2.6.29.4-75.fc10 and hal-0.5.12-15.20081027git.fc10 I can toggle from a keyboard wifi but that does not have any effect on a state of bluetooth (unless I am using my own script in /etc/acpi/actions/ which cyclyes through four states of Fn-F2 key). I did not see "irq 18: nobody cared" with an associated trace though. That does not happen always so maybe just lucky?
kernel-2.6.29.5-84.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.5-84.fc10,hal-0.5.12-15.20081027git.fc10
kernel-2.6.29.5-84.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6717
kernel-2.6.29.6-93.fc10,hal-0.5.12-15.20081027git.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-93.fc10,hal-0.5.12-15.20081027git.fc10
kernel-2.6.29.6-93.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7573
kernel-2.6.29.6-97.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-97.fc10
kernel-2.6.29.6-97.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8697
kernel-2.6.29.6-99.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kernel-2.6.29.6-99.fc10
kernel-2.6.29.6-99.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8870
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.